From attila.lendvai at gmail.com Fri Apr 13 10:17:37 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 13 Apr 2007 12:17:37 +0200 Subject: [closer-devel] lw-compat dependency of closer-mop Message-ID: dear Pascal, it seems like closer-mop does not actually depend on lw-compat and even if it would then a small duplicates.lisp could eliminate the dependency. i'm a big fan of factoring out stuff into standalone projects, but due to the constant price added by the lack of good package management tools for lisp, i usually create a duplicates.lisp for small things. but as it doesn't actually seem to use lw-compat, this is a non-issue. could you please remove the dependency from the closer-mop.asd file so that it becomes a standalone lib? -- attila From pc at p-cos.net Fri Apr 13 11:11:34 2007 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 13 Apr 2007 13:11:34 +0200 Subject: [closer-devel] lw-compat dependency of closer-mop In-Reply-To: References: Message-ID: <998C9FC7-31CE-42E8-A269-6E0C60DF91E0@p-cos.net> On 13 Apr 2007, at 12:17, Attila Lendvai wrote: > dear Pascal, > > it seems like closer-mop does not actually depend on lw-compat and > even if it would then a small duplicates.lisp could eliminate the > dependency. > > i'm a big fan of factoring out stuff into standalone projects, but due > to the constant price added by the lack of good package management > tools for lisp, i usually create a duplicates.lisp for small things. > > but as it doesn't actually seem to use lw-compat, this is a non-issue. > could you please remove the dependency from the closer-mop.asd file so > that it becomes a standalone lib? Both ContextL and Closer to MOP use lw-compat in a few places, so I would indeed need to provide duplicate functionality in both projects. That's not so nice, especially because LispWorks already provides these operators. I actually would like to keep this separation. What specific problems do you encounter? (Maybe you can convince me that it is indeed too much of a hassle...) 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 attila.lendvai at gmail.com Fri Apr 13 11:32:00 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 13 Apr 2007 13:32:00 +0200 Subject: [closer-devel] lw-compat dependency of closer-mop In-Reply-To: <998C9FC7-31CE-42E8-A269-6E0C60DF91E0@p-cos.net> References: <998C9FC7-31CE-42E8-A269-6E0C60DF91E0@p-cos.net> Message-ID: > Both ContextL and Closer to MOP use lw-compat in a few places, so I > would indeed need to provide duplicate functionality in both > projects. That's not so nice, especially because LispWorks already > provides these operators. oops, seems like my scanning was too sloppy. > I actually would like to keep this separation. What specific problems > do you encounter? (Maybe you can convince me that it is indeed too > much of a hassle...) the only problem is that ucw already depends on a lot of packages and for a moment i played with the idea of using closer-mop. but arnesi provides a MOPP package and it's already a dependency, so i may just leave things as they are and do not introduce two more dependencies. so, there's no actual problem, only a cry for a better package management for lisp... :) anyway, thanks for the quick answer and sorry for my sloppiness, -- attila From pc at p-cos.net Fri Apr 13 11:40:29 2007 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 13 Apr 2007 13:40:29 +0200 Subject: [closer-devel] lw-compat dependency of closer-mop In-Reply-To: References: <998C9FC7-31CE-42E8-A269-6E0C60DF91E0@p-cos.net> Message-ID: <3EECC7F3-DF60-4B7C-9398-3FF7A4E003DF@p-cos.net> On 13 Apr 2007, at 13:32, Attila Lendvai wrote: >> Both ContextL and Closer to MOP use lw-compat in a few places, so I >> would indeed need to provide duplicate functionality in both >> projects. That's not so nice, especially because LispWorks already >> provides these operators. > > oops, seems like my scanning was too sloppy. No problem - it's indeed only two or three places where they are used, so they are easy to miss. >> I actually would like to keep this separation. What specific problems >> do you encounter? (Maybe you can convince me that it is indeed too >> much of a hassle...) > > the only problem is that ucw already depends on a lot of packages and > for a moment i played with the idea of using closer-mop. but arnesi > provides a MOPP package and it's already a dependency, so i may just > leave things as they are and do not introduce two more dependencies. Why don't you ask them to switch to Closer to MOP? ;) > so, there's no actual problem, only a cry for a better package > management for lisp... :) Yes, that would be good (but outside of the scope of the closer project :-D ). > anyway, thanks for the quick answer and sorry for my sloppiness, No problem. 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 Sat Apr 21 21:35:19 2007 From: pc at p-cos.net (Pascal Costanza) Date: Sat, 21 Apr 2007 23:35:19 +0200 Subject: [closer-devel] ContextL 0.40. Message-ID: Hi everyone, I have just released ContextL 0.40. The idea is that this version is feature-complete with regard to the feature set of the upcoming 1.0 release. So the goal is to test this version now, and in the meantime I hope I will find enough time to write up some more decent documentation of ContextL before version 1.0 is eventually released. IMPORTANT: There are some changes in the API of ContextL 0.40 compared to previous versions. If you rely on the old version and cannot afford to switch to 0.40 yet for some reason, I have also provided a new version 0.32 which has the same API as before, but just fixes an important internal bug I have discovered recently. If for some reason you can indeed not switch to 0.40, please let me know and I'll see what I can do to fix potential issues. For those who are willing to switch, here are the changes that will probably affect your code: + The functions activate-layer and activate-layer-using-class have been renamed to adjoin-layer and adjoin-layer-using-class, and deactivate-layer and deactivate-layer-using-class have been renamed to remove-layer and remove-layer-using-class. The new names reflect better what these functions actually do. However, the semantics haven't changed. + Removed the functions funcall-with-layers and apply-with-layers. Use the functions funcall-with-layer-context and apply-with-layer- context instead. (That API was ugly, and I guess it was never used.) + The deflayer macro doesn't take a :layer-class option anymore, but instead a :metaclass option. (I have tried to abstract from the internal representation as CLOS classes, but that turns out to be useless for the time being.) There is no change in semantics here, you just have to switch from :layer-class to :metaclass in a deflayer form, that's all. And now to some of the new features in this release: + Added the functions funcall-with-layer-context and apply-with- layer-context, as hopefully better replacements for funcall-with- layers and apply-with-layers. + Added the function current-layer-context. This captures the set of currently active layers, which can later be reinstalled with funcall-with-layer-context and apply-with-layer-context. (This should be handy in conjunction with continuations, as for example in continuation-based web frameworks.) + Added the readers layered-function-definer, layered-function- argument-precedence-order, layered-function-lambda-list for layered- function objects. + Added the readers layered-method-lambda-list, layered-method- specializers, layered-method-layer for layered-method objects. + Added the readers slot-definition-layered-readers and slot- definition-layered-writers for layered slot definition metaobjects. + You can now specify an :in-layer option in slot specifiers. This means that a slot within a define-layered-class form can be declared to be in a different layer than the respective class itself. This should allow, for example, grouping of slots of different layers in the same define-layered-class form. + Layers and layered functions can now also have uninterned symbols as names. This enables a form of anonymous layers and anonymous layered functions when gensym is used to create names for them. It's then probably also better to pass these symbols around instead of the first-class layers or functions themselves. + Added the function ensure-layer for programmatically creating layers. Finally some internal changes, which are not necessarily visible to application programmers: + Some of the :in-layer keyword parameters to internal functions have previously taken lists of layers for technical reasons. This is not the case anymore. This doesn't affect those who have used the define-layered-class, but if you have used plain defclass forms with the respective :metaclass options in the past, you may have to change the corresponding :in-layer class options. + Changed the internal handling of the :defining-metaclass option for partial classes. In the previous versions, that option actually didn't get recorded properly. Fortunately, that didn't affect the correctness of the behavioral semantics. (phew ;) + Layered direct slot definition metaobjects don't take :layered- reader, :layered-writer and :layered-accessor initargs anymore, but rather :layered-readers and :layered-writers, which is closer to how the CLOS MOP works as well. + Added methods for print-object for the major classes and metaclasses, such that, for example, debug output now prints more nicely. So this all effectively means that I have kept my announcements from beginning of January of this year with a delay of only two months. (Hey, that's better than both Microsoft and Apple. ;) Please feel free to ask any questions, either in the closer-devel mailing list (the preferred forum), or in private email. 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 Sat Apr 21 21:45:26 2007 From: pc at p-cos.net (Pascal Costanza) Date: Sat, 21 Apr 2007 23:45:26 +0200 Subject: [closer-devel] in-layer macro Message-ID: <75F12BB6-85D7-462F-A82C-370813F827AD@p-cos.net> Hi again, At the ContextL tutorial at ILC'07, some people have asked for an additional convenience macro to ease writing ContextL code. The idea is to have a construct that "announce" a current layer, such that all subsequent class and method definitions are automatically associated with that layer, somewhat like the in-package macro in Common Lisp. I have given some thought to this and see two possible directions. One would be to capture plain defclass and defmethod macros, and the other is to capture define-layered-class and define-layered-method macros. So for example, such a macro could look like this: (in-layer some-layer (defclass person () ((address :initarg :address :accessor address))) (defmethod do-it ((object person)) (print (address object)))) ...or it could look like that: (in-layer some-layer (define-layered-class person () ((address :initarg :address :layered-accessor address))) (define-layered-method do-it ((object person)) (print (address object)))) In both cases, the expansion would look like this: (progn (define-layered-class person :in-layer some-layer () ((address :initarg :address :layered-accessor address))) (define-layered-method do-it :in-layer some-layer ((object person)) (print (address object)))) The first variant of such an in-layer macro would ease moving existing CLOS code to ContextL, and the second variant would ease refactoring ContextL code, for example, to experiment with putting the same definitions in different layers. Of course, it would also be a possibility to do both, but I am hesitating a bit here because I would like to avoid feature bloat (and I smell some nasty corner cases here). So far, I haven't been in need of such a convenience macro myself, so I don't really know which way to go. Does anyone have any opinions here? 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 Tue Apr 24 17:32:45 2007 From: pc at p-cos.net (Pascal Costanza) Date: Tue, 24 Apr 2007 19:32:45 +0200 Subject: [closer-devel] Reflective Layer Activation in ContextL Message-ID: Hi, I have just uploaded the paper "Reflective Layer Activation in ContextL" to my website that we have presented at this year's ACM Symposium on Applied Computing. You can download it from http://p- cos.net/documents/context-meta.pdf This paper describes some aspects of the metaobject protocol of ContextL. This is not exactly the same version as presented at the symposium, but the paper has been updated to reflect the new API in ContextL 0.4. However, apart from the resulting changes of function names and a few other minor edits, the contents have remained the same. 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