I was wondering if someone familiar with the CLX program could comment
on the various versions out there and what might be needed to have one
common CLX between all free lisp platforms.
>From the cliki page it looks like the most "modern" CLX around is the
"telnet CLX" branch which has support for some of the more modern
features of X, but CMUCL and Clisp both seem to have their own versions
which are somewhat different from "telnet CLX". Two questions:
a) What are the obstacles to using telnet CLX with CMUCL? Is there a
reason telnet CLX is not the default choice for CMUCL?
b) Is there any work ongoing to support more of X (I think someone
once said BIGREQUEST was needed?) AFAICT the portable-clx email list
is the closest thing CLX has to a common development home, and it
doesn't seem to have seen much activity since August - is portable-clx
still the "goto" spot for developing/modernizing CLX? It would seem to
be a logical thing to establish a common-lisp.net site for, but maybe
there is no need?
Cheers,
CY
From: Raymond Toy
Subject: Re: "telnet clx", "portable CLX", and the various Lisps
Date:
Message-ID: <sxdirtlghpc.fsf@rtp.ericsson.se>
>>>>> "CY" == C Y <C> writes:
CY> I was wondering if someone familiar with the CLX program could comment
CY> on the various versions out there and what might be needed to have one
CY> common CLX between all free lisp platforms.
>> From the cliki page it looks like the most "modern" CLX around is the
CY> "telnet CLX" branch which has support for some of the more modern
CY> features of X, but CMUCL and Clisp both seem to have their own versions
CY> which are somewhat different from "telnet CLX". Two questions:
CY> a) What are the obstacles to using telnet CLX with CMUCL? Is there a
CY> reason telnet CLX is not the default choice for CMUCL?
This was discussed quite a while ago on a cmucl mailing list, and I
think the intent was to make telent clx the default choice so that
cmucl doesn't have to maintain its own version.
However, nothing has been about this yet. I don't even know if telent
clx will work with cmucl or if it is incompatible with cmucl clx in
any way.
Ray
Raymond Toy wrote:
> This was discussed quite a while ago on a cmucl mailing list, and I
> think the intent was to make telent clx the default choice so that
> cmucl doesn't have to maintain its own version.
Has the cmucl version kept up with things like the xrender extensions?
If not I would definitely argue in favor of defaulting to the modern
one :-)
> However, nothing has been about this yet. I don't even know if telent
> clx will work with cmucl or if it is incompatible with cmucl clx in
> any way.
Hmm. Well, I suppose the easiest way is to try and find out... /me
makes note to download latest version for testing tonight. Is it
generally true that sbcl stuff runs on cmucl and vice versa, or have
they diverged a lot?
Cheers,
CY
> Hmm. Well, I suppose the easiest way is to try and find out... /me
> makes note to download latest version for testing tonight.
It didn't seem to work right off "out of the box" but I don't think it
will be too terribly difficult to get it working, once I figure out a
little more detail about how cmucl implements require and do a
comparison with cmucl's clx.
By the way, is there any reason asdf is not included in default CMUCL
images nowadays? (Or any other lisp for that matter?) Is it that it's
not stable enough yet?
Cheers,
CY
C Y <···········@yahoo.com> wrote:
+---------------
| It didn't seem to work right off "out of the box" but I don't think it
| will be too terribly difficult to get it working, once I figure out a
| little more detail about how cmucl implements require ...
+---------------
The quick & dirty version: To make (REQUIRE :FOO) work in CMUCL,
assuming CMUCL has been installed in "/usr/local/{bin,lib}/":
0. Make sure the file named, say, "/usr/home/YOU/lib/lisp/foo.lisp",
contains a (PROVIDE :FOO) somewhere in it at the top level, so it
will be executed when it loads.
1. FILE-COMPILE it, producing "/usr/home/YOU/lib/lisp/foo.x86f".
[This is not strictly necessary, but if you don't compile it
then change all ".x86f" below into ".lisp".]
2. Create the symlink "/usr/local/lib/cmucl/lib/subsystems/foo-library.x86f"
pointing to "/usr/home/YOU/lib/lisp/foo.x86f". That is:
$ ln -s /usr/home/YOU/lib/lisp/foo.x86f \
/usr/local/lib/cmucl/lib/subsystems/foo-library.x86f
Note that the symlink *MUST* be named "foo-library", not just "foo".
[Long story. Don't ask.]
3. Run "/usr/local/bin/lisp" or "/usr/local/bin/cmucl" or whatever,
then try the following:
* *modules*
("ASDF" "LOOP")
* (require :foo)
; Loading #p"/usr/home/YOU/lib/lisp/foo.x86f".
T
* *modules*
("FOO" "ASDF" "LOOP")
* (require :foo)
NIL
*
Note that the second (REQUIRE :FOO) does nothing [as expected],
since the (PROVIDE :FOO) pushed "FOO" onto *MODULES*.
-Rob
p.s. If that doesn't work for you [probably because you have
CMUCL installed differently], I'll go into a longer explication
of the #p"modules:" and #p"library:" "search lists", but it ain't
pretty! :-{ Hint: Type this in and try to grok what it tells you:
(loop for k being each hash-key in lisp::*search-lists*
using (hash-value v)
when (lisp::search-list-defined v)
collect (cons k (lisp::search-list-expansions v)))
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> C Y <···········@yahoo.com> wrote:
> +---------------
> | It didn't seem to work right off "out of the box" but I don't think it
> | will be too terribly difficult to get it working, once I figure out a
> | little more detail about how cmucl implements require ...
> +---------------
>
> The quick & dirty version: To make (REQUIRE :FOO) work in CMUCL,
> assuming CMUCL has been installed in "/usr/local/{bin,lib}/":
[snip]
OK, thanks! I'll try this later. One potential problem - clx is
multiple files and has an asd file to load it all - do I just put one
provide in the asd file?
(Sorry if that's a dumb question :-/)
> p.s. If that doesn't work for you [probably because you have
> CMUCL installed differently], I'll go into a longer explication
> of the #p"modules:" and #p"library:" "search lists", but it ain't
> pretty! :-{ Hint: Type this in and try to grok what it tells you:
>
> (loop for k being each hash-key in lisp::*search-lists*
> using (hash-value v)
> when (lisp::search-list-defined v)
> collect (cons k (lisp::search-list-expansions v)))
Is this a standard feature in other lisps or is (require <whatever>)
unique to cmucl/sbcl? (/me hopes it's the former...)
"C Y" <···········@yahoo.com> writes:
> Rob Warnock wrote:
>> C Y <···········@yahoo.com> wrote:
>> +---------------
>> | It didn't seem to work right off "out of the box" but I don't think it
>> | will be too terribly difficult to get it working, once I figure out a
>> | little more detail about how cmucl implements require ...
>> +---------------
>>
>> The quick & dirty version: To make (REQUIRE :FOO) work in CMUCL,
>> assuming CMUCL has been installed in "/usr/local/{bin,lib}/":
>
> [snip]
>
> OK, thanks! I'll try this later. One potential problem - clx is
> multiple files and has an asd file to load it all - do I just put one
> provide in the asd file?
>
> (Sorry if that's a dumb question :-/)
Yes.
Just write in lisp what you described above!!!
I can't understand the number of people who ask this kind of question,
describing exactly what they want to a newsgroup instead of telling it
to their compiler...
> OK, thanks! I'll try this later. One potential problem - clx is
> multiple files and has an asd file to load it all - do I just put one
> provide in the asd file?
(with-open-file (loader "/usr/home/YOU/lib/lisp/telnet/clx-library.lisp"
:direction :output
:if-deos-not-exist :create
:if-exists :supersede)
(print '(push #P"/usr/home/YOU/lib/lisp/telnet/"
asdf:*central-registry*) loader)
(print '(asdf:operate 'asdf:load-op :telnet-clx) loader))
and they you do Rob's receipe substituting clx-library.{lisp,x86f} for
foo.{lisp,x86f}.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"
[I have changed "telnet" to "telent" in the Subject, 'cuz it was
bugging me. Apologies to those with non-threaded newsreaders for
whom it will cause a new pseudo-"thread".]
C Y <···········@yahoo.com> wrote:
+---------------
| Rob Warnock wrote:
| > The quick & dirty version: To make (REQUIRE :FOO) work in CMUCL...
|
| OK, thanks! I'll try this later. One potential problem - clx is
| multiple files and has an asd file to load it all - do I just put one
| provide in the asd file?
+---------------
You can do it that way, as Pascal showed you in a parallel reply.
Or since this is CMUCL, you could just concatenate all of the FASLs
together [well, in the right order] to produce one big ".x86f" file.
This is how the "clx-library.x86f" in the "extras" tarball gets built
for the CMUCL distribution. Observe:
$ tr @ '\012' < clx-library.x86f | grep -a '^FASL'
FASL FILE output from target:clx/package.lisp.
FASL FILE output from target:clx/depdefs.lisp.
FASL FILE output from target:clx/clx.lisp.
FASL FILE output from target:clx/dependent.lisp.
FASL FILE output from target:clx/macros.lisp.
FASL FILE output from target:clx/bufmac.lisp.
FASL FILE output from target:clx/buffer.lisp.
FASL FILE output from target:clx/display.lisp.
FASL FILE output from target:clx/gcontext.lisp.
FASL FILE output from target:clx/input.lisp.
FASL FILE output from target:clx/requests.lisp.
FASL FILE output from target:clx/fonts.lisp.
FASL FILE output from target:clx/graphics.lisp.
FASL FILE output from target:clx/text.lisp.
FASL FILE output from target:clx/attributes.lisp.
FASL FILE output from target:clx/translate.lisp.
FASL FILE output from target:clx/keysyms.lisp.
FASL FILE output from target:clx/manager.lisp.
FASL FILE output from target:clx/image.lisp.
FASL FILE output from target:clx/resource.lisp.
FASL FILE output from target:code/clx-ext.lisp.
FASL FILE output from target:hemlock/charmacs.lisp.
FASL FILE output from target:hemlock/key-event.lisp.
FASL FILE output from target:hemlock/keysym-defs.lisp.
$
But if you want to keep tracking the ASDF-mediated version of
"telent CLX", I'd do it the way Pascal suggested. [Or add ASDF
support to CMUCL's REQUIRE yourself, see below.]
+---------------
| > p.s. If that doesn't work for you [probably because you have
| > CMUCL installed differently], I'll go into a longer explication
| > of the #p"modules:" and #p"library:" "search lists", but it ain't
| > pretty! :-{ Hint: Type this in and try to grok what it tells you:
| >
| > (loop for k being each hash-key in lisp::*search-lists*
| > using (hash-value v)
| > when (lisp::search-list-defined v)
| > collect (cons k (lisp::search-list-expansions v)))
|
| Is this a standard feature in other lisps or is (require <whatever>)
| unique to cmucl/sbcl? (/me hopes it's the former...)
+---------------
Well... uh... this is one of those "standardized non-standard features"
in the ANSI CL spec!! ;-} ;-} That is, REQUIRE/PROVIDE themselves are
standard enough:
http://www.lispworks.com/documentation/HyperSpec/Body/f_provid.htm
but exactly how (REQUIRE :FOO) [with no optional pathname-list]
translates to a file *isn't*!!
If the pathname-list is nil, an implementation-dependent mechanism
will be invoked in an attempt to load the module named module-name...
For CMUCL, the function documentation -- try (DESCRIBE #'REQUIRE) --
is fairly helpful, but for the gory details see the source file
"cmucl/src/code/module.lisp". The function REQUIRE is quite simple;
most of the fussing with pathnames is done in MODULE-DEFAULT-PATHNAME
[try calling DESCRIBE on that one, too].
Other implementations have different ways of interpreting REQUIRE.
Current releases of SBCL, in particular, will also try using ASDF to
load a module requested with REQUIRE. [Looking at the code, it appears
that it would be very easy to add the same to CMUCL -- it's just that
no-one has yet, AFAIK.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Tue, 20 Dec 2005 23:07:24 -0600, <····@rpw3.org> wrote:
>
> Other implementations have different ways of interpreting REQUIRE.
> Current releases of SBCL, in particular, will also try using ASDF to
> load a module requested with REQUIRE. [Looking at the code, it appears
> that it would be very easy to add the same to CMUCL -- it's just that
> no-one has yet, AFAIK.]
It's been posted over at cliki for about a year as I recall. I've
bugged Ray a bit about it too. I never liked the idea of making the
user create symlinks, so I have cmucl find .asd files instead, I
suppose since 'nothing has been done' about the posted subject, I can
get away with that.
--
If you don't like LOOP, how do you feel about DOLIST ?
GP lisper wrote:
> On Tue, 20 Dec 2005 23:07:24 -0600, <····@rpw3.org> wrote:
>
>>Other implementations have different ways of interpreting REQUIRE.
>>Current releases of SBCL, in particular, will also try using ASDF to
>>load a module requested with REQUIRE. [Looking at the code, it appears
>>that it would be very easy to add the same to CMUCL -- it's just that
>>no-one has yet, AFAIK.]
>
>
> It's been posted over at cliki for about a year as I recall. I've
> bugged Ray a bit about it too. I never liked the idea of making the
> user create symlinks, so I have cmucl find .asd files instead, I
> suppose since 'nothing has been done' about the posted subject, I can
> get away with that.
CMUCL 19a plus patch has supported require in this way, but you need a
version of asdf that can hook into this. Or use the asdf patch on
cliki. I think mk-defsys already has the necessary support to hook into
CMUCL's require.
Ray
C Y wrote:
> comparison with cmucl's clx.
>
> By the way, is there any reason asdf is not included in default CMUCL
> images nowadays? (Or any other lisp for that matter?) Is it that it's
Because it's yet another copy of some other package that needs to be
maintained, so it's better to leave it out.
But CMUCL does provide the necessary hooks to require so that it can use
asdf (or mk:defsys) to load up modules. (I think mk:defsys works fine,
but you either need a fairly recent asdf or a patched asdf for it to
work with CMUCL.)
Ray
C Y wrote:
> Raymond Toy wrote:
>
>
>>This was discussed quite a while ago on a cmucl mailing list, and I
>>think the intent was to make telent clx the default choice so that
>>cmucl doesn't have to maintain its own version.
>
>
> Has the cmucl version kept up with things like the xrender extensions?
I doubt it. I don't think there have been any significant changes to
clx in years. Plus, the plain was to use the portable telent clx, so
nothing has been done. :-)
Ray
"C Y" <···········@yahoo.com> writes:
>>From the cliki page it looks like the most "modern" CLX around is the
> "telnet CLX" branch which has support for some of the more modern
> features of X, but CMUCL and Clisp both seem to have their own versions
> which are somewhat different from "telnet CLX". Two questions:
GNU CLISP comes with two CLX implementations, MIT CLX and NCLX. The
former, which is written in Lisp, has its roots in the original MIT/TI
work on CLX. NCLX (New CLX) is a C implementation with the same Lisp
interface of CLX. If I recall correctly, NCLX in now the preferred
CLX for CLISP and MIT CLX is deprecated.
> a) What are the obstacles to using telnet CLX with CMUCL? Is there a
> reason telnet CLX is not the default choice for CMUCL?
Telent CLX is not the default choice for CMUCL probably for historical
reasons. CMUCL has had a CLX implementation based on the MIT/TI one
since its early days.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> wrote:
+---------------
| "C Y" <···········@yahoo.com> writes:
| > ...CMUCL and Clisp both seem to have their own versions
|
| GNU CLISP comes with two CLX implementations, MIT CLX and NCLX. The
| former, which is written in Lisp, has its roots in the original MIT/TI
| work on CLX. NCLX (New CLX) is a C implementation with the same Lisp
| interface of CLX. If I recall correctly, NCLX in now the preferred
| CLX for CLISP and MIT CLX is deprecated.
+---------------
But that's only because CLISP lacks a compiler to native code, yes?
So somebody did a C implementation to get speed faster than CLISP's
byte-code compiler could give. Should CLISP add compilation to native
code some day, that "deprecation" might be reversed.
CMUCL, already having a compiler to native code, would gain nothing
(and lose much maintainability) by switching from MIT CLX to NCLX.
[I can't speak for MIT CLX versus telent CLX.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> But that's only because CLISP lacks a compiler to native code, yes?
> So somebody did a C implementation to get speed faster than CLISP's
> byte-code compiler could give. Should CLISP add compilation to native
Yes, NCLX was initially developed by Gilbert Baumann to run Garnet
under CLISP with acceptable performance. For more information see:
http://cvs.sourceforge.net/viewcvs.py/clisp/clisp/modules/clx/new-clx/README?view=markup
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface