From: Kenny Tilton
Subject: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF370B9.7B0E8EF5@nyc.rr.com>
Now that I see that CLIM has a layered design allowing me to leverage
lower level accomplishments without buying into higher-level decisions,
plus it's all Lisp all the time, geez, looks like a no-brainer. But I
still have options:


1. ACL + CLIM

Positives: I know/like the ACL IDE
Negatives: Pricey

2. LW + CLIM

Positives: I can stick with win32
Negatives: IDE is an unknown

3. Linux/CMUCL/EMACS/McCLIM

Positives: The Open Source community energy, help destroy Evil Empire
Negatives: Massive learning curve on Linux/CMUCL/EMACS

4. MCL + CLIM

Positives: I know/like MCL, own macs and MCL licenses already, and their
CLIM is cheapest commercial
Negatives: Last I looked no MOP support. (Are they mad?)


Questions:

Is LW pretty good? Their CLIM? If both are fine products that will
influence me a lot. I have the personal edition, will try to dig into
the IDE anyway to see what i can see, but feedback welcome.


Does it matter if I am open source if I want to help take out the Death
Star? As long as I have a package compatible with CLIM, does it matter
if I am ACL, LW, or MCL? if not, the linux-based option loses its
positive.

kenny
clinisys

From: Tim Bradshaw
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <fbc0f5d1.0111150336.6ab5aa23@posting.google.com>
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·················@nyc.rr.com>...
> Now that I see that CLIM has a layered design allowing me to leverage
> lower level accomplishments without buying into higher-level decisions,
> plus it's all Lisp all the time, geez, looks like a no-brainer. But I
> still have options:

I think that if you want to implement something that isn't
substantially CLIM then using CLIM's lower layers is a huge waste of
time.  CLIM is good at what it does, but what it does is be CLIM. 
Although, at least in theory, there is a lower-layer there most of it
is oriented to putting CLIM on top of it, and the bits that aren't may
not work as well as you'd like because they probably get almost no
use.

--tim
From: Kenny Tilton
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF3D82C.90727FC9@nyc.rr.com>
Tim Bradshaw wrote:
> 
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·················@nyc.rr.com>...
> > Now that I see that CLIM has a layered design allowing me to leverage
> > lower level accomplishments without buying into higher-level decisions,
> > plus it's all Lisp all the time, geez, looks like a no-brainer. But I
> > still have options:
> 
> I think that if you want to implement something that isn't
> substantially CLIM then using CLIM's lower layers is a huge waste of
> time.

The CLIM II spec over at http://www.mikemac.com/mike/clim/clim.html
says:

"The facilities provided by CLIM include: 

    [Geometry] CLIM provides provides geometric objects like point,
    rectangle, and transformations and functions for manipulating them. 

    [Graphics] CLIM provides a rich set of drawing functions, including
    ones for drawing complex geometric shapes, a wide variety of drawing
options
    (such as line thickness), a sophisticated inking model, and color. 
    CLIM provides full affine transforms, so that a drawing may be
arbitrarily 
    translated, rotated, and scaled (to the extent that the underlying
window system
    supports the rendering of such objects). 

    [Windowing] CLIM provides a portable layer for implementing sheet
classes 
    (types of window-like objects) that are suited to support particular
high
    level facilities or interfaces. The windowing module of CLIM defines
a 
     uniform interface for creating and managing hierarchies of these
objects
    regardless of their sheet class. This layer also provides event
management. 

    [Output Recording] CLIM provides a facility for capturing all output
done 
    to a window. This facility provides the support for arbitrarily
scrollable
    windows. In addition, this facility serves as the root for a variety
of 
    interesting high-level tools."

That sounds like a /lot/ of good stuff and because it is CLIM it is by
definition more portable than X (as long as McCLIM keeps on keeping on).

Is CLIM /bad/ at the above stuff? And when you say "huge waste of time",
compared to what alternative? I /have/ considered just going with native
OS stuff in the short term just to get the ball rolling, but if the
above facilities are for real it seems au contraire a huge win.

When I ported from MCL to ACL I discovered points and rectangles were
done differently. Not the end of the world, but it would be nice not to
have to bother with that kind of stuff.

>  CLIM is good at what it does, but what it does is be CLIM.
> Although, at least in theory, there is a lower-layer there most of it
> is oriented to putting CLIM on top of it, 

OK, I read this last. This does indeed sound as if you feel the
lower-level interface is crud. ie, as I dig into it I will be wondering
why something was done some brain-dead way and the reason will be "well,
the high level CLIM stuff works this way so the low level stuff has to
do this nonsense." 

is the layered structure a sham? an afterthought?

kenny
clinisys
From: Tim Bradshaw
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <fbc0f5d1.0111190215.5a962e38@posting.google.com>
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·················@nyc.rr.com>...
> is the layered structure a sham? an afterthought?

I don't think it's either.  What it is is a layered structure for
supporting CLIM.  It might be a layered structure for supporting
something else, but I think it would be interesteing to look at why no
one else has used it for that, including vendors who had access to all
the CLIM sources.

--tim
From: Scott McKay
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <7k8K7.4366$eh7.2835837@typhoon.ne.mediaone.net>
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
······················@nyc.rr.com...
>
>
> Tim Bradshaw wrote:
> >
> > Kenny Tilton <·······@nyc.rr.com> wrote in message
news:<·················@nyc.rr.com>...
> > > Now that I see that CLIM has a layered design allowing me to leverage
> > > lower level accomplishments without buying into higher-level
decisions,
> > > plus it's all Lisp all the time, geez, looks like a no-brainer. But I
> > > still have options:
> >
> > I think that if you want to implement something that isn't
> > substantially CLIM then using CLIM's lower layers is a huge waste of
> > time.
>
> The CLIM II spec over at http://www.mikemac.com/mike/clim/clim.html
> says:
>
> "The facilities provided by CLIM include:
>
>     [Geometry] CLIM provides provides geometric objects like point,
>     rectangle, and transformations and functions for manipulating them.
>
>     [Graphics] CLIM provides a rich set of drawing functions, including
>     ones for drawing complex geometric shapes, a wide variety of drawing
options
>     (such as line thickness), a sophisticated inking model, and color.
>     CLIM provides full affine transforms, so that a drawing may be
arbitrarily
>     translated, rotated, and scaled (to the extent that the underlying
window system
>     supports the rendering of such objects).
>
>     [Windowing] CLIM provides a portable layer for implementing sheet
classes
>     (types of window-like objects) that are suited to support particular
high
>     level facilities or interfaces. The windowing module of CLIM defines a
>      uniform interface for creating and managing hierarchies of these
objects
>     regardless of their sheet class. This layer also provides event
management.
>
>     [Output Recording] CLIM provides a facility for capturing all output
done
>     to a window. This facility provides the support for arbitrarily
scrollable
>     windows. In addition, this facility serves as the root for a variety
of
>     interesting high-level tools."
>
> That sounds like a /lot/ of good stuff and because it is CLIM it is by
> definition more portable than X (as long as McCLIM keeps on keeping on).
>
> Is CLIM /bad/ at the above stuff? And when you say "huge waste of time",
> compared to what alternative? I /have/ considered just going with native
> OS stuff in the short term just to get the ball rolling, but if the
> above facilities are for real it seems au contraire a huge win.

CLIM -- and DUIM for that matter -- are both pretty good at all of
the above. DUIM is better because it's the third try at implementing
a system like this.

Using the the output recording layer as-is costs you substantially over
doing "native graphics", but that's because there's a lot of object creation
going on.  In DUIM, calling the "medium" draw-xxx methods directly
is only a few percent slower than calling native drawing functions via
the FFI.  Calling "sheet" draw-xxx methods is a few percent slower
than that.  DUIM benefits from a simpler "design" model that more
closely matches what basically all modern toolkits provide.  In CLIM,
we were aiming for something like OpenGL, which appeared too late
and is not the default graphics model.

