Axiom is a very large (3.6M source lines) program, most of which is
written
in common lisp. There are two large subsystems, the browser and the
graphics
which are written in C and X11. Axiom's algebra portion (lisp) runs on
both
linux and windows. The C/X11 code does not. So we are faced with the
problem
of reproducing the graphics/browser (G/B) functionality on windows.
I'm recoding portions of the G/B code into common lisp. However we are
struggling to make a windowing front-end decision. I'd like to see us
use
McClim.
Is McClim stable on windows? Is it robust enough to construct
"product-level"
code? Is there an existing code pile I can read? Please send mail to
daly at axiom-developer.org or the mailing list axiom-developer at
nongnu.org
Thanks,
Tim Daly
Axiom lead developer.
····@rio.sci.ccny.cuny.edu writes:
> I'm recoding portions of the G/B code into common lisp. However we are
> struggling to make a windowing front-end decision. I'd like to see us
> use
> McClim.
>
> Is McClim stable on windows? Is it robust enough to construct
As far as I know, McCLIM has never been ported or tested on Lisp
implementations under Windows. If you are interesting in using CLIM,
you probably have to rely on a commercial Lisp implementation for
Windows.
> code? Is there an existing code pile I can read? Please send mail to
If you refer to CLIM code, most of it is available from this page:
http://mcclim.cliki.net/Application
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
····@rio.sci.ccny.cuny.edu writes:
> Axiom is a very large (3.6M source lines) program, most of which is
> written
> in common lisp. There are two large subsystems, the browser and the
> graphics
> which are written in C and X11. Axiom's algebra portion (lisp) runs on
> both
> linux and windows. The C/X11 code does not. So we are faced with the
> problem
> of reproducing the graphics/browser (G/B) functionality on windows.
>
> I'm recoding portions of the G/B code into common lisp. However we are
> struggling to make a windowing front-end decision. I'd like to see us
> use
> McClim.
>
> Is McClim stable on windows? Is it robust enough to construct
> "product-level"
> code? Is there an existing code pile I can read? Please send mail to
> daly at axiom-developer.org or the mailing list axiom-developer at
> nongnu.org
I don't know McClim implementation at all, so don't take this as a
statement putting it down specifically. (In fact, don't take this as
putting down CLIM generally.) ..
I would not use CLIM unless I needed CLIM-specific features and could
not substitute others.
CLIM was an extraordinarily visionary design and it's got a very
interesting set of tools. If you need these tools, there's probably
nothing else you can substitute and you should be happy it's there.
However, in all situations where a standard window system API would
suffice, such as LispWorks CAPI or Franz Allegro's Common Graphics,
I would definitely prefer one of those.
CLIM's design was originally done on machines that no loner exist and
had special operations that are not well-supported on standard
hardware, both because the operator LETF is not implemented and
because modern windowing systems often have problems if you manipulate
brushes and other resources from more than one thread. (The original
Lisp Machine design did not have this problem because that was not a
restriction of the architecture, and because of the availability of
hardware-supported LETF as a practical way of sharing resources.)
CLIM's design is also, last I checked (which is admittedly a while ago),
underspecified as to manipulating fonts. If you have drawings that mix
fonts and graphics, there is too much latitude for scaling fonts in the
wrong way and still being conforming, and in my experience this means that
when you attach graphics to fonts and then scale them, you often find
yourself only scaling the graphics, not the fonts, and getting fonts that
are WAY too big or WAY too small.
And, although CLIM did a major redesign to attempt to accomodate a great
deal of look and feel, it really didn't have enough usage testing to
be able to accomodate all the user needs. So you may find yourself fighting
with it to let you make the ultimate tweaks you need to customize details
that users have come to see as important.
I've built some applications in CLIM (not recently, but in the past), and
these have turned out to be stumbling blocks. This is not, as nearly as
I can tell, the fault of any vendor. It's intrinsic to the design of CLIM.
It's probably something that could be fixed if CLIM were an evolving standard,
but to my knowledge it is not.
I think no vendor will come out and say it, but I don't think any vendor is
especially rah rah about supporting CLIM, at least in its original
implementation. Maybe the newer "clean room" implementations have a different
theory. I think vendors mostly support CLIM because it is a sometimes
checklist item and they don't want to be seen as uncooperative. But I think
they all regard it as a pit full of bugs that are not cost-effective to fix,
and that will get fixed on an as-paid-for basis.
I might be wrong on this, and vendors are welcome to step in and speak for
themselves. But I think vendors don't like to say negative things about
their products nor about CLIM itself, so they tend to be relatively quiet
and just hope those people who use CLIM will be happy with their choice,
but at the same time they try to steer most people, I think reasonably, to
their other offerings if they don't need the special stuff CLIM has. At
one time in the distant past, I perceived this as an issue of NIH ("not
invented here") syndrome, with vendors not understanding CLIM and so
pushing what I perceived as less-good products. I have over the years
changed my view to be that one should not use an overly elaborate hammer
for a simple problem. There is a reason commodity products have become
commodities. The standard windows API packages tend to provide very good use
of the standard things a lot of people want, without requiring new concepts.
There are places for stretching your imagination (and CLIM is certainly
fun and mind-expanding), but not every business situation is one where you
want to divert time sretching your mind.
In particular, it would be surprising if anything written in C/X11 was so
advanced as to require CLIM functionality and not just standard toolbox
functionality. But then, I've been surprised before...
I hope this advice is helpful to you in asking the right questions to know
how to proceed.
Kent M Pitman <······@nhplace.com> writes:
> I think no vendor will come out and say it, but I don't think any vendor is
> especially rah rah about supporting CLIM, at least in its original
> implementation. Maybe the newer "clean room" implementations have a different
> theory. I think vendors mostly support CLIM because it is a sometimes
> checklist item and they don't want to be seen as uncooperative. But I think
Some vendors are a bit more explicit. From the description of
LispWorks Professional Edition at:
http://www.lispworks.com/products/lispworks.html
"CLIM 2.0 is included to support legacy applications"
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
On Mon, 02 May 2005 13:56:35 +0200, Paolo Amoroso <·······@mclink.it> wrote:
> Some vendors are a bit more explicit. From the description of
> LispWorks Professional Edition at:
>
> http://www.lispworks.com/products/lispworks.html
>
> "CLIM 2.0 is included to support legacy applications"
You can also check out Dave Fox' (LispWorks' director) stance
w.r.t. CLIM at the end of his Amsterdam talk:
<http://weitz.de/eclm2005/>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")