GUI-Toolkits under active development
Friedrich Dominicus
found some infos about GUI-Toolkits but most of them seem to be no
longer maintained. So maybe one can point me to a Toolkit which is
supported, and possibly run under different Lisps?
Is CLX the least common part of all the GUI-Toolkits?
Regards
Friedrich
Rainer Joswig
> I was looking at cons.org and have done a bit Internet search. And I
> found some infos about GUI-Toolkits but most of them seem to be no
> longer maintained. So maybe one can point me to a Toolkit which is
> supported, and possibly run under different Lisps?
All vendors seem to have atleast one own GUI toolkit.
LispWorks on Windows: CAPI (low level)
LispWorks Toolkit, based on CAPI
CLIM based on CAPI
LispWorks on Unix: CAPI/CLX (low level)
LispWorks Toolkit, based on CAPI
CLIM based on CAPI
Genera: CLX (low-level)
TV (low-level)
Dynamic Windows, based on TV (native, CLX, or Mac based)
Mac
CLIM
MCL Mac Toolbox
MCL Views
CLIM
ACL CLX
Common Windows
CLIM
...
...
> Is CLX the least common part of all the GUI-Toolkits?
It's like XLIB but written in Lisp. It can be compiled to use
classes or structures.
On top of that one might use things like CLUE/CLIO or other code.
CLM is another option. You might want to look what
CMUCL and CLisp users are currently using and
what is provided by their distributions.
Unfortunately there is currently no "free" version of CLIM, it might
be interesting to have one and some people seem to work (slowly)
on some components for a free CLIM.
Friedrich Dominicus
As I understand what you've written, that means you can't get a
GUI-Toolkit which runs under one or the other Lips. Just CLX seems to
run on a few Lisps.
I'm quite astonished than that the last files of CLX have been updated
arounr 1995. This is quite a time ago...
>
> ...
>
> > Is CLX the least common part of all the GUI-Toolkits?
>
> It's like XLIB but written in Lisp. It can be compiled to use
> classes or structures.
>
> On top of that one might use things like CLUE/CLIO or other code.
> CLM is another option. You might want to look what
> CMUCL and CLisp users are currently using and
> what is provided by their distributions.
I have looke into CMUCL but found just CLX and this was quite old. So I
wonder why that's the case see above. And worse there are just a very
few examples. I was hoping to find some more but wasn't very successull.
And what I found even more astonishing. That there seems to be no
packages which acces Tcl/Tk, GTK+, or QT. If found one Scheme which
relies on Tcl 8.0 and this looked quite interesting. But for Common
Lisp?
Regards
Friedrich
Martin Cracauer
>I was looking at cons.org and have done a bit Internet search. And I
>found some infos about GUI-Toolkits but most of them seem to be no
>longer maintained. So maybe one can point me to a Toolkit which is
>supported, and possibly run under different Lisps?
>Is CLX the least common part of all the GUI-Toolkits?
Only of the UNIX-based toolkits. Don't know about commercial CLIM
implementations, but everything free UNIX-based is based on CLX,
except for Web/HTML interfaces.
I think Garnet is currently the only free Lisp GUI toolkit that has a
cross-implementation usership, where usership means serious
development, not one-shot projects. It seems to be polished enough to
be useful without maintainance infrastructure (which doesn't exist).
The Motif stuff in CMUCL (based on CLM) is maintained since it is part
of the standard CMUCL distribution and hence will not break as CMUCL
envolves. I see major technical problems with it, though.
Foreign function bindings to the GNOME/GNU toolkit gtk+ seem to become
widely available. Some people don't like the FFI approach in general.
Additonally, in my opinion the gtk+ (C) interface design is exactly
what drives Lisp people away from many UNIX-based projects. The
interface is underdeveloped and full of simplifications that don't
make sense if you take a second look. The advantage of gtk+ is of
course that it has a working implementation (seriously, that's a major
problem with many other C/C++ -based GUI toolkits) and that it has a
large base of applications of compatible infrastructure and look and
feel.
I'm not sure what to do about CLIM. People who tried a free
implementation complained that it is a large unseperatable system.
Implement all or nothing. That doesn't sound appealing, I fear that
bugs in one level can't be worked around and that bug-fixing will be
very hard in general.
Remember that most of the commercial Lisp vendors designed the own GUI
toolkit after CLIM was available or at least they didn't drop their
own stuff for CLIM. That also points to major problems probably caused
by complexity. For me, it looks like the vendors regard CLIM as a
failure. If it's only failure was complexity for the user, why didn't
they develop another layer on top of CLIM, instead of starting from
scratch?
I'm not a fan of CLOS, so maybe I'm biased, but for me it looks that
Garnet is the fastest way to success for the free Lisp
implementations. The available stuff works better than the CLIM
version I tried and it much faster. Maybe Garnet's biggest problem is
that it works so well in its current incarnation, so that people
weren't forced to form a internet-based maintainance project and hence
publicity is zero.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar
program on a junk operating system, eh?
Rainer Joswig
> list snipped
>
> As I understand what you've written, that means you can't get a
> GUI-Toolkit which runs under one or the other Lips. Just CLX seems to
> run on a few Lisps.
CLX runs under all Lisps where it makes sense (-> X Windows).
But it is only really useful if you would like to write
more high-level stuff on top of that or if you need
speed.
CLIM runs on most commercial Lisps and is as high-level as you
can get.
> I'm quite astonished than that the last files of CLX have been updated
> arounr 1995. This is quite a time ago...
I think vendors might have updated their versions.
Actually the generally available CLX might need an update.
I think for Clisp their is direct support of the
C library.
> I have looke into CMUCL but found just CLX and this was quite old. So I
> wonder why that's the case see above. And worse there are just a very
> few examples. I was hoping to find some more but wasn't very successull.
Use the X docs. Look how CLUE/CLIO uses it.
> And what I found even more astonishing. That there seems to be no
> packages which acces Tcl/Tk, GTK+, or QT. If found one Scheme which
> relies on Tcl 8.0 and this looked quite interesting. But for Common
> Lisp?
There are libraries for some of that. But I don't have experience
using this stuff. Seems to be more experimental and I'm
not a user of Tcl/Tk, GTK+, or QT.
Example: A TCL/TK interface for Clisp should be
available at http://clisp.cons.org/ .
Also you might want to look at the old garnet toolkit:
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/garnet/www/garnet-home.html
Addtionally there are some pointers in the Lisp FAQ or
on www.lisp.org. Asking/browsing the mailing lists for CLisp, GCL
or CMU CL might bring up some answers.
Rainer Joswig
> I'm not a fan of CLOS, so maybe I'm biased, but for me it looks that
> Garnet is the fastest way to success for the free Lisp
> implementations. The available stuff works better than the CLIM
> version I tried and it much faster. Maybe Garnet's biggest problem is
> that it works so well in its current incarnation, so that people
> weren't forced to form a internet-based maintainance project and hence
> publicity is zero.
Actually Garnet is sometimes much slower, since it doesn't
really have an efficient implementation, it
does use it's own not optimized object system,
it conses like hell (which makes it IMHO unusable
on a system with a stupid GC - like CMU CL on Unix) and it looks
****ugly**** (big time), atleast on Unix - I haven't tried the patched
Mac version.
Well, it's interesting though and some people are using it
and they seem to be happy.
Rainer Joswig
Jason Trenouth
> In article <37BA4418...@inka.de>, Friedrich...@inka.de wrote:
>
> > I was looking at cons.org and have done a bit Internet search. And I
> > found some infos about GUI-Toolkits but most of them seem to be no
> > longer maintained. So maybe one can point me to a Toolkit which is
> > supported, and possibly run under different Lisps?
>
> All vendors seem to have atleast one own GUI toolkit.
>
> LispWorks on Windows: CAPI (low level)
> LispWorks Toolkit, based on CAPI
> CLIM based on CAPI
>
> LispWorks on Unix: CAPI/CLX (low level)
> LispWorks Toolkit, based on CAPI
> CLIM based on CAPI
I'm not quite sure what you're trying to say here, but this appears to be a
somewhat misleading picture of the relationships between LispWorks UI
toolkits. A more accurate list might be:
LispWorks for Windows
CAPI/GP
CLIM
LispWorks (for Unix)
CAPI/GP
CLIM
ToolKit/CLUE/CLX (GP)
LispWorks started out on Unix with CLX/CLUE/ToolKit UI layers. ToolKit was
Harlequin's alternative to the publicly available CLIO. (The LispWorks
environment was original written using CLX/CLUE/ToolKit).
Then Harlequin developed a portable next generation combination of GP/CAPI. GP
also saw life independently with CLX/CLUE/ToolKit, but that's not important.
(The LispWorks environment was rewritten in GP/CAPI so it became portable
too.)
CLIM was initially implemented on top of CAPI/GP, but later got its own native
backends.
NB GP/CAPI and the Common LispWorks environment also run on Liquid Common Lisp
(nee Lucid Common Lisp).
__Jason
Rainer Joswig
> I'm not quite sure what you're trying to say here, but this appears to be a
> somewhat misleading picture of the relationships between LispWorks UI
> toolkits. A more accurate list might be:
>
> LispWorks for Windows
> CAPI/GP
> CLIM
>
> LispWorks (for Unix)
> CAPI/GP
> CLIM
> ToolKit/CLUE/CLX (GP)
Thanks for the correction!
Fred Gilham
Rainer Joswig wrote:
>Actually Garnet is sometimes much slower, since it doesn't really have
>an efficient implementation, it does use it's own not optimized object
>system, it conses like hell (which makes it IMHO unusable on a system
>with a stupid GC - like CMU CL on Unix) and it looks ****ugly**** (big
>time), atleast on Unix - I haven't tried the patched Mac version.
Personally I think the above is somewhat harsher than I'd be willing
to agree with. I've used Garnet for some time now, for serious work.
A CMUCL image with Garnet is smaller (by a surprising amount) than a
CMUCL image with, for comparison, the CLOS-based CLUE + XIT. The
latter combination also seems to have less functionality than Garnet.
Garnet image: 18919424
CLUE + XIT image: 24170496
I'm also not convinced that Garnet's object system is slower than
CLOS, though I'm less sure on this account. Its prototype-instance
object model seems to fit better with GUI programming---it's often the
case that you want to take a copy of some object you already have,
change it slightly and then use it. The rate of consing seems
acceptable---I have little to compare it with, I suppose. At this
point it seems that if CMUCL runs acceptably on your hardware, Garnet
probably will as well. I've also gotten Garnet working under Linux
ACL 4.3 and 5.0, and it seems to work (except for some problem with
XPM/pixmap stuff).
As far as looks are concerned, besides its own `native' widget set
Garnet has a motif-like widget set that gives the 3-d look that people
seem to like these days.
The other thing about Garnet is that it is fun to program with. It is
kind of like lisp itself, in that it changes the way you think about
programming GUIs.
One major thing Garnet lacks is a pixel-canvas object. There is a
sort of XPM/pixmap interface but it is cumbersome to use and still
somewhat buggy. Also, Garnet doesn't seem to be as easy to extend as
people would probably like.
As far as maintenance and the like are concerned, Garnet is a lost
puppy in need of a home. I was thinking that I might like to become
the maintainer of Garnet, but my funding situation is somewhat
unsettled right now and I don't want to take it on and then have to
drop it. But if people have patches for Garnet I will incorporate
them and make the patched distributions available. I've already added
several patches to make it run better under CMUCL (and under > 8bit
displays). There are also patches by Douglas Crosher to make Garnet
use the CMUCL-x86 version's multiprocessing support. A distribution
incorporating these patches is available at
http://www2.cons.org:8000/ftp-area/cmucl/ports/garnet/
--
Fred Gilham gil...@csl.sri.com
"Come to me, all who labor and are heavy laden, and I will give you
rest. Take my yoke upon you, and learn from me, for I am gentle and
lowly in heart, and you will find rest for your souls. For my yoke
is easy, and my burden is light." --Jesus of Nazareth
Erik Naggum
| I'm quite astonished than that the last files of CLX have been updated
maybe it just isn't buggy?
#:Erik
--
(defun pringles (chips)
(loop (pop chips)))
Rainer Joswig
> CLOS, though I'm less sure on this account. Its prototype-instance
> object model seems to fit better with GUI programming---it's often the
> case that you want to take a copy of some object you already have,
> change it slightly and then use it.
I think that this is a topic one might need
to look deeper into. I have been using Object Lisp with UIs years ago
and I had a similar impression - I would think though,
that it should be possible to implement such a
prototype based GUI toolkit in CLOS.
For the record, the Newton had a very similar programming model -
like Object Lisp, which was the OO-extension of
the early Macintosh Common Lisp (then called differently).
Object Lisp came from the LMI Lisp machine, I think.
Also the SK8 system has a prototype-based object-system
based on a frame system implemented in CLOS. SK8 is
especially suited for easy UI development.
Paolo Amoroso
<Friedrich...@inka.de> wrote:
> longer maintained. So maybe one can point me to a Toolkit which is
> supported, and possibly run under different Lisps?
SLIK is a user interface toolkit that is part of PRISM, a radiation therapy
planning system developed at Washington University. The PRISM Web site is:
http://www.radonc.washington.edu/medinfo/prism/
The source code and documentation of SLIK are available at:
ftp://ftp.radonc.washington.edu/dist/slik/
It is based on CLX and CLOS and runs at least under ACL and CMU CL. SLIK is
not as fancy as other toolkits, but it may be adequate for certain
applications. I don't know whether SLIK is supported or not, and it seems
that it can be used only for non-commercial purposes. If you are
interested, you should contact the author.
Garnet is no longer officially maintained, but Fred Gilham collects bug
fixes, patches and improvements. His unofficial distribution is available
at:
http://www2.cons.org:8000/ftp-area/cmucl/ports/garnet/
By the way, I plan to spend some time playing with Garnet for learning how
to use it, and possibly how it works. Its performance is good under CMU CL
on my Pentium 200MHz Linux box with 64MB of RAM, and acceptable under CLISP
(with NCLX).
I would like to keep in touch with other Garnet users. Is anybody still
using it? Is anybody monitoring the garnet-users mailing list (or the
comp.windows.garnet group which has a bidirectional gateway with the list)?
<DREAM>Is there any interest in maintaining Garnet, <RAVING>and possibly
continuing its development</RAVING>?</DREAM>
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Martin Cracauer
>In article <7pecoj$1l06$1...@counter.bik-gmbh.de>, crac...@bik-gmbh.de (Martin Cracauer) wrote:
>> I'm not a fan of CLOS, so maybe I'm biased, but for me it looks that
>> Garnet is the fastest way to success for the free Lisp
>> implementations. The available stuff works better than the CLIM
>> version I tried and it much faster. Maybe Garnet's biggest problem is
>> that it works so well in its current incarnation, so that people
>> weren't forced to form a internet-based maintainance project and hence
>> publicity is zero.
>Actually Garnet is sometimes much slower, since it doesn't
>really have an efficient implementation, it
>does use it's own not optimized object system,
>it conses like hell (which makes it IMHO unusable
>on a system with a stupid GC - like CMU CL on Unix) and it looks
>****ugly**** (big time), atleast on Unix - I haven't tried the patched
>Mac version.
Well, I didn't say it is efficient, but for me it was speed-wise more
usable than my evaluation of CLIM 2.0 under Lispworks on the same
machine (SPARC 2).
Not to speak of documentation, examples etc.
The newer x86 (FreeBSD, Linux) versions of CMUCL have a good
generational GC. But CLIM on CMUCL would still be slower since the
CLOS of CMUCL isn't well tuned.
Lars Bjønnes
> Foreign function bindings to the GNOME/GNU toolkit gtk+ seem to become
> widely available. Some people don't like the FFI approach in general.
> Additonally, in my opinion the gtk+ (C) interface design is exactly
> what drives Lisp people away from many UNIX-based projects. The
> interface is underdeveloped and full of simplifications that don't
> make sense if you take a second look. The advantage of gtk+ is of
> course that it has a working implementation (seriously, that's a major
> problem with many other C/C++ -based GUI toolkits) and that it has a
> large base of applications of compatible infrastructure and look and
> feel.
Also, with Gnome, there is a standard way of storing userprefs,
registering applications, communicating with other programs (ORBit, a
Corba implementation) etc.
Do you have an URL to a GTK+-binding for ACL?
--
Lars
Marco Antoniotti
lar...@gdpm.no (Lars Bjønnes) writes:
An ACL GTK+ binding would be useless if no CMUCL binding were in place
as well.
And here come the problems. Either you use two separate bindings (due
to the different FFIs of the two implementations) or you use a
client/server solution similar to CMUCL/Motif.
This second solution may be a must, since there seems to be no
docemented and stable way to get into the GTK+ main event loop.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Rainer Joswig
> Well, I didn't say it is efficient, but for me it was speed-wise more
> usable than my evaluation of CLIM 2.0 under Lispworks on the same
> machine (SPARC 2).
Well, this might be some time ago...
When I was trying Garnet under CMUCL or ACL years ago
on a SPARC 2, it was a dog.
> The newer x86 (FreeBSD, Linux) versions of CMUCL have a good
> generational GC.
Martin, (I don't want sound to critical - CMU CL is great)
do you really think it has a "good" generational GC?
> But CLIM on CMUCL would still be slower since the
> CLOS of CMUCL isn't well tuned.
I think this would be an important area for a contribution.
Friedrich Dominicus
> As far as maintenance and the like are concerned, Garnet is a lost
> puppy in need of a home. I was thinking that I might like to become
> the maintainer of Garnet, but my funding situation is somewhat
> unsettled right now and I don't want to take it on and then have to
> drop it. But if people have patches for Garnet I will incorporate
> them and make the patched distributions available. I've already added
> several patches to make it run better under CMUCL (and under > 8bit
> displays). There are also patches by Douglas Crosher to make Garnet
> use the CMUCL-x86 version's multiprocessing support. A distribution
>
> http://www2.cons.org:8000/ftp-area/cmucl/ports/garnet/
I have download that stuff and I was even able to get it running but it
seems to me that it isn't a solution. It consumes sheer masses of RAM (>
80 MB !!!) and if I start the Inspector my computer can't stop
collecting garbage. The documentation seems to be much better but what
does that help if you can't run the examples within reasonable time?
So I guess I have to search further.
Regards
Friedrich
Howard R. Stearns
> ...
> I'm not sure what to do about CLIM. People who tried a free
> implementation complained that it is a large unseperatable system.
> Implement all or nothing. That doesn't sound appealing, I fear that
> bugs in one level can't be worked around and that bug-fixing will be
> very hard in general.
>
> Remember that most of the commercial Lisp vendors designed the own GUI
> toolkit after CLIM was available or at least they didn't drop their
> own stuff for CLIM. That also points to major problems probably caused
> by complexity. For me, it looks like the vendors regard CLIM as a
> failure. If it's only failure was complexity for the user, why didn't
> they develop another layer on top of CLIM, instead of starting from
> scratch?
>
> Garnet is the fastest way to success for the free Lisp
> implementations. The available stuff works better than the CLIM
> version I tried and it much faster. Maybe Garnet's biggest problem is
> that it works so well in its current incarnation, so that people
> weren't forced to form a internet-based maintainance project and hence
> publicity is zero.
I've been playing with implementing parts of CLIM, and I have so far
managed to untangle the following:
presentation-types
command-tables (uses presentation-types)
"paneless" application-frames (uses command tables)
Admitedly, this isn't enough to create very exciting user interfaces,
and I agree that it doesn't look very easy to untangle
panes/output-recording/incremental-redisplay/sheets/stream-panes/input-editing/....
One reason I decided to stay within the CLIM model as opposed to Garnet
is that I AM a CLOS fan and so I didn't like the idea of basing
everything on a different object model. Of course, if the Garnet object
model was built on CLOS/MOP as Rainer suggests could be possible, then
this would be analogous to CLIM being built on presentation-types built
on CLOS/MOP, and my objection would go away. Oh well, I already
started... Biases...
The only reason I mention this is to give people a chance to tell me
that splitting up CLIM and making parts available is either a waste of
time or something potentially usefull....
Paolo Amoroso
<Friedrich...@inka.de> wrote:
> I'm quite astonished than that the last files of CLX have been updated
> arounr 1995. This is quite a time ago...
More recently Gilbert Baumann developed NCLX, a CLX rewriting in C for
CLISP especially meant for running Garnet. It's much faster than MIT CLX.
It comes with the CLISP source distribution.
Marco Antoniotti
amo...@mclink.it (Paolo Amoroso) writes:
> On Wed, 18 Aug 1999 14:13:18 +0200, Friedrich Dominicus
> <Friedrich...@inka.de> wrote:
>
> > I'm quite astonished than that the last files of CLX have been updated
> > arounr 1995. This is quite a time ago...
>
> More recently Gilbert Baumann developed NCLX, a CLX rewriting in C for
> CLISP especially meant for running Garnet. It's much faster than MIT CLX.
> It comes with the CLISP source distribution.
Having been needeld on this point I must reply to this.
CLX on CLisp is "slow" probably because CLisp does not have a native
compiler. Performance for CLX under CMUCL is fine. CLX also
necessitates some low-level implementation dependent hacking to do
more efficient I/O.
Rainer Joswig
> Having been needeld on this point I must reply to this.
>
> CLX on CLisp is "slow" probably because CLisp does not have a native
> compiler. Performance for CLX under CMUCL is fine. CLX also
> necessitates some low-level implementation dependent hacking to do
> more efficient I/O.
Btw., I don't know that much about it, but isn't it also
that Lisp has its own X interface in terms of Lisp code
- whereas most systems do use an interface to the C code?
Is that right?
Lars Bjønnes
>
> An ACL GTK+ binding would be useless if no CMUCL binding were in place
> as well.
I just found the following, it seems to provide ACL, CLISP, and CMUCL.
<URL:http://www.uni-karlsruhe.de/~unk6/export/cl-gtk-1999-01-19.tar.gz>
I'll take a look at it.
--
Lars
Paolo Amoroso
<Friedrich...@inka.de> wrote:
> I have download that stuff and I was even able to get it running but it
> seems to me that it isn't a solution. It consumes sheer masses of RAM (>
> 80 MB !!!) and if I start the Inspector my computer can't stop
> collecting garbage. The documentation seems to be much better but what
> does that help if you can't run the examples within reasonable time?
This is surprising. As I have already said in this thread, I have a 200MHz
Red Hat 5.2 Linux box with 64MB of RAM. I use Fred's patched Garnet
distribution with CMU CL, and the one available at the CLISP site with
CLISP/NCLX. My window manager is fvwm 1.24r (I use it mostly at
1280x1024@8-bit). Garnet's performance is good with CMU CL, and acceptable
with CLISP.
With a dozen Garnet demos and Lapidary running at the same time under CMU
CL 18b, GNU Emacs 20.3 and Netscape 4.06 loaded, my system still doesn't
use swap space and there's even some spare RAM. Here's the output of free
under these conditions:
total used free shared buffers cached
Mem: 63388 61004 2384 28056 220 18760
-/+ buffers/cache: 42024 21364
Swap: 34268 0 34268
According to top, around 50-55% of memory is used by the CMU CL process
running Garnet (the only problem is that every now and then the Garnet apps
complain that they can not allocate enough color map entries, but this is
because of the Netscape vampire :) Am I misinterpreting the data?
Paolo Amoroso
wrote:
[About Garnet]
> on a system with a stupid GC - like CMU CL on Unix) and it looks
> ****ugly**** (big time), atleast on Unix - I haven't tried the patched
> Mac version.
Sure. But there are popular and useful applications--e.g. XDVI, XArchie,
GhostScript/View, XFig, etc.--developed with ugly toolkits such as Athena.
The Garnet look is better, and the Motif one it also offers is acceptable.
Marco Antoniotti
lar...@gdpm.no (Lars Bjønnes) writes:
It does not. I have been working a bit on it and there are some Guile
(read "vile", if it rhymes for you :) ) hacks that make the
compilation non working.
I also commented to Gilbert that his implementation is somewhat
duplicating work present in CMUCL/Motif and CLM. Maybe some
rethinking would be nice.
Anyway, I'd be willing to do some low-intensity work on it.
Fred Gilham
jos...@lavielle.com (Rainer Joswig) writes:
> ...
> Btw., I don't know that much about it, but isn't it also
> that Lisp has its own X interface in terms of Lisp code
> - whereas most systems do use an interface to the C code?
> Is that right?
Yes, the CLX library talks to the X server directly except often
there's a little stub of C code that provides a socket interface. CLX
implements the X protocol's client side in Lisp.
Fred Gilham
Friedrich Dominicus wrote:
>I have download that stuff and I was even able to get it running but
>it seems to me that it isn't a solution. It consumes sheer masses of
>RAM (> 80 MB !!!) and if I start the Inspector my computer can't stop
>collecting garbage. The documentation seems to be much better but
>what does that help if you can't run the examples within reasonable
>time?
This sounds like an installation problem to me. Can you describe your
system in more detail? I have a system that runs two Garnet lisp
processes at the same time on a laptop, along with another non-Garnet
lisp process. I don't have any performance problem. Admittedly the
laptop is a Pentium II with 80 Mb of memory, but if Garnet were
behaving as badly as you describe, this wouldn't be possible.
Friedrich Dominicus
>
> Friedrich Dominicus wrote:
>
> >I have download that stuff and I was even able to get it running but
> >it seems to me that it isn't a solution. It consumes sheer masses of
> >RAM (> 80 MB !!!) and if I start the Inspector my computer can't stop
> >collecting garbage. The documentation seems to be much better but
> >what does that help if you can't run the examples within reasonable
> >time?
>
> This sounds like an installation problem to me. Can you describe your
> system in more detail?
Of course I can and I'm quite sure that it's a misconfiguration on my
side the point is that it's not obvious to a non Lisp programmer how to
do it. But I think I found how to do it.
The System is
PII/350 MHz, 128 MB RAM, Debian glibc based (yesterday 2.0 today after
update 2.1
not tested garnet again.
CMU Common Lisp 18a+ release x86-linux 2.4.7 6 November 1998 cvs,
garnet version which was suggested here don't know the exact URL
Regards
Friedrich
Raymond Toy
Friedrich> Fred Gilham wrote:
>>
>> Friedrich Dominicus wrote:
>>
>> >I have download that stuff and I was even able to get it running but
>> >it seems to me that it isn't a solution. It consumes sheer masses of
>> >RAM (> 80 MB !!!) and if I start the Inspector my computer can't stop
>> >collecting garbage. The documentation seems to be much better but
>> >what does that help if you can't run the examples within reasonable
>> >time?
>>
>> This sounds like an installation problem to me. Can you describe your
>> system in more detail?
Friedrich> Of course I can and I'm quite sure that it's a misconfiguration on my
Friedrich> side the point is that it's not obvious to a non Lisp programmer how to
Friedrich> do it. But I think I found how to do it.
Friedrich> The System is
Friedrich> PII/350 MHz, 128 MB RAM, Debian glibc based (yesterday 2.0 today after
Friedrich> update 2.1
Friedrich> not tested garnet again.
Friedrich> CMU Common Lisp 18a+ release x86-linux 2.4.7 6 November 1998 cvs,
Did you compile garnet before trying to running it?
Like Fred, garnet runs fine for me on a 200 MHz K-6, 64 MB.
Ray
Fred Gilham
Friedrich Dominicus wrote:
>Of course I can and I'm quite sure that it's a misconfiguration on my
>side the point is that it's not obvious to a non Lisp programmer how
>to do it.
Sadly that's the case---the lisp open-source software (like a lot of
other open-source software, I might say) is often ``hackerware''.
>But I think I found how to do it.
I take it this means you are re-doing your installation and will
report back to us?
Martin Cracauer
> >> Friedrich Dominicus wrote:
> >>
> >> >I have download that stuff and I was even able to get it running but
> >> >it seems to me that it isn't a solution. It consumes sheer masses of
> >> >RAM (> 80 MB !!!) and if I start the Inspector my computer can't stop
> >> >collecting garbage. The documentation seems to be much better but
> >> >what does that help if you can't run the examples within reasonable
> >> >time?
>
>Did you compile garnet before trying to running it?
If you use an unpatched Garnet-3.0 on CMUCL/x86, there is a problem
with the default extension of compiled files, since stock garnet
doesn't know about .x86f.
I think it's possible that you compiled the files, but then loaded the
.lisp-files into your image, since (load ...) didn't find the compiled
files with the expected extension (works both ways).
Use the patches on cons.org.
Paolo Amoroso
<mar...@copernico.parades.rm.cnr.it> wrote:
> amo...@mclink.it (Paolo Amoroso) writes:
[...]
> > More recently Gilbert Baumann developed NCLX, a CLX rewriting in C for
> > CLISP especially meant for running Garnet. It's much faster than MIT CLX.
> > It comes with the CLISP source distribution.
>
> Having been needeld on this point I must reply to this.
>
> CLX on CLisp is "slow" probably because CLisp does not have a native
> compiler. Performance for CLX under CMUCL is fine. CLX also
> necessitates some low-level implementation dependent hacking to do
> more efficient I/O.
Of course Marco is right. I meant that NCLX is much faster than MIT CLX
under _CLISP_. NCLX was developed for CLISP from the start, and it is
probably not portable.
Friedrich Dominicus
> Did you compile garnet before trying to running it?
Yes I've done that after I worked a bit on the tour. It was very lame,
but that didn't help me on the tutorial.
Regards
Friedrich
Friedrich Dominicus
>
> Friedrich Dominicus wrote:
>
> >Of course I can and I'm quite sure that it's a misconfiguration on my
> >side the point is that it's not obvious to a non Lisp programmer how
> >to do it.
>
> Sadly that's the case---the lisp open-source software (like a lot of
> other open-source software, I might say) is often ``hackerware''.
I can't say that. most of the software I've installed come at least with
and README or an INSTALL none was found for Garnet and even after
downloading the docs no hint of how to install. Your only chance was to
read the sources. I guess for Lisp-Programmers this is easy.
>
> >But I think I found how to do it.
>
> I take it this means you are re-doing your installation and will
> report back to us?
I'm now re-compiling the sources maybe that helps.
Regards
Friedrich
Friedrich Dominicus
> > I take it this means you are re-doing your installation and will
> > report back to us?
> I'm now re-compiling the sources maybe that helps.
Yes now with compiled source it works nicely. So let's explare it ;-)
I was thinking, that I had compiled all the source but I hadn't. cmucl
was working and I wasn't aware that it was and interrupted it to early
so jut pieces were compiled.
Thanks for the tips.
Regards
Friedrich