> When I ported from MCL to ACL I discovered points and rectangles were
> done differently. Not the end of the world, but it would be nice not to
> have to bother with that kind of stuff.

I wonder why this is?

> >  CLIM is good at what it does, but what it does is be CLIM.
> > Although, at least in theory, there is a lower-layer there most of it
> > is oriented to putting CLIM on top of it,
>
> OK, I read this last. This does indeed sound as if you feel the
> lower-level interface is crud. ie, as I dig into it I will be wondering
> why something was done some brain-dead way and the reason will be "well,
> the high level CLIM stuff works this way so the low level stuff has to
> do this nonsense."
>
> is the layered structure a sham? an afterthought?

The layered structure is designed from the ground-up.  Your mileage
may vary from one implementation to another.  I think that DUIM shows
pretty conclusively that a highly-layered approach, where each layer has
a first-class API, can produce high-performance in the face of a high
level of abstraction.
From: Will Deakin
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF38BA2.9020405@hotmail.com>
Kenny Tilton wrote:

> 2. LW + CLIM
> Negatives: IDE is an unknown

In my limited experience the 'native' IDE is cute and drives very 
much with most of the expected emacs-like keybindings. You can run 
it with ilisp too.

 
> Does it matter if I am open source if I want to help take out the Death
> Star? As long as I have a package compatible with CLIM, does it matter
> if I am ACL, LW, or MCL? if not, the linux-based option loses its
> positive.

You need to talk to a lawyer, which[1] I am not. However, my take on 
this is if the stuff generic CLIM and you release the source code 
then it *should* work on ACL, LW and MCL -- barring minor porting 
issues ;)

Stating the obvious, however, licensing bites when you need to 
deliver applications as runtimes or cores. In this case you need to 
talk carefully with the vendor on who's runtime you want to deploy.

But you know this already.

:)w


[1] thank the good Lord
From: Dr. Edmund Weitz
Subject: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <m3ofm4jr4a.fsf_-_@bird.agharta.de>
Will Deakin <···········@hotmail.com> writes:

> > 2. LW + CLIM
> > Negatives: IDE is an unknown
> 
> In my limited experience the 'native' IDE is cute and drives very much
> with most of the expected emacs-like keybindings. You can run it with
> ilisp too.

Is anybody using LispWorks with Emacs and would like to share his
experiences? Although I like the idea of having an Emacs-like editor
that's directly integrated into the CL environment, I think I might
prefer the combination of GNU Emacs with ILISP for a couple of reasons
(which include being somewhat familiar with it, having the same
interface for CMUCL, CLISP, and LW, and having available things like
CVS which GNU Emacs has but LW's editor hasn't AFAIK).

I've been considering buying LW for some time now but currently I'm
still using the Personal Edition. I'd like to try the LW/ILISP
combination before I buy it. Unfortunately, there seems to be no way
to use the Personal Edition with ILISP. (The ILISP documentation says
you'll have to save an image with the :ENVIRONMENT option set to NIL,
but SAVE-IMAGE isn't available in the Personal Edition...)

Any hints and recommendations are welcome.

Thanx in advance,
Edi.
From: Friedrich Dominicus
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <87zo5ol6wz.fsf@frown.here>
···@agharta.de (Dr. Edmund Weitz) writes:

> 
> Is anybody using LispWorks with Emacs and would like to share his
> experiences?
I have it running here. The only think I really have done was saving
an image without GUI Environment. But I'm using it very seldom. I do
like the LispWorks IDE.

> 
> I've been considering buying LW for some time now but currently I'm
> still using the Personal Edition. I'd like to try the LW/ILISP
> combination before I buy it.
You may check out http://www.q-software-solutions.com and gain a bit
from the introductery prices. I'm so convinced of LispWorks that we
offer it for buying too. 


> Unfortunately, there seems to be no way
> to use the Personal Edition with ILISP. (The ILISP documentation says
> you'll have to save an image with the :ENVIRONMENT option set to NIL,
> but SAVE-IMAGE isn't available in the Personal Edition...)
Yes there is not way to save a world without environment. I think
anyway that the price for LispWorks is quite reasonable.

Regards
Friedrich
From: Jochen Schmidt
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <9t04il$rdt$1@rznews2.rrze.uni-erlangen.de>
Dr. Edmund Weitz wrote:

> Will Deakin <···········@hotmail.com> writes:
> 
>> > 2. LW + CLIM
>> > Negatives: IDE is an unknown
>> 
>> In my limited experience the 'native' IDE is cute and drives very much
>> with most of the expected emacs-like keybindings. You can run it with
>> ilisp too.
> 
> Is anybody using LispWorks with Emacs and would like to share his
> experiences? Although I like the idea of having an Emacs-like editor
> that's directly integrated into the CL environment, I think I might
> prefer the combination of GNU Emacs with ILISP for a couple of reasons
> (which include being somewhat familiar with it, having the same
> interface for CMUCL, CLISP, and LW, and having available things like
> CVS which GNU Emacs has but LW's editor hasn't AFAIK).

I've used ILISP with LW for a while and it works ok. I had problems with
ILISP hanging sometimes if I used the IDE in parallel.

Today I almost only use the LW IDE since it is very nicely integrated.
It may be interesting for you that Xanalys is in Beta-testing phase for the
coming release 4.2. This release adds a lot of nice new things. You can 
contact Xanalys for a list of the new features.

> I've been considering buying LW for some time now but currently I'm
> still using the Personal Edition. I'd like to try the LW/ILISP
> combination before I buy it. Unfortunately, there seems to be no way
> to use the Personal Edition with ILISP. (The ILISP documentation says
> you'll have to save an image with the :ENVIRONMENT option set to NIL,
> but SAVE-IMAGE isn't available in the Personal Edition...)

That is true. At the look and feel section there is not much difference
between CMUCL/ILISP and LW/ILISP.

ciao,
Jochen

--
http://www.dataheaven.de
From: Dr. Edmund Weitz
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <m34rnwjory.fsf@bird.agharta.de>
Jochen Schmidt <···@dataheaven.de> writes:

> Today I almost only use the LW IDE since it is very nicely
> integrated.  It may be interesting for you that Xanalys is in
> Beta-testing phase for the coming release 4.2. This release adds a
> lot of nice new things. You can contact Xanalys for a list of the
> new features.

I remember Rolf Mach from Xanalys posting to this newsgroup that 4.2
will be presented at Linuxworld Expo and announced here shortly
afterwards. Now that Linuxworld is over, I've been wondering when 4.2
will be announced/ready. I think I'll contact them directly, thanks
for the tip.

Edi.
From: Marco Antoniotti
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <y6c4rnwgj66.fsf@octagon.mrl.nyu.edu>
ILISP with the freely downloadable LW on Windows has problems.

Under Windows, it seems like the only way to have ILISP and LW
communicate via ILISP is to save LW as a console application.

There has been some discussion in the ILISP mailing lists about this.

People from Xanalys can give you more info.

I am unaware of any specific problems w.r.t. other versions of
LW+Emacs+ILISP.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Dr. Edmund Weitz
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <m3eln0oxol.fsf@agharta.de>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> ILISP with the freely downloadable LW on Windows has problems.
> 
> Under Windows, it seems like the only way to have ILISP and LW
> communicate via ILISP is to save LW as a console application.

Only on Windows? If I start LispWorks from within Emacs/ILISP it
starts and works fine but I can't talk to it from the inferior Lisp
frame, i.e. I can type into the frame but what I type doesn't seem to
make its way to LW. Closing LW's listener window doesn't change
that. Am I doing something wrong?

(This is SuSE Linux 7.3 with LW Personal Edition 4.1.20, GNU Emacs
21.1, and ILISP 5.11.1.)

Edi.
From: Marco Antoniotti
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <y6clmh8f2h7.fsf@octagon.mrl.nyu.edu>
···@agharta.de (Dr. Edmund Weitz) writes:

> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> > ILISP with the freely downloadable LW on Windows has problems.
> > 
> > Under Windows, it seems like the only way to have ILISP and LW
> > communicate via ILISP is to save LW as a console application.
> 
> Only on Windows? If I start LispWorks from within Emacs/ILISP it
> starts and works fine but I can't talk to it from the inferior Lisp
> frame, i.e. I can type into the frame but what I type doesn't seem to
> make its way to LW. Closing LW's listener window doesn't change
> that. Am I doing something wrong?
> 
> (This is SuSE Linux 7.3 with LW Personal Edition 4.1.20, GNU Emacs
> 21.1, and ILISP 5.11.1.)

As I said I was unaware of this.  Maybe it'd be better to move this to
the ILISP mailing lists.

Also, I want to give credit to the Xanalys people for being very
helpful in making ILISP work well with LW.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Dr. Edmund Weitz
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <m3668couyv.fsf@agharta.de>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> As I said I was unaware of this.  Maybe it'd be better to move this to
> the ILISP mailing lists.

Yep, just did it.

Thanks,
Edi.
From: Wolfgang Mederle
Subject: Re: LispWorks with ILISP
Date: 
Message-ID: <6ol1t9.8qa.ln@DS9.mederle.de>
Es schrieb Edmund Weitz:

> Only on Windows? If I start LispWorks from within Emacs/ILISP it
> starts and works fine but I can't talk to it from the inferior Lisp
> frame, i.e. I can type into the frame but what I type doesn't seem to
> make its way to LW. Closing LW's listener window doesn't change
> that. Am I doing something wrong?

If you click on "break to tty" you can talk to LW from
ILISP. The drawback is that you cannot talk to the LW GUI anymore. The
windows are still there, but don't respond. Same with new windows you
create.

> (This is SuSE Linux 7.3 with LW Personal Edition 4.1.20, GNU Emacs
> 21.1, and ILISP 5.11.1.)

Same here, but Slackware 8.0 instead of SuSE.

-- 
Wolfgang Mederle
················@stud.uni-muenchen.de
http://www.mederle.de/
ICQ# 1435333
From: Dr. Edmund Weitz
Subject: Re: LispWorks with ILISP
Date: 
Message-ID: <m3zo5nwo9r.fsf@bird.agharta.de>
Thanks, that works. I get a lot of errors from ILISP, though (or
rather from ILISP loading its initialisation files into LW). Also, as
your posting already implied, not only you cannot talk to the IDE
anymore but you also cannot test or deploy CAPI application... :(

Thanks,
Edi.



Wolfgang Mederle <················@stud.uni-muenchen.de> writes:

> Es schrieb Edmund Weitz:
> 
> > Only on Windows? If I start LispWorks from within Emacs/ILISP it
> > starts and works fine but I can't talk to it from the inferior Lisp
> > frame, i.e. I can type into the frame but what I type doesn't seem to
> > make its way to LW. Closing LW's listener window doesn't change
> > that. Am I doing something wrong?
> 
> If you click on "break to tty" you can talk to LW from
> ILISP. The drawback is that you cannot talk to the LW GUI anymore. The
> windows are still there, but don't respond. Same with new windows you
> create.
> 
> > (This is SuSE Linux 7.3 with LW Personal Edition 4.1.20, GNU Emacs
> > 21.1, and ILISP 5.11.1.)
> 
> Same here, but Slackware 8.0 instead of SuSE.
> 
> -- 
> Wolfgang Mederle
> ················@stud.uni-muenchen.de
> http://www.mederle.de/
> ICQ# 1435333
From: Vebjorn Ljosa
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <cy31yizpwqk.fsf@ljosa.com>
* ···@agharta.de (Dr. Edmund Weitz)
| 
| I've been considering buying LW for some time now but currently I'm
| still using the Personal Edition. I'd like to try the LW/ILISP
| combination before I buy it. Unfortunately, there seems to be no way
| to use the Personal Edition with ILISP. (The ILISP documentation says
| you'll have to save an image with the :ENVIRONMENT option set to NIL,
| but SAVE-IMAGE isn't available in the Personal Edition...)

To use the personal edition with ILISP, you have to start Lispworks
with the IDE, and then stop the IDE and start a listener for
*terminal-io*.

I did this a few months ago, but I don't remember the details.  If you
can't figure it out, let me know, and I'll play with it again and see
if that makes me remember.

-- 
Vebjorn Ljosa
From: Vebjorn Ljosa
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <cy3adxnfdf1.fsf@ljosa.com>
* Vebjorn Ljosa <·····@ljosa.com>
| 
| To use the personal edition with ILISP, you have to start Lispworks
| with the IDE, and then stop the IDE and start a listener for
| *terminal-io*.
| 
| I did this a few months ago, but I don't remember the details.  If you
| can't figure it out, let me know, and I'll play with it again and see
| if that makes me remember.

After starting Lispworks and digging around with apropos for a while,
it all came back to me.  First start a listener on the terminal:

    (mp:process-run-function "My listener" nil 
                             #'system::listener-top-level *terminal-io*)

Then stop the IDE:

    (environment:stop-environment)

Hope this helps.

-- 
Vebjorn Ljosa
From: Dr. Edmund Weitz
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <m3wv0rxkhl.fsf@bird.agharta.de>
Vebjorn Ljosa <·····@ljosa.com> writes:

> * Vebjorn Ljosa <·····@ljosa.com>
> | 
> | To use the personal edition with ILISP, you have to start Lispworks
> | with the IDE, and then stop the IDE and start a listener for
> | *terminal-io*.
> | 
> | I did this a few months ago, but I don't remember the details.  If you
> | can't figure it out, let me know, and I'll play with it again and see
> | if that makes me remember.
> 
> After starting Lispworks and digging around with apropos for a while,
> it all came back to me.  First start a listener on the terminal:
> 
>     (mp:process-run-function "My listener" nil 
>                              #'system::listener-top-level *terminal-io*)
> 
> Then stop the IDE:
> 
>     (environment:stop-environment)
> 
> Hope this helps.
> 
> -- 
> Vebjorn Ljosa

Thanks, that _DOES_ help very much! However, I wonder if the second
step - stopping the IDE - is really necessary. If I do this, I can't
for example deploy the CAPI examples from their tutorial. If I don't,
the examples work - I just have the IDE sitting somewhere in the
background and can even use it if I want.

(I still have to find out how to get rid of all the error messages
produced by starting LW from ILISP, but I think I can cope with that.)

Thanks again,
Edi.
From: Alain Picard
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <86itcb2dbj.fsf@gondolin.local.net>
···@agharta.de (Dr. Edmund Weitz) writes:


> Is anybody using LispWorks with Emacs and would like to share his
> experiences? 

I've been using that combination daily for a year.
On linux, it's okay (ish), on Windows, there are some
annoying bugs (basically, hitting C-M-x to eval a form
can take many many seconds to execute, don't know why).

ILISP is one of these annoying packages: it's just good
enough that you don't want to bother re-writing it.  :-)
Out of the box, it really gets in your face, there you can
turn most of that stuff off.

I just _have_ to do my work in emacs, however, (specially
all the CVS stuff, and all my fancy editing customizations)
so I can't really abide the LW editor.  I'd LOVE for Xanalys
to officially support some sort of mode where emacs can be
used as the editor *simultaneously* with the rest of their IDE.

Given the choice, I choose emacs over the IDE for day to day work.
[Of course, there are many occasions where you fire up the IDE,
to use the many cool toys provided.]

The really annoying missing features in ilisp is multithreading.
The maintainers (and all users, I guess) already know about it.

That help?

-- 
It would be difficult to construe        Larry Wall, in  article
this as a feature.			 <·····················@netlabs.com>
From: Marco Antoniotti
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <y6cofm24uf3.fsf@octagon.mrl.nyu.edu>
Alain Picard <·······@optushome.com.au> writes:

> ···@agharta.de (Dr. Edmund Weitz) writes:
> 
> 
> > Is anybody using LispWorks with Emacs and would like to share his
> > experiences? 
> 
> I've been using that combination daily for a year.
> On linux, it's okay (ish), on Windows, there are some
> annoying bugs (basically, hitting C-M-x to eval a form
> can take many many seconds to execute, don't know why).
> 
> ILISP is one of these annoying packages: it's just good
> enough that you don't want to bother re-writing it.  :-)
> Out of the box, it really gets in your face, there you can
> turn most of that stuff off.

I have to agree.

A lot of ILISP could use a rewrite (there is a lot of cruft in
it). However, the energies to do so are severely limited.

> I just _have_ to do my work in emacs, however, (specially
> all the CVS stuff, and all my fancy editing customizations)
> so I can't really abide the LW editor.  I'd LOVE for Xanalys
> to officially support some sort of mode where emacs can be
> used as the editor *simultaneously* with the rest of their IDE.
> 
> Given the choice, I choose emacs over the IDE for day to day work.
> [Of course, there are many occasions where you fire up the IDE,
> to use the many cool toys provided.]
> 
> The really annoying missing features in ilisp is multithreading.
> The maintainers (and all users, I guess) already know about it.

It has been particularly sad state of affairs with ACL.  Users of ELI
expect the kind of interaction they get with ELI/ACL and they get
frustrated with ILISP.  Unfortunately doing "multitasking" correctly
in ILISP requires quite a rewrite.

Anybody willing to pick up the challenge is welcome.

Just remember that your solution must accommodate *all* (well, most)
CL implementations plus a few Scheme's.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Thor Kristoffersen
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <yznsnbf55j0.fsf@triumph.nr.no>
Alain Picard writes:
> I just _have_ to do my work in emacs, however, (specially
> all the CVS stuff, and all my fancy editing customizations)
> so I can't really abide the LW editor.

Yeah, me too.

> I'd LOVE for Xanalys to officially support some sort of mode where emacs
> can be used as the editor *simultaneously* with the rest of their IDE.

Well, you _can_ get both Emacs and the IDE if you dump a new image like
this, and then fire up that image from ILISP:

  (load-all-patches)
  (load "lib/4-1-0-0/config/configure.lisp")
  (save-image "lispworks" :environment :with-tty-listener)
  (quit)

I only wish they would provide the same possibilities for the Personal
Edition (which is what I'm using at home).


Thor
From: Erik Haugan
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <87pu6isxga.fsf@kometknut.neitileu.no>
* Alain Picard <·······@optushome.com.au>
> I'd LOVE for Xanalys
> to officially support some sort of mode where emacs can be
> used as the editor *simultaneously* with the rest of their IDE.

What do you mean?  I fire up the IDE from ILISP whenever I have to.

> The really annoying missing features in ilisp is multithreading.
> The maintainers (and all users, I guess) already know about it.

I've seen people mention this, but I don't really get what it means.  What
could you do with a multithreading ILISP?  Wouldn't it require a
multithreading Emacs?

Erik
From: Erik Naggum
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <3214946611295303@naggum.net>
* Erik Haugan <····@haugan.no>
| I've seen people mention this, but I don't really get what it means.
| What could you do with a multithreading ILISP?  Wouldn't it require a
| multithreading Emacs?

  I guess it has to be seen in use to be considered useful.  E.g., you
  could do a large compilation in another thread and not impact symbol
  completion, which, incidentally, would not impact any work in progress in
  the listener where you requested symbol completion.  All compilations
  from Emacs could be performed in their own threads because the Common
  Lisp system would never know how long they would take to complete.  The
  most user-visible feature is that you can have multiple interaction
  buffers, or "Lisp listeners".  Emacs is not multithreaded, but each
  buffer that talks to a subprocess can perform I/O "simultaneously".

  I thought you had played with Allegro CL and the Emacs-Lisp Interface,
  but if not, it is hard to see from the documentation how this can be used
  profitably and conveniently.  The Emacs function fi:open-lisp-listener is
  a good start to get a new listener.  Using M-x fi:compile-file, etc, is
  also more convenient than giving the commands directly to the repl,
  despite with the :cf shorthand.  Both menus and keybindings exist for
  many of these useful functions.  It takes some getting used to, since the
  whole interface is built on a fairly old version of the comint package,
  but it is well worth it.

///
-- 
  Norway is now run by a priest from the fundamentalist Christian People's
  Party, the fifth largest party representing one eighth of the electorate.
-- 
  Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
From: Erik Haugan
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <87herrrt8r.fsf@kometknut.neitileu.no>
* Erik Naggum <····@naggum.net>
> I guess it has to be seen in use to be considered useful.  E.g., you
> could do a large compilation in another thread and not impact symbol
> completion, which, incidentally, would not impact any work in progress in
> the listener where you requested symbol completion.

I suspected it was something like this (working while compiling).  You're
probably right I'll have to see and use it in order to appreciate it.
(Ignorance is bliss! :-)

>   I thought you had played with Allegro CL and the Emacs-Lisp Interface,

I did, but only to learn CL, not ELI.  I'll probably get back to it in the
future though.

Erik
From: Dr. Edmund Weitz
Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...)
Date: 
Message-ID: <m3g07esxq8.fsf@duke.agharta.de>
Alain Picard <·······@optushome.com.au> writes:

> ···@agharta.de (Dr. Edmund Weitz) writes:
>
>
>> Is anybody using LispWorks with Emacs and would like to share his
>> experiences? 
>
> I've been using that combination daily for a year.
> On linux, it's okay (ish), on Windows, there are some
> annoying bugs (basically, hitting C-M-x to eval a form
> can take many many seconds to execute, don't know why).
>
> ILISP is one of these annoying packages: it's just good
> enough that you don't want to bother re-writing it.  :-)
> Out of the box, it really gets in your face, there you can
> turn most of that stuff off.
>
> I just _have_ to do my work in emacs, however, (specially
> all the CVS stuff, and all my fancy editing customizations)
> so I can't really abide the LW editor.  I'd LOVE for Xanalys
> to officially support some sort of mode where emacs can be
> used as the editor *simultaneously* with the rest of their IDE.
>
> Given the choice, I choose emacs over the IDE for day to day work.
> [Of course, there are many occasions where you fire up the IDE,
> to use the many cool toys provided.]
>
> The really annoying missing features in ilisp is multithreading.
> The maintainers (and all users, I guess) already know about it.
>
> That help?

It does. Thank you very much!

Maybe there are some editor improvements in LW 4.2. Some of the IDE
thingies from LW are really nice, and I also wish there would be a
chance to use Emacs in parallel to the IDE. (Or maybe they should
provide the editor source code so that it's easier to
customize. Doesn't Digitool do something like that with their 'Fred'
emacs-clone?)

Thanks again,
Edi.
From: Friedrich Dominicus
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <874rnwmn23.fsf@frown.here>
Kenny Tilton <·······@nyc.rr.com> writes:

> Now that I see that CLIM has a layered design allowing me to leverage
> lower level accomplishments without buying into higher-level decisions,
> plus it's all Lisp all the time, geez, looks like a no-brainer. But I
> still have options:
> 
> 
> 1. ACL + CLIM
> 
> Positives: I know/like the ACL IDE
> Negatives: Pricey
> 
> 2. LW + CLIM
> 
> Positives: I can stick with win32
uncessary. CLIM run on Linux too.
it seems that the LW customers prefer CAPI. I do think if you look a
the examples you will find out why that's the case
> Negatives: IDE is an unknown
What does that mean?

Regards
Friedrich
From: Kenny Tilton
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF3CEC8.8EE64799@nyc.rr.com>
Friedrich Dominicus wrote:
> 
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> > Positives: I can stick with win32
> uncessary. CLIM run on Linux too.

sorry, i was too obscure there, what I meant was "I do not have to spend
a week getting up to speed on Linux, more time getting used to CMUCL and
EMACS". Those are not Bad Things to do with my time, I just do not have
much time.

> it seems that the LW customers prefer CAPI. I do think if you look a
> the examples you will find out why that's the case

i want to do something portable. CAPI looks proprietary to me.
re-education welcome. :)

> > Negatives: IDE is an unknown
> What does that mean?

unknown to me, so i was inviting comment. i have the personal edition
DLed so I can look for myself before plunking for the $700, but if folks
say LW is OK i would skip that step and just plunk away.

kenny
clinisys
From: Friedrich Dominicus
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <87n11ojgsu.fsf@frown.here>
Kenny Tilton <·······@nyc.rr.com> writes:

> Friedrich Dominicus wrote:
> > 
> > Kenny Tilton <·······@nyc.rr.com> writes:
> > 
> > > Positives: I can stick with win32
> > uncessary. CLIM run on Linux too.
> 
> sorry, i was too obscure there, what I meant was "I do not have to spend
> a week getting up to speed on Linux, more time getting used to CMUCL and
> EMACS". Those are not Bad Things to do with my time, I just do not have
> much time.
WEll you have to learn how LispWorks works. This will take quite some time.
> 
> > it seems that the LW customers prefer CAPI. I do think if you look a
> > the examples you will find out why that's the case
> 
> i want to do something portable. CAPI looks proprietary to me.
> re-education welcome. :)
That's true. But again look at a CLIM application and look at a CAPI
application than judge if portability is the most important. (You told
something about sticking to Windows.) CLIM looks like CLIM but CAPI
looks like Motif on Unice and native Windows like on Windows. That can
make a difference.

> 
> > > Negatives: IDE is an unknown
> > What does that mean?
> 
> unknown to me, so i was inviting comment. i have the personal edition
> DLed so I can look for myself before plunking for the $700, but if folks
> say LW is OK i would skip that step and just plunk away.
Well I use the IDE nearly exclusivly. As pointed out in another
message you may check http://www.q-software-solutions.com.

Regards
Friedrich
From: Kenny Tilton
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF3E12D.2AD0663C@nyc.rr.com>
Friedrich Dominicus wrote:
> 
> WEll you have to learn how LispWorks works. This will take quite some time.

i recall the shift from MCL to ACL--hated ACL at first until my brain
rewired for the ACL Way, now I love it. Is that what you are talking
about, or something worse?

Of course if Tim talks me out of CLIM this is all moot. :(

> That's true. But again look at a CLIM application and look at a CAPI
> application than judge if portability is the most important. (You told
> something about sticking to Windows.)

Well I intend to share this with the CL community at large. "sticking to
windows" just lets me avoid the hassle of getting Linux/CMUCL/CLX up and
running. Indeed I should have mentioned another alternative:

take the money I would spend on ACL CLIM or LW and pay some NYC area
Linux/CMUCL-savvy type to get that stuff installed on my NT box under
VMWare.


> CLIM looks like CLIM but CAPI
> looks like Motif on Unice and native Windows like on Windows. That can
> make a difference.

that kind of goal could be targeted by something built on top of the
contrib I have in mind, viz., Garnet-like constraints. I have been using
them in my own stuff for eight years and they work great. It's a real
low-level thing, tho, so if others truly groove on getting native
look/feel out of a portable CL hack they could build it atop my stuff.

Under win32 I use the 3d drawing primitives to draw my own widgets from
scratch, they look quite windows-y. i recently also tapped into the
WM_SYSCOLORS (?) message so our windows update on the fly to user
changes of the Display>Appearance> settings.

So i am down for that sort of thing, but it is not an immediate project
objective.

I did check out the Q link, thx, interesting.

kenny
clinisys
From: Friedrich Dominicus
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <9t0v17$ejg$03$1@news.t-online.com>
"Kenny Tilton" <·······@nyc.rr.com> schrieb im Newsbeitrag
······················@nyc.rr.com...
>
>
> Friedrich Dominicus wrote:
> >
> > WEll you have to learn how LispWorks works. This will take quite some
time.
>
> i recall the shift from MCL to ACL--hated ACL at first until my brain
> rewired for the ACL Way, now I love it. Is that what you are talking
> about, or something worse?
Not just about learning a new environment.

Regards
Friedrich
From: Janis Dzerins
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <87itcbdj3u.fsf@asaka.latnet.lv>
Kenny Tilton <·······@nyc.rr.com> writes:

> Under win32 I use the 3d drawing primitives to draw my own widgets from
> scratch, they look quite windows-y.

Win3.1-y, Win95-y or WinXP-y? :)

-- 
Janis Dzerins

  Eat shit -- billions of flies can't be wrong.
From: Kenny Tilton
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF51CD0.4382B059@nyc.rr.com>
Janis Dzerins wrote:
> 
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> > Under win32 I use the 3d drawing primitives to draw my own widgets from
> > scratch, they look quite windows-y.
> 
> Win3.1-y, Win95-y or WinXP-y? :)

NT-y :)

k
c
From: Francis Leboutte
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <pqg9vtostn60cbqi8hsjne18fe3coos8po@4ax.com>
Friedrich Dominicus <·····@q-software-solutions.com> wrote:

>That's true. But again look at a CLIM application and look at a CAPI
>application than judge if portability is the most important. (You told
>something about sticking to Windows.) CLIM looks like CLIM but CAPI
>looks like Motif on Unice and native Windows like on Windows. That can
>make a difference.

I don't know CAPI, but having used CLIM (some years ago) I agree that CLIM fails
to give the look and feel of the system on which the application is running,
which diminish its interest. It's a pity that CLIM hasn't make any progress in
this area. Maybe the Lisp vendors think it is against their interest to make
CLIM evolve? Or are there technical reasons to this situation?
--
www.algo.be
Logo programming : www.algo.be/logo.html
From: Scott McKay
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <Lw8J7.842$Rf2.640597@typhoon.ne.mediaone.net>
"Francis Leboutte" <··········@algo.be> wrote in message
·······································@4ax.com...
> Friedrich Dominicus <·····@q-software-solutions.com> wrote:
>
> >That's true. But again look at a CLIM application and look at a CAPI
> >application than judge if portability is the most important. (You told
> >something about sticking to Windows.) CLIM looks like CLIM but CAPI
> >looks like Motif on Unice and native Windows like on Windows. That can
> >make a difference.
>
> I don't know CAPI, but having used CLIM (some years ago) I agree that CLIM
fails
> to give the look and feel of the system on which the application is
running,
> which diminish its interest. It's a pity that CLIM hasn't make any
progress in
> this area. Maybe the Lisp vendors think it is against their interest to
make
> CLIM evolve? Or are there technical reasons to this situation?

In my opinion, the smartest thing would be for someone to port
DUIM from Dylan to Common Lisp, and then port CLIM's
presentation-based UI system on top of that.  The back-end I
propose is Gtk, which runs on "everything".

This would solve:
 - The broken low-level layers of CLIM
 - The missing high-level layers of DUIM
 - The portability issue

It would be slightly incompatible with CLIM 2.

If a group of people paid me to do this, I estimate that I could do all
of the work is 6 to 8 months, and the result would be a kick-ass
portable, open-source UI toolkit for the Lisp community.
From: Arthur Lemmens
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF63F49.E097A5DC@xs4all.nl>
Scott McKay wrote:

>  - The broken low-level layers of CLIM

Could you explain what's broken in CLIM's low-level layers? Is there 
something fundamentally wrong with the design or are there just some 
small mistakes?

I've been working on implementing the first 16 chapters of CLIM 2. 
I haven't noticed any fundamental problems so far. I find CLIM weak 
on font and internationalization issues, but as far as I can see it 
would be possible to extend the chapters on text styles and extended 
stream output without introducing incompatibilities with the current 
spec. 

Arthur Lemmens
From: Kent M Pitman
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <sfw4rnt7j27.fsf@shell01.TheWorld.com>
Arthur Lemmens <········@xs4all.nl> writes:

> Scott McKay wrote:
> 
> >  - The broken low-level layers of CLIM
> 
> Could you explain what's broken in CLIM's low-level layers? Is there 
> something fundamentally wrong with the design or are there just some 
> small mistakes?
> 
> I've been working on implementing the first 16 chapters of CLIM 2. 
> I haven't noticed any fundamental problems so far. I find CLIM weak 
> on font and internationalization issues, but as far as I can see it 
> would be possible to extend the chapters on text styles and extended 
> stream output without introducing incompatibilities with the current 
> spec. 

yes, as to fonts, I seem to recall CLIM permits fonts not to scale
correctly in ways that can seriously impact certain applications.  is
that what you mean?  also, of course, it doesn't have a lot of fonts
to choose portably among.  what other font problems might you see?
most weaknesses here could be fixed without incompatibility, assuming
you think tightening the requirement about font scaling was a 
compatible fix.

as to internationalization, i'm not sure if i see what you mean.
are you just saying that because it's procedural it's hard to just
strip in a vector of strings for some other language in order to change
an interface, or are you making some other point that's going right
past me?  i'm not sure what to say about compatibility here since i'm
not sure i see the issue at a fine enough level of detail (yet).
From: Arthur Lemmens
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF909A8.E4F347CF@xs4all.nl>
Kent M Pitman wrote:

> yes, as to fonts, I seem to recall CLIM permits fonts not to scale
> correctly in ways that can seriously impact certain applications.  

I don't understand what you're talking about here. Are you referring 
to merging text styles with relative (:smaller, :larger) and logical 
(:small, :normal, :large, etc.) sizes? 

> it doesn't have a lot of fonts to choose portably among.  what other 
> font problems might you see?

Some things I've been thinking about:
- split text-style-face into something like text-style-weight, 
  text-style-slant and text-style-attributes
- text-style-family should accept arbitrary names (strings or symbols),
  not just three keywords
- there should be a way to find out which fonts are available;
  maybe a function which takes a (partially specified) text style?

As to internationalization and fonts, one of the following seems 
indispensable:
- a way to determine if an arbitrary character (or string) can be 
  displayed with a given font
- a way to determine which fonts are available for a given character
  set. This raises the question what a character set is, of course;
  CLIM doesn't answer that question (understandably).

> as to internationalization, i'm not sure if i see what you mean.
> are you just saying that because it's procedural it's hard to just
> strip in a vector of strings for some other language in order to 
> change an interface

No, I don't think that's CLIM's responsibility. 

> or are you making some other point that's going right past me?  

The chapter on extended stream output assumes a left-to-right 
writing direction. This is wrong for languages like Arabic and 
Hebrew. There should be some way to allow for what the Unicode 
standard calls "bidirectional behavior".
From: Scott McKay
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <k68K7.4358$eh7.2824264@typhoon.ne.mediaone.net>
"Arthur Lemmens" <········@xs4all.nl> wrote in message
······················@xs4all.nl...
>
> Kent M Pitman wrote:
>
> > yes, as to fonts, I seem to recall CLIM permits fonts not to scale
> > correctly in ways that can seriously impact certain applications.
>
> I don't understand what you're talking about here. Are you referring
> to merging text styles with relative (:smaller, :larger) and logical
> (:small, :normal, :large, etc.) sizes?

CLIM does not apply the "user transform" to fonts.  This was a
deliberate decision based on the performance characteristics at
the time.  Given the availability of faster algorithms and processors,
and things as "TrueType" fonts, this decision could be changed.

> > it doesn't have a lot of fonts to choose portably among.  what other
> > font problems might you see?
>
> Some things I've been thinking about:
> - split text-style-face into something like text-style-weight,
>   text-style-slant and text-style-attributes
> - text-style-family should accept arbitrary names (strings or symbols),
>   not just three keywords

FWIW, the above describes what we did in DUIM.

> - there should be a way to find out which fonts are available;
>   maybe a function which takes a (partially specified) text style?

This is just plain hard to do with a portable API...

> As to internationalization and fonts, one of the following seems
> indispensable:
> - a way to determine if an arbitrary character (or string) can be
>   displayed with a given font
> - a way to determine which fonts are available for a given character
>   set. This raises the question what a character set is, of course;
>   CLIM doesn't answer that question (understandably).

Doing the above requires thinking about what character sets are
in a very rigorous way.

> > as to internationalization, i'm not sure if i see what you mean.
> > are you just saying that because it's procedural it's hard to just
> > strip in a vector of strings for some other language in order to
> > change an interface
>
> No, I don't think that's CLIM's responsibility.
>
> > or are you making some other point that's going right past me?
>
> The chapter on extended stream output assumes a left-to-right
> writing direction. This is wrong for languages like Arabic and
> Hebrew. There should be some way to allow for what the Unicode
> standard calls "bidirectional behavior".

Actually, CLIM does support bidirectional fonts, but it's not advertised.
From: Arthur Lemmens
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BFA300E.A86EF9C3@xs4all.nl>
Scott McKay wrote:

> CLIM does not apply the "user transform" to fonts.  

Are you talking about the CLIM spec here or about a specific 
implementation? Isn't the transform-glyphs parameter for draw-text
intended to control this?

> > - there should be a way to find out which fonts are available;
> >   maybe a function which takes a (partially specified) text style?
> 
> This is just plain hard to do with a portable API...

Why? Are there graphic backends that do have font support but don't
have a way to find out which fonts are available?

> > As to internationalization and fonts, one of the following seems
> > indispensable:
> > - a way to determine if an arbitrary character (or string) can be
> >   displayed with a given font
> > - a way to determine which fonts are available for a given character
> >   set. This raises the question what a character set is, of course;
> >   CLIM doesn't answer that question (understandably).
> 
> Doing the above requires thinking about what character sets are
> in a very rigorous way.

If you choose the second way, yes. Maybe not if you choose the first
way.

> > The chapter on extended stream output assumes a left-to-right
> > writing direction. This is wrong for languages like Arabic and
> > Hebrew. There should be some way to allow for what the Unicode
> > standard calls "bidirectional behavior".
> 
> Actually, CLIM does support bidirectional fonts, but it's not advertised.

I'm not sure I understand what a bidirectional font is, but I don't 
think that support for them would be good enough for conformance with 
Unicode. According to Unicode, the direction of a character can depend
on the surrounding characters (especially on the bidirectional coding
characters).
From: Scott McKay
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <kGsK7.6790$eh7.3812478@typhoon.ne.mediaone.net>
"Arthur Lemmens" <········@xs4all.nl> wrote in message
······················@xs4all.nl...
>
>
> Scott McKay wrote:
>
> > CLIM does not apply the "user transform" to fonts.
>
> Are you talking about the CLIM spec here or about a specific
> implementation? Isn't the transform-glyphs parameter for draw-text
> intended to control this?
>
> > > - there should be a way to find out which fonts are available;
> > >   maybe a function which takes a (partially specified) text style?
> >
> > This is just plain hard to do with a portable API...
>
> Why? Are there graphic backends that do have font support but don't
> have a way to find out which fonts are available?

When I was designing CLIM (and DUIM) and was looking at the APIs
for doing this sort of thing, the support was spotty and hugely variable,
making it very hard to come up with a portable API.  I don't doubt that
things might be better now, but at the time it was very tough.

> > > As to internationalization and fonts, one of the following seems
> > > indispensable:
> > > - a way to determine if an arbitrary character (or string) can be
> > >   displayed with a given font
> > > - a way to determine which fonts are available for a given character
> > >   set. This raises the question what a character set is, of course;
> > >   CLIM doesn't answer that question (understandably).
> >
> > Doing the above requires thinking about what character sets are
> > in a very rigorous way.
>
> If you choose the second way, yes. Maybe not if you choose the first
> way.
>
> > > The chapter on extended stream output assumes a left-to-right
> > > writing direction. This is wrong for languages like Arabic and
> > > Hebrew. There should be some way to allow for what the Unicode
> > > standard calls "bidirectional behavior".
> >
> > Actually, CLIM does support bidirectional fonts, but it's not
advertised.
>
> I'm not sure I understand what a bidirectional font is, but I don't
> think that support for them would be good enough for conformance with
> Unicode. According to Unicode, the direction of a character can depend
> on the surrounding characters (especially on the bidirectional coding
> characters).

Remember that CLIM predates Unicode.
From: Arthur Lemmens
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BFA5F05.EF8F26EC@xs4all.nl>
Scott McKay wrote:

> > I'm not sure I understand what a bidirectional font is, but I don't
> > think that support for them would be good enough for conformance with
> > Unicode. According to Unicode, the direction of a character can depend
> > on the surrounding characters (especially on the bidirectional coding
> > characters).
> 
> Remember that CLIM predates Unicode.

Of course. I didn't mean to criticize you or CLIM. 
I'm just trying to learn more about it.

Thanks a lot for your comments.
From: Pekka P. Pirinen
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <ud72ad8xp.fsf@globalgraphics.com>
Arthur Lemmens <········@xs4all.nl> writes:
> Scott McKay wrote:
> > > As to internationalization and fonts, one of the following seems
> > > indispensable:
> > > - a way to determine if an arbitrary character (or string) can be
> > >   displayed with a given font
> > > - a way to determine which fonts are available for a given character
> > >   set. This raises the question what a character set is, of course;
> > >   CLIM doesn't answer that question (understandably).
> > 
> > Doing the above requires thinking about what character sets are
> > in a very rigorous way.

I have to emphasize this: We don't need another incompatible approach
to this issue that ought to be standardized.  Reading ANSI CL 13.1.2
is a good introduction to the CL approach, even though the committee
stopped short of providing actual language representations for most
concepts.

> If you choose the second way, yes. Maybe not if you choose the first
> way.

No, you still have to know how to translate the Lisp character into
the encoding used by the font.

Actually, this should not be CLIM's problem at all, since it's
essentially part of the OS and foreign language interfaces to know how
to translate Lisp strings and characters into foreign equivalents.
Nevertheless, lack of standard interfaces requires intervention by the
font code.  In LispWorks, we designed the external format facility so
that it can be used in the FLI as well as file streams (as required by
ANSI), and the font code just has to know how to translate from the
host window systems character set specs to Lisp's external format
notation.  (I'm simplifying a bit here, there are issues of defaults
and error handling.)  This has been quite succesful, running foreign
versions of Windows 9x that we've never used here.

That still doesn't solve issues of font selection by character set,
but good defaults go a long way there, because application programmers
usually don't want to select a particular character set, they want to
use the one that works with the end user's data.
-- 
Pekka P. Pirinen
"My definition of a free society is a society where it is safe
to be unpopular."
  - Adlai Stevenson
From: Scott McKay
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <ZauJ7.1463$eh7.724095@typhoon.ne.mediaone.net>
"Arthur Lemmens" <········@xs4all.nl> wrote in message
······················@xs4all.nl...
>
>
> Scott McKay wrote:
>
> >  - The broken low-level layers of CLIM
>
> Could you explain what's broken in CLIM's low-level layers? Is there
> something fundamentally wrong with the design or are there just some
> small mistakes?

Many small mistakes, mainly.  Also, the design for supporting
native gadgets is weak.  DUIM uses a design that allows you to
specify gadget behavior in a more "semantic" way.

> I've been working on implementing the first 16 chapters of CLIM 2.
> I haven't noticed any fundamental problems so far. I find CLIM weak
> on font and internationalization issues, but as far as I can see it
> would be possible to extend the chapters on text styles and extended
> stream output without introducing incompatibilities with the current
> spec.

CLIM is weak on i18n because CL was weak at the time.  Fonts are
weaker than they could have been because toolkit support for fonts
was so weak, that overspecifying fonts was an exercise in futility.  We
overspecified the graphics layers (e.g., the full design model), and no
ordinary graphics toolkit less powerful than OpenGL could possibly
support it.

I agree that the fonts and streams issues can be addressed compatibly.
From: Kenny Tilton
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF6B408.F5751546@nyc.rr.com>
Scott McKay wrote:
>   We
> overspecified the graphics layers (e.g., the full design model), and no
> ordinary graphics toolkit less powerful than OpenGL could possibly
> support it.

Funny you should mention that. I want very much to start messing around
with 3D programming with my dataflow hack. It is great for modelling, I
guess because dataflow implements cause and effect.

I see the CMUCL OpenGL bindings come with an NEC license for
non-commercial use, but how hard can it be to cobble up a little C
parser to convert the OpenGL includes? Looks like I would need
permission from SGI based on my untrained parsing of /their/ copyright,
but I guess they would like as wide an audience as possible. Or I could
just distribute the parser? Anyway...

...then what? Could I get a commercial CLIM to use OpenGL? Would I have
to jump into McCLIM to get at the source? I see glimmers of a McCLIM-OGL
marriage, not sure how far that got.

hmmm....


kenny
clinisys
From: Scott McKay
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <EBBJ7.1863$eh7.1166672@typhoon.ne.mediaone.net>
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
······················@nyc.rr.com...
>
>
> Scott McKay wrote:
>
> ...then what? Could I get a commercial CLIM to use OpenGL? Would I have
> to jump into McCLIM to get at the source? I see glimmers of a McCLIM-OGL
> marriage, not sure how far that got.
>
> hmmm....

You should be able to simply define a pane class of your own,
and then define OpenGL "wrapper functions" that draw on the
CLIM pane.

One of the Harlequin hackers did this for DUIM in about a day,
so I can't imagine that it would be much harder, if at all, in CLIM.
From: Daniel Barlow
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <87d72h5546.fsf@noetbook.telent.net>
Kenny Tilton <·······@nyc.rr.com> writes:

> I see the CMUCL OpenGL bindings come with an NEC license for
> non-commercial use, but how hard can it be to cobble up a little C
> parser to convert the OpenGL includes? Looks like I would need

There may already be one.  Tim Moore's cparse application has iirc
been used on OpenGL header files.  

   http://www.bricoworks.com/~moore/cparse/index.html


-dan

-- 

  http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources 
From: Kenny Tilton
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BF7610B.2690B577@nyc.rr.com>
Thanks for the lead, sounded like a wheel already invented. I noticed
Corman CL webs ite says it reads C headers, but I was not sure if it
exported CL source to match or directly compiled .Hs into object code
foreign call definitions.

kenny 
clinisys

Daniel Barlow wrote:
> 
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> > I see the CMUCL OpenGL bindings come with an NEC license for
> > non-commercial use, but how hard can it be to cobble up a little C
> > parser to convert the OpenGL includes? Looks like I would need
> 
> There may already be one.  Tim Moore's cparse application has iirc
> been used on OpenGL header files.
> 
>    http://www.bricoworks.com/~moore/cparse/index.html
> 
> -dan
> 
> --
> 
>   http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
From: Francis Leboutte
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <bvvhvtglj6pltgrvqnjjmhql2t3dg410ur@4ax.com>
"Scott McKay" <···@mediaone.net> wrote:

>In my opinion, the smartest thing would be for someone to port
>DUIM from Dylan to Common Lisp, and then port CLIM's
>presentation-based UI system on top of that.  The back-end I
>propose is Gtk, which runs on "everything".
>
>This would solve:
> - The broken low-level layers of CLIM
> - The missing high-level layers of DUIM
> - The portability issue
>
>It would be slightly incompatible with CLIM 2.
>

Don't you think CLIM should make it simple to reuse any widget and
multimedia stuff available from the host window system (at the cost of
some loss in application portability). Is this possible in DUIM? 
BTW what are the missing high-level layers of DUIM?

>If a group of people paid me to do this, I estimate that I could do all
>of the work is 6 to 8 months, and the result would be a kick-ass
>portable, open-source UI toolkit for the Lisp community.
>
>

--
www.algo.be
Logo programming : www.algo.be/logo.html
From: Scott McKay
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <qd8K7.4361$eh7.2830612@typhoon.ne.mediaone.net>
"Francis Leboutte" <··········@algo.be> wrote in message
·······································@4ax.com...
> "Scott McKay" <···@mediaone.net> wrote:
>
> >In my opinion, the smartest thing would be for someone to port
> >DUIM from Dylan to Common Lisp, and then port CLIM's
> >presentation-based UI system on top of that.  The back-end I
> >propose is Gtk, which runs on "everything".
> >
> >This would solve:
> > - The broken low-level layers of CLIM
> > - The missing high-level layers of DUIM
> > - The portability issue
> >
> >It would be slightly incompatible with CLIM 2.
> >
>
> Don't you think CLIM should make it simple to reuse any widget and
> multimedia stuff available from the host window system (at the cost of
> some loss in application portability).

Yes, but my point is that making CLIM do this is tantamount to
surgically removing the lower layers of CLIM, and replacing them
with Lisp implementations of what is in DUIM.

> Is this possible in DUIM?

Yes.

> BTW what are the missing high-level layers of DUIM?

Here's what is missing in the currently released DUIM:
 - Output recording, but this is in the new FunDev Alpha release.
 - Presentations, but I'm working on that in my copious spare time.
 - Stream-based I/O, which I haven't decided about.  As it happens,
   stream-based I/O is much easier in DUIM than in CLIM, because
   Common Lisp does not have a universal class-based implementation
   of Streams.  Dylan does.
 - An interactive input editor.  It would be nice to see how far you can
   get without this.  I think the answer might be, quite far indeed.
 - Incremental redisplay.  This (and the input editor) are far and away
   the buggiest parts of CLIM.  I've had an epiphany lately about how
   to do incremental redisplay in a way that is semantically equivalent,
   but much easier to implement.

As I said, I think I could do the surgical implant of DUIM, plus better
implementations of the above in about 6 months, but I can't afford not
to be paid for 6 months unless there are product sales at the end of it.
Since I think this "CLIM 2001" should be open-source, I don't see
a paycheck from sales.
From: Wade Humeniuk
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <9te1a2$mfj$1@news3.cadvision.com>
>
> As I said, I think I could do the surgical implant of DUIM, plus better
> implementations of the above in about 6 months, but I can't afford not
> to be paid for 6 months unless there are product sales at the end of it.
> Since I think this "CLIM 2001" should be open-source, I don't see
> a paycheck from sales.
>

I am all for a better toolkit.  Would you mind listing the features
available in DUIM or a pointer to the relevant documentation?  What a about
a two parter?  Port DUIM into CL and then create a layered CLIM.

Wade
From: Scott McKay
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <FyCK7.8429$eh7.4304390@typhoon.ne.mediaone.net>
"Wade Humeniuk" <········@cadvision.com> wrote in message
·················@news3.cadvision.com...
> >
> > As I said, I think I could do the surgical implant of DUIM, plus better
> > implementations of the above in about 6 months, but I can't afford not
> > to be paid for 6 months unless there are product sales at the end of it.
> > Since I think this "CLIM 2001" should be open-source, I don't see
> > a paycheck from sales.
> >
>
> I am all for a better toolkit.  Would you mind listing the features
> available in DUIM or a pointer to the relevant documentation?  What a
about
> a two parter?  Port DUIM into CL and then create a layered CLIM.

Same basic feature set as CLIM, but with more practice implementing it.  :-)
From: Arthur Lemmens
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <3BFA2A7A.608449A3@xs4all.nl>
Francis Leboutte: 
> Don't you think CLIM should make it simple to reuse any widget and
> multimedia stuff available from the host window system (at the cost of
> some loss in application portability).

Scott McKay:
> Yes, but my point is that making CLIM do this is tantamount to
> surgically removing the lower layers of CLIM, and replacing them
> with Lisp implementations of what is in DUIM.

Why? I thought that CLIM's concept of mirrored sheets was designed 
exactly to 'make it simple to reuse any widget and multimedia stuff 
available from the host window system'? Are you saying there's 
something in the CLIM spec that makes this impossible?
From: Scott McKay
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <9IsK7.6791$eh7.3814236@typhoon.ne.mediaone.net>
"Arthur Lemmens" <········@xs4all.nl> wrote in message
······················@xs4all.nl...
>
>
> Francis Leboutte:
> > Don't you think CLIM should make it simple to reuse any widget and
> > multimedia stuff available from the host window system (at the cost of
> > some loss in application portability).
>
> Scott McKay:
> > Yes, but my point is that making CLIM do this is tantamount to
> > surgically removing the lower layers of CLIM, and replacing them
> > with Lisp implementations of what is in DUIM.
>
> Why? I thought that CLIM's concept of mirrored sheets was designed
> exactly to 'make it simple to reuse any widget and multimedia stuff
> available from the host window system'? Are you saying there's
> something in the CLIM spec that makes this impossible?

No, I'm saying that I learned from my mistakes in CLIM, and
got the abstractions more right in DUIM.  DUIM works much
better at these layers because we (myself and Andy Armstrong)
had more practice.  (Honestly, if DUIM weren't much better at
this, it would be pretty embarrassing.)

CLIM has its heart in the right place, but the details are wrong
From: Mike McDonald
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <8AcJ7.174388$Lg.8344881@sjcpnn01.usenetserver.com>
In article <··································@4ax.com>,
	Francis Leboutte <··········@algo.be> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> wrote:
> 
>>That's true. But again look at a CLIM application and look at a CAPI
>>application than judge if portability is the most important. (You told
>>something about sticking to Windows.) CLIM looks like CLIM but CAPI
>>looks like Motif on Unice and native Windows like on Windows. That can
>>make a difference.
> 
> I don't know CAPI, but having used CLIM (some years ago) I agree that CLIM fails
> to give the look and feel of the system on which the application is running,
> which diminish its interest. It's a pity that CLIM hasn't make any progress in
> this area. Maybe the Lisp vendors think it is against their interest to make
> CLIM evolve? Or are there technical reasons to this situation?

  I don't believe there is a technical reason why some of the vendors don't
implement native L&F backends to CLIM. MCL seems to have it. I think ACL does
too from some of their images I've seen. The default CLX backend that was
originally implemented a decade ago does look dated. If that's the L&F you get
with CLIM, then I'd assume your vendor has other priorities. In the McCLIM
project, we haven't worried too much about making it pretty yet, concentrating
on getting it to work instead. But some of our default concrete pane classes
aren't as ugly the original CLIM ones: http://www.mikemac.com/mikemac/abook.jpg
IMNSOHO anyway.

  Mike McDonald
  ·······@mikemac.com
From: Francis Leboutte
Subject: Re: OK, CLIM it is. Now my options are...
Date: 
Message-ID: <jc0ivtkrp3shui6gim56u10lsp5h9nnric@4ax.com>
·······@mikemac.com (Mike McDonald) wrote:

>In article <··································@4ax.com>,
>	Francis Leboutte <··········@algo.be> writes:
 
>> I don't know CAPI, but having used CLIM (some years ago) I agree that CLIM fails
>> to give the look and feel of the system on which the application is running,
>> which diminish its interest. It's a pity that CLIM hasn't make any progress in
>> this area. Maybe the Lisp vendors think it is against their interest to make
>> CLIM evolve? Or are there technical reasons to this situation?
>
>  I don't believe there is a technical reason why some of the vendors don't
>implement native L&F backends to CLIM. MCL seems to have it. I think ACL does
>too from some of their images I've seen. 

More or less. I think a ACL clim application on WIndows has still an
exotic look.

>The default CLX backend that was
>originally implemented a decade ago does look dated. If that's the L&F you get
>with CLIM, then I'd assume your vendor has other priorities. In the McCLIM
>project, we haven't worried too much about making it pretty yet, concentrating
>on getting it to work instead. But some of our default concrete pane classes
>aren't as ugly the original CLIM ones: http://www.mikemac.com/mikemac/abook.jpg
>IMNSOHO anyway.

On which system is it?

>
>  Mike McDonald
>  ·······@mikemac.com

--
www.algo.be
Logo programming : www.algo.be/logo.html