From avodonosov at yandex.ru Wed Nov 4 23:25:36 2009 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Thu, 5 Nov 2009 01:25:36 +0200 Subject: [xcvb-devel] Why (module... ) must be specified in every file? In-Reply-To: <653bea160910250814s2b9175d7g77e7dc0c8fd8893c@mail.gmail.com> References: <1706318373.20091025005552@yandex.ru> <653bea160910250814s2b9175d7g77e7dc0c8fd8893c@mail.gmail.com> Message-ID: <1527159587.20091105012536@yandex.ru> I have been thinking about it for several days, but still haven't understood it completely :) So maybe you may just say it's possible, but not implemented :) Best regards, - Anton on Sunday, October 25, 2009, 5:14:47 PM Far? wrote: > 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 From fahree at gmail.com Wed Nov 4 23:55:15 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Wed, 4 Nov 2009 18:55:15 -0500 Subject: [xcvb-devel] Why (module... ) must be specified in every file? In-Reply-To: <1527159587.20091105012536@yandex.ru> References: <1706318373.20091025005552@yandex.ru> <653bea160910250814s2b9175d7g77e7dc0c8fd8893c@mail.gmail.com> <1527159587.20091105012536@yandex.ru> Message-ID: <653bea160911041555r332cc27ch913a26fda17a512b@mail.gmail.com> >> Why can't module declarations be moved to a central file? [...] > > I have been thinking about it for several days, but still haven't > understood it completely :) > > So maybe you may just say it's possible, but not implemented :) > I'm sorry my explanations weren't clear enough then. Yes, it is definitely within the realm of the possible, but it requires a lot of non-trivial changes that indeed haven't been implemented yet. The demand is great though, so I will bite the bullet as soon as I have time (haha). [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The only way to have a friend is to be one. -- Ralph Waldo Emerson From geoff at wozniak.ca Thu Nov 5 11:32:35 2009 From: geoff at wozniak.ca (Geoff Wozniak) Date: Thu, 5 Nov 2009 06:32:35 -0500 Subject: [xcvb-devel] Unsetting SBCL_HOME problem on OS X Message-ID: After finally finding some time to try converting my personal projects to XCVB, I've noticed that bootstrapping XCVB is not working on my Snow Leopard install (see output below). The problem is in the call "env -u SBCL_HOME ...". The version of env shipped with Snow Leopard doesn't support the -u option. As a quick fix, I removed the line in query-target-lisp-command (in extract- target-properties.lisp) that appends the "env -u" part and I managed to bootstrap XCVB. I tried to adjust the command to run something like sh -c "unset SBCL_HOME ; /usr/local/bin/sbcl ..." but I ran into various quoting issues I'm not sure how to resolve yet. Also, I'm not sure this is the way to get around the problem. Any ideas? make xcvb xcvb make-makefile \ --build /xcvb \ --setup /xcvb/no-asdf \ --lisp-implementation sbcl \ --lisp-binary-path /usr/local/bin/sbcl env: illegal option -- u usage: env [-i] [name=value ...] [utility [argument ...]] BORK: Process ("env" "-u" "SBCL_HOME" "/usr/local/bin/sbcl" "--noinform" "-- no-userinit" "--no-sysinit" "--disable-debugger" "--eval" "(progn (format t \"(cl:setf~% xcvb::*has-cfasls* '~S~% xcvb::*target-system- features* '~S~% xcvb::*lisp-implementation-directory* '~S~% xcvb::*target-lisp-image-pathname* '~S~% xcvb::*target-lisp-executable- pathname* '~S~%)~%\" (or #+sbcl (and (find-symbol \"*EMIT-CFASL*\" \"SB-C\") t)) *features* (or #+sbcl (namestring(sb-int:sbcl-homedir- pathname)) #+ccl (namestring(ccl::ccl-directory))) (or #+clozure (namestring ccl:*HEAP-IMAGE-NAME*) #+sbcl(namestring sb-ext:*core- pathname*)) (or #+sbcl sb-ext:*runtime-pathname* #+(and clozure linux) (namestring(truename(\"/proc/self/ exe\"))) #+(and clisp linux) (read-line (run-program \"readlink \" :arguments (list (format nil \"/proc/~A/exe \" (LINUX:getpid))) :output :stream)))) (finish-output) (sb- ext:quit :unix-status 0))") exited with error code 1 0: unhandled PRINT-NOT-READABLE: # cannot be printed readably. Argh! error within --disable-debugger error handling make: *** [xcvb.mk] Error 1 -- Geoff From fahree at gmail.com Thu Nov 5 12:27:07 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Thu, 5 Nov 2009 07:27:07 -0500 Subject: [xcvb-devel] Unsetting SBCL_HOME problem on OS X In-Reply-To: References: Message-ID: <653bea160911050427l1a2ddaf3hdc81a61c6a72c642@mail.gmail.com> 2009/11/5 Geoff Wozniak : > After finally finding some time to try converting my personal projects > to XCVB, I've noticed that bootstrapping XCVB is not working on my > Snow Leopard install (see output below). > Thanks a lot for trying! > The problem is in the call "env -u SBCL_HOME ...". ?The version of env > shipped with Snow Leopard doesn't support the -u option. ?As a quick > fix, I removed the line in query-target-lisp-command (in extract- > target-properties.lisp) that appends the "env -u" part and I managed > to bootstrap XCVB. > > I tried to adjust the command to run something like > > ? sh -c "unset SBCL_HOME ; /usr/local/bin/sbcl ..." > > but I ran into various quoting issues I'm not sure how to resolve > yet. ?Also, I'm not sure this is the way to get around the problem. > Yearg. Oh, well. Try XCVB .420 from git, and see if that works for you. Instead of using env -u which seems to be a GNU extension, whichever implementation xcvb itself is using, I use sb-posix:putenv when xcvb is itself compiled with sbcl. That's nasty, but should get the thing done until I have a better solution. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "Transported to a surreal landscape, a young girl kills the first woman she meets and then teams up with three complete strangers to kill again." - TV listing for the Wizard of Oz in the Marin Independent Journal From fahree at gmail.com Mon Nov 9 10:43:43 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Mon, 9 Nov 2009 05:43:43 -0500 Subject: [xcvb-devel] XCVB .424, the antiregressive edition Message-ID: <653bea160911090243t37f4c18coaff9dfc6964d720b@mail.gmail.com> Yesterday, I released XCVB .424, which now includes a rough test suite and examples, and along the way fixed several regressions wrt converting to or from ASDF (notably a bug I introduced in ADG a while back while enabling its fine-grained instrumentation). So, the main new feature is that the old features will work more reliably, and I am now more confident that I will be able to write new features without breaking old ones. I still haven't integrated the test suite and the release process, but will come soon (I hope). As usual, git checkout and release tarball from http://common-lisp.net/project/xcvb [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The main reason Santa is so jolly is because he knows where all the bad girls live. From attila.lendvai at gmail.com Tue Nov 10 02:56:13 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 10 Nov 2009 03:56:13 +0100 Subject: [xcvb-devel] branch at dwim.hu Message-ID: dear list, i've got some changes available at: http://dwim.hu/gitweb/gitweb.cgi?p=xcvb;a=summary commit c7b9a1b87caa5e9a33a2e2dd5a9b8341f8d36644 Author: Attila Lendvai Date: Fri Oct 30 23:43:28 2009 +0100 use restarts instead of catch/throw. useful when the debugger comes up. commit 7baf59746ece254d6ffa024d088ae13e9a35ff8b Author: Attila Lendvai Date: Sat Oct 31 00:32:28 2009 +0100 when slave fails, format command line output so that it's ready for copy-pasting. fix small indenting issue. commit 294db81dddbeca025d78c64675e7850cf386c464 Author: Attila Lendvai Date: Thu Oct 29 19:22:56 2009 +0100 remove excessive #' usage in non-performance critical parts (master.lisp) to ease debugging commit 9e6cc591993ab3d327946cb182f41dbd8f9ee32f Author: Attila Lendvai Date: Thu Oct 29 19:04:26 2009 +0100 close stream from an unwind-protect. besides the obvious, it also helps when in the debugger... -- attila From fahree at gmail.com Tue Nov 10 10:35:03 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Tue, 10 Nov 2009 05:35:03 -0500 Subject: [xcvb-devel] branch at dwim.hu In-Reply-To: References: Message-ID: <653bea160911100235ka67a55dp5d549f9954c80886@mail.gmail.com> 2009/11/9 Attila Lendvai : > i've got some changes available at: > > http://dwim.hu/gitweb/gitweb.cgi?p=xcvb;a=summary > I've merged it, done some more hacking, etc., and eventually released XCVB .442. I undid your change to an error message in xcvb/master as it actually makes things worse when there are any spaces or special characters in pathnames. ~S is our friend. On the other hand, I modified xcvb/master to accept symbols as names to builds, and it will automatically case-fold them to the dominant lowercase convention, as in (xcvbm:bnl :xcvb :setup :xcvb/no-asdf :output-path "/tmp/fare/xcvb/") This will stop the bad surprises that you (and other users?) were having when assuming that keywords could usefully name builds for xcvb-master like they did for asdf. They couldn't, now they can. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of the Conservatives is to prevent the mistakes from being corrected. -- G.K. Chesterton From fahree at gmail.com Mon Nov 16 20:15:31 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Mon, 16 Nov 2009 15:15:31 -0500 Subject: [xcvb-devel] Git repositories with XCVB patches? Message-ID: <653bea160911161215r5d35a1abyd88f8ad627b4cf4@mail.gmail.com> Attila was suggesting I should open "official" git mirrors of upstream libraries with XCVB support added when upstream doesn't want it yet. Daniel was previously offering to do that in his libcl, but subject to his slow release schedule. Samium was offering to use such xcvb-enabled repos with Desire. I propose that we should create a collection of repositories on common-lisp.net or somewhere else, and pool our maintenance resources on them. Daniel can keep tagging/branching the releases he wants for libcl, while I can push my xcvb patches, and Samium offer his tool to work on the latest version, etc. I still think it would be nice if libcl and desire could share more tools, but even if they don't, I don't see why we can't at least share the git repositories. Unless you offer a better solution, I propose that you should send a mail to admin at common-lisp.net and ask to be added to the XCVB group, and we can share repositories under /project/xcvb/git/ What do you think? [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I contend we are both atheists, I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. -- Stephen F Roberts From attila.lendvai at gmail.com Mon Nov 16 22:41:59 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 16 Nov 2009 23:41:59 +0100 Subject: [xcvb-devel] Git repositories with XCVB patches? In-Reply-To: <653bea160911161215r5d35a1abyd88f8ad627b4cf4@mail.gmail.com> References: <653bea160911161215r5d35a1abyd88f8ad627b4cf4@mail.gmail.com> Message-ID: > Attila was suggesting I should open "official" git mirrors of upstream > libraries with XCVB support added when upstream doesn't want it yet. just refining the above a bit: i've never suggested anyone to use git, ever... :) this might change in the future, but i doubt, because even though my proficiency in this overtaking voodoo called git is rising, i don't seem to notice the rise of my liking of it. although, i'm all in for the shared repos, be git, darcs, or another DVCS! -- attila From fahree at gmail.com Wed Nov 18 15:41:02 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Wed, 18 Nov 2009 10:41:02 -0500 Subject: [xcvb-devel] XCVB .466, the portable edition Message-ID: <653bea160911180741v5718d9d5t22db8804728c092@mail.gmail.com> After much debugging, here is XCVB .466, that actually passes the regression test suite on all three supported implementations: SBCL, CCL, CLISP. I realized that my previous regression test suite was only actually passing with SBCL, and only when C-L-C was disabled. After a trip in CL portability hell, I emerged with an XCVB that passes all the tests on all supported Lisps. The release tarball is now only pushed to common-lisp.net if the code passes all regressions, including bootstrapping XCVB itself. That was a good pretense to procrastinate from actually implementing the standalone backend and other necessary features (exploded dependencies, etc.). Now I am now to implementing these much requested features, equipped with a test suite that will ensure I am not going to break everything else along the way, as I used to do. The TODO list has only gotten longer, notably with feedback from Stelian Ionescu on usability/deployability issues. Ouch. As usual, git checkout and release tarball from http://common-lisp.net/project/xcvb [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Democracy is a pathetic belief in the collective wisdom of individual ignorance. -- H.L. Mencken