From gwking at metabang.com Mon Oct 9 12:40:33 2006 From: gwking at metabang.com (Gary King) Date: Mon, 9 Oct 2006 08:40:33 -0400 Subject: [asdf-install-devel] Tutorial updated, version 0.6.0 released Message-ID: Version 0.6.0 of Portable ASDF-Install has been released. The largest changes are: * reworking of GPG key handling * Changes to the API of the install function * Changes to the tutorial 1. The GPG check previously piped the signature file directly into the call gpg via a network stream. This worked great but required a lot of platform specific code. Since downloading and shell commands are already used by ASDF-Install, the GPG check now downloads the signature and processes it as a file. 2. The install function now has an additional keyword argument: where. The function signature is install package-or-packages &key where propagate? * package-or-packages is a system designator or list of system designators. * where specifies where to install the systems. It can be a number, symbol or string. If it is a number, it specifies the index of the location specifier in *asdf-install:locations*. If a string or a symbol, it is used to find the location in *asdf- install:locations* by comparing it with the third item in the list. 3. The tutorial has been broken into sections for easier navigation. This is still a work in progress. There are many broken inter-page links and the table of contents has temporarily been left in the dust. The old tutorial is still available as a link from the new one. -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From attila.lendvai at gmail.com Tue Oct 17 12:30:12 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 17 Oct 2006 14:30:12 +0200 Subject: [asdf-install-devel] darcs support Message-ID: hi! i've been playing with the idea of adding darcs support to asdf-install. unfortunately i don't have that much free time to jump right into it, so i sum up my ideas and design plan, so maybe someone feels like hacking on it. if there are other interested people we could use this mail as a scratch doc, feel free to add/change whatever you feel like is missing/wrong, but please start your reply as a forward so the mail will not be full of reply-annotations. user features: - pointing to an url containing a dir '_darcs' (or CVS, or whatever else, but i'm missing darcs the most) should issue a 'darcs get' command to get the repo - support auto updating of installed repos - support versions so that asdf looks for version tags with heuristic search among the tags in the repo (tries things like v-1.2.3, v1.2.3, version-1.2.3, etc). then it could get the tag requested by the user. the default operation should be to only get tagged state from the repos, so the user is relatively safe from too fresh code. this of course needs cooperation from the repo maintainers to tag the rerpos according to the released versions, but i'm sure that's the smallest problem. design plan: - create clos objects for packages (better name?) and implement the install protocol on them, so we can override things like getting the stuff and cleaning up. the protocol should be as finegrained as needed, without coding i would start from these: - install - uninstall - download - update - comptaiblep - create a TARPackage - create a RepositoryPackage class that implements the base functionality by customising the install defmethod's - create a DarcsPackage that adds the missing pieces to darcs get the package future: ultimately i would like to see a tighter integration with asdf in regards of version handling and dependencies. asdf should allow more complex entries for dependencies that also contain a :version info (with support for 'latest' or 'head', so tagged repos could contain dependencies for the exact versions, while the head could contain deps for the head of other systems when necessary). then asdf-install could/should have an operation that starts out from a given asdf system and gets the correct versions of all the dependencies into dirs named project-name-version (and with the darcs integraion all that needs to be done by the maintainers is to properly tag the repos). then some sort of :around method on load-op should rebind the *central-registry* so that the load-op of a system gets a registry with the proper versions. of course there are many open questions, like what happens for contradictory version requirements (a continuable error for using the newer version?) and if a version is already loaded and another version is requested by some operation (fail?). and of course this all should be dropped and we should have something like the smalltalk guys: structured editing of the code in a running lisp image and operations to migrate modules between running images, but this is a much longer story and needs much more work... opinions? or better voulenteers? :) -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at guruhut.com Tue Oct 17 13:05:24 2006 From: sean at guruhut.com (Sean Ross) Date: Tue, 17 Oct 2006 15:05:24 +0200 Subject: [asdf-install-devel] darcs support In-Reply-To: References: Message-ID: <4534D514.4070509@guruhut.com> Attila Lendvai wrote: > > * create a TARPackage FWIW it should be possible to extract tarballs, without resorting to gnu tar, using a combination of gzip-stream and archive. Unfortunately the version of archive relies on a patched version of with-open-archive (to accept streams as well as pathnames). I sent a patch to Nathan in July (or somewhere around there) but i'm not too sure what the current status of archive is. I've been using the following extras in my .asdf-install ;; add lisp tarball extractor (asdf:oos 'asdf:load-op :gzip-stream) (asdf:oos 'asdf:load-op :archive) (defun asdf-install-extractor (to-dir tarball) (let ((name nil)) (gzip-stream:with-open-gzip-file (ins tarball) (archive:with-open-archive (archive ins) (let ((*default-pathname-defaults* (pathname to-dir))) (archive:do-archive-entries (entry archive name) (archive:extract-entry archive entry) (unless name (setf name (archive:name entry))))))) ;; we use string instead of namestring because ;; asdf-install searches for /'s and not \'s ;; which will break on windows (string name))) (push 'asdf-install-extractor *tar-extractors*) Cheers, Sean. From pjb at informatimago.com Tue Oct 17 13:16:58 2006 From: pjb at informatimago.com (Pascal Bourguignon) Date: Tue, 17 Oct 2006 15:16:58 +0200 Subject: [asdf-install-devel] darcs support In-Reply-To: References: Message-ID: <17716.55242.637971.226614@thalassa.informatimago.com> Attila Lendvai writes: > and of course this all should be dropped and we should have something like > the smalltalk guys: structured editing of the code in a running lisp image > and operations to migrate modules between running images, but this is a much > longer story and needs much more work... Just a data point here: the compressed tarballs of all the asdf-installable systems are 20 MB. Indeed, all these sources could stand easily in any lisp image. -- __Pascal Bourguignon__ http://www.informatimago.com/ I need a new toy. Tail of black dog keeps good time. Pounce! Good dog! Good dog! From gwking at metabang.com Tue Oct 17 13:30:28 2006 From: gwking at metabang.com (Gary King) Date: Tue, 17 Oct 2006 09:30:28 -0400 Subject: [asdf-install-devel] darcs support In-Reply-To: References: Message-ID: <1DAA30F0-D247-4133-A239-13E3E7E28441@metabang.com> > i've been playing with the idea of adding darcs support to asdf- > install. unfortunately i don't have that much free time to jump > right into it, so i sum up my ideas and design plan, so maybe > someone feels like hacking on it. if there are other interested > people we could use this mail as a scratch doc, feel free to add/ > change whatever you feel like is missing/wrong, but please start > your reply as a forward so the mail will not be full of reply- > annotations. I'm strongly in favor of enhancing ASDF-Install to support multiple source code access routes above and beyond tarballs pointed at by the CLiki. However, I think that it would be better to keep ASDF-Install as simple as possible and create a new project with all the bells and whistles. The main reason for this is that ASDF-Install is already forked (the SBCL version and the Portable version and perhaps the OpenMCL version) and this adds to confusion as people evaluate Lisps. So my suggestion would be to pick a new name (for example phloog or wrackd (which aren't taken as domain names as of a few weeks ago )) and start a design effort. The trouble, as usual, is that I expect that most of the most interested parties are feeling the time crunch. I know I am. -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.lendvai at gmail.com Tue Oct 17 13:48:19 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 17 Oct 2006 15:48:19 +0200 Subject: [asdf-install-devel] darcs support In-Reply-To: <1DAA30F0-D247-4133-A239-13E3E7E28441@metabang.com> References: <1DAA30F0-D247-4133-A239-13E3E7E28441@metabang.com> Message-ID: > > However, I think that it would be better to keep ASDF-Install as simple as > possible and create a new project with all the bells and whistles. The main > reason for this is that ASDF-Install is already forked (the SBCL version and > the Portable version and perhaps the OpenMCL version) and this adds to > confusion as people evaluate Lisps. > well, we should also consider the confusion added by having numerous projects for the same tasks. (i can't stop thinking of the situation with usocket and trivial-sockets). this brings questions, discussions about the situation, etc... instead i would try to resolve the situation with the branches. i'm sure there would be no trouble with sbcl, just look at how the official asdf plays well with sbcl. i have this in my env.lisp to replace asdf.lispshipped with sbcl to the one from my repo: #+sbcl (eval-when (:compile-toplevel :load-toplevel) (let ((asdf-file (probe-file (merge-pathnames "asdf/asdf.lisp" *workspace-dir*)))) (when asdf-file (defun update-asdf () (delete-package :asdf) (let ((*features* (cons :sbcl-hooks-require *features*))) (load (compile-file asdf-file)))) (update-asdf)))) So my suggestion would be to pick a new name (for example phloog or wrackd > (which aren't taken as domain names as of a few weeks ago )) and > start a design effort. > this too needs extra efforts, setting up a repo, etc... that could be used for coding instead. > The trouble, as usual, is that I expect that most of the most interested > parties are feeling the time crunch. I know I am. > how true... :( especially that i don't even use adsf-install myself. i always ended up checking out repos of everything, so now i start with that. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pjb at informatimago.com Tue Oct 17 14:03:44 2006 From: pjb at informatimago.com (Pascal Bourguignon) Date: Tue, 17 Oct 2006 16:03:44 +0200 Subject: [asdf-install-devel] darcs support In-Reply-To: <1DAA30F0-D247-4133-A239-13E3E7E28441@metabang.com> References: <1DAA30F0-D247-4133-A239-13E3E7E28441@metabang.com> Message-ID: <17716.58048.633767.152368@thalassa.informatimago.com> Gary King writes: > I'm strongly in favor of enhancing ASDF-Install to support multiple > source code access routes above and beyond tarballs pointed at by the > CLiki. > > However, I think that it would be better to keep ASDF-Install as > simple as possible and create a new project with all the bells and > whistles. The main reason for this is that ASDF-Install is already > forked (the SBCL version and the Portable version and perhaps the > OpenMCL version) and this adds to confusion as people evaluate Lisps. This is a problem. Why is it forked? Couldn't some hooks be sufficient to let these implementations do what they need without forking libraries? -- __Pascal Bourguignon__ http://www.informatimago.com/ NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.