From: David Steuber
Subject: SBCL CVS repository being unfriendly?
Date:
Message-ID: <878ynurtna.fsf@verizon.net>
$ cvs ····················@cvs.sourceforge.net:/cvsroot/sbcl login
Logging in to ··················@cvs.sourceforge.net:2401/cvsroot/sbcl
CVS password:
cvs [login aborted]: unrecognized auth response from
cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect
(Connection refused)
Am I doing something wrong here? Will this be fixed if I am not? I
would like to work with the CVS version of SBCL if I may.
I did manage to download 0.8.4. I have no idea how old that is vs the
CVS version.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
David Steuber <·············@verizon.net> writes:
> cvs [login aborted]: unrecognized auth response from
> cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect
> (Connection refused)
>
> Am I doing something wrong here? Will this be fixed if I am not? I
> would like to work with the CVS version of SBCL if I may.
It's a general (though, we are assured, transient) problem with all
sourceforge-hosted projects just now. Too much load for too little
hardware.
> I did manage to download 0.8.4. I have no idea how old that is vs the
> CVS version.
About ten days or so. Unless you're going to stress the
multithreading, you may not even notice the difference. If you are
going to stress the multithreading, the summary is that they fall over
in different though equally exciting ways.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: David Steuber
Subject: Re: SBCL CVS repository being unfriendly?
Date:
Message-ID: <m2ismsvrv7.fsf@verizon.net>
Sorry for taking so long to reply to this. I've moved GNUS from my
Debian Linux box to My OS X thin sliver and lost track of my threads
along the way...
Daniel Barlow <···@telent.net> writes:
> David Steuber <·············@verizon.net> writes:
> > Am I doing something wrong here? Will this be fixed if I am not? I
> > would like to work with the CVS version of SBCL if I may.
>
> It's a general (though, we are assured, transient) problem with all
> sourceforge-hosted projects just now. Too much load for too little
> hardware.
Ok, I guess that would explain it. Would lending an HP-48 calculator
to the effort help? It needs new batteries. Other than that, it
still runs strong.
> > I did manage to download 0.8.4. I have no idea how old that is vs the
> > CVS version.
>
> About ten days or so. Unless you're going to stress the
> multithreading, you may not even notice the difference. If you are
> going to stress the multithreading, the summary is that they fall over
> in different though equally exciting ways.
Well, I guess I can live with that for a little while. I would like
to track the CVS version though.
I still need to get ILISP setup.
People say the Mac is easy. They are either a bunch of liars or they
are not using the machine to do anything other than run iTunes.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
David Steuber <·············@verizon.net> writes:
> > About ten days or so. Unless you're going to stress the
> > multithreading, you may not even notice the difference. If you are
> > going to stress the multithreading, the summary is that they fall over
> > in different though equally exciting ways.
>
> Well, I guess I can live with that for a little while. I would like
> to track the CVS version though.
If you're on a Mac, you're not going to get multithreading anyway
(unlikely to happen before next year unless someone more clever and
industrious than I takes a serious interest), so no need to follow the
bleeding edge.
> I still need to get ILISP setup.
>
> People say the Mac is easy. They are either a bunch of liars or they
> are not using the machine to do anything other than run iTunes.
I find it quite easy, both for running iTunes and for hacking on SBCL
in Emacs (and many other things beside, of course). I don't use ILISP,
though.
--
Patrik Nordebo
From: David Steuber
Subject: Re: SBCL CVS repository being unfriendly?
Date:
Message-ID: <m2zng3r3wn.fsf@verizon.net>
······@nordebo.com writes:
> If you're on a Mac, you're not going to get multithreading anyway
> (unlikely to happen before next year unless someone more clever and
> industrious than I takes a serious interest), so no need to follow the
> bleeding edge.
At some point I would like to look into the implementation. However,
that could be so far down the road that the Universe is a cold dark
place by then.
How does SBCL gain access to threading? Is it using the pthreads
library? Or does it make system calls directly? Is threading being
abstracted to improve portability?
> > I still need to get ILISP setup.
> >
> > People say the Mac is easy. They are either a bunch of liars or they
> > are not using the machine to do anything other than run iTunes.
>
> I find it quite easy, both for running iTunes and for hacking on SBCL
> in Emacs (and many other things beside, of course). I don't use ILISP,
> though.
OK, for iTunes and reading Usenet in Emacs I do find it easy. I've
had some off-topic issues that are kinda annoying me.
What do you use instead of ILISP?
I have iTunes tuned into "dl.fm Vocal Trance" 128kbps stream right
now.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
David Steuber <·············@verizon.net> writes:
> How does SBCL gain access to threading? Is it using the pthreads
> library?
Nope. pthreads in Linux 2.2 (LinuxThreads) interacts really really
badly with signal handling, and SBCL has enough interesting use of
signals already.
> Or does it make system calls directly?
Yes. On x86 Linux (currently the only platform that supports threads)
it calls clone() to create new threads.
More information at http://sbcl-internals.cliki.net/Threading - see
especially the link to the UKUUG presentation (which is slightly out
of date now, but the basic rationale holds)
> Is threading being abstracted to improve portability?
That'll be something to do in the second or third port, not the first
one. Until it's been implemented a couple of times, who can say what
we get to abstract over?
> What do you use instead of ILISP?
Slime! (Not that this helps you immediately, because it's (a) alpha,
(b) unavailable anywhere at all until Sourceforge get their act
together, and (c) the SBCL port currently needs threads. (c) will
change, though, probably fairly soon after (b) does or if savannah
process our application to jump ship
Have some screenshots to whet your appetite, though:
http://ww.telent.net/diary/2003/10/#9.53338
http://ww.telent.net/diary/2003/10/#11.57761
http://ww.telent.net/diary/2003/10/#13.12494
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
Daniel Barlow <···@telent.net> writes:
> Nope. pthreads in Linux 2.2 (LinuxThreads) interacts really really
2.4 too. Unless you're running a patched kernel, the New Posix
Threading Library only works in 2.6. 2.6 might possibly just about be
ready by Christmas, but there'll be people expecting to use older
versions for a while even after that.
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
From: David Steuber
Subject: Re: SBCL CVS repository being unfriendly?
Date:
Message-ID: <m2k777nsnj.fsf@verizon.net>
Daniel Barlow <···@telent.net> writes:
> David Steuber <·············@verizon.net> writes:
>
> > Is threading being abstracted to improve portability?
>
> That'll be something to do in the second or third port, not the first
> one. Until it's been implemented a couple of times, who can say what
> we get to abstract over?
I guess you have a point. I thought perhaps there would be an API or
such thing that applications would call to be hidden from the gorry
details of how a particular kernel implements threading.
> > What do you use instead of ILISP?
>
> Slime! (Not that this helps you immediately, because it's (a) alpha,
> (b) unavailable anywhere at all until Sourceforge get their act
> together, and (c) the SBCL port currently needs threads. (c) will
> change, though, probably fairly soon after (b) does or if savannah
> process our application to jump ship
>
> Have some screenshots to whet your appetite, though:
>
> http://ww.telent.net/diary/2003/10/#9.53338
> http://ww.telent.net/diary/2003/10/#11.57761
> http://ww.telent.net/diary/2003/10/#13.12494
Slime? Never heard of it. Well, there was this stuff that came in
little plastic garbage can replicas that was sold as a toy. It was
very good as a carpet stain.
I've been concerned for a while now that so many projects seem to
rely on sourceforge. I can't imagine that the dot com crash is over.
Can I expect to have difficulty setting up ILISP for SBCL on my Mac?
Hmm. That sounds like I'm asking permission or something.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
David Steuber <·············@verizon.net> writes:
> Can I expect to have difficulty setting up ILISP for SBCL on my Mac?
> Hmm. That sounds like I'm asking permission or something.
No, this is a two-minute job. You just need to unpack ilisp in
the right directory (in my case, /usr/local/share/emacs/site-lisp),
modify the Makefile (set EMACS to /usr/local/bin/emacs), and type
make.
Then, in your emacs startup file, you should add something
like
(autoload 'openmcl "islip" "OpenMCL in ilisp" t)
(setq openmcl-program "/usr/local/bin/openmcl")
(autoload 'sbcl "ilisp" "SBCL in ilisp" t)
(setq sbcl-program "/usr/local/bin/sbcl")
Finally (and somewhat unrelated): asdf and asdf-install
absolutely rock... using these (and SBCL), fetching and installing CLX
and McCLIM is an absolute no-brainer. Good for me :-)
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
From: David Steuber
Subject: Re: SBCL CVS repository being unfriendly?
Date:
Message-ID: <m265iqnwqd.fsf@verizon.net>
Raymond Wiker <·············@fast.no> writes:
Thanks for the ILISP info...
> Finally (and somewhat unrelated): asdf and asdf-install
> absolutely rock... using these (and SBCL), fetching and installing CLX
> and McCLIM is an absolute no-brainer. Good for me :-)
I could use more no-brainer activities.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to bring them all and in the darkness bind them.
Class B NRA Rifle Silhouette shooter
There are no typos in this post. My spelling realy is that bad.
David Steuber writes:
> I've been concerned for a while now that so many projects seem to
> rely on sourceforge. I can't imagine that the dot com crash is over.
A Lispier alternative is Common-Lisp.net.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> writes:
> David Steuber writes:
>
>> I've been concerned for a while now that so many projects seem to
>> rely on sourceforge. I can't imagine that the dot com crash is over.
>
> A Lispier alternative is Common-Lisp.net.
Which, incidentally, SLIME has now been moved to.
http://common-lisp.net/project/slime/
(SLIME will almost certainly be part of the cirCLe CD, for anyone
who's interested)
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
David Steuber <·············@verizon.net> writes:
> What do you use instead of ILISP?
Currently, just plain emacs with no inferior Lisp, because I'm mostly
hacking the C parts of the SBCL runtime.
I'm planning on trying out SLIME as soon as the dependency on
threading is gone. Or I could try it out in OpenMCL.
--
Patrik Nordebo
······@nordebo.com writes:
> I'm planning on trying out SLIME as soon as the dependency on
> threading is gone.
Tomorrow, probably. It's a simple matter of patching, at this point.
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro