Hello all
I'd like some help about asdf, specifically, where
can I find it as the only download page for it as
returned by google is down (sourceforge).
I am shocked that the are no mirrors, is there no
one in the lisp community who mirrors things like asdf?
<rant>
On a related note, while I am falling ever more in love
with lisp as I learn more, I am rapidly losing patience
with the lisp "community", where everyone who writes
the tiniest little thing assumes that your entire
system is setup to exactly their specifications.
1. I downloaded sbcl, but it refuses to run as my
kernel is too old (linux 2.4)? Eh? Everything else
runs fine; why not just disable those features that
require 2.6, as I (and I'm not alone in this) got
fed up with the forever unstable 2.6 series and went
back to 2.4.
2. I downloaded cmucl, which works as advertised.
3. I tried using clsql with it, but apparently it needs
asdf-installer.
4. I downloaded the asdf-installer, but I *still* need
asdf itself (I'm a newbie, and I wasn't aware that
they come seperately, as none of the literature that
comes with stuff that uses asdf actually makes a point
of telling me what asdf actually is, they all assume
that I already know what asdf is).
5. I now try to download asdf itself, but there is only
a single site that has it for download (as serached by
google).
Whats the story here? Why make everything so convoluted?
Whats wrong a make-ish process for building? If asdf is
so damn nice, why don't all the lisps ship with it? If
it is actually that good, then why the hell don't the
people who distribute their stuff (like clsql) distribute
asdf as well? I looked through the .asd files, and it
seems that asdf is simply a brain-damaged replacement
for make (which, admittedly, is even more brain-damaged).
For building a lisp program (say, shipping a core file),
I'd have expected something thats make-like in use to be
better than something like asdf, which seems to have
set as a design goal Perls brain-damaged design/quasi-distro
methods.
</rant>
Now that I've let of a little steam (hey, I spend
hours just spinning wheels with lisp because I
*still* want to learn it), I can think of better ways
of source distribution that don't assume that your
target has *two* programs needed for build which are
distributed by *two* different sources. This current
method means that my target user has got to install:
1. my fav. lisp system (cos they are not easily interchangeable).
2. asdf (unattainable atm because only one source exists).
3. asdf-installer.
4. finally, they get to install my software.
Most users are going to give up long before #4. I suppose the
best thing to do (which no open-source lisp program that I know off
currently does) is to package #2, #3 and #4 up together, optionally
with #1 if the user wants. Why don't any lisp developers do this?
(Thats not rhetorical, btw; I'd really rather like to know).
goose
Hi,
I'm sorry you had such a rough time getting this working but things
are really not as bad as you think, although asdf.lisp only being
available from 1 advertised site is a pity and is something that
should be looked at.
I think the important point that you have missed is that asdf-install
is not at all required for building projects, only asdf is necessary.
asdf-install is for installing pre-packaged modules off some server,
and i'd be very surprised if clsql requires asdf-install to be present
in your lisp image in order to load it (i've run across no such
limitation)
Currently asdf is shipped with SBCL, OpenMCL, ECL and ACL,
which makes up a pretty large portion of the distro's available, and
is fast becoming (or has become) the defacto standard for describing
lisp systems.
The only problem you really have is not being able to get a copy of
asdf.lisp and email can sort that out pretty quickly (or look in your
sbcl distro for a copy :)
To answer your question, packaging asdf.lisp with your module is the
equivalent of including the make binary with your C source, it should
be unnecessary, you only need 1 copy of it (never mind possible
package conflicts), and asdf-install is a download manager with
aspirations to be a lisp version of apt (hopefully soon).
Cheers,
Sean.
Hello there,
Thanks for that well-reasoned response; Now that I've
calmed down a little, I must say that I didn't know
that I need a file asdf.lisp from the sbcl distro.
I'm afraid I posted really inflammatory material
above (twice, nogal!!!) and I'd like to apologise
to this group for my first post.
I really really *really* like this language, and while
I only started looking at it because it looked kinda
interesting, I'm now a total convert (pity that I
can't use it at work, though).
This isn't my first run-in with barriers to using
lisp, however; There are all sorts of things that
get in my way that are totally unrelated to the
actual language but that annoy me intensely; ASDF
was just the last in a long line of frustrations.
Why-oh-Why must every implementation make it so
difficult for fresh converts? What I'd really like
is something that would let me easily define a
system image and its components as easily as a Makefile
lets me define an executable (or library) name and its
components.
Say, something that lets me write:
(build-image "system.core"
(((targetsA) (dependenciesA) (cmdsA))
((targetsB) (dependenciesB) (cmdsB))
((targetsC) (dependenciesC) (cmdsC)))
I'd maintain a checksum for each target, so that I can
determine whether its been changed since the last time
it was loaded. Package management itself is not needed
if target-dependencies-cmds rules would let one do
implicit loading for a pattern of targets. Resolving
circular dependencies are also not needed (solve it the
way make does).
The .asd file I read through seems pretty convoluted in
comparison, although until I actually lay my hands on
asdf.lisp, I won't actually know for sure if it can be
used this simply.
In practice, an example (purely hypothetical):
(defparameter all-files (list
"eng-lng.lisp"
"zulu-lng.lisp"
"german-lng.lisp"
"util.lisp"
"pg-db.lisp"
"mysql-db.lisp"
"file-db.lisp"
"main.lisp"
"email.lisp"))
(build-image "system.core" :components all-files
; files ending in -lng.lisp needs the util file loaded
((("*-lng.lisp") ("util.lisp") (load "util.lisp"))
; util.lisp needs all the *-db files loaded
(("util.lisp") ("*-db.lisp") (#'lambda (dep) (load dep)))
; the default rule is to simply load the rest of the files needed
(("*.lisp") (nil) (#'lambda (target) (load target)))))
Yes, I know it uses the filenames, so just be consistent in
naming the files.
Anyway, does anyone want to post an alternate link to asdf.lisp?
tia
goose
goose wrote:
> Why-oh-Why must every implementation make it so
> difficult for fresh converts? What I'd really like
> is something that would let me easily define a
> system image and its components as easily as a Makefile
ahem. make and easily in the same sentence?
Oh, I see. You have been using make for ten years and asdf for ten
hours. Yes, you might not want to be so quick on the trigger of that
flamethrower. maybe wait /fifteen/ hours before damning Lisp tools to
eternal hell. :)
> lets me define an executable (or library) name and its
> components.
On win32, AllegroCL has what you are looking for. They have a free trial
edition that is not too crippled. I hear they have a Gtk-based version
of their IDE (not just their compiler) on Linux but I do not know more.
I know that is not much help, but you did say "every". :)
kenny
ps. Lispworks has trial editions with IDEs everywhere, but on the
specific issue of automated builds no help; you still use mk:defsystem
or asdf. k
>goose wrote:
>> Why-oh-Why must every implementation make it so
>> difficult for fresh converts? What I'd really like
>> is something that would let me easily define a
>> system image and its components as easily as a Makefile
>
>ahem. make and easily in the same sentence?
<blush>Yeah, yeah ... I know ... but really, I've
got fairly good reasons for saying that (see below).
>
>Oh, I see. You have been using make for ten years and asdf for ten
>hours. Yes, you might not want to be so quick on the trigger of that
>flamethrower. maybe wait /fifteen/ hours before damning Lisp tools to
>eternal hell. :)
OK OK!!! I *get* it ... I (inexcusably???? maybe...) flew
off the handle after being frustrated.
Please, don't hold this against me, I'm really an ok
bloke after a few hours of sleep :-)
My "justification" (I suppose you can call it that?) is
as follows:
Point 1
-------
I know that every lisp system will differ, in fact I
went into all of this understanding that they all *will*
differ. But, to keep some perspective, I've used gcc
(linux, windows, solaris and bsd), borland C builder
(windows), microsoft visual C (windows), cc (solaris),
topspeed (embedded x86), cosmic (embedded motorola),
borland C (embedded x86), uC[1] (8-bit PIC microcontrollers),
Turbo C(dos), vendor-I-can't-quite-remember (z80) and
probably a few others I don't, at this time, remember.
Some of those were hosted implementations and some were
freestanding implementations.
All of the C compilers (and related toolchains like
linkers, etc) above, without exception, were buildable
by make and make alone. The deviation of the tools above
vary much more than the deviation of any two lisp systems
using asdf, so I refuse to buy into the notion that a
lisp system *cannot* be designed to be built by make.
Oh sure, you cannot do it now because some have partially
sane c/line arguments (e.g. -compile) while others lack
c/line arguments to let you build a system (cmucl doesn't
have a c/line argument that will let me compile-file-and-save-
core-image in one go. If it did, then I could write a makefile
that will compile-file-and-save-core-image for each lisp
file in my project to end off with a single core image which
would have all the files loaded). The lisp systems all assume
that lisp is all thats ever needed, and so provide so very
few c/line options.
A slight modification to allow (for example) cmucl to have
a c/line argument to compile a file and save the resultant
image would let me write a makefile, but no lisp does this;
you have to do something like this :
echo -e "(load "filename")\n(initsavemem "image.mem")\n" | \
clisp -M image.mem
to get a single image from a makefile.
Point 2
-------
Make handles recursive builds, with recursive projects, with
deeply nested dependencies in a sane manner: i.e. you can
call make recursively. Now, I haven't as yet gotten my paws
on asdf, so I don't know how it handles recursive builds,
but I have to say that the first time I used make recursively,
I did not have to wonder whether it will work, it just did.
If I have a project which has common files in its root
directory, with a generic executable being generated in
the root directory, and two further subdirs (say ... one
for a gui-admin and for a clue-admin), I can write makefiles
for each subproject and know that my 3 executables will all
be generated by issuing 'make' in the root directory and that
they will all be in the correct directory. I only have to issue
a single ubiquitous command, not write a definition. I also
know that the sub-projects gui-admin and clue-admin will
build on their own without needing the parent project.
Does asdf handle this? Is it supposed to?
Point 3
-------
Make allows me to make great use of my existing system
(bash, grep, sed, awk, cut, sort, uniq, etc) to build
the project. I really doubt that asdf will allow me the same
flexibility (although, in all fairness, I will know when
I finally find time to play with it this weekend). Power
(in lisp) is useless if grep is missing, or if I cannot
redirect output to /dev/null for file handle 2.
Conclusion: I suppose I'm whining because I have this thing
I want to do, and the thing that is stopping me is not
a technical reason (my system cannot do it), or a philosophical
reason (I like/don't like the license) or even a stupidity
reason (I know how to do it); what is stopping me is a
system (lisp) that continously ignores anything non-lisp
(i.e. make), when for many purposes, make might just
work as well for smallish lisp libraries.
I Like Lisp. Lots ... But can we please just use the
normal unix tools when they make sense? Even windows has
msys to allow "./configure && make && make install"
(I used msys to compile gcl on windows, and it worked fine).
Anyway ... rant off ... you might even see me back here in
a week religously espousing the merits of asdf after I actually
get a chance to use it and find that it *really is* the best
thing since sliced bread:-) However, my original post was
to request an alternative download source for asdf, and no
one has yet pitched up to give me one, but I am being led
to believe that it is widespread?
C'mon folks ... if you all have it, then put it up for
download somewhere so that I don't have to rely on a single
point of failure.
[1] I don't quite remember this one, the name may be incorrect.
>
>> lets me define an executable (or library) name and its
>> components.
>
>On win32, AllegroCL has what you are looking for. They have a free trial
>edition that is not too crippled. I hear they have a Gtk-based version
>of their IDE (not just their compiler) on Linux but I do not know more.
>
>I know that is not much help, but you did say "every". :)
I will check it out when i'm ready to write commercial software
in lisp (cos there's no *way* that I am going to get familiar
with it and not like it even more than I do now, so I am going
to try and make money off it the minute I am capable of doing so).
>
>kenny
>
>ps. Lispworks has trial editions with IDEs everywhere, but on the
>specific issue of automated builds no help; you still use mk:defsystem
>or asdf. k
Thanks for the non-inflammatory response. Know where I can get asdf
other than at the offical site?
tia
goose
goose wrote:
> C'mon folks ... if you all have it, then put it up for
> download somewhere so that I don't have to rely on a single
> point of failure.
Oh, is /that/ all you want? I guess ASDF is bound to seem hard for
anyone who doees not even know how to Google "asdf lisp" and take the
first link offered:
http://www.cliki.net/asdf
<g>
Just to be cruel, it offers about ten ways to get ASDF. It may be a long
night for you.
kenny
Sadly, those are the links that don't work for me
(using lynx (not sure if that makes a difference)
and behind a firewall which only lets me out on
port 80).
I was looking for an *alternative*, say a mirror?
Is asdf not mirrored anywhere?
goose
"goose" <····@webmail.co.za> writes:
> Sadly, those are the links that don't work for me
> (using lynx (not sure if that makes a difference)
> and behind a firewall which only lets me out on
> port 80).
>
> I was looking for an *alternative*, say a mirror?
> Is asdf not mirrored anywhere?
If you're not able to figure out how to click on the "cached" link in
google, maybe you should consider a language that caters to that level
of hand-holding, like Logo.
>
>"goose" <····@webmail.co.za> writes:
>> Sadly, those are the links that don't work for me
>> (using lynx (not sure if that makes a difference)
>> and behind a firewall which only lets me out on
>> port 80).
>
>> I was looking for an *alternative*, say a mirror?
>> Is asdf not mirrored anywhere?
>If you're not able to figure out how to click on the "cached" link in
>google, maybe you should consider a language that caters to that level
>of hand-holding, like Logo.
>
<g>
Ok smartypants.
I clicked on the google cache, and then clicked on
the various links to download, but it still won't download.
(hint: before dismissing someone as "too silly to
even do this", maybe *you* should consider that
you aren't even in the running to understand the
problem.)
I thought I made it clear that "those links
don't work for me" in my previous post.
Anyone else here who *is* willing to point me to
a mirror which will simply let me click and download
a tarball or similar?
Sourceforge is nice, and all of that, but I have to
admit that I'm stumped by how asdf is only accessible
in a non-web format with no one willing to host
a mirror
(yes, yes ... I could download a browser other than
lynx and pester the security guys to punch a hole
in the firewall for whatever asdf is using, but I'd
that this "bug" in the distribution is fixed).
Man, give it to me already, I'd put it up for download
on my own site ... at least future would-be-lisp-programmers
won't have to interact with people like you (the others
like Ken Tilton, et al have genuinely tried to offer
helpful suggestions) as then a google search would reveal
more than a single source for it.
goose
ps. Don't knock logo; it's currently the best method
of teaching 10 year olds the *essence* of programming :-)
pps. The various implementations of it leave a lot to
be desired, though, although the kde one seems kinda nice.
"goose" <····@webmail.co.za> writes:
> I thought I made it clear that "those links
> don't work for me" in my previous post.
Does this link work for you?
<http://cclan.cvs.sourceforge.net/*checkout*/cclan/asdf/asdf.lisp?revision=1.97>
(It does for me, but you seem to change the rules of the game freely,
so all I can say is that I can't see any reason why that should fail
to work.)
> Sourceforge is nice, and all of that, but I have to admit that I'm
> stumped by how asdf is only accessible in a non-web format with no
> one willing to host a mirror
Google, and the rest of the web, will no doubt catch up with
Sourceforge's great rearrangement eventually; in case you are unaware,
sourceforge renamed all its CVS servers in the last couple of weeks,
which might be why some things appear "down". In the meantime, I hope
that you are unstumped, and that you can make some progress without
ranting again in public fora.
Christophe
Thanks. That link works just fine.
>
>> Sourceforge is nice, and all of that, but I have to admit that I'm
>> stumped by how asdf is only accessible in a non-web format with no
>> one willing to host a mirror
>Google, and the rest of the web, will no doubt catch up with
>Sourceforge's great rearrangement eventually; in case you are unaware,
I was.
> sourceforge renamed all its CVS servers in the last couple of weeks,
> which might be why some things appear "down".
I never noticed it with other projects on sourceforge (ecl comes
to mind); It could be because I use a mirror when the authoritative
source is down. ASDF has only *one* source, which I considered to
be the actual problem (since just about everything I want to download
to play with requires asdf). Hell, if its that important and that
good, then simply mirror it (release tarballs?).
>In the meantime, I hope
> that you are unstumped, and that you can make some progress without
> ranting again in public fora.
>
>
Sure; I humbly apologise for my ranting.
To be honest though, if I wanted a single-source-language,
I wouldn't be learning common lisp.
Anyway, thanks for the link, much appreciated.
goose
>>>>> "goose" == goose <····@webmail.co.za> writes:
goose> Point 2 ------- Make handles recursive builds, with
goose> recursive projects, with deeply nested dependencies in a
goose> sane manner: i.e. you can call make recursively. Now, I
http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html
I've been doing this for the years since I read this, but make is so
much of a hegemony that hardly anyone believes that a recursive make
is a bug and not a feature :)
Apologies for the off topic post, I don't really have any asdf pearls
to pass on.
Cheers!
Shyamal
"goose" <····@webmail.co.za> writes:
> difficult for fresh converts? What I'd really like
> is something that would let me easily define a
> system image and its components as easily as a Makefile
[...]
> In practice, an example (purely hypothetical):
[...]
> (build-image "system.core" :components all-files
By the way, if you use SBCL and are interested in application delivery see:
Saving a Core Image
http://www.sbcl.org/manual/Saving-a-Core-Image.html#Saving%20a%20Core%20Image
particularly the :EXECUTABLE argument.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
On 2006-05-23 12:10:17 -0400, Paolo Amoroso <·······@mclink.it> said:
> By the way, if you use SBCL and are interested in application delivery see:
>
> Saving a Core Image
> http://www.sbcl.org/manual/Saving-a-Core-Image.html#Saving%20a%20Core%20Image
>
> particularly the :EXECUTABLE argument.
And also be aware that on some platforms such as Fedora you'll have to
run sbcl (and any saved, :executable cores) with 'setarch i386',
effectively making you write a shell script that then runs the
"executable".
You'll also have to do this because --noinform isn't the default, even
on :executable's.
And the Windows beta of this feature still dumps debug output.
But yes, if you ignore Windows and don't mind also shipping a shell
script on several different Unix platforms then yes, it's easy to make
an executable.
:)
Novus
Novus <·····@ngoqde.org> writes:
> And also be aware that on some platforms such as Fedora you'll have to
> run sbcl (and any saved, :executable cores) with 'setarch i386',
> effectively making you write a shell script that then runs the
> "executable".
Do you mean "setarch -R i386"? That's no longer necessary in most
cases.
Zach
On 2006-05-23 19:13:59 -0400, Zach Beane <····@xach.com> said:
> Novus <·····@ngoqde.org> writes:
>
>> And also be aware that on some platforms such as Fedora you'll have to
>> run sbcl (and any saved, :executable cores) with 'setarch i386',
>> effectively making you write a shell script that then runs the
>> "executable".
>
> Do you mean "setarch -R i386"? That's no longer necessary in most
> cases.
No, I mean "setarch i386". And since exec shield is standard on Fedora
it's pretty much necessary on at least every Fedora box, plus other
systems that have applied the exec shield patch.
How does that translate into "no longer necessary in most cases"???
Novus
goose <····@webmail.co.za> wrote:
> 1. I downloaded sbcl, but it refuses to run as my
> kernel is too old (linux 2.4)? Eh? Everything else
> runs fine; why not just disable those features that
> require 2.6,
The pre-NPTL thread implementations on Linux are essentially unusable.
There used to be code in SBCL to detect at startup whether the system
had a working thread implementation, and disable threads in the latter
case. But it turns out that merely having a LinuxThreads libpthread
linked will cause all kinds of hard-to-debug trouble, so the decision
really needs to be done compile-time.
--
Juho Snellman
goose wrote:
> <rant>
> On a related note, while I am falling ever more in love
> with lisp as I learn more, I am rapidly losing patience
> with the lisp "community", where everyone who writes
> the tiniest little thing assumes that your entire
> system is setup to exactly their specifications.
Not so much anymore. I wanted to test the Lisp Application Builder
stuff in Linux:
(
http://svn.sourceforge.net/viewcvs.cgi/*checkout*/lispbuilder/trunk/documentation/index.html?rev=137
)
So I:
1) Downloaded and installed Fedora 5.
2) Made sure the latest version of SBCL and SDL were installed from the
RPMs.
3) Downloaded lispbuilder-sdl from sourceforge SVN, tar'ed and zipp'ed
it up (i.e. made it asdf-installable - the next version will packaged
as ASDF-INSTALLable).
4) Started SBCL and ASDF-INSTALLed the local lispbuilder-sdl.tgz
package
5) Ran the example SDL programs without a hiccup.
In a couple of days these steps will be reduced to:
1) Download and install Fedora 5.
2) Make sure the latest version of SBCL and SDL are installed using the
RPMs.
3) Start SBCL and ASDF-INSTALL will retrieve the lispbuilder-sdl
package from the cliki server
4) Run the example SDL programs.
-Luke
On 9483 day of my life ····@webmail.co.za wrote:
> 1. I downloaded sbcl, but it refuses to run as my
> kernel is too old (linux 2.4)? Eh? Everything else
> runs fine ...
Rebuild SBCL without threading support with CMUCL/CLISP.
> 3. I tried using clsql with it, but apparently it needs
> asdf-installer.
AFAIK it doesn't. All you need is ASDF.
> 5. I now try to download asdf itself, but there is only
> a single site that has it for download (as serached by
> google).
It is ASDF mantainer's site, isn't it? You don't need mirrors for
small files...
--
Ivan Boldyrev
Violets are red, Roses are blue. //
I'm schizophrenic, And so am I.