From Chase at common-lisp.net Mon Jul 3 22:24:56 2006 From: Chase at common-lisp.net (Chase at common-lisp.net) Date: Mon, 03 Jul 2006 16:24:56 -0600 Subject: [closer-devel] Chase Online. Banking Account registration information Message-ID: An HTML attachment was scrubbed... URL: From pc at p-cos.net Fri Jul 14 19:54:57 2006 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 14 Jul 2006 21:54:57 +0200 Subject: [closer-devel] darcsweb support Message-ID: Hi, The darcs repositories in the Closer project are now visible at http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi Cheers, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Thu Jul 20 09:02:41 2006 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 20 Jul 2006 11:02:41 +0200 Subject: [closer-devel] :reinitialize-instance-calls-finalize-inheritance Message-ID: <5A6FF1BC-2EF5-41B2-979A-387AFAE895D3@p-cos.net> Hi everyone, Christophe Rhodes has spotted a mistake in one of the test cases for MOP Feature Tests. In the test for :reinitialize-instance-calls- finalize-inheritance, finalize-inheritance was called explicitly, which means that it always succeeded unconditionally. I have changed this so that now, the call to finalize-inheritance is guarded by a check for class-finalized-p. Additionally, the call to reinitialize-instance is more 'sophisticated' to avoid interference of potentially acceptable optimizations. Unfortunately, the new test reveals that CMUCL, MCL, OpenMCL and SBCL don't implement this feature correctly. You can find the new test case in the darcs repository, as well as the reports on this feature. Many thanks to Christophe Rhodes for spotting the error in the test case and helping to find a better formulation. Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Fri Jul 21 20:35:54 2006 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 21 Jul 2006 22:35:54 +0200 Subject: [closer-devel] starting work on a port to Corman Lisp In-Reply-To: <6EF76183-D738-4E13-85FA-57C4FCBDDF37@metabang.com> References: <670779CC-6B79-4ABC-8026-84B1E9F3B9ED@p-cos.net> <54EB1371-9420-472D-B524-FE25226B9F80@p-cos.net> <6EF76183-D738-4E13-85FA-57C4FCBDDF37@metabang.com> Message-ID: <2265CDF5-CDFF-45DD-89B1-BC0ACC62845B@p-cos.net> Hi everybody, In the recent days, I have taken a look at how these things could be broken up into digestible chunks. However, I am afraid that it doesn't make a lot of sense. The incompatibilities across CL implementations are rather random, and the whole picture looks more like Swiss Cheese [1] to me than anything you could reasonably explain. So this looks like a lot of work without any real benefit. (A nice benefit would have been if you could have stated requirements what features you need for a particular metaprogram, and this would have yielded the Common Lisp implementations that you could use. Unfortunately, things aren't by far that simple...) The obvious separation of introspection and intercession is, well, obvious. So making it more formal doesn't buy us a lot either, I think. Since I think I can spend my time on issues that will turn out more useful for CLOS MOP users, I will drop this idea. Is there still interest to include support for Corman Lisp? I think we could get some (very limited) support into Closer to MOP, similar to the one we currently have for ECL. I would have to change the handling of packages in MOP Feature Tests, and then we could see how to proceed from there. Please let me know if you're interested... Cheers, Pascal [1] lots of holes On 29 Jun 2006, at 19:54, Gary King wrote: > I think that having two or more reasonable conformance "levels" > would make sense. I also think that breaking MOP support into > introspection and semantics (implementation altering) makes sense. > I don't know much of anything about the consistency of MOP > implementations but it work to have something like (warning, ASCII > art ahead): > > MOP Support > | > +-------------------- introspection > | | > | +-------------------- level 1 > | +-------------------- level 2 > | > +-------------------- implementation > | > +-------------------- level 1 > +-------------------- level 2 > > Where the levels lie will depend on how the MOP implementations > carve "nature at its joints". That Plato, he had such a way with > words. > >> Because of my own work with the CLOS MOP, I typically think of the >> more advanced features of the CLOS MOP. But I start to get the >> impression that people find Closer to MOP useful for the very >> basic features - and that makes a lot of sense, of course. Maybe I >> should restructure the library to make it easier to distinguish >> the base features for which we can have at least some guarantee >> that all covered CLOS implementations support them, and the other >> more advanced ones. >> >> For example, the pure introspective features are covered very well >> almost everywhere. It's only the semantics-changing features >> especially in the generic function invocation protocol that are >> problematic across CLOS implementations - but that's also the part >> where there actually seems to be very little demand. > > > -- > Gary Warren King > metabang.com > http://www.metabang.com/ > (413) 210 7511 > gwking on #lisp (occasionally) > > > _______________________________________________ > closer-devel mailing list > closer-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From jdunrue at gmail.com Fri Jul 21 22:01:20 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Fri, 21 Jul 2006 16:01:20 -0600 Subject: [closer-devel] starting work on a port to Corman Lisp In-Reply-To: <2265CDF5-CDFF-45DD-89B1-BC0ACC62845B@p-cos.net> References: <670779CC-6B79-4ABC-8026-84B1E9F3B9ED@p-cos.net> <54EB1371-9420-472D-B524-FE25226B9F80@p-cos.net> <6EF76183-D738-4E13-85FA-57C4FCBDDF37@metabang.com> <2265CDF5-CDFF-45DD-89B1-BC0ACC62845B@p-cos.net> Message-ID: On 7/21/06, Pascal Costanza wrote: > Hi everybody, Hi Pascal! > In the recent days, I have taken a look at how these things could be > broken up into digestible chunks. However, I am afraid that it > doesn't make a lot of sense. The incompatibilities across CL > implementations are rather random, and the whole picture looks more > like Swiss Cheese [1] to me than anything you could reasonably > explain. So this looks like a lot of work without any real benefit. Understood. > (A nice benefit would have been if you could have stated requirements > what features you need for a particular metaprogram, and this would > have yielded the Common Lisp implementations that you could use. > Unfortunately, things aren't by far that simple...) > > The obvious separation of introspection and intercession is, well, > obvious. So making it more formal doesn't buy us a lot either, I think. > > Since I think I can spend my time on issues that will turn out more > useful for CLOS MOP users, I will drop this idea. Your research into the idea is much appreciated and I think time well spent! > Is there still interest to include support for Corman Lisp? I think > we could get some (very limited) support into Closer to MOP, similar > to the one we currently have for ECL. I would have to change the > handling of packages in MOP Feature Tests, and then we could see how > to proceed from there. Please let me know if you're interested... I'm still interested. I strongly suspect that Corman's CLOS implementation will not deviate radically in 2.6 from how it's implemented in 2.51, but Roger did reply to my query about DELETE-PACKAGE saying that they would try to get that done. Incidentally, my MOP usage has increased slightly compared to when this discussion started, such that I now make use of CLASS-PROTOTYPE in Graphic-Forms. I'm reasonably sure that my MOP needs have stabilized now. -- Jack Unrue From pc at p-cos.net Sat Jul 29 14:03:16 2006 From: pc at p-cos.net (Pascal Costanza) Date: Sat, 29 Jul 2006 16:03:16 +0200 Subject: [closer-devel] SBCL 0.9.15 Message-ID: Hi everyone, SBCL 0.9.15 has been released and has improved considerably wrt CLOS MOP support. This means that I had to change some internals of Closer to MOP, so I have dropped support for older SBCL versions. Please find the new version in the repository. In case anyone ever needs this, I have added a tag (0.32) to Closer to MOP which can be used for SBCL <= 0.9.14. This is also noted in the change log. I will also prepare a new "official" release of the Closer software within the next one or two weeks. Cheers, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium