"Andreas Rottmann" wrote:
>> I had to take a version of Xitomatl I had already
>> downloaded a while ago (revision 179) because for some
>> reason the Bazaar checkout failed.
>
> Could you provide the error message?
It was probably a temporary problem with the Launchpad
servers, the raw command:
$ bzr checkout \
--lightweight lp:~rotty/scheme-libraries/xitomatl \
xito
failed with a "no such project" error; today xitomatl
downloading works. But I get the following:
./scripts/fetch-systems ikarus sbank
= Getting base systems
= Preparing symlink tree for ikarus
= Fetching additional systems, using config 'sbank'
% /usr/local/bin/git pull --no-commit git://github.com/rotty/spe.git master
You are in the middle of a conflicted merge.
Unhandled exception:
Condition components:
1. &who: <runner>
2. &runner-error: (#[pathname / ("usr" "local" "bin") #[file "git" () #f]]
"pull" "--no-commit" "git://github.com/rotty/spe.git" "master")
3. &message: "child process (/usr/local/bin/git pull --no-commit
git://github.com/rotty/spe.git master) terminated with unexpected status 1 (not
in 0)\nworking directory: /home/marco/src/devel/scheme/checkouts/spe"
= Starting build using ikarus
* Building system spells
* Building system sbank
(conjure.configure: [info] sbank/config.sls is up to date)
(conjure.configure: [info] sbank/glib.sls is up to date)
(conjure.configure: [info] sbank/gtk.sls is up to date)
* Building system prometheus
when I run it on a tree that should be fully up to date.
> From the fact that it worked, I figure you've run SPE's
> "./scripts/fetch-systems $IMPL sbank" (which calls
> "./scripts/launch $IMPL build" as a last step)
> successfully. Then you could just have set
> $YPSILON_SITELIB to $SPE/r6rs-libs, FWIW.
Understood and confirmed.
> You can spare you the fiddling with the library path
> environment variables by using "./scripts/launch $IMPL
> <whatever script you wanna> run>".
Fine, but in my alpha-testing plan I want to write a set of
scripts under version control in a proper project. So I
need a bit of infrastructure to "fish" the libraries in the
SPE source tree.
> A relevant issue in this regard is discussed in [0]. I've
> not solved this directly in spells, but in sbank -- see
> support/type-data.sls [1], the "signature" part.
I will come back on this when I have a little more time to
read the code.
> [ OT: Is there a way to link to HEAD blobs in github?
> Having those SHA-1 hashes in URLs really annoy me to no
> end ]
It is my understanding that direct browsing of files is
possible with URLs like:
http://github.com/marcomaggi/mbfl/tree/master/src/lib/loader.sh
http://github.com/marcomaggi/mbfl/blob/master/src/lib/loader.sh
and if you tag a revision, for example with "1.3b5", then
you can use:
http://github.com/marcomaggi/mbfl/blob/1.3b5/src/modules/getopts.sh.m4
and you can download the archives using:
http://github.com/marcomaggi/mbfl/tarball/master/HEAD
http://github.com/marcomaggi/mbfl/zipball/master/HEAD
or using "master" as implicit branch:
http://github.com/marcomaggi/mbfl/tarball/HEAD
http://github.com/marcomaggi/mbfl/zipball/HEAD
and if you tag a revision:
http://github.com/marcomaggi/mbfl/tarball/1.3b5
http://github.com/marcomaggi/mbfl/zipball/1.3b5
which work from the browser and the command line (I tried
with "wget"). The archive name itself still has the hash
sum in it, though.
--
Marco Maggi
