From gwking at metabang.com Sun Nov 11 03:54:15 2007 From: gwking at metabang.com (Gary King) Date: Sat, 10 Nov 2007 22:54:15 -0500 Subject: [asdf-install-devel] Re: [PATCH] asdf-install: set external-format for openmcl In-Reply-To: <63870AAB-75AA-46A9-B95E-7B9E6D1A2F96@foldr.org> References: <63870AAB-75AA-46A9-B95E-7B9E6D1A2F96@foldr.org> Message-ID: <1AF57402-ED5C-4CC9-A828-C8C5B55F7383@metabang.com> Hi Michael, Thanks for this patch. I'll get it included in the common-lisp ASDF- Install distribution as soon as I can (hopefully within the next week). Regards, On Nov 5, 2007, at 4:30 AM, Michael Weber wrote: > [I read cclan-list via GMANE. If this mail doesn't make it to the > list, feel free to forward it.] > > Hi, > > cclan's asdf-install bombs in openmcl (1.1-pre-070722 DarwinX8664) > when the default character encodings are changed: it mangles data > when downloading or when writing to files, respectively. > > Patch attached. > > (@Gary Byers: > With openmcl's bundled asdf-install I get a different error, but > presumably for the same reasons, as this seems to be an older version. > > Any chance openmcl's version could be updated? I am all in favor > of reducing the number of asdf-install versions in the wild. Also, > (require :asdf-install) did not work out of the box for me, which > is the reason I downloaded cclan's asdf-install in the first place.) > > Here's the error I get with cclan's version: > > [5184]% openmcl64;;; ASDF-Install version 0.6.10 > Welcome to OpenMCL Version 1.1-pre-070722 (DarwinX8664)! > ? *default-file-character-encoding* > :UTF-8 > ? *default-socket-character-encoding* > :UTF-8 > ? (asdf-install:install :trivial-utf-8) > ;;; ASDF-INSTALL: Downloading 5920 bytes from http://common- > lisp.net/project/trivial-utf-8/trivial-utf-8.tgz to /Users/michaelw/ > asdf-install-0.asdf-install-tmp ... > > Error: value NIL is not of the expected type CHARACTER. > > While executing: CCL::%IOBLOCK-ENCODED-CHARACTER-READ-VECTOR, in > process listener(1). > > Type :POP to abort, :R for a list of available restarts. > > Type :? for other options. > 1 > (quit) > > > -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From pikdj2002 at sneakemail.com Mon Nov 12 04:27:08 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sun, 11 Nov 2007 23:27:08 -0500 Subject: [asdf-install-devel] Dealing with tar on Windows. Message-ID: <22192-57718@sneakemail.com> I work mainly on Windows these days, and I made several unsuccessful attempts at using asdf-install over the years. Works OK with Cygwin's CLISP, but I work with several different Lisps. So today I finally got around to hacking ASDF-INSTALL to simplify setup on Windows a bit. I think I've got some changes that make dealing with tar a lot easier. Basically, here's what I did: - Removed *CYGWIN-BASH-PROGRAM* and *CYGWIN-BIN-DIRECTORY* - Init *SHELL-SEARCH-PATHS* from PATH on Windows. - Fixed a bug in DIRECTORIFY. - Made *SHELL-SEARCH-PATHS* into a list of pathnames. - Adjusted FIND-SHELL-COMMAND accordingly. - Made *GNU-TAR-PROGRAM* be "tar.exe" on Windows. - Made TAR-ARGUMENTS stop treating Windows special. - Added "--force-local" to the tar arguments. My thinking is that just about anyone using Cygwin will have the Cygwin binary directories in PATH. Initializing *SHELL-SEARCH-PATHS* from PATH seems legitimate on Windows, where there's no useful notion of default paths for anything but OS components. The invocation of cygpath is not necessary if one adds --force-local to tar's options, because as a Cygwin program, it understands native paths fine. It was just misfiring on the drive prefix, thinking that you're trying to specify a remote host. Since this seems unlikely even on UNIX systems when ASDF-INSTALL invokes it, I didn't conditionalize the addition of this option. With this setup, it ought to work out of the box a lot easier for people on Windows. I am still testing. It seems to work with both LispWorks 5.0.1. Personal and Cygwin's CLISP. This change is not backwards-compatible if people were customizing with the *CYGWIN- variables. Is there any interest in such an intrusive set of changes? If so, what patch format is preferred? -- Dan Muller From gwking at metabang.com Mon Nov 12 14:29:26 2007 From: gwking at metabang.com (Gary King) Date: Mon, 12 Nov 2007 09:29:26 -0500 Subject: [asdf-install-devel] Dealing with tar on Windows. In-Reply-To: <22192-57718@sneakemail.com> References: <22192-57718@sneakemail.com> Message-ID: Hi Dan, This sounds great. I'm certainly interested in the patches and think that they'd be beneficial to Windows users. (and my apologies to previous Windows fixers whose patches didn't make it in due to my lack of time and Windows box). One question I have is whether cygwin is required for these patches to work (I'm guessing that this is the only way currently to get tar support so that the answer is no)? A darcs patch is the preferred method but diffs are OK too. thanks, On Nov 11, 2007, at 11:27 PM, Dan Muller wrote: > > I work mainly on Windows these days, and I made several unsuccessful > attempts at using asdf-install over the years. Works OK with Cygwin's > CLISP, but I work with several different Lisps. So today I finally got > around to hacking ASDF-INSTALL to simplify setup on Windows a bit. > > I think I've got some changes that make dealing with tar a lot > easier. Basically, here's what I did: > > - Removed *CYGWIN-BASH-PROGRAM* and *CYGWIN-BIN-DIRECTORY* > - Init *SHELL-SEARCH-PATHS* from PATH on Windows. > - Fixed a bug in DIRECTORIFY. > - Made *SHELL-SEARCH-PATHS* into a list of pathnames. > - Adjusted FIND-SHELL-COMMAND accordingly. > - Made *GNU-TAR-PROGRAM* be "tar.exe" on Windows. > - Made TAR-ARGUMENTS stop treating Windows special. > - Added "--force-local" to the tar arguments. > > My thinking is that just about anyone using Cygwin will have the > Cygwin binary directories in PATH. Initializing *SHELL-SEARCH-PATHS* > from PATH seems legitimate on Windows, where there's no useful notion > of default paths for anything but OS components. > > The invocation of cygpath is not necessary if one adds --force-local > to tar's options, because as a Cygwin program, it understands native > paths fine. It was just misfiring on the drive prefix, thinking that > you're trying to specify a remote host. Since this seems unlikely even > on UNIX systems when ASDF-INSTALL invokes it, I didn't conditionalize > the addition of this option. > > With this setup, it ought to work out of the box a lot easier for > people on Windows. I am still testing. It seems to work with both > LispWorks 5.0.1. Personal and Cygwin's CLISP. > > This change is not backwards-compatible if people were customizing > with the *CYGWIN- variables. > > Is there any interest in such an intrusive set of changes? If so, what > patch format is preferred? > > -- > Dan Muller > _______________________________________________ > asdf-install-devel mailing list > asdf-install-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-install-devel -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From acristin at gmail.com Mon Nov 12 17:56:52 2007 From: acristin at gmail.com (Andy Cristina) Date: Mon, 12 Nov 2007 11:56:52 -0600 Subject: [asdf-install-devel] Dealing with tar on Windows. In-Reply-To: References: <22192-57718@sneakemail.com> Message-ID: <6043bfd00711120956r27894788ofd26c2ac7e8f2e7e@mail.gmail.com> There are windows native versions of tar, so cygwin should not be required. At least one of them mostly worked a couple of years ago when the gardeners project started. On Nov 12, 2007 8:29 AM, Gary King wrote: > Hi Dan, > > This sounds great. I'm certainly interested in the patches and think > that they'd be beneficial to Windows users. (and my apologies to > previous Windows fixers whose patches didn't make it in due to my > lack of time and Windows box). > > One question I have is whether cygwin is required for these patches > to work (I'm guessing that this is the only way currently to get tar > support so that the answer is no)? > > A darcs patch is the preferred method but diffs are OK too. > > thanks, > > > On Nov 11, 2007, at 11:27 PM, Dan Muller wrote: > > > > > I work mainly on Windows these days, and I made several unsuccessful > > attempts at using asdf-install over the years. Works OK with Cygwin's > > CLISP, but I work with several different Lisps. So today I finally got > > around to hacking ASDF-INSTALL to simplify setup on Windows a bit. > > > > I think I've got some changes that make dealing with tar a lot > > easier. Basically, here's what I did: > > > > - Removed *CYGWIN-BASH-PROGRAM* and *CYGWIN-BIN-DIRECTORY* > > - Init *SHELL-SEARCH-PATHS* from PATH on Windows. > > - Fixed a bug in DIRECTORIFY. > > - Made *SHELL-SEARCH-PATHS* into a list of pathnames. > > - Adjusted FIND-SHELL-COMMAND accordingly. > > - Made *GNU-TAR-PROGRAM* be "tar.exe" on Windows. > > - Made TAR-ARGUMENTS stop treating Windows special. > > - Added "--force-local" to the tar arguments. > > > > My thinking is that just about anyone using Cygwin will have the > > Cygwin binary directories in PATH. Initializing *SHELL-SEARCH-PATHS* > > from PATH seems legitimate on Windows, where there's no useful notion > > of default paths for anything but OS components. > > > > The invocation of cygpath is not necessary if one adds --force-local > > to tar's options, because as a Cygwin program, it understands native > > paths fine. It was just misfiring on the drive prefix, thinking that > > you're trying to specify a remote host. Since this seems unlikely even > > on UNIX systems when ASDF-INSTALL invokes it, I didn't conditionalize > > the addition of this option. > > > > With this setup, it ought to work out of the box a lot easier for > > people on Windows. I am still testing. It seems to work with both > > LispWorks 5.0.1. Personal and Cygwin's CLISP. > > > > This change is not backwards-compatible if people were customizing > > with the *CYGWIN- variables. > > > > Is there any interest in such an intrusive set of changes? If so, what > > patch format is preferred? > > > > -- > > Dan Muller > > _______________________________________________ > > asdf-install-devel mailing list > > asdf-install-devel at common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-install-devel > > -- > Gary Warren King, metabang.com > Cell: (413) 559 8738 > Fax: (206) 338-4052 > gwkkwg on Skype * garethsan on AIM > > > > > > _______________________________________________ > asdf-install-devel mailing list > asdf-install-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-install-devel > From pikdj2002 at sneakemail.com Mon Nov 12 18:40:22 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Mon, 12 Nov 2007 13:40:22 -0500 Subject: [asdf-install-devel] Dealing with tar on Windows. In-Reply-To: Message-ID: <17899-32739@sneakemail.com> Thanks for feedback! On 11/12/2007, Gary King wrote: >One question I have is whether cygwin is required for these patches >to work (I'm guessing that this is the only way currently to get tar >support so that the answer is no)? With this set of changes, Cygwin is not required. Instead of assuming that Cygwin is installed in a particular place, ASDF-INSTALL will now work if there's a tar executable somewhere in the path that can handle native paths -- or whatever it is that NAMESTRING returns in the running Lisp implementation -- and the --force-local option. I assume that the --force-local option is specific to Gnu tar. Of course, the most obvious way to get a Gnu tar on Windows is still to install Cygwin. I don't know if there are other ports around these days. >A darcs patch is the preferred method but diffs are OK too. Good, I'll try to set aside time to put together a recursive diff soon, perhaps this evening. I picked up the latest tarball from Cliki before I started this work yesterday, hopefully that's an adequate basis for the diffs. I should probably offer updates to the docs, too, but I won't delay for that right now. From acristin at gmail.com Mon Nov 12 19:47:14 2007 From: acristin at gmail.com (Andy Cristina) Date: Mon, 12 Nov 2007 13:47:14 -0600 Subject: [asdf-install-devel] Dealing with tar on Windows. In-Reply-To: <17899-32739@sneakemail.com> References: <17899-32739@sneakemail.com> Message-ID: <6043bfd00711121147u579c13bcm2fd6c5a81b936e49@mail.gmail.com> My knowledge of win32 tar implementations is a bit out of date, but when I last worked on getting asdf-install to work on windows, bsd tar for win32 was the most well supported one. The various gnu tar ports all had bugs, such as an inability to use paths with spaces in the name (even escaping the spaces with a '\' didn't seem to work). Would it be worth looking into removing the gnu tar/gzip dependancy altogether in favor of a lisp solution, ala Edi Weitz' lispworks startup thing? Or is this too big a change for too little gain? On Nov 12, 2007 12:40 PM, Dan Muller wrote: > > Thanks for feedback! > > On 11/12/2007, Gary King wrote: > > >One question I have is whether cygwin is required for these patches > >to work (I'm guessing that this is the only way currently to get tar > >support so that the answer is no)? > > With this set of changes, Cygwin is not required. Instead of assuming > that Cygwin is installed in a particular place, ASDF-INSTALL will now > work if there's a tar executable somewhere in the path that can handle > native paths -- or whatever it is that NAMESTRING returns in the running > Lisp implementation -- and the --force-local option. I assume that the > --force-local option is specific to Gnu tar. > > Of course, the most obvious way to get a Gnu tar on Windows is still to > install Cygwin. I don't know if there are other ports around these days. > > >A darcs patch is the preferred method but diffs are OK too. > > Good, I'll try to set aside time to put together a recursive diff soon, > perhaps this evening. I picked up the latest tarball from Cliki before I > started this work yesterday, hopefully that's an adequate basis for the > diffs. > > I should probably offer updates to the docs, too, but I won't delay for > that right now. > > _______________________________________________ > asdf-install-devel mailing list > asdf-install-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-install-devel > From pikdj2002 at sneakemail.com Mon Nov 12 20:42:49 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Mon, 12 Nov 2007 15:42:49 -0500 Subject: [asdf-install-devel] Dealing with tar on Windows. In-Reply-To: <6043bfd00711121147u579c13bcm2fd6c5a81b936e49@mail.gmail.com> Message-ID: <22913-83135@sneakemail.com> On 11/12/2007 Andy Cristina wrote: >My knowledge of win32 tar implementations is a bit out of date, but >when I last worked on getting asdf-install to work on windows, bsd tar >for win32 was the most well supported one. The various gnu tar ports >all had bugs, such as an inability to use paths with spaces in the >name (even escaping the spaces with a '\' didn't seem to work). Hmm, that sounds all-too familiar. >Would it be worth looking into removing the gnu tar/gzip dependancy >altogether in favor of a lisp solution, ala Edi Weitz' lispworks >startup thing? Or is this too big a change for too little gain? Hard to say. I guess it depends on how onerous people consider installing Cygwin to be, since Cygwin's tar works fine. I assume you're suggesting implementing de-tar and gunzip in Common Lisp. How big a task is that? The only implementation of tar that I found in a quick Google search will currently only work on SBCL, and sounds like it might have other significant limitations, too. Decompressing a gzip file doesn't appear to be too bad. Franz has an open source implementation, although it's encumbered by the LGPL. I just glanced at it to get an idea of the overall size of the code, and it's not that big. Maybe it wouldn't be too hard to write it from scratch from the spec. http://www.cs.rice.edu/~froydnj/lisp/tar.lisp http://opensource.franz.com/deflate/index.html There *is* a hook in ASDF-INSTALL for adding functions to process the tar file. In retrospect, I could have used that to integrate my changes with more backwards compatibility. It could also be used to experiment with a native Lisp implementation. In fact, several predefined functions could be offered that the user could add to this list, to deal with different *external* implementations of tar on different platforms. Hmm. From acristin at gmail.com Mon Nov 12 21:12:18 2007 From: acristin at gmail.com (Andy Cristina) Date: Mon, 12 Nov 2007 15:12:18 -0600 Subject: [asdf-install-devel] Dealing with tar on Windows. In-Reply-To: <22913-83135@sneakemail.com> References: <6043bfd00711121147u579c13bcm2fd6c5a81b936e49@mail.gmail.com> <22913-83135@sneakemail.com> Message-ID: <6043bfd00711121312x52a4e78ar66bf787a38bfa567@mail.gmail.com> Actually, I'm suggesting ripping off Edi Weitz' lispworks program that basically does asdf-install for windows with a gui. There is a lisp implementation of tar and gzip, with specific changes to make it work with lispworks (which we could probably change to work on any lisp), and his program simply downloads asdf packages and does the windows stuff to make them all accessable (see old Bill Clementson blogs for short programs which go through a directory tree adding all directories to the asdf:central-repository, needed due to lack of symlinks). Personally, I'd prefer not using cygwin ever again, but others probably don't feel too strongly. I know that there are some win32 gnu tars that mostly work, and someone had posted on comp.lang.lisp about getting asdf-install to work with bsd tar (basically he had modified the output parsing part of asdf-install). I'll look into the tar/gzip in lisp stuff when I get some free time and do a prototype asdf-install with them, targetting sbcl on windows and linux. On Nov 12, 2007 2:42 PM, Dan Muller wrote: > > On 11/12/2007 Andy Cristina wrote: > > >My knowledge of win32 tar implementations is a bit out of date, but > >when I last worked on getting asdf-install to work on windows, bsd tar > >for win32 was the most well supported one. The various gnu tar ports > >all had bugs, such as an inability to use paths with spaces in the > >name (even escaping the spaces with a '\' didn't seem to work). > > Hmm, that sounds all-too familiar. > > >Would it be worth looking into removing the gnu tar/gzip dependancy > >altogether in favor of a lisp solution, ala Edi Weitz' lispworks > >startup thing? Or is this too big a change for too little gain? > > Hard to say. I guess it depends on how onerous people consider installing > Cygwin to be, since Cygwin's tar works fine. > > I assume you're suggesting implementing de-tar and gunzip in Common > Lisp. How big a task is that? > > The only implementation of tar that I found in a quick Google search will > currently only work on SBCL, and sounds like it might have other > significant limitations, too. > > Decompressing a gzip file doesn't appear to be too bad. Franz has an > open source implementation, although it's encumbered by the LGPL. I > just glanced at it to get an idea of the overall size of the code, and > it's not that big. Maybe it wouldn't be too hard to write it from > scratch from the spec. > > http://www.cs.rice.edu/~froydnj/lisp/tar.lisp > http://opensource.franz.com/deflate/index.html > > There *is* a hook in ASDF-INSTALL for adding functions to process the tar > file. In retrospect, I could have used that to integrate my changes with > more backwards compatibility. It could also be used to experiment with a > native Lisp implementation. In fact, several predefined functions could > be offered that the user could add to this list, to deal with different > *external* implementations of tar on different platforms. Hmm. > > _______________________________________________ > asdf-install-devel mailing list > asdf-install-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-install-devel > From pikdj2002 at sneakemail.com Mon Nov 12 23:06:37 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Mon, 12 Nov 2007 18:06:37 -0500 Subject: [asdf-install-devel] Dealing with tar on Windows. In-Reply-To: <6043bfd00711121312x52a4e78ar66bf787a38bfa567@mail.gmail.com> Message-ID: <25488-06236@sneakemail.com> On 11/12/2007, Andy Cristina wrote: >Actually, I'm suggesting ripping off Edi Weitz' lispworks program that >basically does asdf-install for windows with a gui. There is a lisp >implementation of tar and gzip, with specific changes to make it work >with lispworks (which we could probably change to work on any lisp), >and his program simply downloads asdf packages and does the windows >stuff to make them all accessable I downloaded the source for his starter-pack and took a quick look at it. The tar- and compression-handling code are not an integral part of it; they're in separate modules (archive and gzip-stream) which he doesn't advertise distinctly on his home page. I don't know if that's intention, or an oversight. The URLs for downloading them are embedded in specials.lisp. Both of those modules apparently depend on flexi-streams, according to the data in specials.lisp. I wonder how all of this gets bootstrapped... In any case, although interesting, this looks like a somewhat larger task than I want to tackle right now. > (see old Bill Clementson blogs for >short programs which go through a directory tree adding all >directories to the asdf:central-repository, needed due to lack of >symlinks). Yup, I'm familiar with these, but the technique has some shortcomings. I have an alternative method that I'd like to package up nicely. I want to add a means of overriding ASDF-INSTALL's registration and unregistration activities, so that I can offer this as an external, but easily configurable, alternative for ASDF and ASDF-INSTALL. *That* is what I'd rather work on next. >Personally, I'd prefer not using cygwin ever again, but others >probably don't feel too strongly. Probably depends on whether you're more comfortable with Unix or Windows. My professional Unix programming days are long past, but I still dabble, and like it. Cygwin quality is pretty good overall these days, and the few packages that I frequently use serve me well. I'm sure there are plenty of people that feel as you do, though, so your ideas are probably worth pursuing. As a side note, I think it's even more important that ASDF-INSTALL work well on Windows than on Unix. Linux systems have their own package management tools, and e.g. on Debian (what I run at home on one computer), a lot of CL systems are available that way. I ran into this dilemma with Perl, too: Do I install something using CPAN, or Debian's package manager? Wasn't quite sure of all the implications. Windows, on the other hand, doesn't really have anything like a package manager. Installer programs generally know little to nothing about dependencies between independently installable kits. > I know that there are some win32 >gnu tars that mostly work, and someone had posted on comp.lang.lisp >about getting asdf-install to work with bsd tar (basically he had >modified the output parsing part of asdf-install). I'll look into the >tar/gzip in lisp stuff when I get some free time and do a prototype >asdf-install with them, targetting sbcl on windows and linux. References: http://www.weitz.de/ http://common-lisp.net/project/gzip-stream/files/gzip-stream_latest.tgz http://common-lisp.net/project/gzip-stream/files/gzip-stream_latest.tgz http://www.weitz.de/flexi-streams/ (The two .tgz references come from Edi' specials.lisp in starter-pack source.) From pikdj2002 at sneakemail.com Tue Nov 13 01:54:46 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Mon, 12 Nov 2007 20:54:46 -0500 Subject: [asdf-install-devel] Patch for tar handling Message-ID: <10771-57257@sneakemail.com> OK, here's the patch I was talking about. After some of the other discussion, though, I'm thinking that I should rework it for more backwards compatibility. But if anyone actually takes the time to try it out, I'd be interested in feedback. There are some exported variables that are not documented, e.g. *TAR-EXTRACTORS*. Would those be considered fair game for changing? (I'm not sure I see the point behind having a *list* of extractors, esp. when the only one provided by ASDF-INSTALL warns when it's not applicable!) I'm thinking of reverting most of these changes, exporting and documenting a single-valued *TAR-EXTRACTOR*, and then providing an alternative extractor with my changes. Thoughts? BTW, I have the last released version of ASDF-INSTALL checked into my private SVN repository, and I used SVN to make this patch -- hence the references to "revision 141" in the patch. I don't have darcs on my Windows machine. (Did they ever get that working on Windows?) -- Dan Muller ---- Patch begins below this line --- Index: asdf-install/asdf-install/defpackage.lisp =================================================================== --- asdf-install/asdf-install/defpackage.lisp (revision 141) +++ asdf-install/asdf-install/defpackage.lisp (working copy) @@ -48,12 +48,7 @@ ;; restarts #:install-anyways - ) - - #+(or :win32 :mswindows) - (:export - #:*cygwin-bin-directory* - #:*cygwin-bash-command*)) + )) (defpackage #:asdf-install-customize (:use #:common-lisp #:asdf-install)) Index: asdf-install/asdf-install/installer.lisp =================================================================== --- asdf-install/asdf-install/installer.lisp (revision 141) +++ asdf-install/asdf-install/installer.lisp (working copy) @@ -276,28 +276,19 @@ (defun find-shell-command (command) (loop for directory in *shell-search-paths* do - (let ((target (make-pathname :name command :type nil - :directory directory))) + (let ((target (merge-pathnames (pathname command) directory))) (when (probe-file target) (return-from find-shell-command (namestring target))))) (values nil)) (defun tar-command () - #-(or :win32 :mswindows) - (find-shell-command *gnu-tar-program*) - #+(or :win32 :mswindows) - *cygwin-bash-program*) + (find-shell-command *gnu-tar-program*)) (defun tar-arguments (source packagename) - #-(or :win32 :mswindows :scl) - (list "-C" (namestring (truename source)) + #-(or :scl) + (list "--force-local" + "-C" (namestring (truename source)) "-xzvf" (namestring (truename packagename))) - #+(or :win32 :mswindows) - (list "-l" - "-c" - (format nil "\"tar -C \\\"`cygpath '~A'`\\\" -xzvf \\\"`cygpath '~A'`\\\"\"" - (namestring (truename source)) - (namestring (truename packagename)))) #+scl (list "-C" (ext:unix-namestring (truename source)) "-xzvf" (ext:unix-namestring (truename packagename)))) Index: asdf-install/asdf-install/variables.lisp =================================================================== --- asdf-install/asdf-install/variables.lisp (revision 141) +++ asdf-install/asdf-install/variables.lisp (working copy) @@ -6,9 +6,8 @@ (let ((path (pathname name))) (if (pathname-name path) (merge-pathnames - (make-pathname :directory `(:relative ,(pathname-name path)) - :name "") - path) + (make-pathname :directory `(:relative ,(pathname-name path))) + (make-pathname :host (pathname-host path) :device (pathname-device path) :directory (pathname-directory path))) path))) #+:digitool @@ -38,22 +37,27 @@ (or (get-env-var "CCLAN_MIRROR") "http://ftp.linux.org.uk/pub/lisp/cclan/")) -#+(or :win32 :mswindows) -(defvar *cygwin-bin-directory* - (pathname "C:\\PROGRA~1\\Cygwin\\bin\\")) +(defvar *shell-search-paths* -#+(or :win32 :mswindows) -(defvar *cygwin-bash-program* - "C:\\PROGRA~1\\Cygwin\\bin\\bash.exe") + #-(or :win32 :mswindows) + ;; bin first + (list (make-pathname :directory '(:absolute "bin")) + (make-pathname :directory '(:absolute "usr" "bin"))) + + ;; On Windows, there's no notion of standard paths containing other + ;; than OS components. Simply use the same path that the user does. + #+(or :win32 :mswindows) + (loop + for path = (get-env-var "PATH") then (subseq path (1+ (or (position #\; path) (1- (length path))))) + for elem = (subseq path 0 (position #\; path)) + while (plusp (length elem)) + collect (directorify elem)) + "A list of places to look for shell commands, as pathnames.") -;; bin first -(defvar *shell-search-paths* '((:absolute "bin") - (:absolute "usr" "bin")) - "A list of places to look for shell commands.") - (defvar *gnu-tar-program* - #-(or :netbsd :freebsd :solaris) "tar" + #-(or :netbsd :freebsd :solaris :win32 :mswindows) "tar" #+(or :netbsd :freebsd :solaris) "gtar" + #+(or :win32 :mswindows) "tar.exe" "Path to the GNU tar program") (eval-when (:compile-toplevel :load-toplevel :execute) From pikdj2002 at sneakemail.com Sun Nov 18 18:50:13 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sun, 18 Nov 2007 13:50:13 -0500 Subject: [asdf-install-devel] Revised patch for tar handling Message-ID: <8111-87687@sneakemail.com> This is a revised patch for more flexibility in configuring tar extraction. It supercedes the one that I offered a week ago. Unlike that one, this patch makes no changes to external behavior unless you do something like this prior to using ASDF-INSTALL: (pushnew 'asdf-install:extract-using-tar asdf-install:*tar-extractors*) Summary of changes, relative to the version of ASDF-INSTALL publically available as a tar ball: - Added exported variables *TAR-PROGRAM*, *TAR-OPTIONS*. - Renamed internal EXTRACT-USING-TAR to EXTRACT-USING-GNU-TAR. *TAR-EXTRACTORS* is initialized to a list containing this symbol. - Provided a new, exported EXTRACT-USING-TAR which uses *TAR-PROGRAM* and *TAR-OPTIONS*. - Changed internal *SHELL-SEARCH-PATHS* to a list of pathnames. On Windows, this is now initialized from the user's PATH. - Modified internal find-shell-command to match changes to *SHELL-SEARCH-PATHS*. - Fixed a problem in internal method DIRECTORIFY. (I think -- haven't tested on UNIX yet.) - Added missing load of variables.lisp to load-asdf-install.lisp. -- Dan Muller Patch starts here: Index: asdf-install/asdf-install/defpackage.lisp =================================================================== --- asdf-install/asdf-install/defpackage.lisp (revision 141) +++ asdf-install/asdf-install/defpackage.lisp (working copy) @@ -14,6 +14,8 @@ #:asdf-install-dirs #:private-asdf-install-dirs #:*tar-extractors* + #:*tar-program* + #:*tar-options* #:*shell-search-paths* #:*verify-gpg-signatures* @@ -28,6 +30,7 @@ #:uninstall #:install #:asdf-install-version + #:extract-using-tar #+(and asdf (or :win32 :mswindows)) #:sysdef-source-dir-search Index: asdf-install/asdf-install/installer.lisp =================================================================== --- asdf-install/asdf-install/installer.lisp (revision 141) +++ asdf-install/asdf-install/installer.lisp (working copy) @@ -276,8 +276,7 @@ (defun find-shell-command (command) (loop for directory in *shell-search-paths* do - (let ((target (make-pathname :name command :type nil - :directory directory))) + (let ((target (merge-pathnames (pathname command) directory))) (when (probe-file target) (return-from find-shell-command (namestring target))))) (values nil)) @@ -302,13 +301,28 @@ (list "-C" (ext:unix-namestring (truename source)) "-xzvf" (ext:unix-namestring (truename packagename)))) -(defun extract-using-tar (to-dir tarball) +;;; This is the original method of extracting tar files. It is kept +;;; for backwards compatibility. +(defun extract-using-gnu-tar (to-dir tarball) (let ((tar-command (tar-command))) (if (and tar-command (probe-file tar-command)) (return-output-from-program tar-command (tar-arguments to-dir tarball)) (warn "Cannot find tar command ~S." tar-command)))) +;;; This is a newer method for extracting tarballs. Should work for +;;; most people on any system using Gnu tar, including Cygwin, +;;; provided the program is in the path. Simply push this on +;;; ASDF-INSTALL:*TAR-EXTRACTOR* in order to use it. +(defun extract-using-tar (to-dir tarball) + (let ((tar-command (find-shell-command *tar-program*))) + (when (and tar-command (probe-file tar-command)) + (return-output-from-program + tar-command + (substitute (namestring (truename to-dir)) :OUTPUT + (substitute (namestring (truename tarball)) :INPUT + *tar-options*)))))) + (defun extract (to-dir tarball) (or (some #'(lambda (extractor) (funcall extractor to-dir tarball)) *tar-extractors*) Index: asdf-install/asdf-install/variables.lisp =================================================================== --- asdf-install/asdf-install/variables.lisp (revision 141) +++ asdf-install/asdf-install/variables.lisp (working copy) @@ -6,9 +6,8 @@ (let ((path (pathname name))) (if (pathname-name path) (merge-pathnames - (make-pathname :directory `(:relative ,(pathname-name path)) - :name "") - path) + (make-pathname :directory `(:relative ,(pathname-name path))) + (make-pathname :host (pathname-host path) :device (pathname-device path) :directory (pathname-directory path))) path))) #+:digitool @@ -46,16 +45,43 @@ (defvar *cygwin-bash-program* "C:\\PROGRA~1\\Cygwin\\bin\\bash.exe") +(defvar *shell-search-paths* + + #-(or :win32 :mswindows) ;; bin first -(defvar *shell-search-paths* '((:absolute "bin") - (:absolute "usr" "bin")) - "A list of places to look for shell commands.") + (list (make-pathname :directory '(:absolute "bin")) + (make-pathname :directory '(:absolute "usr" "bin"))) + ;; On Windows, there's no notion of standard paths containing other + ;; than OS components. Simply use the same path that the user does. + #+(or :win32 :mswindows) + (loop + for path = (get-env-var "PATH") + then (subseq path (1+ (or (position #\; path) (1- (length path))))) + for elem = (subseq path 0 (position #\; path)) + while (plusp (length elem)) + collect (directorify elem)) + "A list of places to look for shell commands, as pathnames.") + (defvar *gnu-tar-program* #-(or :netbsd :freebsd :solaris) "tar" #+(or :netbsd :freebsd :solaris) "gtar" "Path to the GNU tar program") +(defvar *tar-program* + #-(or :netbsd :freebsd :solaris :win32 :mswindows) "tar" + #+(or :netbsd :freebsd :solaris) "gtar" + #+(or :win32 :mswindows) "tar.exe" + "File name of the tar program; defaults to Gnu tar on some systems. + Used by extract-using-tar, which is not the default tar extraction method.") + +(defvar *tar-options* + '("--force-local" "-xzv" "-C" :OUTPUT "-f" :INPUT) + "Options for the tar program, as a list. The symbols :INPUT and :OUTPUT + will be replaced by the input file name and the output directory, + respectively. Used by extract-using-tar, which is not the default tar + extraction method.") + (eval-when (:compile-toplevel :load-toplevel :execute) (defparameter *supported-defsystems* (list :mk-defsystem @@ -104,7 +130,7 @@ "Personal installation"))) (defvar *tar-extractors* - '(extract-using-tar)) + '(extract-using-gnu-tar)) (defvar *systems-installed-this-time* nil "Used during installation propagation \(see *propagate-installation*\) to keep track off which systems have been installed during the current call to install.") Index: asdf-install/asdf-install/load-asdf-install.lisp =================================================================== --- asdf-install/asdf-install/load-asdf-install.lisp (revision 145) +++ asdf-install/asdf-install/load-asdf-install.lisp (working copy) @@ -69,6 +69,7 @@ (unless (find-package '#:split-sequence) (load-and-or-compile "ASDF-INSTALL-LIBRARY:split-sequence.lisp")) + (load-and-or-compile "ASDF-INSTALL-LIBRARY:variables.lisp") (load-and-or-compile "ASDF-INSTALL-LIBRARY:installer.lisp") ;; (load-and-or-compile "ASDF-INSTALL-LIBRARY:loader.lisp") From pikdj2002 at sneakemail.com Sun Nov 18 23:48:21 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sun, 18 Nov 2007 18:48:21 -0500 Subject: [asdf-install-devel] Bugs? install-package, defsystem Message-ID: <14400-76115@sneakemail.com> I've been trying to test ASDF-INSTALL using CL-BASE64, a nice, small package. I have both DEFSYSTEM 3.6i and ASDF installed. Downloading and untarring goes fine, using the patch that I offered earlier. I had problems with the internal function INSTALL-PACKAGE -- for some reason, with LispWorks Personal 5.0.1, when *DEFAULT-PATHNAME-DEFAULTS* is bound, DIRECTORY returns NIL. I changed the method to bind a local variable PATH and pass that to MAKE-PATHNAME as the default instead of binding *DEFAULT-PATHNAME-DEFAULTS*. I'm don't know why the standard global was bound, anyway, since it was also explicitly passed to MAKE-PATHNAME, but maybe it served a purpose that I don't understand, perhaps on another platform? In any case, that change got me a bit farther. Specifically, it got me as far as ASDF-INSTALL::LOAD-PACKAGE, which blows up on the call to MK:LOAD-SYSTEM. CL-BASE64 has no .system file, you see. As far as I can tell, the logic when both ASDF and DEFSYSTEM are present is kind of half-baked; ASDF-INSTALL tries to load each package using both systems, via LOAD-PACKAGE. Am I missing something here? -- Dan Muller From gwking at metabang.com Mon Nov 19 04:17:03 2007 From: gwking at metabang.com (Gary King) Date: Sun, 18 Nov 2007 23:17:03 -0500 Subject: [asdf-install-devel] Bugs? install-package, defsystem In-Reply-To: <14400-76115@sneakemail.com> References: <14400-76115@sneakemail.com> Message-ID: Hi Dan, On Nov 18, 2007, at 6:48 PM, Dan Muller wrote: > In any case, that change got me a bit farther. Specifically, it got me > as far as ASDF-INSTALL::LOAD-PACKAGE, which blows up on the call to > MK:LOAD-SYSTEM. CL-BASE64 has no .system file, you see. As far as I > can tell, the logic when both ASDF and DEFSYSTEM are present is kind > of half-baked; ASDF-INSTALL tries to load each package using both > systems, via LOAD-PACKAGE. Am I missing something here? No, you're not missing anything. ASDF's support of mk:defsystem is definitely lagging. I'm inclined to drop support for mk:defsystem for now. What's your opinion? (Others should please chime in) -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From pikdj2002 at sneakemail.com Tue Nov 20 04:43:44 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Mon, 19 Nov 2007 23:43:44 -0500 Subject: [asdf-install-devel] Bugs? install-package, defsystem In-Reply-To: (Gary King gwking-at-metabang com's message of "Sun\, 18 Nov 2007 23\:17\:03 -0500") References: <14400-76115@sneakemail.com> Message-ID: <19186-12804@sneakemail.com> Gary King writes: > On Nov 18, 2007, at 6:48 PM, Dan Muller wrote: > >> In any case, that change got me a bit farther. Specifically, it got me >> as far as ASDF-INSTALL::LOAD-PACKAGE, which blows up on the call to >> MK:LOAD-SYSTEM. CL-BASE64 has no .system file, you see. As far as I >> can tell, the logic when both ASDF and DEFSYSTEM are present is kind >> of half-baked; ASDF-INSTALL tries to load each package using both >> systems, via LOAD-PACKAGE. Am I missing something here? > > > No, you're not missing anything. ASDF's support of mk:defsystem is > definitely lagging. > > I'm inclined to drop support for mk:defsystem for now. What's your > opinion? (Others should please chime in) Even though I get to play with Lisp only part-time, I've encountered a few systems that support mk:defsystem. Personally, I'd rather clean up ASDF-INSTALL without losing any of its current features. If anything, I'm inclined to rearrange things so that it's easier to add support for additional defsystems (not that I know of any, but CL is experiencing a bit of a renaissance now), perhaps distinguishing among system files by their extensions. And even more generally, having studied the internals for two days and several evenings now, I'd like to take a crack at making a cleaner separation between the various tasks involved in ASDF-INSTALL's install functionality, making some of them much more configurable. I see them as being these: 1. acquisition 2. verification 3. unpacking to an installation location 4. identifying supported system files 5. registering system files (might or might not involve symlinks) 6. loading (once only, please) Of these, I've looked at 3, 4, and 5 quite a bit, since 3 and 5 are most problematic on Windows. The use of symlinks is deeply embedded, starting with the two-part locations that are in your face right at the beginning of the operation -- and that's unfortunate, because on Windows that's rarely going to be a good fit. Uninstalling looks problematic too, since ASDF-INSTALL doesn't remember anything about what it did during an installation. It looks like if you only have mk:defsystem installed, the sources won't be deleted. Which I guess isn't too surprising, but the code does generally seem to try to treat both defsystems as optional. I'm not sure how this could be made cleaner without keeping some record of what was done during installation, a strategy which brings its own set of problems to solve. BTW, after reading more about DARCS, I guess I should take some time out to install it and get it working. Might help me organize some of the experimental changes I'm making, which aren't always proceeding in a linear fashion. :) So, am I stepping on any toes here? Were there other plans for future ASDF-INSTALL development? Would rework of the sort described here be welcomed? My impression is that the active user base is not very large, but I think that ASDF-INSTALL can be really important to newcomers' experience of Common Lisp. -- Dan Muller From pikdj2002 at sneakemail.com Sun Nov 25 02:08:02 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sat, 24 Nov 2007 21:08:02 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff Message-ID: <23619-53795@sneakemail.com> I installed Darcs and played around with it a bit. I like. I used darcs to send some patches directly to Gary's email address -- hope that was OK. Related to some comments I made in an earlier email, I am doing some work to make the configuration of defsystems more modular. It's not a small change. :) The only intentional behavioral changes is that, when a system is defined by more than one system file, the system is loaded only once. I'm providing a way for the user to customize the priority of defsystems, so they can control which defsystem will be used in such cases. I'm also adding a way for the user to customize how system files are installed. I have a separate project that registers system files persistently without using symlinks, and this customization allows me to plug that registry into both ASDF and ASDF-INSTALL. I just figured out how to run the test suite included with ASDF-INSTALL, and now I'm trying to figure out what the two failures are that I'm getting. BTW, apropos of unit tests, there's something wrong with the LIFT documentation on its Web site; the reference information doesn't render correctly for me in either Firefox or IE. -- Dan Muller From pikdj2002 at sneakemail.com Sun Nov 25 17:19:19 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sun, 25 Nov 2007 12:19:19 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <23619-53795@sneakemail.com> (Dan Muller pikdj2002-at-sneakemail com's message of "Sat\, 24 Nov 2007 21\:08\:02 -0500") References: <23619-53795@sneakemail.com> Message-ID: <20232-96033@sneakemail.com> Dan Muller writes: > > I just figured out how to run the test suite included with > ASDF-INSTALL, and now I'm trying to figure out what the two failures > are that I'm getting. > Cool. I debugged a number of problems with the help of the unit tests. In fact, when I have time to unravel it from my other local changes, I may have a patch for Windows/Lispworks to fix argument quoting for the tar command (actually making quoting unnecessary). It looks like test TEST-1 of test suite SPACE-IN-WORKING-DIRECTORY is rarely going to succeed on Windows, because its success criterion is that the symlink file is created. Wouldn't it make more sense to assume success if the system was successfully loaded? From running the tests, I realize that this can be a bit misleading, though, since ASDF has persistent state about what systems are defined and where they are -- I suppose it's possible for it to load a system from someplace other than the test's installation location. Not sure how to address that without reaching into ASDF's internals. An ASDF:UNREGISTER-SYTEM would be welcome, similar to MK-DEFSYSTEM's. The only other test that's failing for me now is TEST-1 of DIRECT-INSTALL. Haven't started debugging that one yet. I'm running these tests using my earlier patch for tar extraction, with the alternative extractor in place. Now that I know more, I agree even more with Andy's desire to have integral gzip/tar extraction. I could publish my darcs repository so people could pull some of this stuff directly for experimentation. Any interest? That would take me a while to set up, so I won't bother if I nobody else is really working on ASDF-INSTALL and using darcs. -- Dan Muller From gwking at metabang.com Sun Nov 25 20:06:28 2007 From: gwking at metabang.com (Gary King) Date: Sun, 25 Nov 2007 15:06:28 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <23619-53795@sneakemail.com> References: <23619-53795@sneakemail.com> Message-ID: <2EEB044A-C105-408C-B8AC-D37D5AF27AA7@metabang.com> Hi Dan, My apologies for being so slow in responding to your posts. It sounds like having a lot of interesting ideas and I'm basically in favor of the general intent behind all of them! The only concern I have is making any migrations smooth and of keeping all the "stakeholders" of ASDF and ASDF-Install in the loop. In the past, there has been concern about putting too many bells and whistles into ASDF (and ASDF-Install) where "too many" seems to mean "anything that is not there already". There have been various proposals put forth about an ASDF2 (qwer or zxcv or whatever!). Here is what I think I'd like: * asdf -- stays more or less as it is * asdf-install -- stays more or less as it is * asdf2 -- a new system combining ASDF and ASDF-Install And here are some desiderata for ASDF2 * Fully backward compatible; any ASDF system can be loaded by ASDF2 * I'm still of the opinion that mk:defsystem should fade away and would be more interested in provided ASDF system defs or a compatibility layer within ASDF2 than having to support it...) * Bootstrappable - ASDF2 should be easily installed by ASDF-Install (or other usual means). Once installed, it should be able to take over system definition facilities, etc. from ASDF * Updatable - ASDF2 should be able to update itself easily and know how to check for updates, etc. Does this seem to fit in with your goals. The big problem with ASDF2 is that it's a bigger project with a uncertain "return". I think that there is room for better system definition facilities and am willing to volunteer some time towards the effort. I know that several others on this list have expressed interest in the past. Is this the time to take another crack at specifying and creating a new beast? On Nov 24, 2007, at 9:08 PM, Dan Muller wrote: > > I installed Darcs and played around with it a bit. I like. I used > darcs to send some patches directly to Gary's email address -- hope > that was OK. > > Related to some comments I made in an earlier email, I am doing some > work to make the configuration of defsystems more modular. It's not a > small change. :) The only intentional behavioral changes is that, when > a system is defined by more than one system file, the system is loaded > only once. I'm providing a way for the user to customize the priority > of defsystems, so they can control which defsystem will be used in > such cases. > > I'm also adding a way for the user to customize how system files are > installed. I have a separate project that registers system files > persistently without using symlinks, and this customization allows me > to plug that registry into both ASDF and ASDF-INSTALL. > > I just figured out how to run the test suite included with > ASDF-INSTALL, and now I'm trying to figure out what the two failures > are that I'm getting. > > BTW, apropos of unit tests, there's something wrong with the LIFT > documentation on its Web site; the reference information doesn't > render correctly for me in either Firefox or IE. > > -- > Dan Muller > _______________________________________________ > asdf-install-devel mailing list > asdf-install-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-install-devel -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From gwking at metabang.com Sun Nov 25 20:17:45 2007 From: gwking at metabang.com (Gary King) Date: Sun, 25 Nov 2007 15:17:45 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <20232-96033@sneakemail.com> References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> Message-ID: Hi Dan, (I'm cc'ing Attila because he has much more darcs foo than I do, see the last paragraph...). It sounds like you're having fun and making progress! > Cool. I debugged a number of problems with the help of the unit > tests. In fact, when I have time to unravel it from my other local > changes, I may have a patch for Windows/Lispworks to fix argument > quoting for the tar command (actually making quoting unnecessary). > > It looks like test TEST-1 of test suite SPACE-IN-WORKING-DIRECTORY is > rarely going to succeed on Windows, because its success criterion is > that the symlink file is created. Ah, good point! > ... since ASDF > has persistent state about what systems are defined and where they are > -- I suppose it's possible for it to load a system from someplace > other than the test's installation location. Not sure how to address > that without reaching into ASDF's internals. This is easy to do by manipulated ASDF's notion of where to find systems (though it's tricky to do because you need to make sure that ASDF can still find all the other systems...). Hmmm. > An ASDF:UNREGISTER-SYTEM > would be welcome, similar to MK-DEFSYSTEM's. > > The only other test that's failing for me now is TEST-1 of > DIRECT-INSTALL. Haven't started debugging that one yet. In case you don't already know, the problem is that the install command returns the name of the package installed and then tries to load that. In the usual case, the name is the name of the system; with the direct case, the name is the pathname / URL used and ASDF doesn't know how to install that. > I'm running these tests using my earlier patch for tar extraction, > with the alternative extractor in place. Great. > Now that I know more, I agree even more with Andy's desire to have > integral gzip/tar extraction. I agree. > I could publish my darcs repository so people could pull some of this > stuff directly for experimentation. Any interest? That would take me a > while to set up, so I won't bother if I nobody else is really working > on ASDF-INSTALL and using darcs. I think that It should be possible to include your patches in the darcs repository without making them the tip. If we can figure out the syntax so that folks who grab ASDF-Install will get the "plain" version while folks who want it can get it the cutting edge version, them I'm happy to host your changes (Attila, do you know the mechanics for doing this?). I'm also happy to link to your repo. Just let me know. -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From attila.lendvai at gmail.com Sun Nov 25 21:01:42 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 25 Nov 2007 22:01:42 +0100 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> Message-ID: > I think that It should be possible to include your patches in the > darcs repository without making them the tip. If we can figure out > the syntax so that folks who grab ASDF-Install will get the "plain" > version while folks who want it can get it the cutting edge version, > them I'm happy to host your changes (Attila, do you know the > mechanics for doing this?). I'm also happy to link to your repo. Just > let me know. the usual way people deal with it is to have a stable and an unstable branch. all the developers are working with the unstable branch and after test periods or someone doing their own exhaustive tests, several patches at once are pulled into the stable branch to constitute a stable state of the development. this may involve pulling patches from unstable out of order (i.e. bugfixes are pulled while some new features are not yet). playing with tags is not too good because it's hard to communicate up to which tag people should pull and getting the repo also gets the head. hth, -- attila From pikdj2002 at sneakemail.com Mon Nov 26 00:31:47 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sun, 25 Nov 2007 19:31:47 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <2EEB044A-C105-408C-B8AC-D37D5AF27AA7@metabang.com> (Gary King gwking-at-metabang com's message of "Sun\, 25 Nov 2007 15\:06\:28 -0500") References: <23619-53795@sneakemail.com> <2EEB044A-C105-408C-B8AC-D37D5AF27AA7@metabang.com> Message-ID: <1612-11387@sneakemail.com> course possible that it's colored by my personal inclinations. I wonder why a complete rewrite of either ASDF or ASDF2 is indicated. Typical good reasons for rewrites are: * A codebase that is not amenable to maintenance or extension. Usually large, poorly written, and not enough developers on hand familiar with it. (The "write two and throw the first one away" technique only works if the second is written immediately by the same programmers!) * Some major shift in underlying technology is needed due to changing environment. * The requirements have changed completely, such that most of the program needs to be replaced to accomodate them. * Just for fun. (Sometimes I love a good, pointless rewrite as much as the next hacker.) None of those really seems to apply here, as far as I understand your idea at this point, except maybe the last one. ASDF is relatively small (~1300 lines, straight wc count), ASDF-INSTALL is not much larger (~1900 lines). Lots of people have hacked both of them, and most of those folks are still accessible, I think. Common Lisp isn't changing. And most of the requirements you listed had to do with backwards compatibility, not new requirements. The biggest downside of a rewrite is the usual: It's difficult to know all the knowledge that's already embodied in the existing code. You often end up rediscovering all the same problems that the previous authors did, rediscovering workarounds as you go. (Heck, that goes for my patches, too. You should reject them if they make you nervous; I can rewrite the fixes with fewer changes, now that I understand ASDF-INSTALL better.) However, you didn't go into details as to what *new* things are wanted from ASDF, so maybe there's more justification than I'm thinking. The default choice should be to build on what's there, though. My other concern is that, to a large extent, ASDF and ASDF-INSTALL really handle different concerns. Glomming them together doesn't seem like a big win to me, except for sharing a little bit of code, and simplifying initial setup of a development environment. Now, that latter point is nothing to sneeze at, but I think it might be better to get there in stages. For instance: * Fix ASDF-INSTALL's portability and configuration difficulties. * Integrate ASDF-INSTALL with ASDF using the latter's existing extensibility features. This should be relatively easy, and would allow people to find out if it really makes sense to combine them. * Make ASDF-INSTALL able to understand the concept of "updating". Apply it to itself. Then it will be ready to try updating ASDF, or any other library for that matter. * Make ASDF-INSTALL itself even easier to install. Ideally a single-file download, like ASDF! * At that point, consider the benefits of combining the projects. (But note that some people will never really want that integration, because there *are* alternatives to ASDF-INSTALL that make more sense in some environments.) At the very least, keeping a clean separation between build system issues and installation issues, even if that separation were internal to an ASDF2, would be good policy, since many of the issues are distinct, don't you think? ASDF already has moderately good mechanisms for this: system definition search functions, and extensibility that is often used for things like stowing FASLs in separate directories, and rebuilding stale fasls. The latter extensions seem so common that they ought to incorporated into ASDF; that's a good example of incremental improvement. OK, I worked pretty hard on my reply up to this point. Now let me throw out some more stuff quickly to answer other questions you raised, both explicitly and implicitly, so I can finally send this. Regarding MK-DEFSYSTEM, it is my understanding that it has features which ASDF still hasn't replicated, it has some continuing adherents, and its author does not consider it a dead project. (I could be wrong on some of these.) In any case, accomodating it is not hard, and doing so encourages that clean separation that I discussed earlier. The changes to ASDF-INSTALL that I have (the ones you haven't seen yet) are not minor, but neither are they drastic. They separate defsystem-specifics more cleanly from the rest of what ASDF-INSTALL does. > In the past, there has been concern about putting too many bells and > whistles into ASDF (and ASDF-Install) where "too many" seems to mean > "anything that is not there already". IMO, making things easier for newcomers should take precedence over disgruntling current users; there are a lot of new people coming to Lisp, and my impression is that few of them end up using ASDF-INSTALL because of its current limitations on Windows. If an incompatible change is necessary, document it well and provide whatever is needed to make it easy to adapt to it. If someone hates it, they don't have to upgrade, or they can even fork. Someone already decided that ASDF-INSTALL is supposed to support Windows, and it doesn't do that well. We either undo that decision, or do what it takes to make it really support Windows. (Similar argument for MK-DEFSYSTEM; in both cases I'm advocating preserving the decisions.) > ... The only concern I have is > making any migrations smooth and of keeping all the "stakeholders" of > ASDF and ASDF-Install in the loop. Avoiding unintended breakage *is* important, though. I think your test setup is a great step in the right direction, and wish I'd checked it out earlier. But can we set things up so that candidate changes can be easily tested on a wide variety of platforms? How many environments (OSes, CL implementations) do you currently have the ability to test on yourself? (BTW, you didn't comment on the unit test that's broken for Windows.) As to bootstrap-friendliness: One thing that ASDF has going for it, and ASDF-INSTALL does not, is that the former is a single file. Incorporating ASDF-INSTALL directly into ASDF would more than double the latter's size, even if you assumed some economy of shared code arising from the merger. Instead of going this route, it would seem preferable to (if possible) simplify ASDF-INSTALL's internals, gradually getting it down to where it can also be presented as a single file. The eventual goal would be that, instead of people being told to download and load ASDF as one of the first steps in setting up an environment, they'd be told to do the same thing with ASDF-INSTALL first, and then use it to install ASDF! ASDF-INSTALL doesn't actually have to depend on *any* defsystem to do non-recursive *installation* of a library into site-dependent locations. OK, that's kind of out there, and would *really* beg a rename for ASDF-INSTALL. :) > ... I think that > there is room for better system definition facilities and am willing > to volunteer some time towards the effort. I know that several others > on this list have expressed interest in the past. Is this the time to > take another crack at specifying and creating a new beast? I'm totally into talking about what would be desired from an ASDF2, BTW, although I'll always look at the ideas and consider whether they could be realized in the current systems. Can you point me to earlier discussions on this topic? Haven't found too much on my own so far. -- Dan Muller From pikdj2002 at sneakemail.com Mon Nov 26 00:36:27 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sun, 25 Nov 2007 19:36:27 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <2EEB044A-C105-408C-B8AC-D37D5AF27AA7@metabang.com> (Gary King gwking-at-metabang com's message of "Sun\, 25 Nov 2007 15\:06\:28 -0500") References: <23619-53795@sneakemail.com> <2EEB044A-C105-408C-B8AC-D37D5AF27AA7@metabang.com> Message-ID: <26185-49032@sneakemail.com> Let me try that again, I was having some problems with my mail client ... please disregard the truncated version of this that I just sent. Gary King writes: > My apologies for being so slow in responding to your posts. Thanks for the reply! Your email raises lots of thoughts. And although I like quick responses (who doesn't?), I'm sure this is a sideline for all of us. I just happened to have a lot of free time this weekend. If I'm understanding correctly, you're talking about ASDF2 as a from-the-ground-up rewrite of ASDF and ASDF-INSTALL. To answer one of your last questions first: Personally, that sounds like a larger project that I was looking for. My Lisp programming usually occurs in short but intense bursts, and I have another, much larger project still pending. (And a day job that has, sadly, nothing to do with Lisp, and often consumes more than its share of my time.) OTOH, build systems have always interested me, so I wouldn't entirely turn my back on such a project. The rest of my reply aims to be more objective, although it's of course possible that it's colored by my personal inclinations. I wonder why a complete rewrite of either ASDF or ASDF2 is indicated. Typical good reasons for rewrites are: * A codebase that is not amenable to maintenance or extension. Usually large, poorly written, and not enough developers on hand familiar with it. (The "write two and throw the first one away" technique only works if the second is written immediately by the same programmers!) * Some major shift in underlying technology is needed due to changing environment. * The requirements have changed completely, such that most of the program needs to be replaced to accomodate them. * Just for fun. (Sometimes I love a good, pointless rewrite as much as the next hacker.) None of those really seems to apply here, as far as I understand your idea at this point, except maybe the last one. ASDF is relatively small (~1300 lines, straight wc count), ASDF-INSTALL is not much larger (~1900 lines). Lots of people have hacked both of them, and most of those folks are still accessible, I think. Common Lisp isn't changing. And most of the requirements you listed had to do with backwards compatibility, not new requirements. The biggest downside of a rewrite is the usual: It's difficult to know all the knowledge that's already embodied in the existing code. You often end up rediscovering all the same problems that the previous authors did, rediscovering workarounds as you go. (Heck, that goes for my patches, too. You should reject them if they make you nervous; I can rewrite the fixes with fewer changes, now that I understand ASDF-INSTALL better.) However, you didn't go into details as to what *new* things are wanted from ASDF, so maybe there's more justification than I'm thinking. The default choice should be to build on what's there, though. My other concern is that, to a large extent, ASDF and ASDF-INSTALL really handle different concerns. Glomming them together doesn't seem like a big win to me, except for sharing a little bit of code, and simplifying initial setup of a development environment. Now, that latter point is nothing to sneeze at, but I think it might be better to get there in stages. For instance: * Fix ASDF-INSTALL's portability and configuration difficulties. * Integrate ASDF-INSTALL with ASDF using the latter's existing extensibility features. This should be relatively easy, and would allow people to find out if it really makes sense to combine them. * Make ASDF-INSTALL able to understand the concept of "updating". Apply it to itself. Then it will be ready to try updating ASDF, or any other library for that matter. * Make ASDF-INSTALL itself even easier to install. Ideally a single-file download, like ASDF! * At that point, consider the benefits of combining the projects. (But note that some people will never really want that integration, because there *are* alternatives to ASDF-INSTALL that make more sense in some environments.) At the very least, keeping a clean separation between build system issues and installation issues, even if that separation were internal to an ASDF2, would be good policy, since many of the issues are distinct, don't you think? ASDF already has moderately good mechanisms for this: system definition search functions, and extensibility that is often used for things like stowing FASLs in separate directories, and rebuilding stale fasls. The latter extensions seem so common that they ought to incorporated into ASDF; that's a good example of incremental improvement. OK, I worked pretty hard on my reply up to this point. Now let me throw out some more stuff quickly to answer other questions you raised, both explicitly and implicitly, so I can finally send this. Regarding MK-DEFSYSTEM, it is my understanding that it has features which ASDF still hasn't replicated, it has some continuing adherents, and its author does not consider it a dead project. (I could be wrong on some of these.) In any case, accomodating it is not hard, and doing so encourages that clean separation that I discussed earlier. The changes to ASDF-INSTALL that I have (the ones you haven't seen yet) are not minor, but neither are they drastic. They separate defsystem-specifics more cleanly from the rest of what ASDF-INSTALL does. > In the past, there has been concern about putting too many bells and > whistles into ASDF (and ASDF-Install) where "too many" seems to mean > "anything that is not there already". IMO, making things easier for newcomers should take precedence over disgruntling current users; there are a lot of new people coming to Lisp, and my impression is that few of them end up using ASDF-INSTALL because of its current limitations on Windows. If an incompatible change is necessary, document it well and provide whatever is needed to make it easy to adapt to it. If someone hates it, they don't have to upgrade, or they can even fork. Someone already decided that ASDF-INSTALL is supposed to support Windows, and it doesn't do that well. We either undo that decision, or do what it takes to make it really support Windows. (Similar argument for MK-DEFSYSTEM; in both cases I'm advocating preserving the decisions.) > ... The only concern I have is > making any migrations smooth and of keeping all the "stakeholders" of > ASDF and ASDF-Install in the loop. Avoiding unintended breakage *is* important, though. I think your test setup is a great step in the right direction, and wish I'd checked it out earlier. But can we set things up so that candidate changes can be easily tested on a wide variety of platforms? How many environments (OSes, CL implementations) do you currently have the ability to test on yourself? (BTW, you didn't comment on the unit test that's broken for Windows.) As to bootstrap-friendliness: One thing that ASDF has going for it, and ASDF-INSTALL does not, is that the former is a single file. Incorporating ASDF-INSTALL directly into ASDF would more than double the latter's size, even if you assumed some economy of shared code arising from the merger. Instead of going this route, it would seem preferable to (if possible) simplify ASDF-INSTALL's internals, gradually getting it down to where it can also be presented as a single file. The eventual goal would be that, instead of people being told to download and load ASDF as one of the first steps in setting up an environment, they'd be told to do the same thing with ASDF-INSTALL first, and then use it to install ASDF! ASDF-INSTALL doesn't actually have to depend on *any* defsystem to do non-recursive *installation* of a library into site-dependent locations. OK, that's kind of out there, and would *really* beg a rename for ASDF-INSTALL. :) > ... I think that > there is room for better system definition facilities and am willing > to volunteer some time towards the effort. I know that several others > on this list have expressed interest in the past. Is this the time to > take another crack at specifying and creating a new beast? I'm totally into talking about what would be desired from an ASDF2, BTW, although I'll always look at the ideas and consider whether they could be realized in the current systems. Can you point me to earlier discussions on this topic? Haven't found too much on my own so far. -- Dan Muller From pikdj2002 at sneakemail.com Mon Nov 26 00:38:43 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sun, 25 Nov 2007 19:38:43 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: (Attila Lendvai attila lendvai-at-gmail com's message of "Sun\, 25 Nov 2007 22\:01\:42 +0100") References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> Message-ID: <20099-37291@sneakemail.com> Attila Lendvai wrote: >> Gary King wrote: >> I think that It should be possible to include your patches in the >> darcs repository without making them the tip. If we can figure out >> the syntax so that folks who grab ASDF-Install will get the "plain" >> version while folks who want it can get it the cutting edge version, >> them I'm happy to host your changes (Attila, do you know the >> mechanics for doing this?). I'm also happy to link to your repo. Just >> let me know. > > the usual way people deal with it is to have a stable and an unstable > branch. all the developers are working with the unstable branch and > after test periods or someone doing their own exhaustive tests, > several patches at once are pulled into the stable branch to > constitute a stable state of the development. this may involve pulling > patches from unstable out of order (i.e. bugfixes are pulled while > some new features are not yet). > > playing with tags is not too good because it's hard to communicate up > to which tag people should pull and getting the repo also gets the > head. > Yes, that is my understanding too, after reading about Darcs this weekend. Where "branch" means an entirely separate copy of the repository. In fact, I think that for Linux kernel devleopment (using Git, similar to Darcs), Linus has a separate, publically-visible repository for every major contributor, from which he cherry-picks the patches that he chooses. -- Dan Muller From pikdj2002 at sneakemail.com Mon Nov 26 00:39:51 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sun, 25 Nov 2007 19:39:51 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: (Gary King gwking-at-metabang com's message of "Sun\, 25 Nov 2007 15\:17\:45 -0500") References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> Message-ID: <4760-62853@sneakemail.com> Gary King writes: > >> ... since ASDF >> has persistent state about what systems are defined and where they are >> -- I suppose it's possible for it to load a system from someplace >> other than the test's installation location. Not sure how to address >> that without reaching into ASDF's internals. > > This is easy to do by manipulated ASDF's notion of where to find > systems (though it's tricky to do because you need to make sure that > ASDF can still find all the other systems...). Hmmm. Actually, once the unit tests are running, I don't think it really needs to find anything other than what the test is installing? I think that the problem I ran into was, due to trying to duplicate the failed test's actions outside of the test environment. ASDF remembered the subsystems it had installed for the tests, in *DEFINED-SYSTEMS* or something like that, but the file locations it had recorded for them only existed during the test! >> The only other test that's failing for me now is TEST-1 of >> DIRECT-INSTALL. Haven't started debugging that one yet. > > In case you don't already know, the problem is that the install > command returns the name of the package installed and then tries to > load that. In the usual case, the name is the name of the system; > with the direct case, the name is the pathname / URL used and ASDF > doesn't know how to install that. Yeah, I remember noting something odd about that in the code. I'll look at that some more. So are you saying this is generally broken? I ended up trying to run the tests with the plain vanilla released system, but am having some trouble with that, too. Still working on that. Due to this effort, I suggest that you toss out all the patches I offered you so far; I'm going to redo my tar extraction fixes with a more minimal and (I hope) more robust set of changes, hopefully as a set of patches that allows a plain vanilla installation (following the instructions in the public tutorial) to pass the unit tests on Windows. > >> I'm running these tests using my earlier patch for tar extraction, >> with the alternative extractor in place. > > Great. Except, see above. :) -- Dan Muller From pikdj2002 at sneakemail.com Mon Nov 26 01:50:46 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Sun, 25 Nov 2007 20:50:46 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: (Gary King gwking-at-metabang com's message of "Sun\, 25 Nov 2007 15\:17\:45 -0500") References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> Message-ID: <12190-02752@sneakemail.com> Gary King writes: >> It looks like test TEST-1 of test suite SPACE-IN-WORKING-DIRECTORY is >> rarely going to succeed on Windows, because its success criterion is >> that the symlink file is created. > > Ah, good point! > BTW, a related question, the answer to which might save me some time: Has anyone to your knowledge successfully run the entire, or even most of, the test suite on Windows? I'm thinking "not", as I'm looking at this. Unless it was with Cygwin CLisp. -- Dan Muller From attila.lendvai at gmail.com Mon Nov 26 10:24:44 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 26 Nov 2007 11:24:44 +0100 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <1612-11387@sneakemail.com> References: <23619-53795@sneakemail.com> <2EEB044A-C105-408C-B8AC-D37D5AF27AA7@metabang.com> <1612-11387@sneakemail.com> Message-ID: > * Make ASDF-INSTALL able to understand the concept of > "updating". Apply it to itself. Then it will be ready to try > updating ASDF, or any other library for that matter. > > * Make ASDF-INSTALL itself even easier to install. Ideally a > single-file download, like ASDF! > > * At that point, consider the benefits of combining the projects. (But > note that some people will never really want that integration, > because there *are* alternatives to ASDF-INSTALL that make more > sense in some environments.) it's also a bootstrapping issue: it's about bootstrapping a new lisp environment where the functionality of both asdf and asdf-install are vital at the same time. looking at it from this POV it's better to have it in a single lib/project that has a single install howto. just some 0.02, -- attila From gwking at metabang.com Mon Nov 26 14:10:43 2007 From: gwking at metabang.com (Gary King) Date: Mon, 26 Nov 2007 09:10:43 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <12190-02752@sneakemail.com> References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> <12190-02752@sneakemail.com> Message-ID: <28D544DA-29A3-4A94-AFD0-324E31190942@metabang.com> Hi Dan, > BTW, a related question, the answer to which might save me some time: > Has anyone to your knowledge successfully run the entire, or even most > of, the test suite on Windows? I'm thinking "not", as I'm looking at > this. Unless it was with Cygwin CLisp. Not that I'm aware of... -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From 367znud02 at sneakemail.com Mon Nov 26 00:04:04 2007 From: 367znud02 at sneakemail.com (Dan Muller) Date: Sun, 25 Nov 2007 19:04:04 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <2EEB044A-C105-408C-B8AC-D37D5AF27AA7@metabang.com> (Gary King gwking-at-metabang com's message of "Sun\, 25 Nov 2007 15\:06\:28 -0500") References: <23619-53795@sneakemail.com> <2EEB044A-C105-408C-B8AC-D37D5AF27AA7@metabang.com> Message-ID: Gary King writes: > My apologies for being so slow in responding to your posts. Thanks for the reply! Your email raises lots of thoughts. And although I like quick responses (who doesn't?), I'm sure this is a sideline for all of us. I just happened to have a lot of free time this weekend. If I'm understanding correctly, you're talking about ASDF2 as a from-the-ground-up rewrite of ASDF and ASDF-INSTALL. To answer one of your last questions first: Personally, that sounds like a larger project that I was looking for. My Lisp programming usually occurs in short but intense bursts, and I have another, much larger project still pending. (And a day job that has, sadly, nothing to do with Lisp, and often consumes more than its share of my time.) OTOH, build systems have always interested me, so I wouldn't entirely turn my back on such a project. The rest of my reply aims to be more objective, although it's of course possible that it's colored by my personal inclinations. I wonder why a complete rewrite of either ASDF or ASDF2 is indicated. Typical good reasons for rewrites are: * A codebase that is not amenable to maintenance or extension. Usually large, poorly written, and not enough developers on hand familiar with it. (The "write two and throw the first one away" technique only works if the second is written immediately by the same programmers!) * Some major shift in underlying technology is needed due to changing environment. * The requirements have changed completely, such that most of the program needs to be replaced to accomodate them. * Just for fun. (Sometimes I love a good, pointless rewrite as much as the next hacker.) None of those really seems to apply here, as far as I understand your idea at this point, except maybe the last one. ASDF is relatively small (~1300 lines, straight wc count), ASDF-INSTALL is not much larger (~1900 lines). Lots of people have hacked both of them, and most of those folks are still accessible, I think. Common Lisp isn't changing. And most of the requirements you listed had to do with backwards compatibility, not new requirements. The biggest downside of a rewrite is the usual: It's difficult to know all the knowledge that's already embodied in the existing code. You often end up rediscovering all the same problems that the previous authors did, rediscovering workarounds as you go. (Heck, that goes for my patches, too. You should reject them if they make you nervous; I can rewrite the fixes with fewer changes, now that I understand ASDF-INSTALL better.) However, you didn't go into details as to what *new* things are wanted from ASDF, so maybe there's more justification than I'm thinking. The default choice should be to build on what's there, though. My other concern is that, to a large extent, ASDF and ASDF-INSTALL really handle different concerns. Glomming them together doesn't seem like a big win to me, except for sharing a little bit of code, and simplifying initial setup of a development environment. Now, that latter point is nothing to sneeze at, but I think it might be better to get there in stages. For instance: * Fix ASDF-INSTALL's portability and configuration difficulties. * Integrate ASDF-INSTALL with ASDF using the latter's existing extensibility features. This should be relatively easy, and would allow people to find out if it really makes sense to combine them. * Make ASDF-INSTALL able to understand the concept of "updating". Apply it to itself. Then it will be ready to try updating ASDF, or any other library for that matter. * Make ASDF-INSTALL itself even easier to install. Ideally a single-file download, like ASDF! * At that point, consider the benefits of combining the projects. (But note that some people will never really want that integration, because there *are* alternatives to ASDF-INSTALL that make more sense in some environments.) At the very least, keeping a clean separation between build system issues and installation issues, even if that separation were internal to an ASDF2, would be good policy, since many of the issues are distinct, don't you think? ASDF already has moderately good mechanisms for this: system definition search functions, and extensibility that is often used for things like stowing FASLs in separate directories, and rebuilding stale fasls. The latter extensions seem so common that they ought to incorporated into ASDF; that's a good example of incremental improvement. OK, I worked pretty hard on my reply up to this point. Now let me throw out some more stuff quickly to answer other questions you raised, both explicitly and implicitly, so I can finally send this. Regarding MK-DEFSYSTEM, it is my understanding that it has features which ASDF still hasn't replicated, it has some continuing adherents, and its author does not consider it a dead project. (I could be wrong on some of these.) In any case, accomodating it is not hard, and doing so encourages that clean separation that I discussed earlier. The changes to ASDF-INSTALL that I have (the ones you haven't seen yet) are not minor, but neither are they drastic. They separate defsystem-specifics more cleanly from the rest of what ASDF-INSTALL does. > In the past, there has been concern about putting too many bells and > whistles into ASDF (and ASDF-Install) where "too many" seems to mean > "anything that is not there already". IMO, making things easier for newcomers should take precedence over disgruntling current users; there are a lot of new people coming to Lisp, and my impression is that few of them end up using ASDF-INSTALL because of its current limitations on Windows. If an incompatible change is necessary, document it well and provide whatever is needed to make it easy to adapt to it. If someone hates it, they don't have to upgrade, or they can even fork. Someone already decided that ASDF-INSTALL is supposed to support Windows, and it doesn't do that well. We either undo that decision, or do what it takes to make it really support Windows. (Similar argument for MK-DEFSYSTEM; in both cases I'm advocating preserving the decisions.) > ... The only concern I have is > making any migrations smooth and of keeping all the "stakeholders" of > ASDF and ASDF-Install in the loop. Avoiding unintended breakage *is* important, though. I think your test setup is a great step in the right direction, and wish I'd checked it out earlier. But can we set things up so that candidate changes can be easily tested on a wide variety of platforms? How many environments (OSes, CL implementations) do you currently have the ability to test on yourself? (BTW, you didn't comment on the unit test that's broken for Windows.) As to bootstrap-friendliness: One thing that ASDF has going for it, and ASDF-INSTALL does not, is that the former is a single file. Incorporating ASDF-INSTALL directly into ASDF would more than double the latter's size, even if you assumed some economy of shared code arising from the merger. Instead of going this route, it would seem preferable to (if possible) simplify ASDF-INSTALL's internals, gradually getting it down to where it can also be presented as a single file. The eventual goal would be that, instead of people being told to download and load ASDF as one of the first steps in setting up an environment, they'd be told to do the same thing with ASDF-INSTALL first, and then use it to install ASDF! ASDF-INSTALL doesn't actually have to depend on *any* defsystem to do non-recursive *installation* of a library into site-dependent locations. OK, that's kind of out there, and would *really* beg a rename for ASDF-INSTALL. :) > ... I think that > there is room for better system definition facilities and am willing > to volunteer some time towards the effort. I know that several others > on this list have expressed interest in the past. Is this the time to > take another crack at specifying and creating a new beast? I'm totally into talking about what would be desired from an ASDF2, BTW, although I'll always look at the ideas and consider whether they could be realized in the current systems. Can you point me to earlier discussions on this topic? Haven't found too much on my own so far. -- Dan Muller From 367znud02 at sneakemail.com Mon Nov 26 00:13:37 2007 From: 367znud02 at sneakemail.com (Dan Muller) Date: Sun, 25 Nov 2007 19:13:37 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: (Attila Lendvai attila lendvai-at-gmail com's message of "Sun\, 25 Nov 2007 22\:01\:42 +0100") References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> Message-ID: "Attila Lendvai attila.lendvai-at-gmail.com |asdf-install-devel/Both|" writes: Attila Lendvai wrote: >> Gary King wrote: >> I think that It should be possible to include your patches in the >> darcs repository without making them the tip. If we can figure out >> the syntax so that folks who grab ASDF-Install will get the "plain" >> version while folks who want it can get it the cutting edge version, >> them I'm happy to host your changes (Attila, do you know the >> mechanics for doing this?). I'm also happy to link to your repo. Just >> let me know. > > the usual way people deal with it is to have a stable and an unstable > branch. all the developers are working with the unstable branch and > after test periods or someone doing their own exhaustive tests, > several patches at once are pulled into the stable branch to > constitute a stable state of the development. this may involve pulling > patches from unstable out of order (i.e. bugfixes are pulled while > some new features are not yet). > > playing with tags is not too good because it's hard to communicate up > to which tag people should pull and getting the repo also gets the > head. > Yes, that is my understanding too, after reading about Darcs this weekend. Where "branch" means an entirely separate copy of the repository. In fact, I think that for Linux kernel devleopment (using Git, similar to Darcs), Linus has a separate, publically-visible repository for every major contributor, from which he cherry-picks the patches that he chooses. -- Dan Muller From acristin at gmail.com Mon Nov 26 19:27:52 2007 From: acristin at gmail.com (Andy Cristina) Date: Mon, 26 Nov 2007 13:27:52 -0600 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <28D544DA-29A3-4A94-AFD0-324E31190942@metabang.com> References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> <12190-02752@sneakemail.com> <28D544DA-29A3-4A94-AFD0-324E31190942@metabang.com> Message-ID: <6043bfd00711261127u5ede78a0lf6b2a4563eb37259@mail.gmail.com> On Nov 26, 2007 8:10 AM, Gary King wrote: > Hi Dan, > > > BTW, a related question, the answer to which might save me some time: > > Has anyone to your knowledge successfully run the entire, or even most > > of, the test suite on Windows? I'm thinking "not", as I'm looking at > > this. Unless it was with Cygwin CLisp. > > > Not that I'm aware of... > -- Gmail has had some issues with formatting these emails (it is coloring everything as horrible purple "quoted" text) that has made following this discussion a bit of effort for me, so I've probably missed this part... but where can I get this test suite? I still do most of my lisp programming in windows under lispworks, so I'd be happy to run the tests under lispworks and lispworks personal (although if it works for one, it probably works for the other), and since I don't have any cygwin contamination I'd be happy to run tests under clisp (and sbcl, why not) as well. And with the semester drawing to a close I'll take a crack at ripping off Edi Weitz' tar/gzip work in the next two weeks. --Andy From gwking at metabang.com Mon Nov 26 19:35:46 2007 From: gwking at metabang.com (Gary King) Date: Mon, 26 Nov 2007 14:35:46 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <6043bfd00711261127u5ede78a0lf6b2a4563eb37259@mail.gmail.com> References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> <12190-02752@sneakemail.com> <28D544DA-29A3-4A94-AFD0-324E31190942@metabang.com> <6043bfd00711261127u5ede78a0lf6b2a4563eb37259@mail.gmail.com> Message-ID: Hi Andy, The tests are part of the asdf-install project on common-lisp.net. They require LIFT (also on common-lisp.net). You should be able to #'asdf-install:install both of these and then (asdf:oos 'asdf:test-op 'asdf-install) Please let me know if anything goes wrong or is confusing... I've still not made the time to look at Edi's stuff but I do know that there is an Lisp archive package around somewhere that handles tar files (in case you want to look at two things :)). -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From acristin at gmail.com Mon Nov 26 19:46:26 2007 From: acristin at gmail.com (Andy Cristina) Date: Mon, 26 Nov 2007 13:46:26 -0600 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> <12190-02752@sneakemail.com> <28D544DA-29A3-4A94-AFD0-324E31190942@metabang.com> <6043bfd00711261127u5ede78a0lf6b2a4563eb37259@mail.gmail.com> Message-ID: <6043bfd00711261146t1266cc00l85e8b6909f47ffb8@mail.gmail.com> On Nov 26, 2007 1:35 PM, Gary King wrote: > Hi Andy, > > The tests are part of the asdf-install project on common-lisp.net. > They require LIFT (also on common-lisp.net). You should be able to > #'asdf-install:install both of these and then > > (asdf:oos 'asdf:test-op 'asdf-install) > > Please let me know if anything goes wrong or is confusing... > > I've still not made the time to look at Edi's stuff but I do know that > there is an Lisp archive package around somewhere that handles tar > files (in case you want to look at two things :)). > > Thanks, I'll start looking at these soon. I think Edi actually uses a modified version of archive (it had some lispworks incompatibilities or something) From pikdj2002 at sneakemail.com Tue Nov 27 04:32:27 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Mon, 26 Nov 2007 23:32:27 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: <28D544DA-29A3-4A94-AFD0-324E31190942@metabang.com> (Gary King gwking-at-metabang com's message of "Mon\, 26 Nov 2007 09\:10\:43 -0500") References: <23619-53795@sneakemail.com> <20232-96033@sneakemail.com> <12190-02752@sneakemail.com> <28D544DA-29A3-4A94-AFD0-324E31190942@metabang.com> Message-ID: <27780-96361@sneakemail.com> Gary King writes: > >> BTW, a related question, the answer to which might save me some time: >> Has anyone to your knowledge successfully run the entire, or even most >> of, the test suite on Windows? I'm thinking "not", as I'm looking at >> this. Unless it was with Cygwin CLisp. > > > Not that I'm aware of... Don't be sad, I'm working on it. :) With Lispworks, anyway. I had to go back to work today after a nice long weekend, so progress will be slower. -- Dan Muller From pikdj2002 at sneakemail.com Tue Nov 27 04:51:02 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Mon, 26 Nov 2007 23:51:02 -0500 Subject: [asdf-install-devel] Patches, Darcs, 'n' stuff In-Reply-To: (Attila Lendvai attila lendvai-at-gmail com's message of "Mon\, 26 Nov 2007 11\:24\:44 +0100") References: <23619-53795@sneakemail.com> <2EEB044A-C105-408C-B8AC-D37D5AF27AA7@metabang.com> <1612-11387@sneakemail.com> Message-ID: <10653-69762@sneakemail.com> "Attila Lendvai attila.lendvai-at-gmail.com |asdf-install-devel/Both|" <...> writes: >> * Make ASDF-INSTALL able to understand the concept of >> "updating". Apply it to itself. Then it will be ready to try >> updating ASDF, or any other library for that matter. >> >> * Make ASDF-INSTALL itself even easier to install. Ideally a >> single-file download, like ASDF! >> >> * At that point, consider the benefits of combining the projects. (But >> note that some people will never really want that integration, >> because there *are* alternatives to ASDF-INSTALL that make more >> sense in some environments.) > > it's also a bootstrapping issue: it's about bootstrapping a new lisp > environment where the functionality of both asdf and asdf-install are > vital at the same time. looking at it from this POV it's better to > have it in a single lib/project that has a single install howto. > > just some 0.02, Yup, I'm not ignoring the bootstrapping issue. My point is that most of the integration can occur without combining the packages. (At least I think so; nobody has talked about exactly what kind of integration they're looking for yet.) Once ASDF-INSTALL is as easy as it can be to use on Windows, and the integration is proven to work well, combining them into a single downloadable should be trivially easily. As long as no filenames collide, it could be as simple as putting them all in one directory, and writing that HOWTO. Until you get to that point, there seems (to me) little advantage to putting them together, and the disadvantage of encouraging incidental and unnecessary coupling between their implementations. (Although others would focus more on opportunities for synergy between the implementations. Weighing the pros and cons is a judgement call.) BTW, part of the solution is also simplifying how ASDF works on Windows. But again I think that can be done, at least initially, from outside ASDF. Prove solutions first, then integrate them if it makes sense to. -- Dan Muller From pikdj2002 at sneakemail.com Tue Nov 27 06:16:39 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Tue, 27 Nov 2007 01:16:39 -0500 Subject: [asdf-install-devel] Patch for Windows tar execution Message-ID: <31536-84381@sneakemail.com> I just sent another patch to Gary. (At least, I hope I did. I let darcs send it for me, I hope I had it configured right.) This replaces my earlier attempts, and I was more careful about backwards compatibility. Here's the description, followed by some thought on further refinements. ---------------------------------------------------------------------- Improved Windows tar execution Made tar execution on Windows work much more like it does on Unix, and took steps to avoid argument quoting problems. - *shell-search-paths* gets set from PATH on Windows. See code for rationale. This variable now contains a list of pathnames, not a list of lists. - On Windows, tar is called directly rather than via a shell. - On Windows, we assume that cygpath.exe is in *CYGWIN-BIN-DIRECTORY* or the path, and we use it to prep tar arguments explicitly instead of relying on the shell's backquote handling. This should be more likely to work out-of-the-box, while still giving precedence to the setting of *CYGWIN-BIN-DIRECTORY* which some people might have customized. - Due to the previous change, *CYGWIN-BASH-PROGRAM* is no longer needed and is deprecated. If non-nil, a warning is issued where it would formerly have been used. I recommend removing it entirely in the near future, but perhaps the warning will be helpful to people that currently customize it. - Refactored TAR-ARGUMENTS out of existence, replacing it with TAR-ARGUMENT. This was advisable because of the more complex logic to be executed per-argument in the Windows case. It also makes it clearer how similar the three cases (Windows, SCL, and other) really are. - Changed the Lispworks version of RETURN-OUTPUT-FROM-PROGRAM so that it does *not* glom the program and all the arguments together into a string. Doing so caused CALL-SYTEM-SHOWING-OUTPUT to run the command under a shell rather than directly, which gives rise to all kinds of argument quoting issue. - Changed DIRECTORIFY quite a bit. It wasn't working for me at all as it stood, not even on simple paths. My first rewrite messed up on paths that appeared to end with a file type. Summarizing: On Windows we will now use *GNU-TAR-PROGRAM* and *SHELL-SEARCH-PATHS* just like on UNIX. We still assume Cygwin and still run cygpath on the tar arguments. We no longer use *CYGWIN-BASH-PROGRAM*, but we still honor *CYGWIN-BIN-DIRECTORY*. Are these changes 100% backwards compatible? No, some failure cases will fail differently. But out-of-the-box success, using Cygwin, and without customization, is more likely. ---------------------------------------------------------------------- Thoughts on further refinements: - Note that the program still assumes that if you're on Windows, you're using Cygwin, and cygpath must be available. A further enhancement would be to run cygpath only conditionally; then native DOS-like Gnu tar versions might work out-of-the-box. A good strategy would be to run cygpath only if it's in the same directory as tar. - It would be easy to make the tar argument list configurable; I had another version that did this. The default argument list could be specified, e.g., like this: '("-C" :OUTPUT "-xzvf" :INPUT). This would make it dead easy to accomodate most non-Gnu tars. Changing the name of *GNU-TAR-PROGRAM* to *TAR-PROGRAM* would then be advisable for clarity. - The changes I made to Lispworks' RETURN-OUTPUT-FROM-PROGRAM are probably applicable to some other platforms, too. Running programs directly without the shell usually gives more predictable results. Configurable tar program and arguments would give people a way to force use of the shell if they really felt the need -- just specify the shell as the "tar program" and customize the arg list as needed. - I believe that *CYGWIN-BIN-DIRECTORY* should be deprecated. Using PATH should be adequate (even on UNIX, I would have thought), and if that's not desirable for some reason, people can easily customize *SHELL-SEARCH-PATHS* instead, and/or customize *GNU-TAR-PROGRAM* to include path. And that could be the last word on running an external tar. I hope. -- Dan Muller From pikdj2002 at sneakemail.com Tue Nov 27 06:22:01 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Tue, 27 Nov 2007 01:22:01 -0500 Subject: [asdf-install-devel] Patch for Windows tar execution In-Reply-To: <31536-84381@sneakemail.com> (Dan Muller pikdj2002-at-sneakemail com's message of "Tue\, 27 Nov 2007 01\:16\:39 -0500") References: <31536-84381@sneakemail.com> Message-ID: <29980-37817@sneakemail.com> Dan Muller writes: > I just sent another patch to Gary. [and on and on blah blah blah] BTW, I forgot to mention that with this patch, asdf-install passes all its unit tests except for the one that insists on symlinks, using Lispworks, a plain vanilla installation, and a typical Cygwin installation in a location other than what asdf-install used to assume. Someday I'll get setup to run the tests with CLisp, too, and maybe also on my Debian box. -- Dan Muller From gwking at metabang.com Tue Nov 27 14:25:59 2007 From: gwking at metabang.com (Gary King) Date: Tue, 27 Nov 2007 09:25:59 -0500 Subject: [asdf-install-devel] Patch for Windows tar execution In-Reply-To: <31536-84381@sneakemail.com> References: <31536-84381@sneakemail.com> Message-ID: <5324DC68-B726-4199-8BDC-48EFB9B04B2C@metabang.com> Hi Dan, (This e-mail is entirely about the mechanics of applying the patch and not about ASDF-Install at all...) I did get your patch (I didn't get the previous one (most likely it ended up in junk and I missed it) but I darcs isn't happy about applying it. It says: > [misterx:~/darcs/ai/asdf-install] gwking% darcs apply windows-tar- > patch > darcs: Error parsing patchinfo: > "" > "" > "[Improved Windows tar execution" > "Dan Muller**20071127054320" > "" > "Made tar execution on Windows work much more like it does on Unix, > and" > "took steps to avoid argument quoting problems." > "" > "- *shell-search-paths* gets set from PATH on Windows. See code for" > " rationale. This variable now contains a list of pathnames, not a" > " list of lists." > "" > "- On Windows, tar is called directly rather than via a" > " shell. " > "" > "- On Windows, we assume that cygpath.exe is in *CYGWI" I made a small patch file myself and it looked like this > Tue Nov 27 09:13:58 EST 2007 Gary King > * fooling > > New patches: > > [fooling > Gary King **20071127141358] { > hunk ./test-asdf-install.asd 24 > +;; eof > } > > Context: > > [Tutorial work > Gary King **20071125165713] > > [TAG version-0.6.10 > Gary King **20070814143216] > Patch bundle hash: > e9fae000db988f3846ba567748dc8291fd37d731 Whereas this has the comment above the New Patches; your includes it both above and below. I wonder if this is a darcs change. I'm still using version 1.0.8. I'm not sure if you should try sending again or if I should try applying by hand or if there is another option... Does anyone have any ideas? thanks, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From gwking at metabang.com Tue Nov 27 14:30:20 2007 From: gwking at metabang.com (Gary King) Date: Tue, 27 Nov 2007 09:30:20 -0500 Subject: [asdf-install-devel] Patch for Windows tar execution In-Reply-To: <31536-84381@sneakemail.com> References: <31536-84381@sneakemail.com> Message-ID: Hi Dan, These changes all sounds very good. Thanks for your efforts. I'm looking forward to applying them and getting them out there. -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From pikdj2002 at sneakemail.com Tue Nov 27 15:22:02 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Tue, 27 Nov 2007 10:22:02 -0500 Subject: [asdf-install-devel] Patch for Windows tar execution In-Reply-To: <5324DC68-B726-4199-8BDC-48EFB9B04B2C@metabang.com> References: <31536-84381@sneakemail.com> <5324DC68-B726-4199-8BDC-48EFB9B04B2C@metabang.com> Message-ID: <5755-35706@sneakemail.com> Gary King writes: > (This e-mail is entirely about the mechanics of applying the > patch and not about ASDF-Install at all...) > > I did get your patch (I didn't get the previous one (most > likely it ended up in junk and I missed it) but I darcs isn't > happy about applying it. It says: > > > [misterx:~/darcs/ai/asdf-install] gwking% darcs apply windows-tar- [patch contents...] > > Whereas this has the comment above the New Patches; your > includes it both above and below. > > I wonder if this is a darcs change. I'm still using version 1.0.8. I'm at work right now, so I can't check for sure, but I downloaded my version from http://wiki.darcs.net/DarcsWiki/CategoryBinaries only about a week ago. So I'm likely running 1.0.9. > I'm not sure if you should try sending again or if I should > try applying by hand or if there is another option... Does > anyone have any ideas? I don't have time to investigate right now, but hopefully something on the Darcs site will talk about version compatability issues. (If that's indeed what it is.) There's a -u option for "darcs send" which I can try tonight when I get home, it apparently generates the patch in a slightly different format. From pikdj2002 at sneakemail.com Wed Nov 28 04:19:51 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Tue, 27 Nov 2007 23:19:51 -0500 Subject: [asdf-install-devel] Patch for Windows tar execution In-Reply-To: <5755-35706@sneakemail.com> (Dan Muller pikdj2002-at-sneakemail com's message of "Tue\, 27 Nov 2007 10\:22\:02 -0500") References: <31536-84381@sneakemail.com> <5324DC68-B726-4199-8BDC-48EFB9B04B2C@metabang.com> <5755-35706@sneakemail.com> Message-ID: <21426-42573@sneakemail.com> Dan Muller writes: > > Gary King writes: >> >> I did get your patch (I didn't get the previous one (most >> likely it ended up in junk and I missed it) but I darcs isn't >> happy about applying it. > > I'm at work right now, so I can't check for sure, but I downloaded my > version from http://wiki.darcs.net/DarcsWiki/CategoryBinaries only about > a week ago. So I'm likely running 1.0.9. > > ... There's a -u option for "darcs send" which I can try > tonight when I get home, it apparently generates the patch in a slightly > different format. Gary, I resent the patch using the -u option. I also set up a repository for public access. Try following the link from http://danm.homelinux.org to my Darcs repository area. Be advised that this site has a dynamic IP, so occasionally the DNS record won't be up-to-date. If you have trouble accessing it, wait a little while and then try again BTW, another little detail about my testing which I forgot to mention: I did have to disable MK-DEFSYSTEM support to get the tests to pass. -- Dan Muller From gwking at metabang.com Wed Nov 28 20:59:02 2007 From: gwking at metabang.com (Gary King) Date: Wed, 28 Nov 2007 15:59:02 -0500 Subject: [asdf-install-devel] Patch for Windows tar execution In-Reply-To: <21426-42573@sneakemail.com> References: <31536-84381@sneakemail.com> <5324DC68-B726-4199-8BDC-48EFB9B04B2C@metabang.com> <5755-35706@sneakemail.com> <21426-42573@sneakemail.com> Message-ID: Hi Dan, My darcs still doesn't like your patch file (or what I'm doing with your patch file!) but I was able to pull the patch from your repository with no problems. All the usual tests pass. Unless there are complaints or worries, I'll upload everything in the next day or so. Thanks again for your work (and thanks to all the other contributors too!). -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From pikdj2002 at sneakemail.com Thu Nov 29 04:49:41 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Wed, 28 Nov 2007 23:49:41 -0500 Subject: [asdf-install-devel] Wrestling w/ Darcs (was: Patch for Windows tar execution) In-Reply-To: (Gary King gwking-at-metabang com's message of "Wed\, 28 Nov 2007 15\:59\:02 -0500") References: <31536-84381@sneakemail.com> <5324DC68-B726-4199-8BDC-48EFB9B04B2C@metabang.com> <5755-35706@sneakemail.com> <21426-42573@sneakemail.com> Message-ID: <18170-32223@sneakemail.com> Somewhat off-topic, Darcs learning curve stuff ... Gary King writes: > My darcs still doesn't like your patch file (or what I'm doing with > your patch file!) but I was able to pull the patch from your > repository with no problems. All the usual tests pass. Hmm. I just tried sending a patch to myself, and then applying it to a repo. Tried sending from Windows (exactly as I sent to you), received and applied successfully on both Windows & Linux. The darcs version on my Debian box is 1.0.9rc1, on Windows it's 1.0.9 (released). I'm using Gnus to send and read email; the message shows the patch description in the main body, the patch itself as a separate MIME part of type text/x-darcs-patch. Depending on your mail reader, perhaps it shows as an attachment with an extension of .dpatch. I can ask Gnus to pipe that MIME part into "darcs apply --repo=/path/to/my/repo", and it applies OK. Dunno if any of that helps. -- Dan Muller From pikdj2002 at sneakemail.com Thu Nov 29 05:02:43 2007 From: pikdj2002 at sneakemail.com (Dan Muller) Date: Thu, 29 Nov 2007 00:02:43 -0500 Subject: [asdf-install-devel] Patch for Windows tar execution In-Reply-To: (Gary King gwking-at-metabang com's message of "Wed\, 28 Nov 2007 15\:59\:02 -0500") References: <31536-84381@sneakemail.com> <5324DC68-B726-4199-8BDC-48EFB9B04B2C@metabang.com> <5755-35706@sneakemail.com> <21426-42573@sneakemail.com> Message-ID: <5503-69609@sneakemail.com> Gary King writes: > Unless there are complaints or worries, I'll upload everything in the > next day or so. Cool. Are you going to set up an unstable repository, as Attila suggested? I have a follow-up patch that I just sent you. (Actually, the email will include both patches, since I sent it "to" your online repository. Since this patch depends on the first one, and the target repo doesn't have the first one yet, Darcs won't let me send the second one along. Clever.) This patch actually removes *CYGWIN-BASH-PROGRAM*. To my surprise, I just noticed a little while ago that this variable was never exported. Instead, *CYGWIN-BASH-COMMAND* is exported, but is neither defined nor referenced. Probably a typo in a previous patch. I feel a bit silly about failing to notice this while working on the first patch. Anyway, since the first variable was never exported or documented, I assume that it's OK and cleaner to just remove it instead of leaving the warning in there. Anyone that is setting an unexported variable from outside its package forfeits the right to be annoyed if the symbol disappears. ;-) > Thanks again for your work (and thanks to all the other contributors > too!). My pleasure, and thank /you/ for maintaining ASDF-INSTALL. This will probably be my first accepted OS contribution. I'm ludicrously pleased that it's in Lisp. :-) I'll send along patches for the further refinements that I described in the next few days, being as careful as I can to preserve the existing behavior of exported and/or documented features. At some point I would like to start a discussion here about how UNINSTALL does/should/could work. -- Dan Muller From attila.lendvai at gmail.com Thu Nov 29 08:44:46 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 29 Nov 2007 09:44:46 +0100 Subject: [asdf-install-devel] Wrestling w/ Darcs (was: Patch for Windows tar execution) In-Reply-To: <18170-32223@sneakemail.com> References: <31536-84381@sneakemail.com> <5324DC68-B726-4199-8BDC-48EFB9B04B2C@metabang.com> <5755-35706@sneakemail.com> <21426-42573@sneakemail.com> <18170-32223@sneakemail.com> Message-ID: > Hmm. I just tried sending a patch to myself, and then applying it to a > repo. Tried sending from Windows (exactly as I sent to you), received > and applied successfully on both Windows & Linux. The darcs version on my Debian box is 1.0.9rc1, on Windows it's 1.0.9 (released). the problem usually is that various mail clients feel free to transform text attachments. some of them straight insert them as mail body, but once you copy&paste it into a file darcs refuses to apply the patch. in my experience this is because it has a quite strict format, so extra newlines or transformed EOL chars screw up the patch... hth, -- attila From gwking at metabang.com Thu Nov 29 15:41:42 2007 From: gwking at metabang.com (Gary King) Date: Thu, 29 Nov 2007 10:41:42 -0500 Subject: [asdf-install-devel] Patch for Windows tar execution In-Reply-To: <5503-69609@sneakemail.com> References: <31536-84381@sneakemail.com> <5324DC68-B726-4199-8BDC-48EFB9B04B2C@metabang.com> <5755-35706@sneakemail.com> <21426-42573@sneakemail.com> <5503-69609@sneakemail.com> Message-ID: > Cool. Are you going to set up an unstable repository, as Attila > suggested? Yes, that's a safer idea! The only down side is that I'll need to dust off my aging and creaky common-lisp.net software maintenance tools (actually, that's an upside: they could use dusting off) and that will take a little bit of time. > I have a follow-up patch that I just sent you. (Actually, the email > will include both patches, since I sent it "to" your online > repository. Since this patch depends on the first one, and the target > repo doesn't have the first one yet, Darcs won't let me send the > second one along. Clever.) I'll pull this from your repo. > My pleasure, and thank /you/ for maintaining ASDF-INSTALL. This will > probably be my first accepted OS contribution. I'm ludicrously pleased > that it's in Lisp. :-) Yeah! -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM