i am trying to install mudballs. now i have run (mb:self-update)
and get to
Downloading source for :BOOT 0.0.1 from http://mudballs.com/boot/boot.lisp.
with error:
FUNCALL: undefined function USOCKET:SOCKET-CONNECT
i see :sockets in *features* for whatever thats worth.
i am using slime and clisp on slackware. i have sbcl too if
that might work better. i am out of ideas.
thanks, david
On May 5, 8:17 pm, david <······@gmail.com> wrote:
> i am trying to install mudballs. now i have run (mb:self-update)
> and get to
> Downloading source for :BOOT 0.0.1 fromhttp://mudballs.com/boot/boot.lisp.
> with error:
> FUNCALL: undefined function USOCKET:SOCKET-CONNECT
>
> i see :sockets in *features* for whatever thats worth.
>
> i am using slime and clisp on slackware. i have sbcl too if
> that might work better. i am out of ideas.
>
> thanks, david
Hmm, thats quite strange as USOCKET is one of the core packages that
is distributed with mudballs. In a fresh Lisp session, what does
running (mb:load :usocket) produce?
On a side note you may get a quicker response if you post (or cross
post) mudballs issues to the mudballs google group.
- sean
On May 5, 5:55 pm, sross <······@gmail.com> wrote:
> On May 5, 8:17 pm, david <······@gmail.com> wrote:
>
> > i am trying to install mudballs. now i have run (mb:self-update)
> > and get to
> > Downloading source for :BOOT 0.0.1 fromhttp://mudballs.com/boot/boot.lisp.
> > with error:
> > FUNCALL: undefined function USOCKET:SOCKET-CONNECT
>
> > i see :sockets in *features* for whatever thats worth.
>
> > i am using slime and clisp on slackware. i have sbcl too if
> > that might work better. i am out of ideas.
>
> > thanks, david
>
> Hmm, thats quite strange as USOCKET is one of the core packages that
> is distributed with mudballs. In a fresh Lisp session, what does
> running (mb:load :usocket) produce?
>
> On a side note you may get a quicker response if you post (or cross
> post) mudballs issues to the mudballs google group.
>
> - sean
i get this:
CL-USER> (mb:load :usocket)
0 errors, 0 warnings
0 errors, 0 warnings
#<SYSDEF-USER::SERIAL-SYSTEM :USOCKET 0.4.1 #x20502346>
i was not aware there was a mudballs group. i will find it.
thanks, david
On May 5, 5:55 pm, sross <······@gmail.com> wrote:
> On May 5, 8:17 pm, david <······@gmail.com> wrote:
>
> > i am trying to install mudballs. now i have run (mb:self-update)
> > and get to
> > Downloading source for :BOOT 0.0.1 fromhttp://mudballs.com/boot/boot.lisp.
> > with error:
> > FUNCALL: undefined function USOCKET:SOCKET-CONNECT
>
> > i see :sockets in *features* for whatever thats worth.
>
> > i am using slime and clisp on slackware. i have sbcl too if
> > that might work better. i am out of ideas.
>
> > thanks, david
>
> Hmm, thats quite strange as USOCKET is one of the core packages that
> is distributed with mudballs. In a fresh Lisp session, what does
> running (mb:load :usocket) produce?
>
> On a side note you may get a quicker response if you post (or cross
> post) mudballs issues to the mudballs google group.
>
> - sean
on the way to my latest error message i got this:
FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not
exist
to which i did 3: [COMPILE-SYSTEM] Compile the component and retry.
then i proceed on to usocket problem.
On Tue, 5 May 2009 15:55:40 -0700 (PDT), <······@gmail.com> wrote:
>
Interesting name.
Just a side note on your three noted shortcomings of ASDF, the last two simply are not true.
Operations on components don't happen in the context of a call to the parent system.
Pervasive use of soft links makes Windows users second class citizens.
Inability to have multiple versions of the same system defined.
There is no requirement to use symlinks at all. danb happened to
mention that solution initially, but I have never had any symlinks
while using ASDF for the last 4 years. It's simple to build
ASDF:*CENTRAL-REGISTRY* dynamically.
; find the ASDF files in CMUCL
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defparameter *original-asdf-registry* ASDF:*CENTRAL-REGISTRY*)
; filenames, which work fine[1], make it easy to see what asdf files are active
(defun asdf-global-scanner ()
(directory
(make-pathname :directory
'(:absolute "usr" "local" "lib" "cmucl" "lib" "cmucl" "lib" "subsystems" :wild-inferiors)
:type "asd")))
(defun asdf-local-scanner ()
(directory
(make-pathname :directory
(append (pathname-directory "home:") (list ".lisp" :wild-inferiors))
:type "asd")))
(defun update-asdf-registry ()
(setf ASDF:*CENTRAL-REGISTRY*
(nconc (asdf-global-scanner)
(asdf-local-scanner)
*original-asdf-registry*)))
(update-asdf-registry)
Similar tricks work with other CLs and OS.
Since ASDF:*CENTRAL-REGISTRY* is searched in sequence, to work with
different versions just requires being first, I just handled this
above with a local version. Again, dynamic modification of
ASDF:*CENTRAL-REGISTRY* will produce the desired version.
Note that a second generation "ASDF" is still a good idea, and thanks
again for CL-Store.
[1] actually it's taking advantage of directories treated as files in
*nix and the need to have a trailing / in lisp for a directory.
Adding some code to truncate and remove duplicates is left as an
exercise for the reader.
--
Lisp: Powering `Impossible Thoughts since 1958
On May 6, 1:14 pm, GP lisper <········@CloudDancer.com> wrote:
> On Tue, 5 May 2009 15:55:40 -0700 (PDT), <······@gmail.com> wrote:
>
> Interesting name.
>
> Just a side note on your three noted shortcomings of ASDF, the last two simply are not true.
>
> Operations on components don't happen in the context of a call to the parent system.
> Pervasive use of soft links makes Windows users second class citizens.
> Inability to have multiple versions of the same system defined.
>
> There is no requirement to use symlinks at all. danb happened to
> mention that solution initially, but I have never had any symlinks
> while using ASDF for the last 4 years. It's simple to build
> ASDF:*CENTRAL-REGISTRY* dynamically.
>
> ; find the ASDF files in CMUCL
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (defparameter *original-asdf-registry* ASDF:*CENTRAL-REGISTRY*)
>
> ; filenames, which work fine[1], make it easy to see what asdf files are active
> (defun asdf-global-scanner ()
> (directory
> (make-pathname :directory
> '(:absolute "usr" "local" "lib" "cmucl" "lib" "cmucl" "lib" "subsystems" :wild-inferiors)
> :type "asd")))
>
> (defun asdf-local-scanner ()
> (directory
> (make-pathname :directory
> (append (pathname-directory "home:") (list ".lisp" :wild-inferiors))
> :type "asd")))
>
> (defun update-asdf-registry ()
> (setf ASDF:*CENTRAL-REGISTRY*
> (nconc (asdf-global-scanner)
> (asdf-local-scanner)
> *original-asdf-registry*)))
>
> (update-asdf-registry)
>
> Similar tricks work with other CLs and OS.
>
Yes, you can work around the usage of symlinks on Windows, typically
I've
pushed a new search function onto asdf:*system-definition-search-
functions*.
The problem with this approach however is that it's not the default
and
Windows users still lose, by default, when they really don't have to.
It's not that it can't be done, it's just that I don't believe that
trying
to convince a system definition tool to load systems should be a
requirement for new users on Windows, hence the 'second citizen'
comment.
> Since ASDF:*CENTRAL-REGISTRY* is searched in sequence, to work with
> different versions just requires being first, I just handled this
> above with a local version. Again, dynamic modification of
> ASDF:*CENTRAL-REGISTRY* will produce the desired version.
Yes, and it's a testament to ASDF and yourself that you've been able
to get this working,
however, while this works for finding systems you'll find that it
start breaking when
you ask questions like, give me a list of all the system objects that
I could load,
or what changed between version A and version B of a particular system
without resorting
to all sorts of hacks.
The problem is that you can't have 2 different versions of a system
defined at the same
time since ASDF will reuse the SYSTEM object that you had.
Again, there are cases where an ingenious programmer can convince ASDF
to behave as
if there were multiple systems available, it's just that you cannot do
it for all cases.
> Note that a second generation "ASDF" is still a good idea, and thanks
> again for CL-Store.
It's a pleasure.
- sean
GP lisper wrote:
> On Tue, 5 May 2009 15:55:40 -0700 (PDT), <······@gmail.com> wrote:
> Interesting name.
>
> Just a side note on your three noted shortcomings of ASDF, the last two simply are not true.
>
No problem, I have a list of fifteen over here to fill in the gaps.
> Note that a second generation "ASDF" is still a good idea,
I was thinking extinction would be simpler. The thing is an atrocity,
start over or help with mudballs but for the love of g*d let's erase
this blight from the Lisp landscape.
kt
david escreveu:
> i am trying to install mudballs. now i have run (mb:self-update)
> and get to
> Downloading source for :BOOT 0.0.1 from http://mudballs.com/boot/boot.lisp.
> with error:
> FUNCALL: undefined function USOCKET:SOCKET-CONNECT
>
> i see :sockets in *features* for whatever thats worth.
what about usocket?
--
a game sig: http://tinyurl.com/d3rxz9
On May 5, 2:18 pm, namekuseijin <············@gmail.com> wrote:
> david escreveu:
>
> > i am trying to install mudballs. now i have run (mb:self-update)
> > and get to
> > Downloading source for :BOOT 0.0.1 fromhttp://mudballs.com/boot/boot.lisp.
> > with error:
> > FUNCALL: undefined function USOCKET:SOCKET-CONNECT
>
> > i see :sockets in *features* for whatever thats worth.
>
> what about usocket?
>
> --
> a game sig:http://tinyurl.com/d3rxz9
i have no usocket. catch-22.
david escreveu:
> On May 5, 2:18 pm, namekuseijin <············@gmail.com> wrote:
>> david escreveu:
>>
>>> i am trying to install mudballs. now i have run (mb:self-update)
>>> and get to
>>> Downloading source for :BOOT 0.0.1 fromhttp://mudballs.com/boot/boot.lisp.
>>> with error:
>>> FUNCALL: undefined function USOCKET:SOCKET-CONNECT
>>> i see :sockets in *features* for whatever thats worth.
>> what about usocket?
>>
>> --
>> a game sig:http://tinyurl.com/d3rxz9
>
> i have no usocket. catch-22.
http://www.cliki.net/USOCKET
I didn't know about it either. Thanks, Google.
--
a game sig: http://tinyurl.com/d3rxz9