From: Paolo A. <am...@mc...> - 2003-12-08 11:08:13
|
There has been a recent discussion in the clisp-list mailing list (I hope it's acceptable to Cc: clisp-list) about the possibility of making McCLIM work with CLISP. I told there my experience with early versions of McCLIM, and I have been asked what would be involved in making it work again with CLISP. I was able to run early versions of McCLIM with CLISP and MIT CLX. There were noticeable peformance improvements between the very first and last versions of McCLIM I tested. In the end, performance was "acceptable" for me under Linux with an old Pentium 200 PC with 64 MB of RAM. McCLIM stopped working with CLISP when presentations were added. At the time, the use of metaclasses was mentioned in the context of presentations, and I assumed that actual CLOS MOP metaclasses were used to implement them. But a superficial inspection of the code shows that some sort of custom metaclass mechanism is used instead. Since I am not familiar with the internals of McCLIM, I'd like to ask how much effort would be needed to make it work again with CLISP, and what are the most probable sources of incompatibility. Besides the above mentioned problem related to presentations, the issue of CLIM-style multiproccesing, which CLISP does not provide yet, comes to mind. I have been asked what kind of multiprocessing support is required for running McCLIM: fork, threads, pvm, mpi? Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film |
From: Timothy M. <mo...@br...> - 2003-12-08 21:20:35
|
On Dec 8, 2003, at 11:43 AM, Paolo Amoroso wrote: > There has been a recent discussion in the clisp-list mailing list (I > hope it's acceptable to Cc: clisp-list) about the possibility of > making McCLIM work with CLISP. I told there my experience with early > versions of McCLIM, and I have been asked what would be involved in > making it work again with CLISP. > ... > McCLIM stopped working with CLISP when presentations were added. At > the time, the use of metaclasses was mentioned in the context of > presentations, and I assumed that actual CLOS MOP metaclasses were > used to implement them. But a superficial inspection of the code shows > that some sort of custom metaclass mechanism is used instead. No, we use as much of the MOP as we can. The catch is that McCLIM has to do a lot of work at compile time before the metaclasses are available, so the mixin that is a superclass of the presentation type metaclass is also used standalone at compile time. Another thing that confuses the issue is that the describe function and the Listener app use the MOP too, and there is support for them in the Lisp-dep files, but those are demos and not necessary to get the core bits of McCLIM running. Of course, they are nice to have. You can grep for clim-mop in the sources and see all the uses of the MOP. The highlights for the presentation type system are: Ability to define subclasses (metaclasses) of standard-class and standard-generic-function and instantiate classes of those metaclasses class-prototype class-precedence-list class-direct-superclasses ensure-class method-specializers eql-specializer eql-specializer-object specialization of compute-applicable-methods-using-classes, compute-applicable-methods generic-function-methods extract-specializer-names extract-lambda-list > > Since I am not familiar with the internals of McCLIM, I'd like to ask > how much effort would be needed to make it work again with CLISP, and > what are the most probable sources of incompatibility. See above :) We of course make heavy use of Gray streams; I don't know what the status of that is in CLISP. Also, at one time nested backquote didn't work in CLISP, though I suppose that is ancient history. > > Besides the above mentioned problem related to presentations, the > issue of CLIM-style multiproccesing, which CLISP does not provide yet, > comes to mind. I have been asked what kind of multiprocessing support > is required for running McCLIM: fork, threads, pvm, mpi? > Lispm style processes, which are really threads. McCLIM also works in a non-threaded mode which only allows one application to run at a time. Hope this helps, Tim |
From: Sam S. <sd...@gn...> - 2003-12-08 21:34:30
|
> * Timothy Moore <zbber@oevpbjbexf.pbz> [2003-12-08 22:19:11 +0100]: > >> Since I am not familiar with the internals of McCLIM, I'd like to ask >> how much effort would be needed to make it work again with CLISP, and >> what are the most probable sources of incompatibility. > See above :) We of course make heavy use of Gray streams; I don't know > what the status of that is in CLISP. available in the GRAY package (re-exported from EXT and thus available in CL-USER) > Also, at one time nested backquote didn't work in CLISP, though I > suppose that is ancient history. works fine. > we use as much of the MOP as we can. why? it's not in the CLtS. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Abandon all hope, all ye who press Enter. |
From: Timothy M. <mo...@br...> - 2003-12-08 21:45:08
|
On Dec 8, 2003, at 10:34 PM, Sam Steingold wrote: >> * Timothy Moore <zbber@oevpbjbexf.pbz> [2003-12-08 22:19:11 +0100]: ... >> we use as much of the MOP as we can. > > why? it's not in the CLtS. Neither are Gray streams and processes, but that doesn't stop us :) A less glib answer: presentation types are a system of classes, objects and methods. It's a bit different from CLOS but they do share a lot of characteristics. The MOP is ideal for implementing this kind of system and was a big timesaver in attacking a problem that had held up free CLIM efforts for years. Tim |