So, what is going on here. The process of installing cmucl and
finding an editor proper is utterly, dremendously, unbelievably,
attrociously, complicated times 10 trillion more complicated.
The original cmucl editor what should I say: I have got absolutely no
idea what they had in mind, what might be their mission, and how one
could use it. Therefore my search for slime:
All I want to know: a simple way to do the following: (compile-file
'file.lisp"), (load "file.lisp") this is equivalent to: bigloo
file.scm, a.out. The latter can be done on the command line in a
terminal (eventhough Bigloo Bee is a ver good Emacs mode for Scheme).
However, cmucl does not have this 'history' feature and using the
command line after starting cmucl is a nightmare.
First confusion arises: cmucl is not called cmucl rather it is called /
bin/lisp (how intelligent). Slime .emacs somehow has in the Readme:
chose your lisp (as far as I cann tell their emacs lisp packagge has
cmucl in its name). Could that be the reason why I get the following
error message afer loading M-x slime in my Emacs (I am not sure at all
if that is an error message because the slime manual is utterly
complicated not sure what they try to accomplish with the slime
manual):
==
Debugger entered: (("Error in timer" slime-attempt-connection
(#<process inferior-lisp<1>> nil 2) (error "SIGPIPE raised on process
SLIME Lisp; closed it")))
(condition-case data (apply fun args) (error (debug nil ...)))
slime-timer-call(slime-attempt-connection #<process inferior-
lisp<1>> nil 2)
apply(slime-timer-call (slime-attempt-connection #<process inferior-
lisp<1>> nil 2))
byte-code("ÁÂHÃH\"" [timer apply 5 6] 4)
timer-event-handler([t 18752 9591 822466 0.3 slime-timer-call (slime-
attempt-connection #<process inferior-lisp<1>> nil 2) nil])
recursive-edit()
byte-code("Æ @················@)¢Ì=!ÈÍÊ\"Î
!Ï Ð !\fcÑed\"
VWebÒ
¥y` dbÒ
¥
Zy`|)ÓcebÔÕÖ \"× ÔØ!ÙÊ ÔØ!Ú +Ù" [unread-command-char
debugger-args x debugger-buffer noninteractive debugger-batch-max-
lines -1 debug backtrace-debug 4 t backtrace-frame lambda 5 pop-to-
buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n"
message "%s" buffer-string kill-emacs "" nil recursive-edit
middlestart buffer-read-only standard-output] 4)
debug(nil ("Error in timer" slime-attempt-connection (#<process
inferior-lisp> nil 2) (error "SIGPIPE raised on process SLIME Lisp;
closed it")))
(condition-case data (apply fun args) (error (debug nil ...)))
slime-timer-call(slime-attempt-connection #<process inferior-lisp>
nil 2)
apply(slime-timer-call (slime-attempt-connection #<process inferior-
lisp> nil 2))
byte-code("ÁÂHÃH\"" [timer apply 5 6] 4)
timer-event-handler([t 18752 9468 943383 0.3 slime-timer-call (slime-
attempt-connection #<process inferior-lisp> nil 2) nil])
==
my .emacs:
==
(add-to-list 'load-path "/Users/king_of_the_universe/tmp/lisp/
slime-2008-12-10/") ; your SLIME directory
(setq inferior-lisp-program "/Users/king_of_the_universe/tmp/lisp/bin/
lisp") ; your Lisp system
(require 'slime)
(slime-setup)
==
Question: are there any other alternatives to slime. I am not
interested in any 'dynamism' yet all I want: editing or writing
(learning) Common Lisp in an editor with auto-ident, () macthing, and
nice color highlightning. Next comes: compling a lisp file and
starting it. Please can anone explain to me or give me a pointer. I
know I can load things in cmucl but as said it is not nice and I
cannot hit the "up" key to save typing.
Thanks, Dracula
From: Albert Krewinkel
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <m24p1bms25.fsf@gmx.net>
···········@yahoo.de writes:
> Question: are there any other alternatives to slime. I am not
> interested in any 'dynamism' yet all I want: editing or writing
> (learning) Common Lisp in an editor with auto-ident, () macthing, and
> nice color highlightning. Next comes: compling a lisp file and
> starting it. Please can anone explain to me or give me a pointer. I
> know I can load things in cmucl but as said it is not nice and I
> cannot hit the "up" key to save typing.
Since you are using Mac OS X (and got Opera running), you probably know
about Fink and Darwin-Ports. Just try downloading SBCL using one of
those. Then you can also use clbuild[1] to download more packages --
including slime. That should make running a lisp as easy as typing
./clbuilb slime
[1] http://common-lisp.net/project/clbuild
> Since you are using Mac OS X (and got Opera running), you probably know
> about Fink and Darwin-Ports. Just try downloading SBCL using one of
> those.
It is not difficult to setup on OS X a nice environments with:
- SBCL (there are prebuilt Darwin binaries on their download page)
- Aquamacs
- SLIME
Note that you may encounter problems with recent binaries of SBCL if
your OS X is old (like 10.3).
g
On Wed, 10 Dec 2008 12:50:19 -0800 (PST), <···········@yahoo.de> wrote:
> So, what is going on here. The process of installing cmucl and
> finding an editor proper is utterly, dremendously, unbelievably,
> attrociously, complicated times 10 trillion more complicated.
>
> Thanks, Dracula
Nope, you're just another instance of roll-a-name troll. At least
upgrade the quality of your lame questions for Xmas. After all, then
your spam harvester will reap a larger yield.
V. Heisling
** Posted from http://www.teranews.com **
On Dec 11, 2:20 am, GP lisper <········@CloudDancer.com> wrote:
> On Wed, 10 Dec 2008 12:50:19 -0800 (PST), <···········@yahoo.de> wrote:
> > So, what is going on here. The process of installing cmucl and
> > finding an editor proper is utterly, dremendously, unbelievably,
> > attrociously, complicated times 10 trillion more complicated.
>
> > Thanks, Dracula
>
> Nope, you're just another instance of roll-a-name troll. At least
> upgrade the quality of your lame questions for Xmas. After all, then
> your spam harvester will reap a larger yield.
>
> V. Heisling
>
> ** Posted fromhttp://www.teranews.com**
Hi: I have absolutely no idea what you are talking about. xmass
meassge for you: common lisp sucks. I hope I made your day. Sincerely
Yours, Frankenstein
On Dec 11, 1:50 am, ···········@yahoo.de wrote:
> So, what is going on here. The process of installing cmucl and
> finding an editor proper is utterly, dremendously, unbelievably,
> attrociously, complicated times 10 trillion more complicated.
>
> The original cmucl editor what should I say: I have got absolutely no
> idea what they had in mind, what might be their mission, and how one
> could use it. Therefore my search for slime:
> All I want to know: a simple way to do the following: (compile-file
> 'file.lisp"), (load "file.lisp") this is equivalent to: bigloo
> file.scm, a.out. The latter can be done on the command line in a
> terminal (eventhough Bigloo Bee is a ver good Emacs mode for Scheme).
> However, cmucl does not have this 'history' feature and using the
> command line after starting cmucl is a nightmare.
>
> First confusion arises: cmucl is not called cmucl rather it is called /
> bin/lisp (how intelligent). Slime .emacs somehow has in the Readme:
> chose your lisp (as far as I cann tell their emacs lisp packagge has
> cmucl in its name). Could that be the reason why I get the following
> error message afer loading M-x slime in my Emacs (I am not sure at all
> if that is an error message because the slime manual is utterly
> complicated not sure what they try to accomplish with the slime
> manual):
>
> ==
> Debugger entered: (("Error in timer" slime-attempt-connection
> (#<process inferior-lisp<1>> nil 2) (error "SIGPIPE raised on process
> SLIME Lisp; closed it")))
> (condition-case data (apply fun args) (error (debug nil ...)))
> slime-timer-call(slime-attempt-connection #<process inferior-
> lisp<1>> nil 2)
> apply(slime-timer-call (slime-attempt-connection #<process inferior-
> lisp<1>> nil 2))
> byte-code("Á ÂH ÃH\"‡" [timer apply 5 6] 4)
> timer-event-handler([t 18752 9591 822466 0.3 slime-timer-call (slime-
> attempt-connection #<process inferior-lisp<1>> nil 2) nil])
> recursive-edit()
> byte-code("Æ @Ç=ƒ!ÈÉÊ\"ˆËÉ!‰ ·@)¢Ì=ƒ!ÈÍÊ\"ˆÎ
> !ˆÏ ˆÐ !ˆ\fƒcÑed\"
> VƒWebˆÒ
> ¥yˆ` dbˆÒ
> ¥
> Zyˆ `|ˆ)ÓcˆebˆÔÕÖ \"ˆ× ˆÔØ!ˆÙÊ ÔØ!ˆŠÚ ˆ+Ù‡" [unread-command-char
> debugger-args x debugger-buffer noninteractive debugger-batch-max-
> lines -1 debug backtrace-debug 4 t backtrace-frame lambda 5 pop-to-
> buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n"
> message "%s" buffer-string kill-emacs "" nil recursive-edit
> middlestart buffer-read-only standard-output] 4)
> debug(nil ("Error in timer" slime-attempt-connection (#<process
> inferior-lisp> nil 2) (error "SIGPIPE raised on process SLIME Lisp;
> closed it")))
> (condition-case data (apply fun args) (error (debug nil ...)))
> slime-timer-call(slime-attempt-connection #<process inferior-lisp>
> nil 2)
> apply(slime-timer-call (slime-attempt-connection #<process inferior-
> lisp> nil 2))
> byte-code("Á ÂH ÃH\"‡" [timer apply 5 6] 4)
> timer-event-handler([t 18752 9468 943383 0.3 slime-timer-call (slime-
> attempt-connection #<process inferior-lisp> nil 2) nil])
> ==
>
> my .emacs:
>
> ==
> (add-to-list 'load-path "/Users/king_of_the_universe/tmp/lisp/
> slime-2008-12-10/") ; your SLIME directory
> (setq inferior-lisp-program "/Users/king_of_the_universe/tmp/lisp/bin/
> lisp") ; your Lisp system
> (require 'slime)
> (slime-setup)
> ==
>
> Question: are there any other alternatives to slime. I am not
> interested in any 'dynamism' yet all I want: editing or writing
> (learning) Common Lisp in an editor with auto-ident, () macthing, and
> nice color highlightning. Next comes: compling a lisp file and
> starting it. Please can anone explain to me or give me a pointer. I
> know I can load things in cmucl but as said it is not nice and I
> cannot hit the "up" key to save typing.
>
> Thanks, Dracula
I think Lispworks Personal Edition and AllegroCL Express support OS X.
Regards
Gautham
From: Espen Vestre
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <m1iqprt7r1.fsf@vestre.net>
gautham <·······@lisphacker.org> writes:
> I think Lispworks Personal Edition and AllegroCL Express support OS X.
They do. Highly recommended for the OP.
Additional comment to the OP:
>> I am not interested in any 'dynamism'
Hopefully, you'll change your mind after trying out one of the above
mentioned test versions for some weeks!
--
(espen)
···········@yahoo.de wrote:
...
> Question: are there any other alternatives to slime. I am not
> interested in any 'dynamism' yet all I want: editing or writing
> (learning) Common Lisp in an editor with auto-ident, () macthing, and
> nice color highlightning. Next comes: compling a lisp file and
> starting it. Please can anone explain to me or give me a pointer. I
> know I can load things in cmucl but as said it is not nice and I
> cannot hit the "up" key to save typing.
A simpler alternative to Slime is ABLE:
http://phil.nullable.eu/
IIRC, CLisp comes with Slime (only on MS?)
(Especially) for Macs, clozure may be your best option:
http://trac.clozure.com/openmcl
- Daniel
From: Helmut Eller
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <m2wse7wuuj.fsf@common-lisp.net>
* ···········@yahoo.de [2008-12-10 21:50+0100] writes:
> Question: are there any other alternatives to slime. I am not
> interested in any 'dynamism' yet all I want: editing or writing
> (learning) Common Lisp in an editor with auto-ident, () macthing, and
> nice color highlightning. Next comes: compling a lisp file and
> starting it. Please can anone explain to me or give me a pointer. I
> know I can load things in cmucl but as said it is not nice and I
> cannot hit the "up" key to save typing.
You don't need SLIME to edit a Lisp file. Just open the file in Emacs
and Emacs will use the ordinary lisp-mode. That gives you indentation
and paren matching.
For command line history you can use generic tools like rlwrap (I guess
you can google that by yourself) That works for most terminal
applications.
Alternatively you can run CMUCL inside Emacs with M-x run-lisp. This
creates a buffer with the standard CMUCL repl. In that buffer you can
use M-p and M-n for history navigation.
Your error looks like a CMUCL problem. Perhaps the combination
CMUCL/Emacs/MacOS doesn't work so well. You could also try another
implementation like SBCL or CCL. CCL is especially nice.
Helmut.
From: toy
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <49405F49.6020605@gmail.com>
Helmut Eller wrote:
> * ···········@yahoo.de [2008-12-10 21:50+0100] writes:
>
> Your error looks like a CMUCL problem. Perhaps the combination
> CMUCL/Emacs/MacOS doesn't work so well. You could also try another
> implementation like SBCL or CCL. CCL is especially nice.
On the other hand, I use cmucl and xemacs on Mac OS X just fine.
Ray
On Dec 11, 12:31 am, toy <···········@gmail.com> wrote:
> Helmut Eller wrote:
> > * ···········@yahoo.de [2008-12-10 21:50+0100] writes:
>
> > Your error looks like a CMUCL problem. Perhaps the combination
> > CMUCL/Emacs/MacOS doesn't work so well. You could also try another
> > implementation like SBCL or CCL. CCL is especially nice.
>
> On the other hand, I use cmucl and xemacs on Mac OS X just fine.
>
> Ray
Hi: I think cmucl itself works.
I couldn't also install ilisp emacs package. Also Helmlock seems to be
not working proper (honestly: the helmlock manual is not parseable)
and I got an 'infinite error message loop' in the cmucl listener and
had to kill cmucl and emacs.
Probably the best option shall be to use macports.
From: Raymond Toy
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <sxd4p1aztci.fsf@rtp.ericsson.se>
>>>>> "klohmuschel" == klohmuschel <···········@yahoo.de> writes:
klohmuschel> On Dec 11, 12:31�am, toy <···········@gmail.com> wrote:
>> Helmut Eller wrote:
>> > * ···········@yahoo.de [2008-12-10 21:50+0100] writes:
>>
>> > Your error looks like a CMUCL problem. �Perhaps the combination
>> > CMUCL/Emacs/MacOS doesn't work so well. �You could also try another
>> > implementation like SBCL or CCL. �CCL is especially nice.
>>
>> On the other hand, I use cmucl and xemacs on Mac OS X just fine.
>>
>> Ray
klohmuschel> Hi: I think cmucl itself works.
I meant to say cmucl and xemacs and slime work together quite well for
me on OS X.
klohmuschel> I couldn't also install ilisp emacs package. Also Helmlock seems to be
I used to ilisp a lot, but switched over to slime completely. There
is nothing (now) in ilisp that slime doesn't do better.
klohmuschel> not working proper (honestly: the helmlock manual is not parseable)
klohmuschel> and I got an 'infinite error message loop' in the cmucl listener and
klohmuschel> had to kill cmucl and emacs.
I'm not sure I've ever tried hemlock on OSX. I think there is an
issue that cmucl can't parse the DISPLAY variable. You have manually
set it to :0.0 or something before starting cmucl and hemlock. I think.
klohmuschel> Probably the best option shall be to use macports.
Does macports have cmucl? In any case, there are lots of other lisps
to use on OSX.
Ray
Raymond Toy <···········@ericsson.com> wrote:
+---------------
| I'm not sure I've ever tried hemlock on OSX. I think there is an
| issue that cmucl can't parse the DISPLAY variable. You have manually
| set it to :0.0 or something before starting cmucl and hemlock. I think.
+---------------
Probably some other CMUCL_vs_OS-X issue. At least with recent CMUCLs
(19c or later) it parses the DISPLAY variable just fine, well enough
for Hemlock to work with SSH forwarded X connections (where a typical
"DISPLAY" is "localhost:11.0", say).
If the OP's using a *really* old CMUCL, then it might be the case
that that Hemlock tried to open the display with XLIB:OPEN-DISPLAY
instead of EXT:OPEN-CLX-DISPLAY -- the latter correctly extracts/parses
a display from the "DISPLAY" environment variable. [I seem to
remember some trouble about that with some of the CLX demo apps
that used XLIB:OPEN-DISPLAY.]
Anyway, as I said, in (near-)current CMUCL Hemlock works fine across
SSH-forwarded X connections without any special tweaking of "DISPLAY".
[I just confirmed it.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Raymond Toy
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <sxdwse5wju6.fsf@rtp.ericsson.se>
>>>>> "Rob" == Rob Warnock <····@rpw3.org> writes:
Rob> Raymond Toy <···········@ericsson.com> wrote:
Rob> +---------------
Rob> | I'm not sure I've ever tried hemlock on OSX. I think there is an
Rob> | issue that cmucl can't parse the DISPLAY variable. You have manually
Rob> | set it to :0.0 or something before starting cmucl and hemlock. I think.
Rob> +---------------
Rob> Probably some other CMUCL_vs_OS-X issue. At least with recent CMUCLs
Rob> (19c or later) it parses the DISPLAY variable just fine, well enough
Rob> for Hemlock to work with SSH forwarded X connections (where a typical
Rob> "DISPLAY" is "localhost:11.0", say).
I don't have OSX handy right now, but if you have an xterm, the
DISPLAY variable is not the typical <host>:0.0. It's something like
/var/tmp/<stuff>, which, I think is a socket or something. The
current clx can't make sense of that.
Ray
On Dec 12, 2:26 pm, Raymond Toy <···········@ericsson.com> wrote:
> >>>>> "Rob" == Rob Warnock <····@rpw3.org> writes:
>
> Rob> Raymond Toy <···········@ericsson.com> wrote:
> Rob> +---------------
> Rob> | I'm not sure I've ever tried hemlock on OSX. I think there is an
> Rob> | issue that cmucl can't parse the DISPLAY variable. You have manually
> Rob> | set it to :0.0 or something before starting cmucl and hemlock. I think.
> Rob> +---------------
>
> Rob> Probably some other CMUCL_vs_OS-X issue. At least with recent CMUCLs
> Rob> (19c or later) it parses the DISPLAY variable just fine, well enough
> Rob> for Hemlock to work with SSH forwarded X connections (where a typical
> Rob> "DISPLAY" is "localhost:11.0", say).
>
> I don't have OSX handy right now, but if you have an xterm, the
> DISPLAY variable is not the typical <host>:0.0. It's something like
> /var/tmp/<stuff>, which, I think is a socket or something. The
> current clx can't make sense of that.
>
> Ray
Oh Jesus. The open source free software movement religion is sometimes
full of shit.
However, cmucl + slime seems to be working now. Had to do the
following: sudo port install slime. Macports will install emacs and
slime. After: sudo port install sbcl. However, everything is full of
crap: slime + sblc does not work. One gets an unparseable error
message sort of "look up 'Package Lock Concepts' in you favorite sbcl
manual'. Frankly: I have no idea what this means. Additionally the
newly installed Emacs with macports does not work too. Likely slime
+sbcl does not work because I am using it in combination with my older
fink emacs install.
/Nevertheless/: slime (via macports) + emacs (via fink ) + cmucl (via
donwloading bin) works now: 'Connected. Take this REPL, brother, and
may it serve you well.' Hallehula!
Btw: I always set my mac os x Display to :0.0 both of .profile
and .bashrc. But I am not sure if thats good. I did this way pack
under Tiger.
Raymond Toy <···········@ericsson.com> wrote:
+---------------
| >>>>> "Rob" == Rob Warnock <····@rpw3.org> writes:
| Rob> Probably some other CMUCL_vs_OS-X issue. At least with recent CMUCLs
| Rob> (19c or later) it parses the DISPLAY variable just fine, well enough
| Rob> for Hemlock to work with SSH forwarded X connections (where a typical
| Rob> "DISPLAY" is "localhost:11.0", say).
|
| I don't have OSX handy right now, but if you have an xterm, the
| DISPLAY variable is not the typical <host>:0.0. It's something like
| /var/tmp/<stuff>, which, I think is a socket or something. The
| current clx can't make sense of that.
+---------------
Though it certainly could be taught to, without much effort.
After all, XLIB::GET-DEFAULT-DISPLAY already contains code to
translate $DISPLAY values of ":x.y" & "unix:x.y" to use the
:LOCAL transport protocol:
> (xlib::get-default-display "localhost:2.3")
("localhost" 2 3 :INTERNET)
> (xlib::get-default-display "unix:2.3")
("unix" 2 3 :LOCAL)
> (xlib::get-default-display ":2.3")
("" 2 3 :LOCAL)
>
and [for CMUCL, at least] :LOCAL (or :UNIX) transport gets converted
in XLIB::OPEN-X-STREAM to the canonical X-Windows-on-Unix socket file
reference, to wit:
(make-pathname :directory '(:absolute "tmp" ".X11-unix")
:name (format nil "X~D" display)
So adding a test in the :LOCAL case for the display name *already*
being an absolute path to a socket file should be trivial. You'd
also have to extend the parsing in XLIB::GET-DEFAULT-DISPLAY, which
currently blows up on display names like "/var/tmp/.X11-unix/X0".
-Rob
p.s. I don't have a Mac to test it on, or I'd do it myself.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Raymond Toy <···········@ericsson.com> wrote:
> +---------------
> | >>>>> "Rob" == Rob Warnock <····@rpw3.org> writes:
> | Rob> Probably some other CMUCL_vs_OS-X issue. At least with recent CMUCLs
> | Rob> (19c or later) it parses the DISPLAY variable just fine, well enough
> | Rob> for Hemlock to work with SSH forwarded X connections (where a typical
> | Rob> "DISPLAY" is "localhost:11.0", say).
> |
> | I don't have OSX handy right now, but if you have an xterm, the
> | DISPLAY variable is not the typical <host>:0.0. It's something like
> | /var/tmp/<stuff>, which, I think is a socket or something. The
> | current clx can't make sense of that.
> +---------------
>
> Though it certainly could be taught to, without much effort.
> After all, XLIB::GET-DEFAULT-DISPLAY already contains code to
> translate $DISPLAY values of ":x.y" & "unix:x.y" to use the
> :LOCAL transport protocol:
>
> > (xlib::get-default-display "localhost:2.3")
>
> ("localhost" 2 3 :INTERNET)
> > (xlib::get-default-display "unix:2.3")
>
> ("unix" 2 3 :LOCAL)
> > (xlib::get-default-display ":2.3")
>
> ("" 2 3 :LOCAL)
> >
>
> and [for CMUCL, at least] :LOCAL (or :UNIX) transport gets converted
> in XLIB::OPEN-X-STREAM to the canonical X-Windows-on-Unix socket file
> reference, to wit:
>
> (make-pathname :directory '(:absolute "tmp" ".X11-unix")
> :name (format nil "X~D" display)
>
> So adding a test in the :LOCAL case for the display name *already*
> being an absolute path to a socket file should be trivial. You'd
> also have to extend the parsing in XLIB::GET-DEFAULT-DISPLAY, which
> currently blows up on display names like "/var/tmp/.X11-unix/X0".
>
>
> -Rob
>
> p.s. I don't have a Mac to test it on, or I'd do it myself.
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
Thanks, that motivated me to look into the CMUCL sources for CLX.
The following works for me with CMUCL snapshot november 2008 and Mac OS X 10.5.5
The DISPLAY variable looks like this:
DISPLAY=/tmp/launch-YUbg3g/:0
Now CLX can parse above display strings and can open an x stream for those.
---------------------------------------
(in-package "XLIB")
(defun get-default-display (&optional display-name)
"Parse the argument DISPLAY-NAME, or the environment variable $DISPLAY
if it is NIL. Display names have the format
[protocol/] [hostname] : [:] displaynumber [.screennumber]
absolute-pathname : display-number
There are two special cases in parsing, to match that done in the Xlib
C language bindings
- If the hostname is ``unix'' or the empty string, any supplied
protocol is ignored and a connection is made using the :local
transport.
- If a double colon separates hostname from displaynumber, the
protocol is assumed to be decnet.
Returns a list of (host display-number screen protocol)."
(let* ((name (or display-name (getenv "DISPLAY") (error "DISPLAY environment variable is not set")))
(slash-i (or (position #\/ name) -1))
(colon-i (position #\: name :start (1+ slash-i)))
(decnet-colon-p (eql (elt name (1+ colon-i)) #\:))
(host (subseq name (if (zerop slash-i) 0 (1+ slash-i)) colon-i))
(dot-i (and colon-i (position #\. name :start colon-i)))
(display (when colon-i
(parse-integer name :start (if decnet-colon-p (+ colon-i 2) (1+ colon-i)) :end dot-i)))
(screen (when dot-i
(parse-integer name :start (1+ dot-i))))
(protocol (cond ((or (string= host "") (string-equal host "unix") (zerop slash-i)) :local)
(decnet-colon-p :decnet)
((> slash-i -1) (intern (string-upcase (subseq name 0 slash-i)) :keyword))
(t :internet))))
(list host (or display 0) (or screen 0) protocol)))
(defun open-x-stream (host display protocol)
(let ((stream-fd
(ecase protocol
;; establish a TCP connection to the X11 server, which is
;; listening on port 6000 + display-number
((:internet :tcp nil)
(let ((fd (ext:connect-to-inet-socket host (+ *x-tcp-port* display))))
(unless (plusp fd)
(error 'connection-failure
:major-version *protocol-major-version*
:minor-version *protocol-minor-version*
:host host
:display display
:reason (format nil "Cannot connect to internet socket: ~S"
(unix:get-unix-error-msg))))
fd))
;; establish a connection to the X11 server over a Unix socket
((:unix :local)
(let ((path (if (and host (> (length host) 0) (char= (aref host 0) #\/))
(make-pathname :defaults (pathname host) :name (format nil ":~D" display))
(make-pathname :directory '(:absolute "tmp" ".X11-unix") :name (format nil "X~D" display)))))
(unless (probe-file path)
(error 'connection-failure
:major-version *protocol-major-version*
:minor-version *protocol-minor-version*
:host host
:display display
:reason (format nil "Unix socket ~s does not exist" path)))
(let ((fd (ext:connect-to-unix-socket (namestring path))))
(unless (plusp fd)
(error 'connection-failure
:major-version *protocol-major-version*
:minor-version *protocol-minor-version*
:host host
:display display
:reason (format nil "Can't connect to unix socket: ~S"
(unix:get-unix-error-msg))))
fd))))))
(system:make-fd-stream stream-fd :input t :output t :element-type '(unsigned-byte 8))))
---------------------------------------
Note to ruby fanboys on c.l.l: I'm not interested in a ruby version.
--
http://lispm.dyndns.org/
On 13 déc, 12:33, Rainer Joswig <······@lisp.de> wrote:
> Thanks, that motivated me to look into the CMUCL sources for CLX.
>
> The following works for me with CMUCL snapshot november 2008 and Mac OS X 10.5.5
>
> The DISPLAY variable looks like this:
>
> DISPLAY=/tmp/launch-YUbg3g/:0
>
> Now CLX can parse above display strings and can open an x stream for those.
Damn you, Rainer, you got me to install CMUCL and Hemlock to try this
out :-)
Works for me with 19e (latest ppc build) and 10.5.5, too. That said,
Hemlock with a French Mac keyboard is even worse than Lispworks!
From: Raymond Toy
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <sxdej09jy39.fsf@rtp.ericsson.se>
>>>>> "Rainer" == Rainer Joswig <······@lisp.de> writes:
Rainer> In article <································@speakeasy.net>,
Rainer> The following works for me with CMUCL snapshot november 2008 and Mac OS X 10.5.5
Rainer> The DISPLAY variable looks like this:
Rainer> DISPLAY=/tmp/launch-YUbg3g/:0
Rainer> Now CLX can parse above display strings and can open an x stream for those.
Nice! I haven't tried this myself, but Thomas F. Burdick says it
works, and I believe him.
I do hope the portable CLX guys (if they haven't already fixed it)
will look into this.[1]
Ray
Footnotes:
[1] CMUCL no longer uses its own copy of CLX, but uses portable CLX
instead.
* Raymond Toy <···············@rtp.ericsson.se> :
Wrote on Thu, 11 Dec 2008 09:20:29 -0500:
| I used to ilisp a lot, but switched over to slime completely. There
| is nothing (now) in ilisp that slime doesn't do better.
SLIME requires a TCP stack and TCP connection between EMACS and Lisp.
If your lisp or kernel does not have a network stack ILISP would work
where SLIME does not.
SLIME introduces a lot of complexity into the LISP where ILISP is
straightforward, ILISP is more stable in that development is dead, so
ILISP wont "break my local changes after the next update" :-)
Using ILISP again ATM after patching it up for emacs 23. It won't work
from sf.
--
Madhu
From: Zach Beane
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <m3abb1u3b4.fsf@unnamed.xach.com>
Madhu <·······@meer.net> writes:
> * Raymond Toy <···············@rtp.ericsson.se> :
> Wrote on Thu, 11 Dec 2008 09:20:29 -0500:
>
> | I used to ilisp a lot, but switched over to slime completely. There
> | is nothing (now) in ilisp that slime doesn't do better.
>
> SLIME requires a TCP stack and TCP connection between EMACS and Lisp.
> If your lisp or kernel does not have a network stack ILISP would work
> where SLIME does not.
First JavaScript, now TCP...those upstart snot-nosed kids are pushing
all kinds of worthless technologies on you.
Zach
Zach Beane <····@xach.com> writes:
> Madhu <·······@meer.net> writes:
>
>> * Raymond Toy <···············@rtp.ericsson.se> :
>> Wrote on Thu, 11 Dec 2008 09:20:29 -0500:
>>
>> | I used to ilisp a lot, but switched over to slime completely. There
>> | is nothing (now) in ilisp that slime doesn't do better.
>>
>> SLIME requires a TCP stack and TCP connection between EMACS and Lisp.
>> If your lisp or kernel does not have a network stack ILISP would work
>> where SLIME does not.
>
> First JavaScript, now TCP...those upstart snot-nosed kids are pushing
> all kinds of worthless technologies on you.
Next they'll try to make you use a TTY!
--
__Pascal Bourguignon__
* Zach Beane <··············@unnamed.xach.com> :
Wrote on Fri, 12 Dec 2008 04:54:07 -0500:
| Madhu <·······@meer.net> writes:
|
|> * Raymond Toy <···············@rtp.ericsson.se> :
|> Wrote on Thu, 11 Dec 2008 09:20:29 -0500:
|>
|> | I used to ilisp a lot, but switched over to slime completely. There
|> | is nothing (now) in ilisp that slime doesn't do better.
|>
|> SLIME requires a TCP stack and TCP connection between EMACS and Lisp.
|> If your lisp or kernel does not have a network stack ILISP would work
|> where SLIME does not.
|
| First JavaScript, now TCP...those upstart snot-nosed kids are pushing
| all kinds of worthless technologies on you.
FTR I can't see where I said TCP was a worthless technology or where
javascript is in this thread or why you identify yourself with a
"snot-nosed kid" trying to sell someone something that they don't need.
--
Madhu
* Helmut Eller <··············@common-lisp.net> :
Wrote on Wed, 10 Dec 2008 23:04:04 +0100:
| Your error looks like a CMUCL problem. Perhaps the combination
| CMUCL/Emacs/MacOS doesn't work so well. You could also try another
| implementation like SBCL or CCL. CCL is especially nice.
More likely it is a problem in SLIME beacuse SLIME is making incorrect
assumptions on the default behaviour of Emacs and CMUCL on that
platform.
--
Madhu
From: Pascal Costanza
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <6qc45vFbtrrhU1@mid.individual.net>
···········@yahoo.de wrote:
> Question: are there any other alternatives to slime. I am not
> interested in any 'dynamism' yet all I want: editing or writing
> (learning) Common Lisp in an editor with auto-ident, () macthing, and
> nice color highlightning. Next comes: compling a lisp file and
> starting it. Please can anone explain to me or give me a pointer. I
> know I can load things in cmucl but as said it is not nice and I
> cannot hit the "up" key to save typing.
The free editions of the commercial implementations are _perfect_ for
learning Common Lisp. None of the restrictions of the free editions
should ever matter to you in the beginning, and unlike some other Lisp
dialects, Common Lisp provides a very high degree of portability, so the
danger of vendor lock-in is extremely low.
The choice between open source and commercial implementations for
deployment is a choice that is better made once you are more experienced
and/or have an actual real application to deploy. Until then, stop worrying.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Dec 11, 9:17 am, Pascal Costanza <····@p-cos.net> wrote:
> The free editions of the commercial implementations are _perfect_ for
> learning Common Lisp. None of the restrictions of the free editions
> should ever matter to you in the beginning, and unlike some other Lisp
> dialects, Common Lisp provides a very high degree of portability, so the
> danger of vendor lock-in is extremely low.
>
> The choice between open source and commercial implementations for
> deployment is a choice that is better made once you are more experienced
> and/or have an actual real application to deploy. Until then, stop worrying.
I want to give Common Lisp a second chance and see what's in store.
Reason being this: during my Phd term no one cared what I was using
(my supervisor was happy that I am happy and that we are in good
health and alive). However, now as post-doc in England in a foreign
country and in a research group I have often wondered how my
colleagues would react here if I start writing code in Bigloo or
Common Lisp. The argument for Common Lisp: there are many more choices
of implementations avilable. I am not saying that I am fluent in
Bigloo but I used it for nearly 3 or 4 years on a daily basis for m
Phd in physics.
I am a long time reader of comp.lang.lisp but have never descended to
start really learning it (except a short exploration with LispWorks a
couple of years ago). I only know 2 or 3 Emacs commands and do most of
the things with the mouse even thogh I use Emacs daily for a couple of
hours. But have somehow managed to work with Bee Bigloo its Emacs
package.
Regards, Schneewittchen
From: Pascal Costanza
Subject: Re: slime+cmucl installation process is horribly complicated
Date:
Message-ID: <6qcj6vFbq8k3U1@mid.individual.net>
···········@yahoo.de wrote:
> On Dec 11, 9:17 am, Pascal Costanza <····@p-cos.net> wrote:
>
>> The free editions of the commercial implementations are _perfect_ for
>> learning Common Lisp. None of the restrictions of the free editions
>> should ever matter to you in the beginning, and unlike some other Lisp
>> dialects, Common Lisp provides a very high degree of portability, so the
>> danger of vendor lock-in is extremely low.
>>
>> The choice between open source and commercial implementations for
>> deployment is a choice that is better made once you are more experienced
>> and/or have an actual real application to deploy. Until then, stop worrying.
>
> I want to give Common Lisp a second chance and see what's in store.
> Reason being this: during my Phd term no one cared what I was using
> (my supervisor was happy that I am happy and that we are in good
> health and alive). However, now as post-doc in England in a foreign
> country and in a research group I have often wondered how my
> colleagues would react here if I start writing code in Bigloo or
> Common Lisp. The argument for Common Lisp: there are many more choices
> of implementations avilable. I am not saying that I am fluent in
> Bigloo but I used it for nearly 3 or 4 years on a daily basis for m
> Phd in physics.
>
> I am a long time reader of comp.lang.lisp but have never descended to
> start really learning it (except a short exploration with LispWorks a
> couple of years ago). I only know 2 or 3 Emacs commands and do most of
> the things with the mouse even thogh I use Emacs daily for a couple of
> hours. But have somehow managed to work with Bee Bigloo its Emacs
> package.
That's the good thing about the commercial implementations: You can use
the keybindings of the underlying operating system, and you can use the
mouse using the gestures of the underlying operating system, and stop
worrying about emacs keybindings. Emacs keybindings are much more
efficient, but that's not the first thing you want to learn when you
want to learn Lisp...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
············@yahoo.de writes:
> I am a long time reader of comp.lang.lisp but have never descended to
^^^^^^^^^
Should be: ascended:-)
> start really learning it (except a short exploration with LispWorks a
> couple of years ago).
Nicolas
From: Pascal J. Bourguignon
Subject: Re: slime+cmucl installation process is horribly complicated / another distro
Date:
Message-ID: <7c63lrvz3x.fsf@pbourguignon.anevia.com>
···········@yahoo.de writes:
> So, what is going on here. The process of installing cmucl and
> finding an editor proper is utterly, dremendously, unbelievably,
> attrociously, complicated times 10 trillion more complicated.
There's another "distribution" that is super simple to install, I
tried it yesterday night. Namely, Common Music for Macintosh. You
only have to download the Aquamacs dmg, and the cm dmg, and then
double-click on the cm.app icon.
You get emacs + slime + sbcl + cm, but you can do:
(in-package :cl-user)
right away and forget the music.
I didn't try the installation process of cm on linux, but it might be
as simple.
--
__Pascal Bourguignon__