From pc at p-cos.net Mon Nov 2 18:41:46 2009 From: pc at p-cos.net (Pascal Costanza) Date: Mon, 2 Nov 2009 19:41:46 +0100 Subject: [closer-devel] Closer to MOP improvements Message-ID: <994665F3-098C-4D3D-8C70-0CB9975067BB@p-cos.net> Hi, I just checked in some changes to the darcs repository for Closer to MOP. This is a major update, with the most significant change being better support for the generic function invocation protocols across several Common Lisp implementations, i.e., clisp, Clozure Common Lisp, LispWorks and SBCL. In all these versions, the major parts of these protocols work as specified in AMOP, including MAKE-METHOD-LAMBDA, COMPUTE-APPLICABLE-METHODS, COMPUTE-APPLICABLE-METHODS-USING-CLASSES, COMPUTE-EFFECTIVE-METHOD, and, as an add-on, COMPUTE-EFFECTIVE-METHOD- FUNCTION. There are also some other minor changes. One that could affect existing programs is that Closer to MOP is now less 'aggressive' in forcing its own versions of the standard metaclasses on user code. So, for example, DEFCLASS now uses CL:STANDARD-CLASS all the time, unless an explicit :METACLASS options specifies C2MOP:STANDARD-CLASS or one of its subclasses. This is to ensure that straightforward uses of such macros don't incur a serious performance penalty. I will document these changes later, when I turn them into a major new release of Closer to MOP. The next step is to publish the code for filtered functions, which need the proper generic function invocation protocols to work correctly. See further announcements in the coming days or weeks. Best, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From sky at viridian-project.de Wed Nov 4 10:33:03 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Wed, 4 Nov 2009 11:33:03 +0100 (CET) Subject: [closer-devel] New warning "No generic function F present when encountering macroexpansion of defmethod." Message-ID: This newly introduced warning seems to be emitted every time when there's a defmethod that is not preceded by a defgeneric. But this is perfectly valid code and c2mop must[1] assume that the implicit gf is of class standard-generic-function without emitting a warning (which causes ASDF to stop everytime it is encountered). How about a compiler note instead? Leslie [1] http://www.lispworks.com/documentation/HyperSpec/Body/m_defmet.htm "If (fboundp function-name) is nil, a generic function is created with default values for the argument precedence order (each argument is more specific than the arguments to its right in the argument list), for the generic function class (the class standard-generic-function), for the method class (the class standard-method), and for the method combination type (the standard method combination type)." -- http://www.linkedin.com/in/polzer From pc at p-cos.net Wed Nov 4 11:40:43 2009 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 4 Nov 2009 12:40:43 +0100 Subject: [closer-devel] New warning "No generic function F present when encountering macroexpansion of defmethod." In-Reply-To: References: Message-ID: <47141336-AD0C-4CCF-91C3-F56D6BA6227E@p-cos.net> On 4 Nov 2009, at 11:33, Leslie P. Polzer wrote: > This newly introduced warning seems to be emitted every time > when there's a defmethod that is not preceded by a defgeneric. > > But this is perfectly valid code and c2mop must[1] assume > that the implicit gf is of class standard-generic-function > without emitting a warning (which causes ASDF to stop everytime > it is encountered). > > How about a compiler note instead? Is there a portable way to emit compiler notes? I don't immediately find anything in the HyperSpec. Another option is to emit the warning only when some global flag (*warn-on-defmethod-without-defgeneric*, or so) is true. Would that be acceptable? It should then be fine to use nil as the default. The warning is important, IMHO, when you define your own generic function metaclasses... Pascal > > Leslie > > > [1] http://www.lispworks.com/documentation/HyperSpec/Body/m_defmet.htm > > "If (fboundp function-name) is nil, a generic function is created > with default values for the argument precedence order (each argument > is more specific than the arguments to its right in the argument > list), for the generic function class (the class standard-generic- > function), > for the method class (the class standard-method), and for the method > combination type (the standard method combination type)." > > -- > http://www.linkedin.com/in/polzer > > > _______________________________________________ > 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 Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From sky at viridian-project.de Wed Nov 4 11:59:00 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Wed, 4 Nov 2009 12:59:00 +0100 (CET) Subject: [closer-devel] New warning "No generic function F present when encountering macroexpansion of defmethod." In-Reply-To: <47141336-AD0C-4CCF-91C3-F56D6BA6227E@p-cos.net> References: <47141336-AD0C-4CCF-91C3-F56D6BA6227E@p-cos.net> Message-ID: <9ea3dab67dd924093968ee7d5d811088.squirrel@mail.stardawn.org> Pascal Costanza wrote: > Is there a portable way to emit compiler notes? I don't immediately > find anything in the HyperSpec. There doesn't seem to be, unfortunately. > Another option is to emit the warning only when some global flag > (*warn-on-defmethod-without-defgeneric*, or so) is true. Would that be > acceptable? It should then be fine to use nil as the default. > > The warning is important, IMHO, when you define your own generic > function metaclasses... I concur. Your global switch proposal would also be perfectly acceptable at least to me. Leslie -- http://www.linkedin.com/in/polzer From tcr at freebits.de Wed Nov 4 12:57:00 2009 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Wed, 04 Nov 2009 13:57:00 +0100 Subject: [closer-devel] New warning "No generic function F present when encountering macroexpansion of defmethod." References: <47141336-AD0C-4CCF-91C3-F56D6BA6227E@p-cos.net> Message-ID: <878weme9cz.fsf@freebits.de> Pascal Costanza writes: > On 4 Nov 2009, at 11:33, Leslie P. Polzer wrote: > > > This newly introduced warning seems to be emitted every time > > when there's a defmethod that is not preceded by a defgeneric. > > > > But this is perfectly valid code and c2mop must[1] assume > > that the implicit gf is of class standard-generic-function > > without emitting a warning (which causes ASDF to stop everytime > > it is encountered). > > > > How about a compiler note instead? > > Is there a portable way to emit compiler notes? I don't immediately > find anything in the HyperSpec. Signal a STYLE-WARNING, it's what it's for. -T. From attila.lendvai at gmail.com Wed Nov 4 13:07:11 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Wed, 4 Nov 2009 14:07:11 +0100 Subject: [closer-devel] New warning "No generic function F present when encountering macroexpansion of defmethod." In-Reply-To: <878weme9cz.fsf@freebits.de> References: <47141336-AD0C-4CCF-91C3-F56D6BA6227E@p-cos.net> <878weme9cz.fsf@freebits.de> Message-ID: >> > How about a compiler note instead? >> >> Is there a portable way to emit compiler notes? I don't immediately >> find anything in the HyperSpec. > > Signal a STYLE-WARNING, it's what it's for. yes, and sane compilers already signal a style warning for this, while the conflict with cl:defmethod is kinda cumbersome. needs to be dealt with at every usage of closer mop... is it worth it? maybe as part of a closer-mop-strict package? -- attila From pc at p-cos.net Wed Nov 4 13:51:09 2009 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 4 Nov 2009 14:51:09 +0100 Subject: [closer-devel] New warning "No generic function F present when encountering macroexpansion of defmethod." In-Reply-To: References: <47141336-AD0C-4CCF-91C3-F56D6BA6227E@p-cos.net> <878weme9cz.fsf@freebits.de> Message-ID: <3B48411D-7718-4B29-993F-DFDAEE8348A8@p-cos.net> On 4 Nov 2009, at 14:07, Attila Lendvai wrote: >>>> How about a compiler note instead? >>> >>> Is there a portable way to emit compiler notes? I don't immediately >>> find anything in the HyperSpec. >> >> Signal a STYLE-WARNING, it's what it's for. > > > yes, and sane compilers already signal a style warning for this, while > the conflict with cl:defmethod is kinda cumbersome. needs to be dealt > with at every usage of closer mop... is it worth it? OK, a style warning seems reasonable. I will check which compilers already issue such a style warning, and only include the warning for implementations that don't do this. If there is a common way of disabling such style warnings, I will try to integrate that as well, hopefully in a uniform way. > maybe as part of a closer-mop-strict package? I'm not sure if I would want that. I think the right way is to use a global variable, a symbol macro, or an entry in *features*. I will check what is best. Thanks a lot for the feedback! Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Wed Nov 4 15:22:50 2009 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 4 Nov 2009 16:22:50 +0100 Subject: [closer-devel] New warning "No generic function F present when encountering macroexpansion of defmethod." In-Reply-To: <3B48411D-7718-4B29-993F-DFDAEE8348A8@p-cos.net> References: <47141336-AD0C-4CCF-91C3-F56D6BA6227E@p-cos.net> <878weme9cz.fsf@freebits.de> <3B48411D-7718-4B29-993F-DFDAEE8348A8@p-cos.net> Message-ID: Hi, OK, I solved this as follows: + I turned the warning into a style-warning. + I provide a symbol macro warn-on-defmethod-without-generic-function that can be used to disable/enable that warning. By default it is set to t, except for SBCL where it is set to nil because SBCL already warns about this. If you want to disable the warning locally, just wrap your code in this: (symbol-macrolet ((warn-on-defmethod-without-generic-function nil)) ...) If you want to enable the warning locally (for whatever strange reason you might think of ;), use t instead of nil. You can also globally disable the warning after you loaded Closer to MOP like this: (define-symbol-macro warn-on-defmethod-without-generic-function nil) I think this should make most people happy. The changes are in the repository. Best, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Thu Nov 5 19:35:53 2009 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 5 Nov 2009 20:35:53 +0100 Subject: [closer-devel] More changes in Closer to MOP Message-ID: <01D3A186-1587-4A68-88CC-D379A4E6C0B4@p-cos.net> Hi, I have added more changes to the repository: I had to fix a number of bugs specifically for Clozure Common Lisp (which is now pretty much completely MOP-compliant when using Closer to MOP ;), and also one corner case for the other implementations. I have now added support for special functions in AspectL for Clozure Common Lisp. I still don't recommend using AspectL in practice, but the fact that Clozure Common Lisp now supports that feature in AspectL shows that it can deal with somewhat hairy extensions as well. Best, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Wed Nov 11 14:55:52 2009 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 11 Nov 2009 15:55:52 +0100 Subject: [closer-devel] LAYER-NAME vs LAYER in ADJOIN-LAYER/REMOVE-LAYER. In-Reply-To: References: Message-ID: On 24 Jun 2009, at 18:06, Drew Crampsie wrote: > Hello, > > I'm sure i'm abusing contextl in some way (anonymous layers that > themselves are layered classes), but for my code to work the call to > ADJOIN-LAYER in REMOVE-LAYER-USING-CLASS must pass the layer directly > to ADJOIN-LAYER, not indirect through the layer name. > > In other words : > > hunk ./cx-layer.lisp 103 > - (layer-name active-layer) > + active-layer > > This works for me and passes all the tests, but i'm not sure if it's > the right thing to do... i'm likely abusing contextl in many ways ;). Wow, how time passes.... I finally had time to take care of this. I have made several changes in several places in ContextL, and it should now be possible to use named layers by referring to their name, as well as anonymous layers interchangeably. I'm pretty sure that I covered all cases, but of course there could still be problematic corner cases I have missed. Please let me know if this works for you. Thanks again for submitting this bug report. I'm still interested to know how you use ContextL here... ;) Best, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From tcr at freebits.de Thu Nov 12 08:09:11 2009 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Thu, 12 Nov 2009 09:09:11 +0100 Subject: [closer-devel] Adding dynamic-wind to ContextL References: Message-ID: <87tyx0xizc.fsf@freebits.de> Pascal Costanza wrote a year ago: > [.. adding dynamic-wind ..] As far as I can see, that stuff is orthogonal to ContextL. How standalone is the code? (I have the need for temporarily tearing down and later reestablishing dynamic context like mutex state, and I could possibly make use of your work in that respect.) -T. From pc at p-cos.net Thu Nov 12 09:39:12 2009 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 12 Nov 2009 10:39:12 +0100 Subject: [closer-devel] Adding dynamic-wind to ContextL In-Reply-To: <87tyx0xizc.fsf@freebits.de> References: <87tyx0xizc.fsf@freebits.de> Message-ID: <6CC6A65C-BB28-4AD4-BAEF-2663FB86B1BD@p-cos.net> On 12 Nov 2009, at 09:09, Tobias C. Rittweiler wrote: > Pascal Costanza wrote a year ago: > >> [.. adding dynamic-wind ..] > > As far as I can see, that stuff is orthogonal to ContextL. How > standalone is the code? (I have the need for temporarily tearing down > and later reestablishing dynamic context like mutex state, and I could > possibly make use of your work in that respect.) There are two ways how to interpret your question: + Do you mean "Can dynamic-wind & co be used independent of the other features of ContextL?" The answer is a clear yes: You don't have to buy into layered classes, layered functions and all that other layered stuff just to use dynamic-wind. So you can just go ahead and use it. + Do you mean "Can I provide dynamic-wind as a separate library, without adding all that layered stuff in the same library as well?" I think I potentially could, but I'm hesitating to do so. Library granularity is a problematic thing: If you make your libraries too small, you create lots of dependencies that people somehow have to manage (including the maintainers of the library, but also users of the library). If you create them too large, users load a lot of code into their application that they ultimately don't need. I have already got complaints in the past that I had too many dependencies (that's why I removed the lw-compat from Closer to MOP library, for example). So: Is it really worthwhile to separate out dynamic-wind? Does it hurt so much to load the rest of ContextL even if you don't need it? I could of course also use more code conditionalization, so that you could remove layered stuff on demand. Would that help? + Do you mean "Can I separate out the code easily myself?" [1] Yes, that should be possible: You want cx-dynamic-environments.lisp and probably also cx-dynamic-variables.lisp. Pascal [1] "Three ways to interpret your questions, there are three ways to interpret your questions. Amongst our interpretations are such diverse elements as: ..." -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From tcr at freebits.de Fri Nov 13 09:09:20 2009 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Fri, 13 Nov 2009 10:09:20 +0100 Subject: [closer-devel] Adding dynamic-wind to ContextL References: <87tyx0xizc.fsf@freebits.de> <6CC6A65C-BB28-4AD4-BAEF-2663FB86B1BD@p-cos.net> Message-ID: <87aayqeqpr.fsf@freebits.de> Pascal Costanza writes: > + Do you mean "Can I provide dynamic-wind as a separate library, > + without adding all that layered stuff in the same library as well?" > + I think I potentially could, but I'm hesitating to do so. Library > + granularity is a problematic thing: If you make your libraries too > + small, you create lots of dependencies that people somehow have to > + manage (including the maintainers of the library, but also users of > + the library). If you create them too large, users load a lot of code > + into their application that they ultimately don't need. > > I have already got complaints in the past that I had too many > dependencies (that's why I removed the lw-compat from Closer to MOP > library, for example). So: Is it really worthwhile to separate out > dynamic-wind? Does it hurt so much to load the rest of ContextL even > if you don't need it? I can relate to that. I'd be fine if the dynamic-wind stuff came in its own defsystem, but is distributed with ContextL. It's like the "use the most specific function" rule of thumb. (That said, I think I could just :import-from dynamic-wind from contextl.) -T. PS. http://common-lisp.net/project/closer/downloads.html still says that lw-compat is required. From pc at p-cos.net Sat Nov 14 20:49:08 2009 From: pc at p-cos.net (Pascal Costanza) Date: Sat, 14 Nov 2009 21:49:08 +0100 Subject: [closer-devel] Support for Scieneer Common Lisp Message-ID: <8DDCDFD3-192A-46F2-BC89-776E1B92C9C4@p-cos.net> Hi, I have added some basic support for Closer to MOP in Scieneer Common Lisp. Unfortunately, the existing CLOS MOP implementation in SCL is very weak, so I cannot do a lot about making it more compatible. However, some of you may still find it useful. Unfortunately, the CLOS MOP support is not strong enough to support ContextL or filtered functions, so they won't work in SCL. I have tested this in CentOS 4.8, which is supposed to be compatible with RHEL 4.8, on Intel x86. Best, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Sun Nov 15 00:04:22 2009 From: pc at p-cos.net (Pascal Costanza) Date: Sun, 15 Nov 2009 01:04:22 +0100 Subject: [closer-devel] Support for MCL resurrected Message-ID: <673BB5EF-5F57-49F5-9711-AE8B802458CE@p-cos.net> Hi, Macintosh Common Lisp has a working implementation again (now open source). I have resurrected support for MCL in Closer to MOP, and this means that ContextL also works again for MCL. Even AspectL does its job. Filtered functions are out, though, due to the lack of fundamental support for extending generic function invocation in MCL. All of this is currently available in the darcs repositories (also the support for Scieneer Common Lisp previously mentioned). This will be a pretty large update coming up... Best, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Sun Nov 15 15:19:12 2009 From: pc at p-cos.net (Pascal Costanza) Date: Sun, 15 Nov 2009 16:19:12 +0100 Subject: [closer-devel] Adding dynamic-wind to ContextL In-Reply-To: <87aayqeqpr.fsf@freebits.de> References: <87tyx0xizc.fsf@freebits.de> <6CC6A65C-BB28-4AD4-BAEF-2663FB86B1BD@p-cos.net> <87aayqeqpr.fsf@freebits.de> Message-ID: On 13 Nov 2009, at 10:09, Tobias C. Rittweiler wrote: > Pascal Costanza writes: > >> + Do you mean "Can I provide dynamic-wind as a separate library, >> + without adding all that layered stuff in the same library as well?" >> + I think I potentially could, but I'm hesitating to do so. Library >> + granularity is a problematic thing: If you make your libraries too >> + small, you create lots of dependencies that people somehow have to >> + manage (including the maintainers of the library, but also users of >> + the library). If you create them too large, users load a lot of code >> + into their application that they ultimately don't need. >> >> I have already got complaints in the past that I had too many >> dependencies (that's why I removed the lw-compat from Closer to MOP >> library, for example). So: Is it really worthwhile to separate out >> dynamic-wind? Does it hurt so much to load the rest of ContextL even >> if you don't need it? > > I can relate to that. I'd be fine if the dynamic-wind stuff came in its > own defsystem, but is distributed with ContextL. It's like the "use the > most specific function" rule of thumb. Is that common practice in other CL libraries? Do I understand the idea right? I set up the same package and export the same symbols as before, but only implement a subset of them, by loading only a subset of the implementation files, and I do this by defining a system that only specifies that subset of the implementation files. Is that correct? How many other libraries use that approach? If that's really common, I'm willing to give it a try... > http://common-lisp.net/project/closer/downloads.html still says that > lw-compat is required. Yes, because the 'official' distribution still requires this. This will change hopefully soon... Best, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From attila.lendvai at gmail.com Sun Nov 15 17:07:33 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 15 Nov 2009 18:07:33 +0100 Subject: [closer-devel] Adding dynamic-wind to ContextL In-Reply-To: References: <87tyx0xizc.fsf@freebits.de> <6CC6A65C-BB28-4AD4-BAEF-2663FB86B1BD@p-cos.net> <87aayqeqpr.fsf@freebits.de> Message-ID: >> I can relate to that. I'd be fine if the dynamic-wind stuff came in its >> own defsystem, but is distributed with ContextL. It's like the "use the >> most specific function" rule of thumb. > > Is that common practice in other CL libraries? > > Do I understand the idea right? I set up the same package > and export the same symbols as before, but only implement > a subset of them, by loading only a subset of the implementation > files, and I do this by defining a system that only specifies that > subset of the implementation files. Is that correct? people (well, we) usually create a new separate system definition and a separate package for a standalone functionality. if the functionality is tightly coupled then it's a good idea to keep them in one repo, but we usually just set up also a new repo for the standalone part. and a new project was just born. we do the same-repo/different-system practice for things like hu.dwim.util, which contains various other systems which are not really useful libraries in themselves, but at the same time we don't want to force their dependencies on all our libs that use parts of hu.dwim.util. hu.dwim.wui is our web server, and it has several asdf systems that bring in more and more machinery that build on each other. then users can chose how much of it they need. we use a shared hu.dwim.wui package for them, but we keep the exports at the definition sites (as opposed to a central package.lisp), so that's not a big issue. but back to dynamic wind: the cost for running a separate project seems big, but if you look at it from the point of view that it's just a new darcs repo next to contextl, then it doesn't seem so bad. so, i'd set up a new repo, a new package, move the code there, and then we have one more CL lib... :) just some 0.02, -- attila From pc at p-cos.net Mon Nov 16 13:39:31 2009 From: pc at p-cos.net (Pascal Costanza) Date: Mon, 16 Nov 2009 14:39:31 +0100 Subject: [closer-devel] Adding dynamic-wind to ContextL In-Reply-To: References: <87tyx0xizc.fsf@freebits.de> <6CC6A65C-BB28-4AD4-BAEF-2663FB86B1BD@p-cos.net> <87aayqeqpr.fsf@freebits.de> Message-ID: OK, I found another good reason why separating out dynamic-wind is a good idea: The implementation of dynamic-wind is independent of the CLOS MOP, and doesn't even require CLOS. So it should be much better portable than the rest of ContextL. So I will do this. It will take a little while though, so don't hold your breath... Best, Pascal On 15 Nov 2009, at 18:07, Attila Lendvai wrote: >>> I can relate to that. I'd be fine if the dynamic-wind stuff came in its >>> own defsystem, but is distributed with ContextL. It's like the "use the >>> most specific function" rule of thumb. >> >> Is that common practice in other CL libraries? >> >> Do I understand the idea right? I set up the same package >> and export the same symbols as before, but only implement >> a subset of them, by loading only a subset of the implementation >> files, and I do this by defining a system that only specifies that >> subset of the implementation files. Is that correct? > > > people (well, we) usually create a new separate system definition and > a separate package for a standalone functionality. if the > functionality is tightly coupled then it's a good idea to keep them in > one repo, but we usually just set up also a new repo for the > standalone part. and a new project was just born. > > we do the same-repo/different-system practice for things like > hu.dwim.util, which contains various other systems which are not > really useful libraries in themselves, but at the same time we don't > want to force their dependencies on all our libs that use parts of > hu.dwim.util. > > hu.dwim.wui is our web server, and it has several asdf systems that > bring in more and more machinery that build on each other. then users > can chose how much of it they need. we use a shared hu.dwim.wui > package for them, but we keep the exports at the definition sites (as > opposed to a central package.lisp), so that's not a big issue. > > but back to dynamic wind: the cost for running a separate project > seems big, but if you look at it from the point of view that it's just > a new darcs repo next to contextl, then it doesn't seem so bad. so, > i'd set up a new repo, a new package, move the code there, and then we > have one more CL lib... :) > > just some 0.02, > > -- > attila -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Sat Nov 21 16:33:42 2009 From: pc at p-cos.net (Pascal Costanza) Date: Sat, 21 Nov 2009 17:33:42 +0100 Subject: [closer-devel] Closer to MOP: More news Message-ID: <1A02E0DB-69D3-46B0-A3AC-5391AC1D670E@p-cos.net> Hi, Major reorganization of the code, plus support for generic function invocation protocols in Allegro Common Lisp. A major reorganization of the code became necessary, because the old structure became harder than necessary to maintain. I have now moved code that is similar across many Common Lisp implementations into a shared source code file, and leave only small parts to implementation-dependent source code files. The setup of packages is combined into one file, and all relevant symbols are now exported from the packages, including symbols that may not have any definitions in some Common Lisp implementations. To further simplify things, I have moved source code from subfolders into the main folder, to avoid hierarchy creep. Finally, Allegro Common Lisp now also supports the full generic function invocation protocols. This means that filtered functions now also work there. However, please ensure that the newest patches for Allegro 8.1 are installed and loaded! Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Sat Nov 21 16:35:59 2009 From: pc at p-cos.net (Pascal Costanza) Date: Sat, 21 Nov 2009 17:35:59 +0100 Subject: [closer-devel] Note to ECL users Message-ID: <0A8D7750-C4BC-4FE8-A84C-A8DE4847F7F6@p-cos.net> Hi again, The reorganization of the source code means that ECL is currently not supported. Please use the 'official' release of Closer to MOP if you really need this, not the version in the darcs repository. Supporting ECL is properly is one of the next items on my todo list, but this may still take some time. (Among other things, I'm currently waiting for the new ECL release.) Sorry for any inconveniences. Please let me know if this hurts too much, I can also try to find a workaround if there is enough demand. Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Sat Nov 21 19:47:33 2009 From: pc at p-cos.net (Pascal Costanza) Date: Sat, 21 Nov 2009 20:47:33 +0100 Subject: [closer-devel] Adding dynamic-wind to ContextL In-Reply-To: References: <87tyx0xizc.fsf@freebits.de> <6CC6A65C-BB28-4AD4-BAEF-2663FB86B1BD@p-cos.net> <87aayqeqpr.fsf@freebits.de> Message-ID: <5327E5E2-61CA-4CB5-A86A-92FDC120D38D@p-cos.net> Hi, There is now a separate system definition for dynamic-wind functionality in the repository. I'm still using the same package structure, and no separate repository, because I changed my mind again and think that it's too much overhead. However, the dynamic-wind part can now be used independently of the CLOS extensions of ContextL, and now works in Scieneer Common Lisp, for example. Pascal On 16 Nov 2009, at 14:39, Pascal Costanza wrote: > OK, I found another good reason why separating out dynamic-wind is a good idea: The implementation of dynamic-wind is independent of the CLOS MOP, and doesn't even require CLOS. So it should be much better portable than the rest of ContextL. > > So I will do this. It will take a little while though, so don't hold your breath... > > > Best, > Pascal > > On 15 Nov 2009, at 18:07, Attila Lendvai wrote: > >>>> I can relate to that. I'd be fine if the dynamic-wind stuff came in its >>>> own defsystem, but is distributed with ContextL. It's like the "use the >>>> most specific function" rule of thumb. >>> >>> Is that common practice in other CL libraries? >>> >>> Do I understand the idea right? I set up the same package >>> and export the same symbols as before, but only implement >>> a subset of them, by loading only a subset of the implementation >>> files, and I do this by defining a system that only specifies that >>> subset of the implementation files. Is that correct? >> >> >> people (well, we) usually create a new separate system definition and >> a separate package for a standalone functionality. if the >> functionality is tightly coupled then it's a good idea to keep them in >> one repo, but we usually just set up also a new repo for the >> standalone part. and a new project was just born. >> >> we do the same-repo/different-system practice for things like >> hu.dwim.util, which contains various other systems which are not >> really useful libraries in themselves, but at the same time we don't >> want to force their dependencies on all our libs that use parts of >> hu.dwim.util. >> >> hu.dwim.wui is our web server, and it has several asdf systems that >> bring in more and more machinery that build on each other. then users >> can chose how much of it they need. we use a shared hu.dwim.wui >> package for them, but we keep the exports at the definition sites (as >> opposed to a central package.lisp), so that's not a big issue. >> >> but back to dynamic wind: the cost for running a separate project >> seems big, but if you look at it from the point of view that it's just >> a new darcs repo next to contextl, then it doesn't seem so bad. so, >> i'd set up a new repo, a new package, move the code there, and then we >> have one more CL lib... :) >> >> just some 0.02, >> >> -- >> attila > > -- > Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net > Vrije Universiteit Brussel > Software Languages Lab > Pleinlaan 2, B-1050 Brussel, Belgium > > > > > > > > _______________________________________________ > 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 Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium From tcr at freebits.de Sun Nov 22 08:52:42 2009 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Sun, 22 Nov 2009 09:52:42 +0100 Subject: [closer-devel] Adding dynamic-wind to ContextL References: <87tyx0xizc.fsf@freebits.de> <6CC6A65C-BB28-4AD4-BAEF-2663FB86B1BD@p-cos.net> <87aayqeqpr.fsf@freebits.de> <5327E5E2-61CA-4CB5-A86A-92FDC120D38D@p-cos.net> Message-ID: <87aayfeyat.fsf@freebits.de> Pascal Costanza writes: > Hi, > > There is now a separate system definition for dynamic-wind > functionality in the repository. I'm still using the same package > structure, and no separate repository, because I changed my mind again > and think that it's too much overhead. However, the dynamic-wind part > can now be used independently of the CLOS extensions of ContextL, and > now works in Scieneer Common Lisp, for example. Thanks! -T. From pc at p-cos.net Mon Nov 30 14:19:39 2009 From: pc at p-cos.net (Pascal Costanza) Date: Mon, 30 Nov 2009 15:19:39 +0100 Subject: [closer-devel] ECL support in Closer projects Message-ID: Hi, There is now full support for ECL in the Closer to MOP projects. All of the libraries are supported and pass all of their test suites. This includes: Closer to MOP itself, ContextL, AspectL and Filtered Functions (the latter still only available as a darcs repository, but not a as a 'full' release yet). You need the newest version of ECL that can be found in its CVS repository (will be released soon) for all of this to work. Thanks a lot to Alexander Gavrilov who provided a lot of very useful patches that I was able to incorporate, and to Juan Jose Garcia-Ripoll for fixing a lot of bugs in ECL to make this possible. On a related note, filtered functions now have a test suite added, from which it is easier to understand what they actually do. Furthermore, Closer to MOP now has an Allegro-specific system definition file. As soon as the new version of ECL is released, all of this will be released as well, along with updated documentation that mentions ECL-specific details. Best, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium