Joachim De Beule <·······@arti.vub.ac.be> writes:
> Does anybody has any suggestions about a graphical package/library to
> use with ACL on a linux pc ?
CLX?
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
Janis Dzerins <·····@latnet.lv> writes:
> Joachim De Beule <·······@arti.vub.ac.be> writes:
>
> > Does anybody has any suggestions about a graphical package/library to
> > use with ACL on a linux pc ?
>
> CLX?
Free-CLIM / McClim, perhaps?
http://www.mikemac.com/mikemac/McCLIM/index.html
--
Raymond Wiker
·············@fast.no
Raymond Wiker <·············@fast.no> writes:
> Janis Dzerins <·····@latnet.lv> writes:
>
> > Joachim De Beule <·······@arti.vub.ac.be> writes:
> >
> > > Does anybody has any suggestions about a graphical package/library to
> > > use with ACL on a linux pc ?
> >
> > CLX?
>
> Free-CLIM / McClim, perhaps?
>
> http://www.mikemac.com/mikemac/McCLIM/index.html
Let me take this opportunity to give you a project status report.
We are making steady and relatively quick progress. We have recently
made considerable progress on replay and scrolling in stream panes,
bordered panes, command tables, menu bars, and more.
What (mostly) works:
- regions and transformations
- bounding rectangles
- sheets and sheet protocols
- ports, grafts, and mirrored sheets
- mediums
- graphics operations
- text styles
- extended stream output
- output recording
- menu bars
- command processing (partially)
- application frames (mostly)
- panes (layout panes, border panes, scroller panes, and many more)
- gadgets (button, menu buttons, labels, text fields, and many more)
What does not (yet) work:
- general designs
- table formatting
- graph formatting
- bordered output
- text formatting
- incremental redisplay
- extended stream inputs
- presentation types
- input editing and completion
- menu facility
- dialog facility
If you feel like helping us, there are many minor things you can do
such as:
- test the code, fixing minor bugs, reporting major ones
- add type declarations
- add :documentation strings
- write demos
- add tests for syntax in macros and better error reporting
Some intermediate things:
- write new gadgets and panes
- write code for command processing, table formatting,
graph formatting, text formatting and more
And some big chunks:
- presentation types
- text editor gadget
- extended stream input
- porting to windowing systems other than CLX
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Robert STRANDH <·······@labri.u-bordeaux.fr> writes:
> Let me take this opportunity to give you a project status report.
>
> [snip]
>
> If you feel like helping us, there are many minor things you can do
> such as:
>
> - add type declarations
Is this actually necessary? I can't find the archives of your lists,
so I can't see the internal reasoning, but surely this should be the
last thing to happen, if it turns out to be needed in the end?
I mention this because I've been bitten by inappropriate type
declarations in code before; the solution chosen when I reported a bug
(an incorrect type declaration) was simply to remove the declaration,
which is fine as far as it goes, but not terribly ideal.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
(FORMAT T "(·@{~w ········@{~w~^ ~})" 'FORMAT T "(·@{~w ········@{~w~^ ~})")
Dr Nick Levine wrote in message <················@anglia.ac.uk>...
>
>> > - add type declarations
>>
>> Is this actually necessary?
>
>If could be because CLIM has been known to run stunningly slow...?
>
For the record, all of the LispWorks, Lucid, and Franz system
source code I have seen is riddled with type, speed, and
safety declarations in crucial areas, and some of these systems
provide special declarations for fixnums and flonums to gain
that last little bit of performance. Genera source code is
uniquely absent of such declarations because of the unique
hardware it ran on, but that's no longer a useful datapoint.
So CLIM is hardly alone in using such declarations.
Also note that Swing is, by it's choice of language, also riddled
with type declarations, and its performance makes CLIM look
great by comparison.
Dr Nick Levine <········@anglia.ac.uk> writes:
> > > - add type declarations
> >
> > Is this actually necessary?
>
> If could be because CLIM has been known to run stunningly slow...?
CLIM implementations (or at least Franz's implementation: I don't have
access to the LW system) are actually adequately fast on modern
hardware. I think this is like a lot of lisp things -- partly
machines have go fast enough that complex lisp systems now run
adequately, and partly the C-based systems have got large enough that
they've started to turn into the canonical slow, buggy lisp systems
and got *really* slow. Java GUIs seem often to be just stunningly
slow for instance.
CLIM could obviously be a lot faster (I think that its design is
pretty painful in places) and there are lots of things you still
wouldn't want to do in CLIM, but I doubt whether type declarations
would help much as it's not really that sort of slowness. But for a
lot of things where it wins -- like doing type-aware interfaces for
systems in a day -- it's more than adequate on any machine that will
run a recent Windows or Unix (probably linux can still run on smaller
machines than CLIM).
--tim
Joachim De Beule wrote:
> ok I had a look at the free McCLIM and tried to absorb the CLIM spec
> and ... whell, I admit, I can't say it is very clear to me now how to
> do some simple graphics ...
>
> Is there a tutorial or something for CLIM that is a litle more
> transparant then the clim spec ?
>
> thanks, Joachim.
The lack of a tutorial is one of the biggest problems, IMHO, with CLIM.
The best I have found so far (which is admittedly somewhat difficult to
find) is the CLIM 1 manual for symbolics. Barring that, Harlequin (now
Xanalys) had a clim manual that got me proficient enough to write some
code, but it did not get across CLIM's paradigm. Once you have some
grasp of CLIM, the best thing to do is to start trying to understand
some existing CLIM applications, such as CLIP/CLASP at cs.umass.edu.
Sunil
Joachim De Beule wrote:
> ok I had a look at the free McCLIM and tried to absorb the CLIM spec
> and ... whell, I admit, I can't say it is very clear to me now how to
> do some simple graphics ...
>
> Is there a tutorial or something for CLIM that is a litle more
> transparant then the clim spec ?
>
> thanks, Joachim.
I work on the Free-CLIM project and you can use as "small tutorial" the
example we made (as calculator, slider and some others) that should give
you some indications. At least i can try to help if you have a specific
request.
Iban HATCHONDO.
I
> I work on the Free-CLIM project and you can use as "small tutorial" the
> example we made (as calculator, slider and some others) that should give
> you some indications. At least i can try to help if you have a specific
> request.
>
> Iban HATCHONDO.
Is there any place to download the tatest version of free-clim. I looked
at the place pointed to by http://www.cons.org/free-clim/ but I only
found some very old files there.
Thanks a lot in advance
Marc Mertens
>>>>> "MM" == Marc Mertens <········@vt4.net> writes:
MM> Is there any place to download the tatest version of free-clim. I looked
MM> at the place pointed to by http://www.cons.org/free-clim/ but I only
MM> found some very old files there.
Take a look at <URL:http://www.mikemac.com/mikemac/McCLIM/>.
TTFN,
'mr
--
Martin Rydstr|m, ·····@cd.chalmers.se ; rationalize till I'm blue in the face,
; you cannot lose if you throw the race.
Looking for a LispM to play with. Any and all offers/ideas appreciated.
Also - " - job - " - - " -
In article <·························@news.be.uu.net>,
"Marc Mertens" <········@vt4.net> writes:
> Is there any place to download the tatest version of free-clim. I looked
> at the place pointed to by http://www.cons.org/free-clim/ but I only
> found some very old files there.
>
> Thanks a lot in advance
>
> Marc Mertens
McCLIM can be found at http://www.mikemac.com/mikemac/McCLIM/index.html
Mike McDonald
·······@mikemac.com
Christophe Rhodes <·····@cam.ac.uk> writes:
> Robert STRANDH <·······@labri.u-bordeaux.fr> writes:
>
> > Let me take this opportunity to give you a project status report.
> >
> > [snip]
> >
> > If you feel like helping us, there are many minor things you can do
> > such as:
> >
> > - add type declarations
>
> Is this actually necessary? I can't find the archives of your lists,
> so I can't see the internal reasoning, but surely this should be the
> last thing to happen, if it turns out to be needed in the end?
>
> I mention this because I've been bitten by inappropriate type
> declarations in code before; the solution chosen when I reported a bug
> (an incorrect type declaration) was simply to remove the declaration,
> which is fine as far as it goes, but not terribly ideal.
My thinking was as follows:
- Type declarations provide documentation for the code maintainter.
- At least in CMUCL (if I understand correctly), they are checked
when the compiler options are set properly, allowing a higher
level of safety of the code.
- (minor issue) They improve code speed.
But if people think they are a source of errors, then obviously I
won't insist. Perhaps we should add explicit type checks instead?
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Robert STRANDH <·······@labri.u-bordeaux.fr> writes:
> - Type declarations provide documentation for the code maintainter.
> - At least in CMUCL (if I understand correctly), they are checked
> when the compiler options are set properly, allowing a higher
> level of safety of the code.
> - (minor issue) They improve code speed.
>
The dangerous case I think is that some (most?) compilers can treat a
type declaration as an indication that it's safe to blindly *omit*
type checks rather than to check the declaration is true before
compiling possibly-better code on that assumption as CMUCL tends to
do. However I think that this is only done at unsafe compilation
settings (lots of speed, low safety), so so long as you compile with
good settings then they're completely safe, and as you say are good
documentation for the code. I use type declarations as documentation
quite a lot.
Actually I think that even cmucl will completely omit checks if you
turn safety all the way downn, won't it?
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Actually I think that even cmucl will completely omit checks if you
> turn safety all the way downn, won't it?
With regard to type-checking the Python compiler distinguishes between
the following modes:
- (>= safety (max speed compilation-speed space))
Precise type-checking of all type declarations, e.g.
(declare (type (integer 3 17) index))
results in type-checking code equivalent to
(and (fixnump index) (<= 3 index 17))
- (< 0 safety (max speed compilation-speed space))
Weakened type-checking is performed, i.e. expensive type-checks are
converted to cheaper type-checks, e.g.
(declare (type (integer 3 17) index))
results in a (fixnump index) test.
- (= safety 0)
All type-checks are omitted, as are argument count, symbol unbound
and array bounds checking.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Joachim De Beule a �crit :
>
> Hi all,
>
> Does anybody has any suggestions about a graphical package/library to
> use with ACL on a linux pc ?
>
> Thanks, Joachim.
The CLIM specification is being implemented by the FreeCLIM project.
Check on lisp.org
--
----------------------------
Bailleul Jonathan
DEA Informatique
LaBRI, Universite Bordeaux I