From fahree at gmail.com Wed Oct 7 21:53:14 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Wed, 7 Oct 2009 17:53:14 -0400 Subject: [xcvb-devel] XCVB .396, now with XCVB master and slave compilation Message-ID: <653bea160910071453p73fea842ueb348f209f743e73@mail.gmail.com> One feature I added last weekend and debugged earlier this week is the xcvb-master package. See blurb below my signature from the README: http://common-lisp.net/project/xcvb/doc/README.html#interactive-update-of-a-running-image-with-xcvb-master As usual, release tarballs are below: http://common-lisp.net/projects/xcvb/releases/ Which leads me to my next question: according to you gentle readers, what are the obstacles to adoption that I should focus on? [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Love doesn't scale. -- Eric S. Raymond Interactive update of a running image with XCVB master /xcvb/master is a small standalone Lisp file. It allows you to build some Lisp software cleanly in a subprocess then load the results into the current image. When you call xcvb-master:build-and-load (which also has the short-hand xcvbm:bnl), it will use run-program to invoke a slave XCVB process that will drive all the compilation out-of-image then reply to the master with a specification of files to load. The function takes as arguments the name of a build and a flurry of options. The build specifies what you want to update; the options precisely match those of xcvb make-makefile. The slave will complete the build then reply with a list of files to load, including a TTH checksum of each file so the master can skip the files of which the very same version has already been loaded. The slave will do all the cryptographic hashing on its side, so you don't have to include crypto libraries in your image -- or anything beside the simple and short xcvb-master. By default XCVB will include the master and provide initial configuration of it in any build you make with the Makefile backend, unless you explicitly specify --no-master (which really is only useful for bootstrapping XCVB itself). Even then, you can explicitly include it in your software by specifying a dependency on /xcvb/master, though it might not be initially configured by XCVB if you compiled with the --no-master flag or with the ASDF/POIU backend. You can also include the XCVB master in an ASDF build as system xcvb-master or load it as a Lisp file from a bare image with (load "/path/to/xcvb/master/master.lisp") as an alternative to using asdf.lisp to drive further compilations. The XCVB master can advantageously replace ASDF, as it has a much smaller footprint, doesn't pollute the current process with artefacts of compilation or the compilation with the artefacts of the current process, doesn't have as many threads concurrency issues as compiling in-process can raise, and preserves determinism in the FASL files being built. Note that if you built your Lisp image using ASDF, either directly with ADSF (possibly with files from our ASDF backend), or with our current non-dependency-enforcing build, then XCVB master will basically rebuild and reload everything using our enforcing backend; but you can use the usual ASDF mechanisms to update your system as usual. If you used our non-enforcing backend, you currently have to regenerate a new image from the command-line, then use ASDF to reload the system in your current image (we hope to provide automation for that in a further version of XCVB). From fahree at gmail.com Thu Oct 8 19:28:47 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Thu, 8 Oct 2009 15:28:47 -0400 Subject: [xcvb-devel] build.xcvb's Message-ID: <653bea160910081228p7dcc9fb4q8007299ca74de8ec@mail.gmail.com> I have patches to make recentish versions of the following libraries work with xcvb. What should I do with them? Publish the patches on the xcvb site, then try to push them upstream, otherwise fork the projects and apply my patch there? alexandria babel bordeaux-threads cffi chunga cl-base64 cl-fad closer-mop cl-ppcre cl+ssl cl-unicode drakma flexi-streams hunchentoot lw-compat_0.22 md5 net-telent-date puri rfc2388 split-sequence trivial-features trivial-gray-streams trivial-ldap-0.80 usocket [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Hopefully, they ban not just gay marriage, but straight marriage too, and at last we have separation of state and marriage. From attila.lendvai at gmail.com Thu Oct 8 20:17:27 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 8 Oct 2009 22:17:27 +0200 Subject: [xcvb-devel] build.xcvb's In-Reply-To: <653bea160910081228p7dcc9fb4q8007299ca74de8ec@mail.gmail.com> References: <653bea160910081228p7dcc9fb4q8007299ca74de8ec@mail.gmail.com> Message-ID: for DVCS repos, clone the official repo to a publicly available url, record your patch, and inform the owner with a mail containing: darcs pull http://foooo i have the commit bit for the following projects, where i can push your changes: > alexandria > babel > rfc2388 (-binary only, but that's the one to use) i'm sure Luis won't mind for babel, i'm not so sure about alexandria but should also be fine, and for rfc2388-binary noone seems to care too much besides me. -- attila From _deepfire at feelingofgreen.ru Fri Oct 9 01:54:04 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Fri, 09 Oct 2009 05:54:04 +0400 (MSD) Subject: [xcvb-devel] Initial release of desire, a module transport/knowledge layer. Message-ID: <20091009.055404.513768762127109387._deepfire@feelingofgreen.ru> Good day folks, I've finally took my time to document desire and scratch off some rough edges. Let the preliminary documentation speak for itself: http://www.feelingofgreen.ru/shared/git/desire/doc/overview.txt It is also attached, for the sake of completeness. An accompanying bootstrap script: http://www.feelingofgreen.ru/shared/git/desire/climb.sh regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ---- 8< ---- Overview of desire, a software knowledge and distribution system. October 9, 2009, 05:43 0. Index 0.1 About this document 1. What is desire (supposed to be)? 2. Overview of terms 2.1 Distributors 2.2 Remotes 2.3 Modules 2.4 Systems 2.5 Applications 2.6 Localities 3. API (aka end-user interface) 3.1 Querying the knowledge base: user level 3.2 Making wishes 3.2.1 Reader macros for add-module 4. Workflow 4.1 Streamlined bootstrap 4.2 Advanced use 4.2.1 User mode 4.2.2 Wishmaster mode 4.2.3 The real truth about wishmaster and user modes 5. Shortcomings 0.1 About this document This document has a canonical location: http://www.feelingofgreen.ru/shared/git/desire/doc/overview.txt 1. What is desire (supposed to be)? The domain of desire includes software distribution points, software modules and applications. All these terms are represented internally in a detailed, comprehensive manner, and full knowledge about them is maintained in a PRINT/READ-able form, additionally being easily transportable[1] between desire nodes. There are two sides of desire[2]: - maximally streamlined software retrieval, and - redistribution. --- footnotes --- 1. Not yet, but the client mode depends on it, so at least partially it works. 2. Although, by nature of being a full-knowledge system the applications might easily go beyond that. 2. Overview of terms 2.1 Distributors The largest unit of software granularity is a 'distributor', which corresponds to an internet domain name[1]. Currently, they don't carry much information beyond just that. 'Wishmasters' represent instances of desire acting as distributors which are in business of making ordinary desire users' lives easier by repackaging modules from their respective VCS of choice into git, thereby relieving burden from the user and reducing the amount of points of failure. 2.2 Remotes Distributors contain one or more 'remotes', which combine following concepts: - version control system type (git, darcs, cvs or svn) - transport type (native, http or rsync) - simple pattern path on the distributor - an internet port number The concept of remote serves (or actually, the more general type of location does) as a point of distribution for a group of modules. 2.3 Modules Modules represent units of software, as released by the distributor, and contain the information remaining to complete the information provided by less granular concepts to construct a module address. Modules can be provided by several different remotes of different distributors. 2.4 Systems Descending further down we meet systems. Systems are objects only meant to be relevant in the domain of Common Lisp software, and more precisely -- to backend system definition facilities, such as ASDF, XCVB, Mudballs or others[2]. The concept of system introduces inter-system dependencies, which cross module boundaries, producing inter-module dependencies. Evidently, there can be several systems per module, and also those can be obscured from the end-user, either intentionally or by unfortunate accident[3]. Desire handles all these complications and operates on the full inter-module dependency graph. It also doesn't store that graph anywhere, recomputing it instead every time a request for module is performed. 2.5 Applications Applications are simple extensions of systems, providing some very preliminary support for launching applications, potentially simplifiable to the point of the end-user being able to say "launch mcclim" and have everything downloaded, required systems loaded and the application up and running as a result. 2.6 Localities The more general type of 'location' besides remotes also includes 'localities', which serve the same purpose as remotes, but on the local machine. Master localities are canonical locations for module repositories managed by a specific VCS type. The master git locality is a canonical location for module redistribution. --- footnotes --- 1. Actually, sometimes a group of domain names, like in case of sourceforge. 2. Currently, the only backend system implemented is ASDF. 3. Recovering such hidden systems complicates construction of full dependency graph in case of ASDF. 3. API (aka end-user interface) 3.1 Querying the knowledge base: user level distributor name &key (if-does-not-exist :error) => distributor remote name &key (if-does-not-exist :error) => remote module name &key (if-does-not-exist :error) => module system name &key (if-does-not-exist :error) => system app name &key (if-does-not-exist :error) => app locality name &key (if-does-not-exist :error) => locality master name &key (if-does-not-exist :error) => locality name object => symbol url remote-designator &optional module-specifier => string apropos-desr string-designator &optional set-designator => apropos-desr-list string-designator &optional set-designator => desirables list-modules => module-present-p module-designator module &optional (locality (master 'git)) check-when-present-p (check-when-missing-p t) => boolean system-loadable-p system-designator &optional (locality (master 'git)) => generalised-boolean 3.2 Making wishes init path &key as (default-wishmasters (list *default-wishmaster*)) => boolean lust &rest module-names => boolean add-module url &optional module-name &key systemlessp (system-type *default-system-type*) (lust *auto-lust*) => module 3.2.1 Reader macros for add-module Following reader macro is enabled by install-add-module-reader #@"u://r.l" #@("u://r.l" &optional module-name &key (lust *auto-lust*)) 3.x Querying the knowledge base: advanced level system-definition system repository-path &key (if-does-not-exist :error) => pathname 4. Workflow 4.1 Streamlined bootstrap To attain maximum ease, desire includes a booststrap script, whose canonical permanent location is: http://www.feelingofgreen.ru/shared/git/desire/climb.sh The first argument should be an empty, writable filesystem location. That is, the exact filename must not exist, but its parent must exist, and be writable. This location will be registered as root directory for per-VCS localities, serving to satisfy storage needs arising from user module retrieval requests. The path to the 'git/.asdf-registry/' subdirectory of this root directory should be pushed into ASDF:*CENTRAL-REGISTRY*, if ASDF is to have access to modules in the desire's pool. This script when invoked performs following operations: - use git to download modules desire depends on, placing them in /tmp, - load desire, - the most important part, cheer up the user! 4.2 Advanced use Depending on the way you intend to run desire, you issue either: (init "/path/to/root/"), for user mode or: (init "/path/to/root/" :as 'well-known-distributor), for wishmaster mode ---- Note: ---- This path provided to INIT will henceforth be referred to as $ROOT. --------------- The modes provide the end-user with a tradeoff between hassle and variety of module available. This stems from the difference between operation of wishmaster and user modes. Wishmasters use a variety of tools to access the whole set of modules retrievable using desire, but from this power comes fragility and, because wishmasters also serve the role of simplifier gateways, time consuming whatever->git repository conversion process. User mode is the chief reason for that complications, as the only thing the user needs to have is git, and boy is that fast[1]. The price, though, is relying on the set of modules available from wishmasters. 4.2.1 User mode During INIT a default wishmaster (currently 'git.feelingofgreen.ru) will be chosen, its module export set will be retrieved and that, with the notable addition of modules present in $ROOT/git/, will constitute the whole set available to the end user. Who is, then, free to use LUST, APROPOS-DESR, LIST-MODULES and other such functions listed in section 3. 4.2.2 Wishmaster mode This mode requires that the $ROOT/git/.meta/DEFINITIONS file contains a definition for the distributor your desire node will act as, and whose name you will pass using the :AS keyword to the INIT function. The INIT function: - scans for modules in the canonical export location $ROOT/git/ - checks that this set includes every module that is claimed to be "well known" to be distributed by our distributor[2], otherwise signalling an error - publishes the informations about non-"well known", converted modules - calls it a day ADD-MODULE and the accompanying reader macro #@"u://r.l/" can be used to populate the set of known modules by hand. --- footnotes --- 1. Not faster than downloading and extracting release tarballs, though. 2. This is tied to the concept of well known release locations and differs from the set of modules converted and reexported in the wishmaster process. 5. Shortcomings * SBCL-only * ASDF-only * has a non-trivial amount of CL library dependencies, half of them not exactly being common * calls out to an obscene amount of external executables, thereby only being able to guess about failure reasons * the master mode is git-centric * obviously has rough edges * this documentation sucks * the author wants sleep From _deepfire at feelingofgreen.ru Fri Oct 9 05:38:45 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Fri, 09 Oct 2009 09:38:45 +0400 (MSD) Subject: [xcvb-devel] Initial release of desire, a module transport/knowledge layer. In-Reply-To: <20091009.055404.513768762127109387._deepfire@feelingofgreen.ru> References: <20091009.055404.513768762127109387._deepfire@feelingofgreen.ru> Message-ID: <20091009.093845.423410111305003742._deepfire@feelingofgreen.ru> From: Samium Gromoff <_deepfire at feelingofgreen.ru> > > Good day folks, > > I've finally took my time to document desire and scratch off > some rough edges. > > Let the preliminary documentation speak for itself: > > http://www.feelingofgreen.ru/shared/git/desire/doc/overview.txt There were some last-minute updates to that. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From attila.lendvai at gmail.com Sat Oct 10 15:04:03 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sat, 10 Oct 2009 17:04:03 +0200 Subject: [xcvb-devel] [alexandria-devel] XCVB patch for Alexandria In-Reply-To: <653bea160910100716h42294df0tda2ddf8618f8a69e@mail.gmail.com> References: <653bea160910091140w28dfe663x981a2c67262d6263@mail.gmail.com> <653bea160910091237m223583bey77048bfee588d1a6@mail.gmail.com> <653bea160910100716h42294df0tda2ddf8618f8a69e@mail.gmail.com> Message-ID: >> wouldn't it be nicer to do it using :compile-depends-on? if i'm not >> way off, that is... >> > You can also do that. > > But if a function is used by macros, you'll save a lot by doing the > right thing, i.e. putting that function in an EVAL-WHEN. [i'm moving this discussion from alexandria-devel to xcvb-devel] ...if used by macros _in the same file_ (well, at least for 99% of current CL programmers) i'm slowly getting used to the idea of accepting these scattered eval-when's, but i'm sure you'll get into many questions from maintainers who will be reluctant to scatter the code with eval-when's. also, reading your readme and blog post on how eval-when needs to be used, i'd consider exporting an eval-always from xcvb. finally, some suggestions for the relevant part of the readme that can be copy-pasted for reluctant maintainers: "To conform with the CLHS (see section 3.2.2.3), any defun, defvar or other side-effect must be effected in the compilation environment to be available for use in macros, while compiling either the current file or any further file. This means that these effects should be enclosed in an (eval-when (:compile-toplevel :load-toplevel :execute) ...). (See on my blog a discussion of eval-when.)" i'm missing a short elaboration on why it's so different to asdf. namely that asdf first compiles a dependency and then always loads it _before_ it goes on compiling anything else that depends on this file, so with asdf the eval-when is only needed when used by a macro in the same file. asdf always follows a compile-then-load pattern when going through dependencies, while xcvb can go on a different path. "Respecting that constraint will make your programs better conformant with the standard, but will also allow for faster recompilation (where CFASLs are available), since CFASLs may be smaller and faster to load than FASLs, and subject to less variation which may trigger fewer recompilations." i would bring this paragraph above the detailed discussion on the various type of dependencies and put more pressure on why it's good for the user. the argument that that it's "more conformant" is questionable, so i would turn it into a sidenote. because the standard doesn't say a word about how you split up your program to files and what is a build tool, and what it does with them, and in which order they are processed, and how with-compilation-unit is used, etc... hth, and thanks for xcvb, looks more and more intersting! -- attila From fahree at gmail.com Sun Oct 11 03:29:21 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Sat, 10 Oct 2009 23:29:21 -0400 Subject: [xcvb-devel] [alexandria-devel] XCVB patch for Alexandria In-Reply-To: References: <653bea160910091140w28dfe663x981a2c67262d6263@mail.gmail.com> <653bea160910091237m223583bey77048bfee588d1a6@mail.gmail.com> <653bea160910100716h42294df0tda2ddf8618f8a69e@mail.gmail.com> Message-ID: <653bea160910102029x30fbca11j70629b86f20b23f5@mail.gmail.com> 2009/10/10 Attila Lendvai : > [i'm moving this discussion from alexandria-devel to xcvb-devel] > > ...if used by macros _in the same file_ (well, at least for 99% of > current CL programmers) > > i'm slowly getting used to the idea of accepting these scattered > eval-when's, but i'm sure you'll get into many questions from > maintainers who will be reluctant to scatter the code with > eval-when's. > > also, reading your readme and blog post on how eval-when needs to be > used, i'd consider exporting an eval-always from xcvb. > XCVB is not really intended to be included in other software, and so is not where such a macro belong. I have an eval-now in fare-utils. Eval-always is probably a better name. Should be exported from alexandria instead. > finally, some suggestions for the relevant part of the readme that can > be copy-pasted for reluctant maintainers: [...] I tried to take your remarks these into consideration in the latest version. > hth, and thanks for xcvb, looks more and more intersting! Thanks a lot for the comments. PS: XCVB .398, with fewer bugs and more features. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Rocky's Lemma of Innovation Prevention Unless the results are known in advance, funding agencies will reject the proposal. From _deepfire at feelingofgreen.ru Tue Oct 13 02:11:58 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Tue, 13 Oct 2009 06:11:58 +0400 (MSD) Subject: [xcvb-devel] Requirement for SB-SPROF Message-ID: <20091013.061158.1055958205020900441._deepfire@feelingofgreen.ru> Good day folks, Is the requirement for SB-SPROF being absolute? I just happened to hit its unavailability in my manually built linux/x86-64 SBCL, which, while certainly being oddball, can happen and is a small obstacle on the way. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From fahree at gmail.com Tue Oct 13 13:05:28 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Tue, 13 Oct 2009 09:05:28 -0400 Subject: [xcvb-devel] Requirement for SB-SPROF In-Reply-To: <20091013.061158.1055958205020900441._deepfire@feelingofgreen.ru> References: <20091013.061158.1055958205020900441._deepfire@feelingofgreen.ru> Message-ID: <653bea160910130605s142e9509lc69aa116aefc9898@mail.gmail.com> 2009/10/12 Samium Gromoff <_deepfire at feelingofgreen.ru>: > > Good day folks, > > Is the requirement for SB-SPROF being absolute? > > I just happened to hit its unavailability in my manually built linux/x86-64 > SBCL, which, while certainly being oddball, can happen and is a small obstacle > on the way. > Dear Samium, while I would certainly recommend that you should build the very useful sb-sprof into your sbcl, it is very possible to disable the use of sb-sprof in XCVB, that is only useful to XCVB developers anyway (i.e. me). Happily for you, references to sb-sprof are restricted to 1- xcvb.asd, and 2- profiling.lisp. You can just comment out the references to sb-sprof in xcvb.asd and profiling.lisp, and making sure the code there that is currently #+sbcl be disabled instead (e.g. in #| ... |#) and the code that is currently #-sbcl be always enabled (e.g. #| #-sbcl |#). Don't forget to also comment out the (:when (:featurep :sbcl) (:require :sb-sprof)). If you know a good test of whether the sb-sprof feature is available, I'm interested. Hope this helps, [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] There is no such thing as a "necessary evil". If it's necessary, then it cannot be evil, neither can it be good: it's a datum. From _deepfire at feelingofgreen.ru Wed Oct 14 00:36:01 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Wed, 14 Oct 2009 04:36:01 +0400 (MSD) Subject: [xcvb-devel] Requirement for SB-SPROF In-Reply-To: <653bea160910130605s142e9509lc69aa116aefc9898@mail.gmail.com> References: <20091013.061158.1055958205020900441._deepfire@feelingofgreen.ru> <653bea160910130605s142e9509lc69aa116aefc9898@mail.gmail.com> Message-ID: <20091014.043601.252220771172660406._deepfire@feelingofgreen.ru> From: Far? > while I would certainly recommend that you should build the very > useful sb-sprof into your sbcl, it is very possible to disable the use > of sb-sprof in XCVB, that is only useful to XCVB developers anyway > (i.e. me). Happily for you, references to sb-sprof are restricted to > 1- xcvb.asd, and 2- profiling.lisp. > > You can just comment out the references to sb-sprof in xcvb.asd and > profiling.lisp, and making sure the code there that is currently > #+sbcl be disabled instead (e.g. in #| ... |#) and > the code that is currently #-sbcl be always enabled (e.g. #| #-sbcl > |#). Don't forget to also comment out the (:when (:featurep :sbcl) > (:require :sb-sprof)). Yes, I'm very well aware this can be sidestepped. What I was worrying about, chiefly, was how it affects other prospective users. Upon a closer inspection I realised that I did, indeed, have sb-sprof built and properly installed, but also that two factors were at play, preventing it from being loaded: 1. SBCL_HOME was unset (the typical default), and 2. I was running a manually produced core This resulted in (sb-int:sbcl-homedir-pathname) returning a location which didn't contain the fasls for extensions. > If you know a good test of whether the sb-sprof feature is available, > I'm interested. Having polluted the list with a non-problem, I felt an obligation to offset the damage with something useful, and looked that question up. So, SB-IMPL::MODULE-PROVIDE-CONTRIB, modulo the load-the-thing part is, currently, the proper check for contrib availability on SBCL. That is: (defun module-contrib-available-p (name) "Stringify and downcase NAME, then attempt to load the file $SBCL_HOME/name/name" (let* ((filesys-name (string-downcase (string name))) (unadorned-path (merge-pathnames (make-pathname :directory (list :relative filesys-name) :name filesys-name) (truename (or (sbcl-homedir-pathname) (return-from module-provide-contrib nil))))) (fasl-path (merge-pathnames (make-pathname :type *fasl-file-type*) unadorned-path)) (lisp-path (merge-pathnames (make-pathname :type "lisp") unadorned-path))) (or (probe-file unadorned-path) (probe-file fasl-path) (probe-file lisp-path)))) regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From _deepfire at feelingofgreen.ru Thu Oct 15 22:40:45 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Fri, 16 Oct 2009 02:40:45 +0400 (MSD) Subject: [xcvb-devel] README unclear on module name case sensitivity. Message-ID: <20091016.024045.556078213007425745._deepfire@feelingofgreen.ru> Good day list, The XCVB README, specifically the "Module Full Names" appears to be unclear about case sensitivity of module names. The case insensitivity is suggested by composition with domain names, but no definitive statement seems to be there. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From _deepfire at feelingofgreen.ru Thu Oct 15 23:40:35 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Fri, 16 Oct 2009 03:40:35 +0400 (MSD) Subject: [xcvb-devel] Stale ASDF vs. asdf-dependency-grovel: adoption problem. Message-ID: <20091016.034035.479439950575807989._deepfire@feelingofgreen.ru> Dear list, As might be well-known already, the version of ASDF in current SBCL (1.0.31.32) fails to load asdf-dependency-grovel by falling into infinite recursion. If one follows the download-it-all XCVB installation suggestion, this problem isn't even encountered. However this is definitely a problem if one wants to follow a more casual way, without going to the trouble of replacing SBCL's ASDF. So, shouldn't we pester SBCL's folk to include a newer version? regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From _deepfire at feelingofgreen.ru Fri Oct 16 00:08:17 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Fri, 16 Oct 2009 04:08:17 +0400 (MSD) Subject: [xcvb-devel] Stale ASDF vs. asdf-dependency-grovel: adoption problem. In-Reply-To: <20091016.034035.479439950575807989._deepfire@feelingofgreen.ru> References: <20091016.034035.479439950575807989._deepfire@feelingofgreen.ru> Message-ID: <20091016.040817.790625714618452923._deepfire@feelingofgreen.ru> From: Samium Gromoff <_deepfire at feelingofgreen.ru> > Dear list, > > As might be well-known already, the version of ASDF in current SBCL (1.0.31.32) > fails to load asdf-dependency-grovel by falling into infinite recursion. > > If one follows the download-it-all XCVB installation suggestion, this problem > isn't even encountered. However this is definitely a problem if one wants > to follow a more casual way, without going to the trouble of replacing SBCL's > ASDF. Turns out this is more noise from me: my problem was caused by stale A-D-G. Sorry for that. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From fahree at gmail.com Fri Oct 16 00:15:12 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Thu, 15 Oct 2009 20:15:12 -0400 Subject: [xcvb-devel] Stale ASDF vs. asdf-dependency-grovel: adoption problem. In-Reply-To: <20091016.040817.790625714618452923._deepfire@feelingofgreen.ru> References: <20091016.034035.479439950575807989._deepfire@feelingofgreen.ru> <20091016.040817.790625714618452923._deepfire@feelingofgreen.ru> Message-ID: <653bea160910151715x4b904677m61ac26ec013dbaeb@mail.gmail.com> 2009/10/15 Samium Gromoff <_deepfire at feelingofgreen.ru>: > Turns out this is more noise from me: my problem was caused by stale A-D-G. > > Sorry for that. > Note that if you start from one of my recent release tarballs, you should have a ready-to-compile system with matching sets of checkouts from the correct repositories, without having to play the usual CL game of dependency hell. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Don't tread on me. -- Nemo me impune lacesset. -- Nul ne m'agresse impun?ment. From fahree at gmail.com Fri Oct 16 00:19:11 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Thu, 15 Oct 2009 20:19:11 -0400 Subject: [xcvb-devel] README unclear on module name case sensitivity. In-Reply-To: <20091016.024045.556078213007425745._deepfire@feelingofgreen.ru> References: <20091016.024045.556078213007425745._deepfire@feelingofgreen.ru> Message-ID: <653bea160910151719k373c355cnbe6df982346f7410@mail.gmail.com> 2009/10/15 Samium Gromoff <_deepfire at feelingofgreen.ru>: > The XCVB README, specifically the "Module Full Names" appears to be unclear > about case sensitivity of module names. > > The case insensitivity is suggested by composition with domain names, > but no definitive statement seems to be there. > I'm adding this sentence to that section of the README: XCVB build names are case-sensitive (unlike ASDF names) but it is strongly suggested to respect the current convention of using all lowercase names. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You can discover what your enemy fears most by observing the means he uses to frighten you. -- Eric Hoffer From _deepfire at feelingofgreen.ru Fri Oct 16 01:45:17 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Fri, 16 Oct 2009 05:45:17 +0400 (MSD) Subject: [xcvb-devel] Stale ASDF vs. asdf-dependency-grovel: adoption problem. In-Reply-To: <653bea160910151715x4b904677m61ac26ec013dbaeb@mail.gmail.com> References: <20091016.034035.479439950575807989._deepfire@feelingofgreen.ru> <20091016.040817.790625714618452923._deepfire@feelingofgreen.ru> <653bea160910151715x4b904677m61ac26ec013dbaeb@mail.gmail.com> Message-ID: <20091016.054517.885013510077421936._deepfire@feelingofgreen.ru> From: Far? > 2009/10/15 Samium Gromoff <_deepfire at feelingofgreen.ru>: >> Turns out this is more noise from me: my problem was caused by stale A-D-G. >> >> Sorry for that. >> > Note that if you start from one of my recent release tarballs, you > should have a ready-to-compile system with matching sets of checkouts > from the correct repositories, without having to play the usual CL > game of dependency hell. The thing is, I'm currently in business[1] of dealing with that dependency hell: I'm trying to provide a Desire-automated bootstrap pathway into XCVB. regards, Samium Gromoff -- 1. Well, not literally :-) _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From _deepfire at feelingofgreen.ru Tue Oct 20 06:27:28 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Tue, 20 Oct 2009 10:27:28 +0400 (MSD) Subject: [xcvb-devel] Small patch for customising XCVB build from environment. Message-ID: <20091020.102728.14212012692719032._deepfire@feelingofgreen.ru> Good day list, The attached path makes xcvb build process configurable from environment. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Alternatively available from: git://git.feelingofgreen.ru/xcvb --- 8< --- diff --git a/doc/configure.mk.example b/doc/configure.mk.example index 64c8c68..998630a 100644 --- a/doc/configure.mk.example +++ b/doc/configure.mk.example @@ -8,25 +8,25 @@ ## ## Prefix from which to deduce various default locations -PREFIX = /usr/local +PREFIX ?= /usr/local #PREFIX = /usr #PREFIX = /home/USER/.local #### Where to install executables? -INSTALL_BIN = ${PREFIX}/bin +INSTALL_BIN ?= ${PREFIX}/bin #INSTALL_BIN := /usr/bin #INSTALL_BIN := /home/USER/bin ### Where to find run-time configuration? [not currently used] -INSTALL_ETC = ${PREFIX}/etc +INSTALL_ETC ?= ${PREFIX}/etc #INSTALL_ETC := /etc #INSTALL_ETC := /home/USER/.config ### Where to put shared stuff? [Only used indirectly below] -INSTALL_SHARE = ${PREFIX}/share +INSTALL_SHARE ?= ${PREFIX}/share #INSTALL_SHARE := /usr/share #INSTALL_ETC := /home/USER/.local/share @@ -38,24 +38,24 @@ INSTALL_SHARE = ${PREFIX}/share ### Image directory for lisp images. ## Make sure the directory exists and you can write to it: ## mkdir -p ${INSTALL_IMAGE} ; chown ${USER}.${GROUP} ${INSTALL_IMAGE} -INSTALL_IMAGE = ${PREFIX}/lib/common-lisp/images +INSTALL_IMAGE ?= ${PREFIX}/lib/common-lisp/images #INSTALL_IMAGE := /usr/lib/common-lisp/images #INSTALL_IMAGE := /home/USER/.local/lib/common-lisp/images #### Where to install Lisp files? -INSTALL_LISP = ${INSTALL_SHARE}/common-lisp +INSTALL_LISP ?= ${INSTALL_SHARE}/common-lisp #INSTALL_LISP := /usr/share/common-lisp #INSTALL_LISP := /home/USER/.local/share/common-lisp ### Where to install Lisp source? -LISP_SOURCE := ${INSTALL_LISP}/source +LISP_SOURCE ?= ${INSTALL_LISP}/source ### Where to install symlinks to ASDF systems? -LISP_SYSTEMS := ${INSTALL_LISP}/systems +LISP_SYSTEMS ?= ${INSTALL_LISP}/systems #### Where to install the XCVB source, including important driver files? -INSTALL_XCVB = ${LISP_SOURCE}/xcvb +INSTALL_XCVB ?= ${LISP_SOURCE}/xcvb #### Where to find cl-launch? From fahree at gmail.com Tue Oct 20 06:35:42 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Tue, 20 Oct 2009 02:35:42 -0400 Subject: [xcvb-devel] Small patch for customising XCVB build from environment. In-Reply-To: <20091020.102728.14212012692719032._deepfire@feelingofgreen.ru> References: <20091020.102728.14212012692719032._deepfire@feelingofgreen.ru> Message-ID: <653bea160910192335w75ae392u8787f9a8249ac3a9@mail.gmail.com> Thanks, I pulled it, and pushed it upstream! [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If you don't like yourself, you *can't* like other people. -- Robert Heinlein, "Time Enough For Love" 2009/10/20 Samium Gromoff <_deepfire at feelingofgreen.ru>: > > Good day list, > > The attached path makes xcvb build process configurable from environment. > > regards, > ?Samium Gromoff > -- > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? _deepfire-at-feelingofgreen.ru > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > > Alternatively available from: > > ? ? ? ?git://git.feelingofgreen.ru/xcvb From _deepfire at feelingofgreen.ru Wed Oct 21 05:02:41 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Wed, 21 Oct 2009 09:02:41 +0400 (MSD) Subject: [xcvb-devel] Bootstrap failure: static-traversal.lisp appears to be missing. Message-ID: <20091021.090241.891968047451371264._deepfire@feelingofgreen.ru> Good day, While trying to bootstrap XCVB using ASDF, an error about missing component appears, referring to 'static-traversal'. Looking at the .asd and grepping through the source suggests that it is both a missing file and a class :-) It might be that my mistake is grabbing a non-release, non-numeric commit, though, so I'm not entirely sure this is unintended.. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From fahree at gmail.com Wed Oct 21 10:31:50 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Wed, 21 Oct 2009 06:31:50 -0400 Subject: [xcvb-devel] Bootstrap failure: static-traversal.lisp appears to be missing. In-Reply-To: <20091021.090241.891968047451371264._deepfire@feelingofgreen.ru> References: <20091021.090241.891968047451371264._deepfire@feelingofgreen.ru> Message-ID: <653bea160910210331i64ced735ub695a0b03d89056a@mail.gmail.com> 2009/10/21 Samium Gromoff <_deepfire at feelingofgreen.ru>: > While trying to bootstrap XCVB using ASDF, an error about missing component > appears, referring to 'static-traversal'. Looking at the .asd and grepping > through the source suggests that it is both a missing file and a class :-) > > It might be that my mistake is grabbing a non-release, non-numeric commit, > though, so I'm not entirely sure this is unintended.. I had a bug in adding farmer.lisp xcvb.asd (which shows that when things go well and I'm not doing surgery, I tend to not bootstrap with asdf). It has been fixed in .403. Please try again with the latest XCVB (.404 as I write this message). Note that the farmer is still far from complete, as I've been working to smooth out some bugs and limitations. In particular, the master now works fine with ASDF and REQUIRE dependencies. See for instance Exscribe as an example program that requires both XCVB and ASDF dependencies (or can still be built with ASDF only). Also individual lisp files can now override their build's :build-depends-on, which is what you want for setup files and other magic files. Name canonicalization also has been fixed, which makes the Master happier, especially since since .398 it can now load individual modules (and their dependencies) - e.g. (xcvbm:bnl "/xcvb/utilities"). An earlier notable change, in XCVB .400 was that XCVB now (re)sets the optimization settings to the configured default before loading or compiling every single file. Configuration is by side-effecting xcvb:*optimization-settings*, which should be of the form (optimize (speed 1) (debug 3) (safety 2)) or some such. This works around the fact that whether declaim and proclaim of settings stay in the same file or leak to further files is non-deterministic from one Lisp implementation to the other. XCVB is getting usable (I hope). Enjoy! [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The rule is perfect: in all matters of opinion our adversaries are insane. -- Mark Twain From _deepfire at feelingofgreen.ru Wed Oct 21 12:40:46 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Wed, 21 Oct 2009 16:40:46 +0400 (MSD) Subject: [xcvb-devel] Success for make xcvb-using-asdf, yet system load fails. Message-ID: <20091021.164046.901185575349882711._deepfire@feelingofgreen.ru> The Desire's bootstrap script climb.sh now successfully builds and installs xcvb-using-asdf. The next quirk now is loading it, as it fails to load a fasl from cache. A way to reproduce it is rather simple now: wget http://www.feelingofgreen.ru/shared/git/desire/climb.sh bash climb.sh /home//desr xcvb The backtrace: debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #: Couldn't load #P"/little/home/empty/.cache/common-lisp/sbcl-1.0.31.32-linux-x86-64/little/home/empty/desr/git/xcvb/driver.fasl": file does not exist. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [TRY-RECOMPILING] Recompile driver and try loading it again 1: [RETRY ] Retry performing # on #. 2: [ACCEPT ] Continue, treating # on # as having been successful. 3: [CONTINUE ] Ignore runtime option --eval " (progn (setf executor:*execute-explanatory* nil executor:*execute-verbosely* nil) (init \"/home/empty/desr/\" :wishmaster-branch :master) (format t \"~&~%~%~ Congratulations! You have reached a point where you can wish for any package~%~ desire knows about. Just type (lust 'desiree) and it will happen.~%~ You can link desire's pool of packages into ASDF by ensuring that~%~ #p\\\"/home/empty/desr/git/.asdf-registry/\\\" is in your ASDF:*CENTRAL-REGISTRY*~%~%~ To see what's possible, issue:~%~ (apropos-desr 'clim)~%~ or~%~ (list-modules)~%~%~ Have fun!~%~%\") (let* ((app (app 'xcvb :if-does-not-exist :continue)) (system (if app (app-system app) (system 'xcvb :if-does-not-exist :continue))) (module (if system (system-module system) (module 'xcvb :if-does-not-exist :continue)))) (when (and 'xcvb (not module)) (error \"~@\" 'xcvb)) (when module (lust (name module))) (when system (require (down-case-name system))) (when app (run app))))". 4: [ABORT ] Skip rest of --eval and --load options. 5: Skip to toplevel READ/EVAL/PRINT loop. 6: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). (LOAD #P"/little/home/empty/.cache/common-lisp/sbcl-1.0.31.32-linux-x86-64/little/home/empty/desr/git/xcvb/driver.fasl")[:EXTERNAL] 0] :ba 0: (LOAD #P"/little/home/empty/.cache/common-lisp/sbcl-1.0.31.32-linux-x86-64/little/home/empty/desr/git/xcvb/driver.fasl")[:EXTERNAL] 1: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:LOAD-OP ASDF:CL-SOURCE-FILE)) #) 2: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #) 3: ((SB-PCL::FAST-METHOD ASDF:PERFORM ASDF:AROUND (ASDF:LOAD-OP ASDF:CL-SOURCE-FILE)) #) 4: ((LAMBDA ()) #) 5: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 6: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]291)) 7: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK # #S(SB-THREAD:MUTEX :NAME "World Lock" :%OWNER # :STATE 1)) 8: (SB-C::%WITH-COMPILATION-UNIT #)[:EXTERNAL] 9: (ASDF:OPERATE #)[:EXTERNAL] 10: (ASDF::MODULE-PROVIDE-ASDF #) 11: ((LAMBDA (#:G[REQUIRE]13)) ASDF::MODULE-PROVIDE-ASDF) 12: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1 # (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB)) 13: (REQUIRE "xcvb" NIL) 14: ((LAMBDA ()) #) 15: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LET* ((APP (APP 'XCVB :IF-DOES-NOT-EXIST :CONTINUE)) (SYSTEM (IF APP (APP-SYSTEM APP) (SYSTEM 'XCVB :IF-DOES-NOT-EXIST :CONTINUE))) (MODULE (IF SYSTEM (SYSTEM-MODULE SYSTEM) (MODULE 'XCVB :IF-DOES-NOT-EXIST :CONTINUE)))) (WHEN (AND 'XCVB (NOT MODULE)) (ERROR "~@" 'XCVB)) (WHEN MODULE (LUST (NAME MODULE))) (WHEN SYSTEM (REQUIRE (DOWN-CASE-NAME SYSTEM))) (WHEN APP (RUN APP))) #) 16: (SB-INT:SIMPLE-EVAL-IN-LEXENV regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From fahree at gmail.com Wed Oct 21 18:52:25 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Wed, 21 Oct 2009 14:52:25 -0400 Subject: [xcvb-devel] Success for make xcvb-using-asdf, yet system load fails. In-Reply-To: <20091021.164046.901185575349882711._deepfire@feelingofgreen.ru> References: <20091021.164046.901185575349882711._deepfire@feelingofgreen.ru> Message-ID: <653bea160910211152y23f36df0g7b65e60f67431c92@mail.gmail.com> 2009/10/21 Samium Gromoff <_deepfire at feelingofgreen.ru>: > The Desire's bootstrap script climb.sh now successfully builds and > installs xcvb-using-asdf. The next quirk now is loading it, as it > fails to load a fasl from cache. > > A way to reproduce it is rather simple now: > > wget http://www.feelingofgreen.ru/shared/git/desire/climb.sh > bash climb.sh /home//desr xcvb > > The backtrace: > > debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #: > Couldn't load > #P"/little/home/empty/.cache/common-lisp/sbcl-1.0.31.32-linux-x86-64/little/home/empty/desr/git/xcvb/driver.fasl": > file does not exist. > It looks like there's a FASL location conflict between cl-launch and whatever other configuration of ASDF-BINARY-LOCATIONS you are using. The FASL location attempted above is typically what cl-launch would do if you don't otherwise configure it by either poking at its variables or exporting LISP_FASL_CACHE or LISP_FASL_ROOT. E.g. you can disable cl-launch caching of files with export LISP_FASL_CACHE=NIL [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Due to circumstances beyond your control, you are master of your fate and captain of your soul. From _deepfire at feelingofgreen.ru Wed Oct 21 20:58:27 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Thu, 22 Oct 2009 00:58:27 +0400 (MSD) Subject: [xcvb-devel] Success for make xcvb-using-asdf, yet system load fails. In-Reply-To: <653bea160910211152y23f36df0g7b65e60f67431c92@mail.gmail.com> References: <20091021.164046.901185575349882711._deepfire@feelingofgreen.ru> <653bea160910211152y23f36df0g7b65e60f67431c92@mail.gmail.com> Message-ID: <20091022.005827.1014985072705240787._deepfire@feelingofgreen.ru> From: Far? > 2009/10/21 Samium Gromoff <_deepfire at feelingofgreen.ru>: >> The Desire's bootstrap script climb.sh now successfully builds and >> installs xcvb-using-asdf. The next quirk now is loading it, as it >> fails to load a fasl from cache. >> >> A way to reproduce it is rather simple now: >> >> wget http://www.feelingofgreen.ru/shared/git/desire/climb.sh >> bash climb.sh /home//desr xcvb >> >> The backtrace: >> >> debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #: >> Couldn't load >> #P"/little/home/empty/.cache/common-lisp/sbcl-1.0.31.32-linux-x86-64/little/home/empty/desr/git/xcvb/driver.fasl": >> file does not exist. >> > > It looks like there's a FASL location conflict between cl-launch and > whatever other configuration of ASDF-BINARY-LOCATIONS you are using. > The FASL location attempted above is typically what cl-launch would do > if you don't otherwise configure it by either poking at its variables > or exporting LISP_FASL_CACHE or LISP_FASL_ROOT. E.g. you can disable > cl-launch caching of files with > export LISP_FASL_CACHE=NIL The thing is -- no A-B-L is in picture, it's not even there -- the only five modules installed are XCVB's direct dependencies.. Speaking of cl-launch, I specify non-standard INSTALL_SOURCE and INSTALL_BIN during its making, leaving the rest by default. Could that be the reason? regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From fahree at gmail.com Wed Oct 21 22:35:31 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Wed, 21 Oct 2009 18:35:31 -0400 Subject: [xcvb-devel] Success for make xcvb-using-asdf, yet system load fails. In-Reply-To: <20091022.005827.1014985072705240787._deepfire@feelingofgreen.ru> References: <20091021.164046.901185575349882711._deepfire@feelingofgreen.ru> <653bea160910211152y23f36df0g7b65e60f67431c92@mail.gmail.com> <20091022.005827.1014985072705240787._deepfire@feelingofgreen.ru> Message-ID: <653bea160910211535p1165d026xcbcea62918f206a3@mail.gmail.com> >>> A way to reproduce it is rather simple now: >>> >>> ?wget http://www.feelingofgreen.ru/shared/git/desire/climb.sh >>> ?bash climb.sh /home//desr xcvb >>> Works for me. Takes a while to download and compile stuff, then I have a prompt, and I can successfully (find-package :xcvb) and test functions in that package. Do you have anything (write permissions, etc.) that interfere with cl-launch's caching? I admit at home I'm using debian's sbcl the CLC installation of which overrides cl-launch. Once again, you could disable cl-launch's caching entirely with export LISP_FASL_CACHE=NIL [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Nothing takes the taste out of peanut butter quite like unrequited love. -- Charlie Brown From _deepfire at feelingofgreen.ru Thu Oct 22 05:23:47 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Thu, 22 Oct 2009 09:23:47 +0400 (MSD) Subject: [xcvb-devel] Success for make xcvb-using-asdf, yet system load fails. In-Reply-To: <653bea160910211535p1165d026xcbcea62918f206a3@mail.gmail.com> References: <653bea160910211152y23f36df0g7b65e60f67431c92@mail.gmail.com> <20091022.005827.1014985072705240787._deepfire@feelingofgreen.ru> <653bea160910211535p1165d026xcbcea62918f206a3@mail.gmail.com> Message-ID: <20091022.092347.471176527837411465._deepfire@feelingofgreen.ru> From: Far? >>>> A way to reproduce it is rather simple now: >>>> >>>> ?wget http://www.feelingofgreen.ru/shared/git/desire/climb.sh >>>> ?bash climb.sh /home//desr xcvb >>>> > Works for me. > > Takes a while to download and compile stuff, then I have a prompt, and > I can successfully > (find-package :xcvb) and test functions in that package. > > Do you have anything (write permissions, etc.) that interfere with > cl-launch's caching? I admit at home I'm using debian's sbcl the CLC > installation of which overrides cl-launch. There, I think, we have it -- I'm using a custom-built SBCL without C-L-C.. About write permissions -- I'm testing in a Specially Crafted (tm) clean user environment, with a vanilla home directory.. > Once again, you could disable cl-launch's caching entirely with > export LISP_FASL_CACHE=NIL Maybe I'll turn this on, for robustness.. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From fahree at gmail.com Fri Oct 23 02:31:33 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Thu, 22 Oct 2009 22:31:33 -0400 Subject: [xcvb-devel] build.xcvb's In-Reply-To: <653bea160910081228p7dcc9fb4q8007299ca74de8ec@mail.gmail.com> References: <653bea160910081228p7dcc9fb4q8007299ca74de8ec@mail.gmail.com> Message-ID: <653bea160910221931y364db8c3o111a85a8455a547b@mail.gmail.com> I've uploaded all these patches to http://common-lisp.net/project/xcvb/releases/patches/ and sent a copy upstream, after applying to the latest of each as installed from clbuild or else from the web, and checking that it all builds for me on SBCL (though I didn't pass any test suite). I made some changes to go with it, and released XCVB .408 that also includes the latest ASDF and ADG (now with working pathnames for static-files and files with a / in the name), plus some bug fixes. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A Libertarian Constitutional Amendment: Congress shall make no law. From fahree at gmail.com Fri Oct 23 08:19:07 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Fri, 23 Oct 2009 04:19:07 -0400 Subject: [xcvb-devel] [asdf-devel] XCVB patch for split-sequence In-Reply-To: <87fx9ak09w.fsf@freebits.de> References: <653bea160910221923i41cb1b68mfbebf9fbdf60d315@mail.gmail.com> <653bea160910221926w4b270f19mbba48319cda4fd85@mail.gmail.com> <87ljj2in72.fsf@cantab.net> <653bea160910230047r4171eeb3sa0e7030741122ab3@mail.gmail.com> <87fx9ak09w.fsf@freebits.de> Message-ID: <653bea160910230119m6d8ca6ecva66ca58a65251dd4@mail.gmail.com> 2009/10/23 Tobias C. Rittweiler : >> > > >> > > +#+xcvb (module ()) >> > > + >> > >> > This is... no. ?Please find some way of not infesting code with >> > build-related metainformation. >> > >> OK, I'll put this much-requested feature near the top of my TODO list. > > If every .lisp file has to begin with such an expression, can't you > simply introduce a file-as-module defaulting scope? > Not sure what you mean. Unlike say PLT module forms, the XCVB module form does not enclose the whole file, it's just the first form in the file, protected by a #+xcvb so you can keep compiling normally without xcvb. I need a place to specify the dependencies in a SEXP language, if possible in the file itself (so I can trivially use a Make backend), so that's the obvious solution. A non-trivial Make backend or Make-less backend is of course possible and makes it possible to have dependencies in a central file if you want. I'll be working on the standalone backend next, which will use a cache of tthsum instead of file timestamps to detect change, at which point it will be easier to have file dependency information be centralized, for those maintainers who consider dependency information as "pollution". PS: I first sent my mail to the cclan-list on sourceforge, and was surprised to receive a note redirecting me to the asdf-devel mailing-list as its successor. What about all the cclan packages that are not asdf? (are there any of them beside split-sequence?) PPS: Unless it's on-topic for cclan or asdf, please follow-up to xcvb-devel at common-lisp.net. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Classical Liberalism: the only truly subversive ideology. From attila.lendvai at gmail.com Fri Oct 23 14:09:23 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 23 Oct 2009 16:09:23 +0200 Subject: [xcvb-devel] building from the git checkout Message-ID: using a recent git head. i have cl-launch checked out with: git clone ssh://alendvai at common-lisp.net/project/xcvb/git/cl-launch.git (although the dir has no lisp files): ati at ed101:~/workspace/xcvb$ ll ../cl-launch/ total 128 -rwxr-xr-x 1 ati ebr42 112617 2009-10-23 16:05 cl-launch.sh drwxr-sr-x 2 ati ebr42 4096 2009-10-23 16:05 debian -rw-r--r-- 1 ati ebr42 983 2009-10-23 16:05 INTERNALS -rw-r--r-- 1 ati ebr42 1814 2009-10-23 16:05 Makefile the failure: ati at ed101:~/workspace/xcvb$ XCVB_PATH=~/workspace/ make xcvb make-makefile \ --build /xcvb \ --setup /xcvb/no-asdf \ --lisp-implementation sbcl \ --lisp-binary-path /usr/local/bin/sbcl BORK: Couldn't resolve "/cl-launch" to a valid module from grain "/xcvb" 0: (SB-DEBUG::MAP-BACKTRACE #) [:EXTERNAL] 1: (SB-DEBUG:BACKTRACE) [:EXTERNAL] 2: (BORK #) 3: (SIGNAL #) [:EXTERNAL] 4: (ERROR "Couldn't resolve ~S to a valid module from grain ~S") [:EXTERNAL] 5: (XCVB::LISP-GRAIN-FROM "/cl-launch" #) 6: (XCVB::NORMALIZE-DEPENDENCY-ATOM # "/cl-launch") 7: (XCVB::NORMALIZE-DEPENDENCIES ("/asdf" "/cl-launch" "/asdf-dependency-grovel" "/closer-mop" "/command-line-arguments" "/xcvb/master") # :BUILD-DEPENDS-ON) 8: (XCVB::HANDLE-LISP-DEPENDENCIES #) 9: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) # # # XCVB::DEPENDENCIES-R NIL XCVB::INCLUDED-DEPENDENCIES # XCVB::ISSUED-LOAD-COMMANDS # XCVB::LOAD-COMMANDS-R NIL)> #) 10: (WRITE-MAKEFILE "/xcvb") [:EXTERNAL] 11: (XCVB::INTERPRET-COMMAND-LINE ("--build" "/xcvb" "--setup" "/xcvb/no-asdf" "--lisp-implementation" "sbcl" "--lisp-binary-path" "/usr/local/bin/sbcl")) 12: ((LAMBDA NIL)) 13: (XCVB-DRIVER::CALL-WITH-CODED-EXIT #) 14: (XCVB::MAIN) 15: (SB-INT:SIMPLE-EVAL-IN-LEXENV (XCVB::MAIN) #) 16: (SB-FASL::LOAD-AS-SOURCE # NIL NIL) 17: ((FLET SB-FASL::LOAD-STREAM) # NIL) 18: (LOAD #) [:EXTERNAL] 19: (CL-LAUNCH::LOAD-STRING "(setf xcvb::*xcvb-lisp-directory* (pathname \"/usr/local/share/common-lisp/source/xcvb/\")) (xcvb::main)") 20: (CL-LAUNCH::DO-RESUME) 21: ((LABELS SB-IMPL::RESTART-LISP)) Couldn't resolve "/cl-launch" to a valid module from grain "/xcvb" make: *** [xcvb.mk] Error 99 any hints? -- attila From fahree at gmail.com Fri Oct 23 18:54:44 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Fri, 23 Oct 2009 14:54:44 -0400 Subject: [xcvb-devel] building from the git checkout In-Reply-To: References: Message-ID: <653bea160910231154g45f5d39p28e84b37261a4e50@mail.gmail.com> 2009/10/23 Attila Lendvai : > git clone ssh://alendvai at common-lisp.net/project/xcvb/git/cl-launch.git > > ati at ed101:~/workspace/xcvb$ XCVB_PATH=~/workspace/ make > xcvb make-makefile \ > ? ? ? ? ? ? --build /xcvb \ > ? ? ? ? ? ? --setup /xcvb/no-asdf \ > ? ? ? ? ? ? --lisp-implementation sbcl \ > ? ? ? ? ? ? --lisp-binary-path /usr/local/bin/sbcl > BORK: > Couldn't resolve "/cl-launch" to a valid module from grain "/xcvb" You need to install cl-launch first. git pull and look at cl-launch's new 00INSTALL document (extracted and expanded from comments formerly in its Makefile). Note that XCVB's release-tarball usually does that for you. Yes, installing dependencies is a pain. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Nobody expects the SPAMISH INQUISITION! From avodonosov at yandex.ru Sat Oct 24 21:55:52 2009 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Sun, 25 Oct 2009 00:55:52 +0300 Subject: [xcvb-devel] Why (module... ) must be specified in every file? Message-ID: <1706318373.20091025005552@yandex.ru> Hello, Why in XCVB (module... ) must be specified in every file? What makes it insufficient to just list the files in the build.xcvb (e.g. compiling them in the order they are listed)? Desire to parallelize the compilation (not total order, in contrast to :depends-on list in build.xcvb)? Is the (module... ) in every file optional? What will happen if I leave only :depends-on list in build.xcvb and remove all the (mudule... ) in separate files? Best regards, - Anton From fahree at gmail.com Sun Oct 25 15:14:47 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Sun, 25 Oct 2009 11:14:47 -0400 Subject: [xcvb-devel] Why (module... ) must be specified in every file? In-Reply-To: <1706318373.20091025005552@yandex.ru> References: <1706318373.20091025005552@yandex.ru> Message-ID: <653bea160910250814s2b9175d7g77e7dc0c8fd8893c@mail.gmail.com> 2009/10/24 Anton Vodonosov : > Why in XCVB (module... ) must be specified in every file? > > What makes it insufficient to just list the files in the build.xcvb > (e.g. compiling them in the order they are listed)? Desire to > parallelize the compilation (not total order, in contrast to > :depends-on list in build.xcvb)? > > Is the (module... ) in every file optional? What will happen > if I leave only :depends-on list in build.xcvb and remove all > the (mudule... ) in separate files? > That's kind of a FAQ, so I probably should answer it in the README. Here's more or less what I'll add to it... Why can't module declarations be moved to a central file? ========================================================= The reason why there needs be a module in every file is that (at least in the current version of XCVB) is that we build using Make, which uses change detection at the file resolution (using timestamps), to determine whether or not to recompile object files. The failure scenario is what happens when you modify the dependencies of a Lisp file in a way that changes its semantics (e.g. a missing macro, special-variable or package declaration, etc., may cause an error in one case, not the other). If you want reliable deterministic compilation (the goal of XCVB), then you want to recompile any time such dependency modification happens. If you put all the dependencies in a central file, then whenever the central file is modified because a new file was added or its dependencies modified, then everything will have to be recompiled. Or if you may trust modifications to the central file to not matter, and experience subtle failures. Note that recompiling based on file-contents instead of file timestamp would have the same issue. The issue is the resolution of change detection. The solution that would allow to reconcile reliable incremental compilation with a centralized dependency definition is what in the XCVB TODO file I called "Exploded File Dependencies": for the sake of detecting changes, explode the centralized dependency file into one file per Lisp module, with each per-module exploded bit containing all the dependency information about that module, and only that information. It's by no means impossible, but it's just something painful and non-trivial that hasn't shown anywhere near the top of my TODO list yet. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] There is no such thing as philosophy-free science; there is only science whose philosophical baggage is taken on board without examination. -- Daniel C. Dennett, Darwin's Dangerous Idea