From aperto1973 at web.de  Sun Dec  7 14:21:43 2008
From: aperto1973 at web.de (user)
Date: Sun, 07 Dec 2008 09:21:43 -0500
Subject: [clbuild-devel] uffi asd registration failed (register_other_asd ?)
Message-ID: <1228659703.19819.10.camel@user-desktop>

Hello all,
hello David (as was suggested to me in #lisp),

creating the uffi asd in /clbuild/systems/ failed here with the current
clbuild. Had a look then into a previously working version of clbuild on
my system and manually created the link, so everythings fine for now.

 At first sight it looks as if register_other_asd in the current version
didnt work this time. The old working code was this:


link_extra_asds() {
    # some (buggy) projects try to hide their .asd files from us:
    ln -sf $source_dir/mcclim/Experimental/freetype/*.asd ${system_dir}/
    ln -sf $source_dir/eclipse/system.lisp ${system_dir}/eclipse.asd
    ln -f -s $source_dir/graphic-forms/src/external-libraries/*/*/*.asd
\
        ${system_dir}
    ln -sf $source_dir/clg/*/*.asd ${system_dir}
    ln -sf $source_dir/cells-gtk/*/*.asd ${system_dir}

    # also, override uffi:
    ln -sf $source_dir/cffi/uffi-compat/uffi.asd ${system_dir}/
}


P.S.: Thank you to all maintainers and patch submitters of clbuild. So
happy with it!






From daniel at whitehouse.id.au  Tue Dec  9 05:40:32 2008
From: daniel at whitehouse.id.au (Daniel White)
Date: Tue, 9 Dec 2008 15:40:32 +1000
Subject: [clbuild-devel] uffi asd registration failed
 (register_other_asd ?)
In-Reply-To: <1228659703.19819.10.camel@user-desktop>
References: <1228659703.19819.10.camel@user-desktop>
Message-ID: <20081209154032.0177b865@whitehouse.id.au>

On Sun, 07 Dec 2008 09:21:43 -0500
user <aperto1973 at web.de> wrote:

> Hello all,
> hello David (as was suggested to me in #lisp),
> 
> creating the uffi asd in /clbuild/systems/ failed here with the current
> clbuild. Had a look then into a previously working version of clbuild on
> my system and manually created the link, so everythings fine for now.
> 
>  At first sight it looks as if register_other_asd in the current version
> didnt work this time. The old working code was this:
> 
> 
> link_extra_asds() {
>     # some (buggy) projects try to hide their .asd files from us:
>     ln -sf $source_dir/mcclim/Experimental/freetype/*.asd ${system_dir}/
>     ln -sf $source_dir/eclipse/system.lisp ${system_dir}/eclipse.asd
>     ln -f -s $source_dir/graphic-forms/src/external-libraries/*/*/*.asd
> \
>         ${system_dir}
>     ln -sf $source_dir/clg/*/*.asd ${system_dir}
>     ln -sf $source_dir/cells-gtk/*/*.asd ${system_dir}
> 
>     # also, override uffi:
>     ln -sf $source_dir/cffi/uffi-compat/uffi.asd ${system_dir}/
> }
> 
> 
> P.S.: Thank you to all maintainers and patch submitters of clbuild. So
> happy with it!
> 

It turns out my patches to link_extra_asds had made it into the repository.

Are there any error messages?

Maybe the output of 'clbuild rebuild-links' would be helpful?

-- 
Daniel White



From aperto1973 at web.de  Tue Dec  9 09:32:48 2008
From: aperto1973 at web.de (user)
Date: Tue, 09 Dec 2008 04:32:48 -0500
Subject: [clbuild-devel] uffi asd registration failed
 (register_other_asd ?)
In-Reply-To: <20081209154032.0177b865@whitehouse.id.au>
References: <1228659703.19819.10.camel@user-desktop>
	<20081209154032.0177b865@whitehouse.id.au>
Message-ID: <1228815168.6019.5.camel@user-desktop>

On Tue, 2008-12-09 at 15:40 +1000, Daniel White wrote:
> On Sun, 07 Dec 2008 09:21:43 -0500
> user <aperto1973 at web.de> wrote:
> 

> > creating the uffi asd in /clbuild/systems/ failed here with the current
> > clbuild. Had a look then into a previously working version of clbuild on
> > my system and manually created the link, so everythings fine for now.
> > 
> >  At first sight it looks as if register_other_asd in the current version
> > didnt work this time. The old working code was this:
> > 
> > 
> > link_extra_asds() {
> >     # some (buggy) projects try to hide their .asd files from us:
> >     ln -sf $source_dir/mcclim/Experimental/freetype/*.asd ${system_dir}/
> >     ln -sf $source_dir/eclipse/system.lisp ${system_dir}/eclipse.asd
> >     ln -f -s $source_dir/graphic-forms/src/external-libraries/*/*/*.asd
> > \
> >         ${system_dir}
> >     ln -sf $source_dir/clg/*/*.asd ${system_dir}
> >     ln -sf $source_dir/cells-gtk/*/*.asd ${system_dir}
> > 
> >     # also, override uffi:
> >     ln -sf $source_dir/cffi/uffi-compat/uffi.asd ${system_dir}/
> > }
> > 

> 
> It turns out my patches to link_extra_asds had made it into the repository.
> 
> Are there any error messages?
> 
> Maybe the output of 'clbuild rebuild-links' would be helpful?
> 

user at user-desktop:~/clbuild$ ./clbuild rebuild-links
/home/user/clbuild/source/alexandria/alexandria.asd
/home/user/clbuild/source/alexandria/alexandria-tests.asd
/home/user/clbuild/source/trivial-features/trivial-features.asd
/home/user/clbuild/source/trivial-features/trivial-features-tests.asd
/home/user/clbuild/source/babel/babel.asd
/home/user/clbuild/source/babel/babel-streams.asd
/home/user/clbuild/source/babel/babel-tests.asd
/home/user/clbuild/source/cffi/cffi.asd
/home/user/clbuild/source/cffi/cffi-examples.asd
/home/user/clbuild/source/cffi/cffi-grovel.asd
/home/user/clbuild/source/cffi/cffi-tests.asd
/home/user/clbuild/source/cffi/cffi-uffi-compat.asd
/home/user/clbuild/source/md5/md5.asd
/home/user/clbuild/source/clsql/clsql-aodbc.asd
/home/user/clbuild/source/clsql/clsql.asd
/home/user/clbuild/source/clsql/clsql-db2.asd
/home/user/clbuild/source/clsql/clsql-mysql.asd
/home/user/clbuild/source/clsql/clsql-odbc.asd
/home/user/clbuild/source/clsql/clsql-oracle.asd
/home/user/clbuild/source/clsql/clsql-postgresql.asd
/home/user/clbuild/source/clsql/clsql-postgresql-socket.asd
/home/user/clbuild/source/clsql/clsql-sqlite3.asd
/home/user/clbuild/source/clsql/clsql-sqlite.asd
/home/user/clbuild/source/clsql/clsql-tests.asd
/home/user/clbuild/source/clsql/clsql-uffi.asd
Ignoring invalid
path: /home/user/clbuild/source/mcclim/Experimental/freetype
Ignoring invalid
path: /home/user/clbuild/source/graphic-forms/src/external-libraries/*/*
Ignoring invalid path: /home/user/clbuild/source/clg/*
Ignoring invalid path: /home/user/clbuild/source/eclipse/system.lisp
/home/user/clbuild/source/cffi/uffi-compat/uffi.asd
26 system definition files registered






From daniel at whitehouse.id.au  Tue Dec  9 12:25:34 2008
From: daniel at whitehouse.id.au (Daniel White)
Date: Tue, 9 Dec 2008 22:25:34 +1000
Subject: [clbuild-devel] uffi asd registration failed
 (register_other_asd ?)
In-Reply-To: <1228815168.6019.5.camel@user-desktop>
References: <1228659703.19819.10.camel@user-desktop>
	<20081209154032.0177b865@whitehouse.id.au>
	<1228815168.6019.5.camel@user-desktop>
Message-ID: <20081209222534.442c746c@whitehouse.id.au>

On Tue, 09 Dec 2008 04:32:48 -0500
user <aperto1973 at web.de> wrote:

> On Tue, 2008-12-09 at 15:40 +1000, Daniel White wrote:
> > On Sun, 07 Dec 2008 09:21:43 -0500
> > user <aperto1973 at web.de> wrote:
> > 
> 
> > > creating the uffi asd in /clbuild/systems/ failed here with the current
> > > clbuild. Had a look then into a previously working version of clbuild on
> > > my system and manually created the link, so everythings fine for now.
> > > 
> > >  At first sight it looks as if register_other_asd in the current version
> > > didnt work this time. The old working code was this:
> > > 
> > > 
> > > link_extra_asds() {
> > >     # some (buggy) projects try to hide their .asd files from us:
> > >     ln -sf $source_dir/mcclim/Experimental/freetype/*.asd ${system_dir}/
> > >     ln -sf $source_dir/eclipse/system.lisp ${system_dir}/eclipse.asd
> > >     ln -f -s $source_dir/graphic-forms/src/external-libraries/*/*/*.asd
> > > \
> > >         ${system_dir}
> > >     ln -sf $source_dir/clg/*/*.asd ${system_dir}
> > >     ln -sf $source_dir/cells-gtk/*/*.asd ${system_dir}
> > > 
> > >     # also, override uffi:
> > >     ln -sf $source_dir/cffi/uffi-compat/uffi.asd ${system_dir}/
> > > }
> > > 
> 
> > 
> > It turns out my patches to link_extra_asds had made it into the repository.
> > 
> > Are there any error messages?
> > 
> > Maybe the output of 'clbuild rebuild-links' would be helpful?
> > 
> 
> user at user-desktop:~/clbuild$ ./clbuild rebuild-links
> [snip...]
> Ignoring invalid
> path: /home/user/clbuild/source/mcclim/Experimental/freetype
> Ignoring invalid
> path: /home/user/clbuild/source/graphic-forms/src/external-libraries/*/*
> Ignoring invalid path: /home/user/clbuild/source/clg/*
> Ignoring invalid path: /home/user/clbuild/source/eclipse/system.lisp
> /home/user/clbuild/source/cffi/uffi-compat/uffi.asd
> 26 system definition files registered

The 'Ignoring invalid path' messages are just letting you know that the
special cases haven't been run because you don't have the library.  Not
a real concern.

Additionally, uffi.asd seems to have been registered fine.  Is it in
your systems directory?

-- 
Daniel White



From daniel at whitehouse.id.au  Tue Dec  9 16:09:53 2008
From: daniel at whitehouse.id.au (Daniel White)
Date: Wed, 10 Dec 2008 02:09:53 +1000
Subject: [clbuild-devel] uffi asd registration failed
 (register_other_asd ?)
In-Reply-To: <1228827529.5480.6.camel@user-desktop>
References: <1228659703.19819.10.camel@user-desktop>
	<20081209154032.0177b865@whitehouse.id.au>
	<1228815168.6019.5.camel@user-desktop>
	<20081209222534.442c746c@whitehouse.id.au>
	<1228827529.5480.6.camel@user-desktop>
Message-ID: <20081210020953.6e4d3645@whitehouse.id.au>

On Tue, 09 Dec 2008 07:58:49 -0500
user <aperto1973 at web.de> wrote:

> On Tue, 2008-12-09 at 22:25 +1000, Daniel White wrote:
> > On Tue, 09 Dec 2008 04:32:48 -0500
> > user <aperto1973 at web.de> wrote:
> > 
> > > On Tue, 2008-12-09 at 15:40 +1000, Daniel White wrote:
> > > > On Sun, 07 Dec 2008 09:21:43 -0500
> > > > user <aperto1973 at web.de> wrote:
> > > > 
> > > 
> > > > > creating the uffi asd in /clbuild/systems/ failed here with the current
> > > > > clbuild. Had a look then into a previously working version of clbuild on
> > > > > my system and manually created the link, so everythings fine for now.
> > > > > 
> > > > >  At first sight it looks as if register_other_asd in the current version
> > > > > didnt work this time. The old working code was this:
> > > > > 
> > > > > 
> > > > > link_extra_asds() {
> > > > >     # some (buggy) projects try to hide their .asd files from us:
> > > > >     ln -sf $source_dir/mcclim/Experimental/freetype/*.asd ${system_dir}/
> > > > >     ln -sf $source_dir/eclipse/system.lisp ${system_dir}/eclipse.asd
> > > > >     ln -f -s $source_dir/graphic-forms/src/external-libraries/*/*/*.asd
> > > > > \
> > > > >         ${system_dir}
> > > > >     ln -sf $source_dir/clg/*/*.asd ${system_dir}
> > > > >     ln -sf $source_dir/cells-gtk/*/*.asd ${system_dir}
> > > > > 
> > > > >     # also, override uffi:
> > > > >     ln -sf $source_dir/cffi/uffi-compat/uffi.asd ${system_dir}/
> > > > > }
> > > > > 
> > > 
> > > > 
> > > > It turns out my patches to link_extra_asds had made it into the repository.
> > > > 
> > > > Are there any error messages?
> > > > 
> > > > Maybe the output of 'clbuild rebuild-links' would be helpful?
> > > > 
> > > 
> > > user at user-desktop:~/clbuild$ ./clbuild rebuild-links
> > > [snip...]
> > > Ignoring invalid
> > > path: /home/user/clbuild/source/mcclim/Experimental/freetype
> > > Ignoring invalid
> > > path: /home/user/clbuild/source/graphic-forms/src/external-libraries/*/*
> > > Ignoring invalid path: /home/user/clbuild/source/clg/*
> > > Ignoring invalid path: /home/user/clbuild/source/eclipse/system.lisp
> > > /home/user/clbuild/source/cffi/uffi-compat/uffi.asd
> > > 26 system definition files registered
> > 
> > The 'Ignoring invalid path' messages are just letting you know that the
> > special cases haven't been run because you don't have the library.  Not
> > a real concern.
> > 
> > Additionally, uffi.asd seems to have been registered fine.  Is it in
> > your systems directory?
> > 
> 
> Yes. Loads also fine with asdf on the REPL. What i liked about the
> previously used version of clbuild is that no manual 'rebuild-links' run
> was needed. 'update $project' was enough to care about the uffi-asd-case
> (of the "special asds" mentioned in link_extra_asds() i have only been
> using uffi/uffi).

This is a regression.

The following patches fix this and some other brain-dead errors in
the .asd registration changes.

Repository can be found (for now) at:
http://whitehouse.id.au/darcs/daniel/clbuild/

Wed Dec 10 00:58:47 EST 2008  Daniel White <daniel at whitehouse.id.au>
  * Use given file name when registering single file with register_other_asd

Wed Dec 10 01:01:40 EST 2008  Daniel White <daniel at whitehouse.id.au>
  * Simplified register_other_asd for the directory argument
  
  Was originally able to be provided a file pattern other
  than *.asd, but YAGNI.  Simpler and cleaner.

Wed Dec 10 01:12:44 EST 2008  Daniel White <daniel at whitehouse.id.au>
  * Only look in directories of expanded glob for .asd files
  
  When register_other_asd is handed a glob, it uses all the expanded 
  paths whether or not they are files.  The only reason this actually 
  works is because register_single_asd checks that the paths it is handed 
  are actually files.

Wed Dec 10 01:15:39 EST 2008  Daniel White <daniel at whitehouse.id.au>
  * Quote globs passed to register_other_asd
  
  For some reason, these end up being expanded early when update 
  is run but not rebuild-links.  These should be quoted to avoid
  errors.

Wed Dec 10 01:17:40 EST 2008  Daniel White <daniel at whitehouse.id.au>
  * register_all_asd_in_path should pass on the quiet parameter

Wed Dec 10 01:18:52 EST 2008  Daniel White <daniel at whitehouse.id.au>
  * register_other_asd should be quiet by default

-- 
Daniel White



From krewinkel at gmx.net  Fri Dec 12 07:51:56 2008
From: krewinkel at gmx.net (Albert Krewinkel)
Date: Thu, 11 Dec 2008 23:51:56 -0800
Subject: [clbuild-devel] bash completion
Message-ID: <m2zlj1ltk3.fsf@gmx.net>

I've added primitive bash completion to clbuild.  To test/use it, change
to the clbuild directory and do
$ . clbuild-bash-completion.sh

It's not much of a useful feature, but I found it to be worthwhile at
times.  Still needs work, though.  Constructive criticsm and comments
are welcome.

Cherrs, Albert


<demo>
$ ./clbuild <TAB> <TAB>
--help            diff              list              slime
--implementation  help              preloaded         uninstall
--long-help       install           recompile         update
check             lisp              run               

$ ./clbuild --implementation <TAB> <TAB>
ccl    clisp  ecl    sbcl   

$ ./clbuild --implementation sbcl s<TAB>
$ ./clbuild --implementation sbcl slime

$ ./clbuild update <TAB><TAB>
Display all 192 possibilities? (y or n)
</demo>



From daniel at whitehouse.id.au  Fri Dec 12 11:12:53 2008
From: daniel at whitehouse.id.au (Daniel White)
Date: Fri, 12 Dec 2008 21:12:53 +1000
Subject: [clbuild-devel] bash completion
In-Reply-To: <m2zlj1ltk3.fsf@gmx.net>
References: <m2zlj1ltk3.fsf@gmx.net>
Message-ID: <20081212211253.16431084@whitehouse.id.au>

On Thu, 11 Dec 2008 23:51:56 -0800
Albert Krewinkel <krewinkel at gmx.net> wrote:

> I've added primitive bash completion to clbuild.  To test/use it, change
> to the clbuild directory and do
> $ . clbuild-bash-completion.sh
> 
> It's not much of a useful feature, but I found it to be worthwhile at
> times.  Still needs work, though.  Constructive criticsm and comments
> are welcome.

Looks good.

I literally just sat down this evening to start adding bash completion.

I have got a patch in my repository that refactors the compgen code
into a single function.

Repository located at http://darcs.whitehouse.id.au/daniel/clbuild/.

> <demo>
> $ ./clbuild <TAB> <TAB>
> --help            diff              list              slime
> --implementation  help              preloaded         uninstall
> --long-help       install           recompile         update
> check             lisp              run               

A misnamed variable has broken this.  Also have a patch for this in my
repository.

> $ ./clbuild --implementation <TAB> <TAB>
> ccl    clisp  ecl    sbcl   
> 
> $ ./clbuild --implementation sbcl s<TAB>
> $ ./clbuild --implementation sbcl slime

I can't work out why exactly this isn't working for me.

The refactoring was an attempt to work out how to fix this.  It was a
little misguided initially as I thought I was trying to complete
projects :/

-- 
Daniel White



From budden-lisp at mail.ru  Mon Dec 15 07:41:54 2008
From: budden-lisp at mail.ru (budden)
Date: Mon, 15 Dec 2008 10:41:54 +0300
Subject: [clbuild-devel] my-projects?
Message-ID: <10445.081215@mail.ru>

Hallo there!
  I've noticed something like "my-projects" in clbuild source.
But it is not documented and it seems to have a bug in line
1478:

                    ;;
                --wnpp-projects)
                    extra="$extra $wnpp_projects"
                    shift
                    ;;
                --my-projects)
                    extra="$extra $wnpp_projects"
                    shift

It would be very convinient if I could have my own (local and
independent) files with dependencies and projects. It is easier for me
to enter dependencies manually than to download all the projects
to my HDD. I'm not sure automatic pathching mechanism is reliable
enough to keep the things ok. And if I do

And I want to publish my own dependencies to my users,
it is inconvinent and unsafe to require that they patch
autogenerated dependencies file.

How easy would it be to make "my-projects" work for projects and for
dependencies too? Sorry if it is a stupid question, but I'm not a bash
programmer...

-- 
Best regards,
 budden                          mailto:budden-lisp at mail.ru





From budden-lisp at mail.ru  Mon Dec 15 07:51:39 2008
From: budden-lisp at mail.ru (budden)
Date: Mon, 15 Dec 2008 10:51:39 +0300
Subject: [clbuild-devel] how to post fixes/additions?
Message-ID: <2452.081215@mail.ru>

Hallo one more time.
  I'd like to post some additions/fixes.

linedit_doc get_cvs_full :pserver:anonymous:anonymous at common-lisp.net:/project/linedit/cvsroot doc # two lines in projects. How to do it better?
qbook       get_darcs http://common-lisp.net/project/bese/repos/qbook # creating html/latex versions of source code
yaclml       get_darcs http://common-lisp.net/project/bese/repos/yaclml #generating XML/HTML
log5 get_darcs http://common-lisp.net/project/log5 # logging framework organized around five things: categories, outputs, senders, messages and contexts
cl-randist get_git http://lambdatau.com/git/cl-randist.git # random number distribution. Repo fails, download from http://code.google.com/p/cl-randist/
contextl get_darcs http://common-lisp.net/project/closer/repos/contextl/  # CLOS extension for Context-oriented Programming
cl-l10n get_darcs http://www.common-lisp.net/project/cl-l10n/repos/cl-l10n # localization
local-time get_darcs http://common-lisp.net/project/local-time/darcs/local-time # library for manipulating date and time information
cl-utilities get_cvs_clnet cl-utilities #Semi-standartized common lisp utilities

Fix:
# parenscript      get_git http://common-lisp.net/project/parenscript/git/parenscript failed
parenscript      get_darcs http://common-lisp.net/project/parenscript/repository/parenscript/

  Are clbuild developers interested in such?

-- 
Best regards,
 budden                          mailto:budden-lisp at mail.ru





From david at lichteblau.com  Mon Dec 15 08:51:15 2008
From: david at lichteblau.com (David Lichteblau)
Date: Mon, 15 Dec 2008 09:51:15 +0100
Subject: [clbuild-devel] how to post fixes/additions?
In-Reply-To: <2452.081215@mail.ru>
References: <2452.081215@mail.ru>
Message-ID: <20081215085115.GA13955@radon>

Hi,

Quoting budden (budden-lisp at mail.ru):
> Hallo one more time.
>   I'd like to post some additions/fixes.

the best way to post patches is to record them using
  darcs record
and then attach the diff generated by
  darcs diff
to your mails.  Alternatively, you can also just publish your repository
on any web server, so that we can pull from it.

However, it's best to follow these guidelines:


 * Please minimize changes per patch.

   If ten projects got added, it's better to record ten individual
   patches rather than one big change, so that we can cherry-pick
   changes individually.

 * Please don't record changes to the 'dependencies' file in the same step.

   I record dependencies myself, so I don't need the diff for the file
   at all.

I know this means a little more work for patch submitters, but my own
time for clbuild hacking is also very limited, especially for projects I
don't use myself, so often I only find time to consider those patches
that come in small easy-to-digest chunks.

[...]
>   Are clbuild developers interested in such?

Most of those look interesting, yes.  Please submit them as outlined
above, so that we can apply them with your name on them.


Thanks,
d.



From david at lichteblau.com  Mon Dec 15 08:58:59 2008
From: david at lichteblau.com (David Lichteblau)
Date: Mon, 15 Dec 2008 09:58:59 +0100
Subject: [clbuild-devel] my-projects?
In-Reply-To: <10445.081215@mail.ru>
References: <10445.081215@mail.ru>
Message-ID: <20081215085859.GB13955@radon>

Quoting budden (budden-lisp at mail.ru):
>                 --my-projects)
>                     extra="$extra $wnpp_projects"
>                     shift

Looks like a bug to me.  Please submit a patch.

[...]
> How easy would it be to make "my-projects" work for projects and for
> dependencies too? Sorry if it is a stupid question, but I'm not a bash
> programmer...

I have not though much about this, but we record dependencies for each
project separately, so it should be possible to keep a file
  my-dependencies
separately from
  dependencies.

If we do that, perhaps we would also want to set up
  wnpp-dependencies
separately?  Not sure.

To reduce conflicts in dependencies, we might even abandon the
single-file approach completely and save the dependencies of each
$project into a file
  clbuild/dependencies/$project
(However, it's easy to forget the "darcs add" for that file when adding
new projects, so this could be more hassle than it's worth.)


Opinions?  Patches?
d.



From sky at viridian-project.de  Mon Dec 15 09:18:27 2008
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Mon, 15 Dec 2008 10:18:27 +0100 (CET)
Subject: [clbuild-devel] how to post fixes/additions?
In-Reply-To: <2452.081215@mail.ru>
References: <2452.081215@mail.ru>
Message-ID: <64279.88.73.241.125.1229332707.squirrel@mail.stardawn.org>


> Fix:
> # parenscript      get_git http://common-lisp.net/project/parenscript/git/parenscript
> failed
> parenscript      get_darcs
> http://common-lisp.net/project/parenscript/repository/parenscript/

The Darcs repo is dead. We need to have it point at the git repo
in any case.

It does work for me, so maybe cl.net was down when you tried it.

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From krewinkel at gmx.net  Mon Dec 15 09:25:00 2008
From: krewinkel at gmx.net (Albert Krewinkel)
Date: Mon, 15 Dec 2008 01:25:00 -0800
Subject: [clbuild-devel] my-projects?
In-Reply-To: <10445.081215@mail.ru> (budden's message of "Mon, 15 Dec 2008
	10:41:54 +0300")
References: <10445.081215@mail.ru>
Message-ID: <m2prjt4wpf.fsf@gmx.net>

budden <budden-lisp at mail.ru> writes:

>   I've noticed something like "my-projects" in clbuild source.
> But it is not documented 

Yeah, I really have to write better documentation.  I hope to fix that
Real Soon Now.

> and it seems to have a bug in line
> 1478:
>
>                     ;;
>                 --wnpp-projects)
>                     extra="$extra $wnpp_projects"
>                     shift
>                     ;;
>                 --my-projects)
>                     extra="$extra $wnpp_projects"
>                     shift

Whoops.  Sloppy copy and pasting on my side.  Fixed that, thanks for
noticing.

> It would be very convinient if I could have my own (local and
> independent) files with dependencies and projects. It is easier for me
> to enter dependencies manually than to download all the projects
> to my HDD. I'm not sure automatic pathching mechanism is reliable
> enough to keep the things ok. And if I do
>
> And I want to publish my own dependencies to my users,
> it is inconvinent and unsafe to require that they patch
> autogenerated dependencies file.
>
> How easy would it be to make "my-projects" work for projects and for
> dependencies too?

I just compiled a quick patch and pushed it to the public repo: You can
put your own projects in `my-projects' and your dependencies in
`my-dependencies'.  There is no automatic dependency-recording for you
personal projects, so you have to keep track of them yourself.

Cheers,
Albert



From krewinkel at gmx.net  Mon Dec 15 09:39:03 2008
From: krewinkel at gmx.net (Albert Krewinkel)
Date: Mon, 15 Dec 2008 01:39:03 -0800
Subject: [clbuild-devel] restructuring code oranization, was: my-projects?
In-Reply-To: <20081215085859.GB13955@radon> (David Lichteblau's message of
	"Mon, 15 Dec 2008 09:58:59 +0100")
References: <10445.081215@mail.ru> <20081215085859.GB13955@radon>
Message-ID: <m2iqpl4w20.fsf_-_@gmx.net>

David Lichteblau <david at lichteblau.com> writes:

> If we do that, perhaps we would also want to set up
>   wnpp-dependencies
> separately?  Not sure.
>
> To reduce conflicts in dependencies, we might even abandon the
> single-file approach completely and save the dependencies of each
> $project into a file
>   clbuild/dependencies/$project
> (However, it's easy to forget the "darcs add" for that file when adding
> new projects, so this could be more hassle than it's worth.)
>
> Opinions?  Patches?
> d.

I like that idea and may give it a shot as soon as I find the time.

Which brings me to a different topic: Is there a specific reason, that
the clbuild-script is a single file, or did it just grow organicaly that
way?  I ask, since I'd prefer having a `scripts' directory and a main
programm calling only the scripts which are needed.  This could bring
the advantage of somewhat cleaner code at times (at least my
contributions are more of a mess than they have to be due to the current
one-file approach).




From david at lichteblau.com  Mon Dec 15 10:19:42 2008
From: david at lichteblau.com (David Lichteblau)
Date: Mon, 15 Dec 2008 11:19:42 +0100
Subject: [clbuild-devel] restructuring code oranization,
	was: my-projects?
In-Reply-To: <m2iqpl4w20.fsf_-_@gmx.net>
References: <10445.081215@mail.ru> <20081215085859.GB13955@radon>
	<m2iqpl4w20.fsf_-_@gmx.net>
Message-ID: <20081215101941.GC13955@radon>

Quoting Albert Krewinkel (krewinkel at gmx.net):
> David Lichteblau <david at lichteblau.com> writes:
> 
> > If we do that, perhaps we would also want to set up
> >   wnpp-dependencies
> > separately?  Not sure.
> >
> > To reduce conflicts in dependencies, we might even abandon the
> > single-file approach completely and save the dependencies of each
> > $project into a file
> >   clbuild/dependencies/$project
[...]
> I like that idea and may give it a shot as soon as I find the time.

Attached a quick patch to auto-generate my-dependencies.  I didn't push
it yet, but it might be useful as inspiration for other changes.

> Which brings me to a different topic: Is there a specific reason, that
> the clbuild-script is a single file, or did it just grow organicaly that
> way?  I ask, since I'd prefer having a `scripts' directory and a main
> programm calling only the scripts which are needed.  This could bring
> the advantage of somewhat cleaner code at times (at least my
> contributions are more of a mess than they have to be due to the current
> one-file approach).

Once upon a time, I proposed such a split-up, but didn't get any
responses, so I didn't go through with it.  There weren't any objections
either though, and I'm still in favour of it, so if you want to do, just
go ahead and push your changes.


d.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auto-my-dependencies.patch
Type: text/x-diff
Size: 32166 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/clbuild-devel/attachments/20081215/b246714e/attachment.patch>

From budden-lisp at mail.ru  Mon Dec 15 13:12:06 2008
From: budden-lisp at mail.ru (budden)
Date: Mon, 15 Dec 2008 16:12:06 +0300
Subject: [clbuild-devel] how to post fixes/additions?
In-Reply-To: <64279.88.73.241.125.1229332707.squirrel@mail.stardawn.org>
References: <64279.88.73.241.125.1229332707.squirrel@mail.stardawn.org>
Message-ID: <4675.081215@mail.ru>

Hallo all,

>> # parenscript      get_git http://common-lisp.net/project/parenscript/git/parenscript
>> failed
>> parenscript      get_darcs
>> http://common-lisp.net/project/parenscript/repository/parenscript/

LPP> The Darcs repo is dead. We need to have it point at the git repo
LPP> in any case.
Git starts to work for me, but after
printing some abracadabra for a minute or so, it says:

error: Couldn't get
http://common-lisp.net/project/parenscript/git/parenscript//refs/tags/parenscript-20070720 for tags/parenscript-20070720
The requested URL returned error: 404
error: Could not interpret tags/parenscript-20070720 as something to pull

Darcs works well.

-- 
Best regards,
 budden                            mailto:budden-lisp at mail.ru





From david at lichteblau.com  Mon Dec 15 13:19:00 2008
From: david at lichteblau.com (David Lichteblau)
Date: Mon, 15 Dec 2008 14:19:00 +0100
Subject: [clbuild-devel] how to post fixes/additions?
In-Reply-To: <4675.081215@mail.ru>
References: <64279.88.73.241.125.1229332707.squirrel@mail.stardawn.org>
	<4675.081215@mail.ru>
Message-ID: <20081215131900.GD13955@radon>

Quoting budden (budden-lisp at mail.ru):
> Git starts to work for me, but after
> printing some abracadabra for a minute or so, it says:
> 
> error: Couldn't get
> http://common-lisp.net/project/parenscript/git/parenscript//refs/tags/parenscript-20070720 for tags/parenscript-20070720
> The requested URL returned error: 404
> error: Could not interpret tags/parenscript-20070720 as something to pull

I can't reproduce that.  Make sure your git is reasonably recent, and
try "clbuild trash parenscript" to get rid of any existing broken
checkout you might have.

BTW, I think should we should have a policy against git repositories
using http:// URLs.  It's very easy to set up automatic repo.or.cz
mirrors for those projects, and cloning from those using git:// tends to
be faster and more reliable in my experience.  (Some of the projects
affected are my own repositories.  I'll move them sometime soon.)



From daniel at whitehouse.id.au  Mon Dec 15 13:16:14 2008
From: daniel at whitehouse.id.au (Daniel White)
Date: Mon, 15 Dec 2008 23:16:14 +1000
Subject: [clbuild-devel] how to post fixes/additions?
In-Reply-To: <4675.081215@mail.ru>
References: <64279.88.73.241.125.1229332707.squirrel@mail.stardawn.org>
	<4675.081215@mail.ru>
Message-ID: <20081215231614.68fa6b82@whitehouse.id.au>

On Mon, 15 Dec 2008 16:12:06 +0300
budden <budden-lisp at mail.ru> wrote:

> Hallo all,
> 
> >> # parenscript      get_git http://common-lisp.net/project/parenscript/git/parenscript
> >> failed
> >> parenscript      get_darcs
> >> http://common-lisp.net/project/parenscript/repository/parenscript/
> 
> LPP> The Darcs repo is dead. We need to have it point at the git repo
> LPP> in any case.
> Git starts to work for me, but after
> printing some abracadabra for a minute or so, it says:
> 
> error: Couldn't get
> http://common-lisp.net/project/parenscript/git/parenscript//refs/tags/parenscript-20070720 for tags/parenscript-20070720
> The requested URL returned error: 404
> error: Could not interpret tags/parenscript-20070720 as something to pull
> 
> Darcs works well.
> 

FWIW git works perfectly for me.  What version of git are you running?

-- 
Daniel White



From budden-lisp at mail.ru  Tue Dec 16 17:19:48 2008
From: budden-lisp at mail.ru (budden)
Date: Tue, 16 Dec 2008 20:19:48 +0300
Subject: [clbuild-devel] Recursive search for dependencies
In-Reply-To: <20081215231614.68fa6b82@whitehouse.id.au>
References: <20081215231614.68fa6b82@whitehouse.id.au>
Message-ID: <12847.081216@mail.ru>

Hi there!
  Am I right that "sh clbuild install/update system" will update only
direct dependencies of that system and do not recurse dependency tree?
I found that unexpected and unconvinient - make software usually
operates on dependency tree in a recursive manner.  First of all, I
can not install directly just the libraries that I need. Either I need
to install everything, or go through "install-require-see backtrace"
loop.

  First of all, I think this feature should be noted at manual page,
as most user would expect recursive behaviour. It is mentioned
that "non-transitive dependency is not a bug", but it is only a weak
hint.

  Second, I made a workaround. It is a lisp program, which can be
launched with

sh clbuild run show-deps-on-system system-name [dependency-file-name  ...]

  It walks dependency files and collects all direct and indirect dependencies
of the system given to a single dependency line. This line can be
inserted into dependency file, e.g. with command

sh clbuild run show-deps-on-system my-system | tail -1 >> my-dependencies

  and by subsequent removing of original dependency line (which can be made just
by manual processing of .asd file).

  I know this functionality is a subset of "sh clbuild
record-dependencies", but some users (me) do not need all libraries
installed.

  I can send a patch (it is a patch to clbuild.lisp and to clbuild).

  Is it interesting?


-- 
Best regards,
 budden                            mailto:budden-lisp at mail.ru





From david at lichteblau.com  Tue Dec 16 18:30:20 2008
From: david at lichteblau.com (David Lichteblau)
Date: Tue, 16 Dec 2008 19:30:20 +0100
Subject: [clbuild-devel] Recursive search for dependencies
In-Reply-To: <12847.081216@mail.ru>
References: <20081215231614.68fa6b82@whitehouse.id.au> <12847.081216@mail.ru>
Message-ID: <20081216183019.GA32205@radon>

Quoting budden (budden-lisp at mail.ru):
>   Am I right that "sh clbuild install/update system" will update only
> direct dependencies of that system and do not recurse dependency tree?

"clbuild install" doesn't install systems, it installs projects.
Projects can contain multiple systems.  System dependencies are
transitive and acyclic; project dependencies are not necessarily
transitive and can be cyclic.  Project dependencies always agree with
system dependencies if every project contains only one system.

Please refer to the FAQ at:
http://common-lisp.net/project/clbuild/#faq_dependency_details

[...]
>   First of all, I think this feature should be noted at manual page,
> as most user would expect recursive behaviour. It is mentioned
> that "non-transitive dependency is not a bug", but it is only a weak
> hint.

Back then, I've given my best to explain this in the FAQ.  I don't know
what else to write on the subject.

>   Second, I made a workaround. It is a lisp program, which can be
> launched with
[...]

Please explain what your intention is.

If project FOO has a system file foo.asd, and you do 

  $ clbuild install foo
followed by
  CL-USER> (asdf:operate 'asdf:load-op :foo)

the first step is meant to install all projects required for the second
step to work.

>From your mail I'm not sure whether you are
  a) reporting a bug (i.e. our dependency guessing logic got something
     wrong and the design goal above was violated)
or
  b) requesting a feature (you think that the design goal above isn't
     sufficient)
     
If you are reporting a bug, please explain for which project our
dependency file is incorrect (of course, a patch is even better).

If you are requesting a change in behaviour, I suggest a command line
argument (say, --follow-auxiliary-dependencies) that joins the
dependencies.  This could be implemented in the shell script.


d.



From budden-lisp at mail.ru  Tue Dec 16 23:55:16 2008
From: budden-lisp at mail.ru (budden)
Date: Wed, 17 Dec 2008 02:55:16 +0300
Subject: [clbuild-devel] Recursive search for dependencies
In-Reply-To: <20081216183019.GA32205@radon>
References: <20081216183019.GA32205@radon>
Message-ID: <9121.081217@mail.ru>

Hallo David, list

Tuesday, December 16, 2008, 9:30:20 PM, you wrote:

DL> Quoting budden (budden-lisp at mail.ru):
>>   Am I right that "sh clbuild install/update system" will update only
>> direct dependencies of that system and do not recurse dependency tree?
Well, I see I didnt' specify the problem with a sufficient details.
I'm talking about adding new projects which are currently not listed
in clbuild at all and can depend on some yet unlisted libraries.
In the situation, I look at .asd file, see dependencies, try
to identify projects, load the projects (I'm extremely reluctant
to load everything as I'm narrow in time and storage).

DL> "clbuild install" doesn't install systems, it installs projects.
DL> Projects can contain multiple systems.  System dependencies are
DL> transitive and acyclic; project dependencies are not necessarily
DL> transitive and can be cyclic.  Project dependencies always agree with
DL> system dependencies if every project contains only one system.

DL> Please refer to the FAQ at:
DL> http://common-lisp.net/project/clbuild/#faq_dependency_details
The only thing that is unclear (for me) is that this project of calculating
dependencies is runned when we invoke "rebuild-dependencies" (am I
right?). So, if I don't have all projects installed and I am reluctant to install
everything, I have to specify dependencies for my new system manually.
And I can not do it automatically until system is loaded.

So if I have .asd file and dependencies file, I have to traverse one level
of project dependency tree manually.

Well, I see I might confuse you completely. But I tried hard to
explain myself :)

DL> Please explain what your intention is.

DL> If project FOO has a system file foo.asd, and you do 

DL>   $ clbuild install foo
DL> followed by
DL>   CL-USER> (asdf:operate 'asdf:load-op :foo)

DL> the first step is meant to install all projects required for the second
DL> step to work.
You see now that it holds only for system/project which was processed by
rebuild-dependencies already, but not for my new project. So, I can't
know dependencies until I installed project and I can't install
project until I know dependencies.

DL> From your mail I'm not sure whether you are
DL>   a) reporting a bug (i.e. our dependency guessing logic got something
DL>      wrong and the design goal above was violated)
DL> or
DL>   b) requesting a feature (you think that the design goal above isn't
DL>      sufficient)
b)

DL> If you are requesting a change in behaviour, I suggest a command line
DL> argument (say, --follow-auxiliary-dependencies) that joins the
DL> dependencies.  This could be implemented in the shell script.
Yeah, but I didn't want to bother you asking and I was rushing, so I implemented it in
lisp which I know better than shell. Of course, command line switch would be better.

Thanks for fast reply!

-- 
Best regards,
 budden                            mailto:budden-lisp at mail.ru





From david at lichteblau.com  Wed Dec 17 07:52:49 2008
From: david at lichteblau.com (David Lichteblau)
Date: Wed, 17 Dec 2008 08:52:49 +0100
Subject: [clbuild-devel] Recursive search for dependencies
In-Reply-To: <9121.081217@mail.ru>
References: <20081216183019.GA32205@radon> <9121.081217@mail.ru>
Message-ID: <20081217075249.GA3820@radon>

Quoting budden (budden-lisp at mail.ru):
> The only thing that is unclear (for me) is that this project of
> calculating dependencies is runned when we invoke
> "rebuild-dependencies" (am I right?).  So, if I don't have all
> projects installed and I am reluctant to install everything, I have to
> specify dependencies for my new system manually.  And I can not do it
> automatically until system is loaded.

The patch I already sent to the list implementing a separate file
my-dependencies didn't help you at all?

Note that you don't have to run "clbuild record-dependencies" with that
patch, you can also run

  clbuild run record-dependencies "YOUR-PROJECT" YOUR-FILE

and it will write the dependencies of YOUR-PROJECT to YOUR-FILE.


d.



From budden-lisp at mail.ru  Wed Dec 17 08:04:02 2008
From: budden-lisp at mail.ru (Denis Bodyak)
Date: Wed, 17 Dec 2008 11:04:02 +0300
Subject: [clbuild-devel]
	=?koi8-r?b?UmVjdXJzaXZlIHNlYXJjaCBmb3IgZGVwZW5k?=
	=?koi8-r?b?ZW5jaWVz?=
Message-ID: <E1LCrNy-000N2i-00.budden-lisp-mail-ru@f60.mail.ru>

Hi David!

DL> The patch I already sent to the list implementing a separate file
DL> my-dependencies didn't help you at all?
Yeah, this helped a lot, thanks!

DL> Note that you don't have to run "clbuild record-dependencies" with that
DL> patch, you can also run
DL>   clbuild run record-dependencies "YOUR-PROJECT" YOUR-FILE
It's fine, but I didn't find it in a docs and I don't remember you
mentioned it before. If this feature present, no more patches are needed.

DL> and it will write the dependencies of YOUR-PROJECT to YOUR-FILE.

-- 
Best regards,
 budden                            mailto:budden-lisp at mail.ru




From sky at viridian-project.de  Fri Dec 19 10:23:01 2008
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Fri, 19 Dec 2008 11:23:01 +0100 (CET)
Subject: [clbuild-devel] [Fwd: Re: [elephant-devel] Problems with elephant
 on sbcl using postmodern]
Message-ID: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>

Hi,

more and more people seem to fall into the trap copied below.

Is there a reason for not making Elephant depend on UFFI?

  Thanks!

    Leslie

----------------------------------- Original Message -----------------------------------
Subject: Re: [elephant-devel] Problems with elephant on sbcl using postmodern
From:    "Hugo Duncan" <hugo_duncan at yahoo.com>
Date:    Fri, December 19, 2008 5:19 am
To:      "Elephant bugs and development" <elephant-devel at common-lisp.net>
----------------------------------------------------------------------------------------

That was painful.  clbuild includes a dependency for cffi for elephant, but
cffi-uffi-compat doesn't suffice.  Ensuring uffi was loaded got everything running for
me.

Hugo Duncan wrote:

> I am attempting to use Elephant (from clbuild) on SBCL (1.0.23.49 and
> 1.0.17) on OSX with postmodern and postgresql 8.3.
>
> OPEN-STORE is failing in INIT-ROOT, as below.


-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From david at lichteblau.com  Fri Dec 19 10:46:25 2008
From: david at lichteblau.com (David Lichteblau)
Date: Fri, 19 Dec 2008 11:46:25 +0100
Subject: [clbuild-devel] [Fwd: Re: [elephant-devel] Problems
	with	elephant on sbcl using postmodern]
In-Reply-To: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
References: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
Message-ID: <20081219104624.GC3820@radon>

Hi,

Quoting Leslie P. Polzer (sky at viridian-project.de):
> more and more people seem to fall into the trap copied below.
> 
> Is there a reason for not making Elephant depend on UFFI?

uffi isn't included in clbuild at all, hence no dependency.

I made the decision to use cffi's emulation instead of uffi because I
was under the impression that uffi is unmaintained legacy code and that
cffi-uffi-compat is a good replacement.  Shipping both cffi and uffi
seemed like a bad solution to me and still does.

Can the incompatibility that prompted your question be resolved by
fixing elephant and/or cffi-uffi-compat?

(Note that uffi is notorious for leaking the data structures of the
underlying Lisp implementation's FFI to the caller, so it's very easy to
write code using uffi that isn't actually portable across Lisps, and
such code won't run using cffi's emulation either.  Is this such a
case?)


d.



From sky at viridian-project.de  Fri Dec 19 10:57:26 2008
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Fri, 19 Dec 2008 11:57:26 +0100 (CET)
Subject: [clbuild-devel] [Fwd: Re: [elephant-devel] Problems
 with	elephant on sbcl using postmodern]
In-Reply-To: <20081219104624.GC3820@radon>
References: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
	<20081219104624.GC3820@radon>
Message-ID: <63268.88.73.218.138.1229684246.squirrel@mail.stardawn.org>


> I made the decision to use cffi's emulation instead of uffi because I
> was under the impression that uffi is unmaintained legacy code and that
> cffi-uffi-compat is a good replacement.  Shipping both cffi and uffi
> seemed like a bad solution to me and still does.
>
> Can the incompatibility that prompted your question be resolved by
> fixing elephant and/or cffi-uffi-compat?

Yes. The migration to CFFI is underway, but it's still a couple of
weeks until we can release it.

So it would be good to include UFFI and make Elephant depend
on it until the CFFI-based solution is integrated.


> (Note that uffi is notorious for leaking the data structures of the
> underlying Lisp implementation's FFI to the caller, so it's very easy to
> write code using uffi that isn't actually portable across Lisps, and
> such code won't run using cffi's emulation either.  Is this such a
> case?)

Elephant is portable across Lisps (where UFFI works).

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From david at lichteblau.com  Fri Dec 19 11:32:44 2008
From: david at lichteblau.com (David Lichteblau)
Date: Fri, 19 Dec 2008 12:32:44 +0100
Subject: [clbuild-devel] [Fwd: Re: [elephant-devel] Problems
	with	elephant on sbcl using postmodern]
In-Reply-To: <63268.88.73.218.138.1229684246.squirrel@mail.stardawn.org>
References: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
	<20081219104624.GC3820@radon>
	<63268.88.73.218.138.1229684246.squirrel@mail.stardawn.org>
Message-ID: <20081219113244.GD3820@radon>

Quoting Leslie P. Polzer (sky at viridian-project.de):
> Yes. The migration to CFFI is underway, but it's still a couple of
> weeks until we can release it.

Well, as far as I can tell from a superficial look at the code,
compatibility with cffi-uffi-compat wouldn't be about migration from
uffi to cffi, but rather about migration of all the non-portable #+sbcl
parts in memutil.lisp from aliens to saps.

But if the former is in progress anyway, the latter would also be
addressed, I guess.

Anyway, let's wait for elephant developers to finish their changes.

In the meantime, users who want to download elephant using clbuild can
continue to do so, and would just have to download uffi manually and
change the symlink.  Or contribute patches, for that matter.


d.



From sky at viridian-project.de  Fri Dec 19 11:58:20 2008
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Fri, 19 Dec 2008 12:58:20 +0100 (CET)
Subject: [clbuild-devel] [Fwd: Re: [elephant-devel] Problems with
 elephant on sbcl using postmodern]
In-Reply-To: <20081219113244.GD3820@radon>
References: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
	<20081219104624.GC3820@radon>
	<63268.88.73.218.138.1229684246.squirrel@mail.stardawn.org>
	<20081219113244.GD3820@radon>
Message-ID: <62038.88.73.218.138.1229687900.squirrel@mail.stardawn.org>


> In the meantime, users who want to download elephant using clbuild can
> continue to do so, and would just have to download uffi manually and
> change the symlink.  Or contribute patches, for that matter.

Yes, but we should at least provide a huge warning sign/comment out
Elephant.

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From david at lichteblau.com  Fri Dec 19 12:05:44 2008
From: david at lichteblau.com (David Lichteblau)
Date: Fri, 19 Dec 2008 13:05:44 +0100
Subject: [clbuild-devel] [Fwd: Re: [elephant-devel] Problems
	with	elephant on sbcl using postmodern]
In-Reply-To: <62038.88.73.218.138.1229687900.squirrel@mail.stardawn.org>
References: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
	<20081219104624.GC3820@radon>
	<63268.88.73.218.138.1229684246.squirrel@mail.stardawn.org>
	<20081219113244.GD3820@radon>
	<62038.88.73.218.138.1229687900.squirrel@mail.stardawn.org>
Message-ID: <20081219120544.GE3820@radon>

Quoting Leslie P. Polzer (sky at viridian-project.de):
> > In the meantime, users who want to download elephant using clbuild can
> > continue to do so, and would just have to download uffi manually and
> > change the symlink.  Or contribute patches, for that matter.
> 
> Yes, but we should at least provide a huge warning sign/comment out
> Elephant.

I agree.

That's why it's listed as a "work-needing or prospective project" as
opposed to a "main project".  That's our warning sign.


d.



From sky at viridian-project.de  Fri Dec 19 12:15:30 2008
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Fri, 19 Dec 2008 13:15:30 +0100 (CET)
Subject: [clbuild-devel] [Fwd: Re: [elephant-devel] Problems
 with	elephant on sbcl using postmodern]
In-Reply-To: <20081219120544.GE3820@radon>
References: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
	<20081219104624.GC3820@radon>
	<63268.88.73.218.138.1229684246.squirrel@mail.stardawn.org>
	<20081219113244.GD3820@radon>
	<62038.88.73.218.138.1229687900.squirrel@mail.stardawn.org>
	<20081219120544.GE3820@radon>
Message-ID: <63346.88.73.218.138.1229688930.squirrel@mail.stardawn.org>


> That's why it's listed as a "work-needing or prospective project" as
> opposed to a "main project".  That's our warning sign.

Sorry for pestering around, but how about giving a bit more
specific hints as to the pitfall?

Like "CFFI DOESN'T WORK, YOU NEED UFFI!"? :)

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From david at lichteblau.com  Fri Dec 19 12:36:47 2008
From: david at lichteblau.com (David Lichteblau)
Date: Fri, 19 Dec 2008 13:36:47 +0100
Subject: [clbuild-devel] [Fwd: Re: [elephant-devel] Problems
	with	elephant on sbcl using postmodern]
In-Reply-To: <63346.88.73.218.138.1229688930.squirrel@mail.stardawn.org>
References: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
	<20081219104624.GC3820@radon>
	<63268.88.73.218.138.1229684246.squirrel@mail.stardawn.org>
	<20081219113244.GD3820@radon>
	<62038.88.73.218.138.1229687900.squirrel@mail.stardawn.org>
	<20081219120544.GE3820@radon>
	<63346.88.73.218.138.1229688930.squirrel@mail.stardawn.org>
Message-ID: <20081219123647.GA7963@radon>

Quoting Leslie P. Polzer (sky at viridian-project.de):
> > That's why it's listed as a "work-needing or prospective project" as
> > opposed to a "main project".  That's our warning sign.
> 
> Sorry for pestering around, but how about giving a bit more
> specific hints as to the pitfall?
> 
> Like "CFFI DOESN'T WORK, YOU NEED UFFI!"? :)

I agree that the whole wnpp distinction is probably not clear enough to
users and would consider accepting a patch that refuses to download
-any- wnpp project without interactive confirmation by the user.  ("You
are about to download a WNPP project.  For details, see if there are
comments in the wnpp-projects file for this project.  If you know what
you're doing, type 'yes'".)

This would have to be overridable in clbuild.conf.

"CFFI DOESN'T WORK, YOU NEED UFFI!" could then go into wnpp-projects an
a comment.

I'm not too fond of the idea of displaying such comments automatically,
because it kind of implies that sb-alien use in elephant is the only
issue that we have with it in clbuild.  Which may or may not be the
case.  But if any clbuild maintainer had the time to say for sure, it
probably wouldn't be a wnpp project in the first place.  Also, such
comments tend to be out of date quickly, and are more harmful than
helpful then.


d.



From luismbo at gmail.com  Fri Dec 19 13:42:48 2008
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Fri, 19 Dec 2008 13:42:48 +0000
Subject: [clbuild-devel] [Fwd: Re: [elephant-devel] Problems with
	elephant on sbcl using postmodern]
In-Reply-To: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
References: <62435.88.73.218.138.1229682181.squirrel@mail.stardawn.org>
Message-ID: <391f79580812190542h6b7183d9u81a7f3d3b75f35ad@mail.gmail.com>

On Fri, Dec 19, 2008 at 10:23 AM, Leslie P. Polzer
<sky at viridian-project.de> wrote:
> That was painful.  clbuild includes a dependency for cffi for elephant, but
> cffi-uffi-compat doesn't suffice.  Ensuring uffi was loaded got everything running for
> me.

CFFI-UFFI-COMPAT is by no means perfect but, very often it finds bugs
in UFFI code. I.e., code that happens to work in, e.g., SBCL but
wouldn't work in other Lisps supported by UFFI. (In other occasions
people have found it to be much faster than UFFI.)  In any case, I'd
be interested in applying patches to fix any bugs cffi-uffi-compat, or
fix it myself if someone can describe the problem.

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/



From david at lichteblau.com  Mon Dec 22 10:02:00 2008
From: david at lichteblau.com (David Lichteblau)
Date: Mon, 22 Dec 2008 11:02:00 +0100
Subject: [clbuild-devel] Optional parameter for 'clbuild {prebuild,
	lisp}'
In-Reply-To: <m2fxlatpti.fsf@visnet-80.csl.sri.com>
References: <m263mazbjv.fsf@gmx.net> <m23ahbvy7x.fsf@visnet-80.csl.sri.com>
	<20081129104320.GA4527@radon>
	<m2fxlatpti.fsf@visnet-80.csl.sri.com>
Message-ID: <20081222100200.GA11792@radon>

Hi,

Quoting Albert Krewinkel (krewinkel at gmx.net):
> $ ./clbuild --implementation sbcl COMMAND 
> is now legal for the whole set of commands.  Someone with better English
> skills than me please have a look at the documentation I added to the
> long-help output.

I'm having so trouble with this, and I'm hesitant to randomly "fix" code
that I don't fully understand, so I hope that you can help me with it.

Here's the situation:

  * there's an SBCL compiled by clbuild in target/

  * clbuild is invoked as
      clbuild lisp
    or
      clbuild --implementation sbcl lisp

    or, in particular, "clbuild slime", which ends up using the latter
    form.

  * DEFAULT_IMPLEMENTATION is set to sbcl in clbuild.conf
  * SBCL isn't set in clbuild.conf

In this case, the SBCL from target/ should be used, but for some reason
that only works out for "clbuild lisp", not "clbuild --implementation
sbcl lisp".

I think the problem might be around here, where $SBCL is already set
properly, and then $1 takes precedence:

diff -rN -u old-clbuild/clbuild new-clbuild/clbuild
--- old-clbuild/clbuild	2008-12-22 10:51:48.000000000 +0100
+++ new-clbuild/clbuild	2008-12-22 10:51:48.000000000 +0100
@@ -282,7 +282,10 @@
     if [ -z "$SBCL" ]; then
         set_lisp_command sbcl
     fi
+    echo '$SBCL:' "$SBCL"
+    echo '$1:' "$1"
     lisp=${1:-$SBCL}
+    echo '$lisp:' "$lisp"
 
     noinform="--noinform"
     end_toplevel_options="--end-toplevel-options"

Output for the case that works:
  : david at lanthan:~; clbuild lisp
  $SBCL: /home/david/clbuild/target/bin/sbcl --core /home/david/clbuild/target/lib/sbcl/sbcl.core
  $1: 
  $lisp: /home/david/clbuild/target/bin/sbcl --core /home/david/clbuild/target/lib/sbcl/sbcl.core
  This is SBCL 1.0.23.62, an implementation of ANSI Common Lisp.
  More information about SBCL is available at <http://www.sbcl.org/>.

  SBCL is free software, provided as is, with absolutely no warranty.
  It is mostly in the public domain; some portions are provided under
  BSD-style licenses.  See the CREDITS and COPYING files in the
  distribution for more information.
  * 

Output for the case that doesn't work:
  : david at lanthan:~; clbuild --implementation sbcl lisp
  $SBCL: /home/david/clbuild/target/bin/sbcl --core /home/david/clbuild/target/lib/sbcl/sbcl.core
  $1: sbcl
  $lisp: sbcl
  /home/david/bin/clbuild: line 382: sbcl: command not found


Thanks,
d.



From krewinkel at gmx.net  Mon Dec 22 18:42:59 2008
From: krewinkel at gmx.net (Albert Krewinkel)
Date: Mon, 22 Dec 2008 10:42:59 -0800
Subject: [clbuild-devel] Optional parameter for 'clbuild {prebuild,
	lisp}'
In-Reply-To: <20081222100200.GA11792@radon> (David Lichteblau's message of
	"Mon, 22 Dec 2008 11:02:00 +0100")
References: <m263mazbjv.fsf@gmx.net> <m23ahbvy7x.fsf@visnet-80.csl.sri.com>
	<20081129104320.GA4527@radon> <m2fxlatpti.fsf@visnet-80.csl.sri.com>
	<20081222100200.GA11792@radon>
Message-ID: <m2vdtcf3v0.fsf@gmx.net>

Hello,

David Lichteblau <david at lichteblau.com> writes:

> Quoting Albert Krewinkel (krewinkel at gmx.net):
>> $ ./clbuild --implementation sbcl COMMAND 
>> is now legal for the whole set of commands.  Someone with better English
>> skills than me please have a look at the documentation I added to the
>> long-help output.
>
> I'm having so trouble with this, and I'm hesitant to randomly "fix" code
> that I don't fully understand, so I hope that you can help me with it.
>
> Here's the situation:
>
>   * there's an SBCL compiled by clbuild in target/
>
>   * clbuild is invoked as
>       clbuild lisp
>     or
>       clbuild --implementation sbcl lisp
>
>     or, in particular, "clbuild slime", which ends up using the latter
>     form.
>
>   * DEFAULT_IMPLEMENTATION is set to sbcl in clbuild.conf
>   * SBCL isn't set in clbuild.conf
>
> In this case, the SBCL from target/ should be used, but for some reason
> that only works out for "clbuild lisp", not "clbuild --implementation
> sbcl lisp".

[snip]

Strange. I was not able to reproduce this error on my machine.  The
problem seems to be in line 352:

  if [ ! -x "$lisp_command" ]; then
      lisp_command=""
  fi

this is supposed to catch errors like the one you describe.  What
happens when you type
$ [ -x sbcl ] || echo "dammit"

into your shell?

I added a little more documentation to those functions (pushed to
c-l.net repo, I hope they are at least somewhat helpful).  When doing
this, I noted quite a few shortcomings of my approach.  The whole
"--implementation" thingy should be rethought.  Maybe allowing
executables as parameters isn't such a good idea after all.

HTH
Albert



From david at lichteblau.com  Tue Dec 23 15:51:35 2008
From: david at lichteblau.com (David Lichteblau)
Date: Tue, 23 Dec 2008 16:51:35 +0100
Subject: [clbuild-devel] Optional parameter for 'clbuild {prebuild,
	lisp}'
In-Reply-To: <m2vdtcf3v0.fsf@gmx.net>
References: <m263mazbjv.fsf@gmx.net> <m23ahbvy7x.fsf@visnet-80.csl.sri.com>
	<20081129104320.GA4527@radon>
	<m2fxlatpti.fsf@visnet-80.csl.sri.com>
	<20081222100200.GA11792@radon> <m2vdtcf3v0.fsf@gmx.net>
Message-ID: <20081223155135.GA14033@radon>

Hi,

Quoting Albert Krewinkel (krewinkel at gmx.net):
> this is supposed to catch errors like the one you describe.  What
> happens when you type
> $ [ -x sbcl ] || echo "dammit"
> 
> into your shell?

it prints nothing, because I'm starting clbuild from my home directory,
and there is a directory ~/sbcl/ with SBCL sources in it, which has the
execute bit (i.e., search bit) set.


d.



From krewinkel at gmx.net  Tue Dec 23 18:36:17 2008
From: krewinkel at gmx.net (Albert Krewinkel)
Date: Tue, 23 Dec 2008 10:36:17 -0800
Subject: [clbuild-devel] Optional parameter for 'clbuild {prebuild,
	lisp}'
In-Reply-To: <20081223155135.GA14033@radon> (David Lichteblau's message of
	"Tue, 23 Dec 2008 16:51:35 +0100")
References: <m263mazbjv.fsf@gmx.net> <m23ahbvy7x.fsf@visnet-80.csl.sri.com>
	<20081129104320.GA4527@radon> <m2fxlatpti.fsf@visnet-80.csl.sri.com>
	<20081222100200.GA11792@radon> <m2vdtcf3v0.fsf@gmx.net>
	<20081223155135.GA14033@radon>
Message-ID: <m2tz8u91su.fsf@gmx.net>

David Lichteblau <david at lichteblau.com> writes:

> Hi,
>
> Quoting Albert Krewinkel (krewinkel at gmx.net):
>> this is supposed to catch errors like the one you describe.  What
>> happens when you type
>> $ [ -x sbcl ] || echo "dammit"
>> 
>> into your shell?
>
> it prints nothing, because I'm starting clbuild from my home directory,
> and there is a directory ~/sbcl/ with SBCL sources in it, which has the
> execute bit (i.e., search bit) set.
>
>
> d.

D'OH, never thought of this.  Changing the test to 
   [ -d "$lisp_command" -o ! -x "$lisp_command" ]
fixes this.  I'm going to upload that in a second.

Nevertheless, the whole thing remains rather buggy.  Let's see if I can
clean it up over the holidays.

cheers,
 Albert



From david at lichteblau.com  Tue Dec 23 18:48:26 2008
From: david at lichteblau.com (David Lichteblau)
Date: Tue, 23 Dec 2008 19:48:26 +0100
Subject: [clbuild-devel] Optional parameter for 'clbuild {prebuild,
	lisp}'
In-Reply-To: <m2tz8u91su.fsf@gmx.net>
References: <m263mazbjv.fsf@gmx.net> <m23ahbvy7x.fsf@visnet-80.csl.sri.com>
	<20081129104320.GA4527@radon>
	<m2fxlatpti.fsf@visnet-80.csl.sri.com>
	<20081222100200.GA11792@radon> <m2vdtcf3v0.fsf@gmx.net>
	<20081223155135.GA14033@radon> <m2tz8u91su.fsf@gmx.net>
Message-ID: <20081223184826.GB12494@radon>

Quoting Albert Krewinkel (krewinkel at gmx.net):
> D'OH, never thought of this.  Changing the test to 
>    [ -d "$lisp_command" -o ! -x "$lisp_command" ]
> fixes this.  I'm going to upload that in a second.
> 
> Nevertheless, the whole thing remains rather buggy.  Let's see if I can
> clean it up over the holidays.

Thank you, that would be great.

I'm probably belaboring the point needlessly by now, but note that any
other executable that "happens" to be called $lisp_command would have
the same issue, since [ -x ] looks for files in the current directory,
but the current directory isn't usually in the $PATH on Unix.

Anyway, I basically only care about "clbuild slime", which shouldn't
call out to "clbuild --implementation ANYTHING lisp" if that ANYTHING
doesn't do the same thing that "clbuild lisp" would have done.


d.



From daniel at whitehouse.id.au  Wed Dec 24 09:39:11 2008
From: daniel at whitehouse.id.au (Daniel White)
Date: Wed, 24 Dec 2008 19:39:11 +1000
Subject: [clbuild-devel] Include completion support for the recompile command
Message-ID: <20081224193911.1ad315aa@whitehouse.id.au>

There is a patch to add this in my repository.  

To reuse _clbuild_projects I've changed it so that it only includes
project groups only when the first paramter isn't empty (e.g.
_clbuild_projects "+groups").

Is this overly convoluted?

-- 
Daniel White
darcsweb: http://darcs.whitehouse.id.au/



From scott.clbuild at h4ck3r.net  Wed Dec 31 19:38:33 2008
From: scott.clbuild at h4ck3r.net (Scott Graham)
Date: Wed, 31 Dec 2008 11:38:33 -0800
Subject: [clbuild-devel] patch to add cl-cairo2 to projects
Message-ID: <84decce20812311138g4fcb7df6l5fd46647495a5a2@mail.gmail.com>

Hi

Attached is a patch to add cl-cairo2 to the list of projects (along
with a few of its dependencies). "Works for me" on sbcl 1.0.18, ubuntu
x64 & x86.

scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_cl-cairo2.patch
Type: text/x-patch
Size: 475 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/clbuild-devel/attachments/20081231/8fc3cb20/attachment.bin>

From daniel at whitehouse.id.au  Wed Dec 31 20:22:55 2008
From: daniel at whitehouse.id.au (Daniel White)
Date: Thu, 1 Jan 2009 06:22:55 +1000
Subject: [clbuild-devel] Pending patches (completion support / libraries)
Message-ID: <20090101062255.4bc2e62a@whitehouse.id.au>

* Include completion support for the show command
* Added cl-utilities
* Include completion support for the recompile command

They are only in '--long-help' but I've personally been using them often
enough to want completion.

These can be pulled from my repository at:
http://darcs.whitehouse.id.au/daniel/clbuild/

-- 
Daniel White



From daniel at whitehouse.id.au  Wed Dec 31 20:26:39 2008
From: daniel at whitehouse.id.au (Daniel White)
Date: Thu, 1 Jan 2009 06:26:39 +1000
Subject: [clbuild-devel] patch to add cl-cairo2 to projects
In-Reply-To: <84decce20812311138g4fcb7df6l5fd46647495a5a2@mail.gmail.com>
References: <84decce20812311138g4fcb7df6l5fd46647495a5a2@mail.gmail.com>
Message-ID: <20090101062639.5270ccb7@whitehouse.id.au>

On Wed, 31 Dec 2008 11:38:33 -0800
"Scott Graham" <scott.clbuild at h4ck3r.net> wrote:

> Attached is a patch to add cl-cairo2 to the list of projects (along
> with a few of its dependencies). "Works for me" on sbcl 1.0.18, ubuntu
> x64 & x86.

A few things:

- New projects are generally added to wnpp-projects first,
- trivial-garbage already exists, and
- common-lisp.net cvs projects have a shortcut: 'get_cvs_clnet'.

-- 
Daniel White