Filtered functions
in [Lisp]
|
Prev: [ANN] Filtered functions
Next: Filtered functions.
From: Kenneth Tilton on 6 Dec 2009 14:18 Pascal Costanza wrote: > Kenneth Tilton wrote: >> Alessio Stalla wrote: >>> On Dec 6, 4:06 am, Raffael Cavallaro >>> <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> wrote: >>> [snip] >>>> Not merely related, but central to this discussion. Your "analysis" is >>>> just spite. Since your extension to CLOS was not well received, then no >>>> one's should be. >>> >>> I'm much more on Pascal's side than Kenny's in this discussion, but... >>> why do you keep saying the Cells is not well received? I don't believe >>> so. There are many applications and libraries that use Cells. >> >> ...and this is Lisp so Cells is even more plagiarized than used: Mr. >> Burdick's C4, Mr. Eby's Trellis (for Python), Mr. Jain's incipient >> Formulate, and this: http://common-lisp.net/project/computed-class/. >> >>> As for it not being publication-quality and well documented... writing >>> and documenting Cells is not Kenny's main job, while writing >>> publications is part of Pascal's job; if his software and >>> documentation weren't publication-quality, he wouldn't be doing a good >>> job. >> >> Man, documentation is hard, unrewarding work. And I do admire good >> doc, such as the Postgres doc and the old Inside Mac books (and the >> doc for the Apple II Basics and for VAX/VMS). The CLHS is OK, tho it >> will be named in my upcoming carpal tunnel class action. >> >>> The fact that he and his colleagues go to extra lengths to make >>> their software publicly available and running on multiple CL >>> implementations is of course very appreciated, not everyone would do >>> such a thing. >> >> And they shouldnt, it's a PITA. Cells runs everywhere, and Celtk and >> Cells-GTk do not do too badly. Cello has been observed at different >> times in its life on Linux and the Mac as well as Windows. Lisp >> implementation does not matter if it is conformant CL. But my >> experience with the above confirms the experience of many others: >> doing X for open source is 27 times harder than doing it for oneself, >> with documentation being part of the burden, portability being another. >> >> I'd rather /use/ X (http://www.theoryyalgebra.com/) to make money so I >> can hire all you deadbeats than spend hundreds of hours working on >> casting pearls before you swine. >> >> But the important thing is getting Raffy to see how he misapplied >> "sour grapes"! There are so many other insults he fairly could have >> switched to once his gaffe was exposed. Ah, the vanity of the Usenet >> denizen, never able to publicly concede a mistake, digging deeper and >> deeper. Especially those Mexicans. >> >> Anyway, I finally persuaded GraphicsMagick to not require separate >> installation (after belatedly discovering NSIS would support nested >> installs, but this is still nicer) so I should be able to put together >> an installer for Stuck On Algebra (the new name) and start my Algebra >> empire in short order. Get your resumes ready. > > None of this has anything to do with the topic of the thread, right? > Did you miss the part where Lars argued for GF dispatch as a good way to handle variable on-click handling? This in reply to my bemoaning your software's attempt to beat the GF horse even deader with f/fn? Perhaps you are distracted by Raffy's insistence on deflecting this worthy discussion into a debate over my motivation. What Raffy does not know is that I just happen to be looking thru a bit of GF-heavy code and am especially sensitive these days to the issue. Poor guy. He does not know English, he does not know humor, he cannot apply an analogy to save his life, and he does not know what I am thinking. The latter may be a blessing, tho: it's not pretty in here. kt -- http://thelaughingstockatpngs.com/ http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf
From: Lars Rune Nøstdal on 6 Dec 2009 14:23 On Dec 6, 8:15 pm, Lars Rune Nøstdal <larsnost...(a)gmail.com> wrote: > On Dec 6, 6:06 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote: > > > > > > > Lars Rune Nøstdal wrote: > > > On Dec 5, 7:05 am, Kenneth Tilton <kentil...(a)gmail.com> wrote: > > >> .. > > >> Filed under "Stupid CLOS Tricks". > > >> .. > > >> kt > > > > Hm, but by using EQL-specialized methods things do turn from type/ > > > class driven dispatch to data driven, no? > > > > (defgeneric on-click (widget)) > > > > (let ((x (list "<some-button-widget>")) > > > (logged-in-p nil)) > > > > (defmethod on-click ((button (eql x))) > > > (assert logged-in-p) > > > (write-line "B")) > > > > (defmethod on-click :before ((button (eql x))) > > > (setf logged-in-p t) > > > (write-line "A")) > > > > (on-click x)) > > > A > > > B > > > > There is some trouble involved with lifetime (GC) here and I'm sort of > > > using an outer Viewport layer which when GCed will "manually" GC these > > > methods thus freeing the widgets they in turn point to. Another > > > possibility is weak-pointers or a weak hash-table, I think. > > > > A problem is that SB-PCL seems to have a leak at the moment: > > > https://bugs.launchpad.net/sbcl/+bug/492851 > > > > I've tried doing stuff like (REMHASH X SB-PCL::*EQL-SPECIALIZER- > > > TABLE*) and (REMHASH X SB-PCL::*EQL-SPECIALIZER-METHODS*) at the > > > "right time" (helping it a bit manually) and, stuff, but it seems a > > > reference is still being held _somewhere_. So, even if I somehow did > > > use weak pointers the pointers _themselves_ would leak; that is, all > > > use of EQL-specialization, even if handled "correctly from the > > > outside" -- will have an "internal leak" AFAICT .... hm. > > > > Anyway, this is ramblish -- and the reason I posted is method > > > combinations (even user defined ones!) seem interesting for cases like > > > these (totally disregarding this problem for a moment), and I wonder > > > how and perhaps why one would go about re-implementing this in > > > something like Cells or similar. > > > This does not have much to do with Cells; most Lisp GUI frameworks > > accept callbacks as data, ie the values of slots called 'on-click: > > > (make-instance 'button > > :on-click (lambda (self event) ...)) > > > If you think you need to divide the code in two (between primary and > > before methods): > > > (make-instance 'button > > :on-click 'my-super-on-click-handler) > > Hm. Yeah, but now I've lost the ability to add further callbacks to > the ON-CLICK slot. Well, at least while at the same time controlling > order when that is needed for a group/sub-set of the callbacks -- > sometimes on a pr. instance basis, sometimes not. > > ... or something. I keep losing track of what the problem actually is/ > was, but something _is_ wrong with what I'm currently doing here, and > it is remarkably hard coming up with a small test-case or example to > illustrate the problem .. gah. Ok, again, some order is needed in > _some_ cases, but at the same time I don't want external or unrelated > code to have to worry about stuff like a MY-SUPER-ON-CLICK-HANDLER > being around. > > Experimenting here; so perhaps multiple ways ("categories") of adding > callbacks, then? I don't know: > > (defgeneric on-event (event widget &rest args) > (:method-combination progn)) Whops, that should have been: (defgeneric on-event (event widget &rest args) (:method-combination progn :most-specific-last)) ...so in that the order of output becomes: A B BULK OP. ...and the not shown here "Cellsy" callbacks last.
From: Lars Rune Nøstdal on 6 Dec 2009 15:12 On Dec 6, 8:23 pm, Lars Rune Nøstdal <larsnost...(a)gmail.com> wrote: > On Dec 6, 8:15 pm, Lars Rune Nøstdal <larsnost...(a)gmail.com> wrote: > > > > > > > On Dec 6, 6:06 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote: > > > > Lars Rune Nøstdal wrote: > > > > On Dec 5, 7:05 am, Kenneth Tilton <kentil...(a)gmail.com> wrote: > > > >> .. > > > >> Filed under "Stupid CLOS Tricks". > > > >> .. > > > >> kt > > > > > Hm, but by using EQL-specialized methods things do turn from type/ > > > > class driven dispatch to data driven, no? > > > > > (defgeneric on-click (widget)) > > > > > (let ((x (list "<some-button-widget>")) > > > > (logged-in-p nil)) > > > > > (defmethod on-click ((button (eql x))) > > > > (assert logged-in-p) > > > > (write-line "B")) > > > > > (defmethod on-click :before ((button (eql x))) > > > > (setf logged-in-p t) > > > > (write-line "A")) > > > > > (on-click x)) > > > > A > > > > B > > > > > There is some trouble involved with lifetime (GC) here and I'm sort of > > > > using an outer Viewport layer which when GCed will "manually" GC these > > > > methods thus freeing the widgets they in turn point to. Another > > > > possibility is weak-pointers or a weak hash-table, I think. > > > > > A problem is that SB-PCL seems to have a leak at the moment: > > > > https://bugs.launchpad.net/sbcl/+bug/492851 > > > > > I've tried doing stuff like (REMHASH X SB-PCL::*EQL-SPECIALIZER- > > > > TABLE*) and (REMHASH X SB-PCL::*EQL-SPECIALIZER-METHODS*) at the > > > > "right time" (helping it a bit manually) and, stuff, but it seems a > > > > reference is still being held _somewhere_. So, even if I somehow did > > > > use weak pointers the pointers _themselves_ would leak; that is, all > > > > use of EQL-specialization, even if handled "correctly from the > > > > outside" -- will have an "internal leak" AFAICT .... hm. > > > > > Anyway, this is ramblish -- and the reason I posted is method > > > > combinations (even user defined ones!) seem interesting for cases like > > > > these (totally disregarding this problem for a moment), and I wonder > > > > how and perhaps why one would go about re-implementing this in > > > > something like Cells or similar. > > > > This does not have much to do with Cells; most Lisp GUI frameworks > > > accept callbacks as data, ie the values of slots called 'on-click: > > > > (make-instance 'button > > > :on-click (lambda (self event) ...)) > > > > If you think you need to divide the code in two (between primary and > > > before methods): > > > > (make-instance 'button > > > :on-click 'my-super-on-click-handler) > > > Hm. Yeah, but now I've lost the ability to add further callbacks to > > the ON-CLICK slot. Well, at least while at the same time controlling > > order when that is needed for a group/sub-set of the callbacks -- > > sometimes on a pr. instance basis, sometimes not. > > > ... or something. I keep losing track of what the problem actually is/ > > was, but something _is_ wrong with what I'm currently doing here, and > > it is remarkably hard coming up with a small test-case or example to > > illustrate the problem .. gah. Ok, again, some order is needed in > > _some_ cases, but at the same time I don't want external or unrelated > > code to have to worry about stuff like a MY-SUPER-ON-CLICK-HANDLER > > being around. > > > Experimenting here; so perhaps multiple ways ("categories") of adding > > callbacks, then? I don't know: > > > (defgeneric on-event (event widget &rest args) > > (:method-combination progn)) > > Whops, that should have been: > > (defgeneric on-event (event widget &rest args) > (:method-combination progn :most-specific-last)) > > ..so in that the order of output becomes: > > A > B > BULK OP. > > ..and the not shown here "Cellsy" callbacks last. Actually, make that the way it was, then instead replace the "top level" PROGN ON-EVENT method with: (defmethod on-event :around (event widget &rest args) #| Forward to something that might want to use another method-combination than the "brute force" PROGN used here. |# (let* ((gf-name (intern (format nil "ON-~A" event))) (gf (and (fboundp gf-name) (fdefinition gf-name)))) (when gf (apply gf widget args))) (call-next-method)) ...giving the same updated output: A B BULK OP. This isn't very important for this particular example, but it might make a bit more sense in that ON-EVENT methods will be handled in a more natural order as a "category or group" of callbacks.
From: Kenneth Tilton on 6 Dec 2009 16:26 Lars Rune N�stdal wrote: > Hm, nope. (LIST "<some widget>") is really just a dummy version of > what in real code is an instance of a widget class; nothing fancy > here. :) Oh, for the love of G*d, please never do that again. Programming solutions have more than a little to do with the problem being solved, so don't offer problem X to ask about problem Y. As for problem Y, your problem is meta-problem J: you have decided that the solution involves GF method dispatch, witness your fallback now to various method-combination hacks. Here is a Sacred Trick From Kenny: when solution basis Q has you tied in knots, ask yourself how much Q is helping. The best way to find other letters of the alphabet is to write out your problem in a free-writing session and turn off your upper cortex, see what your navel says. Sorry I cannot be less specific*. kt * I am reminded however (somewhat fascinatingly) of how that Cello rendering got handled: data. Instead of a function or GF, a widget specifies a list of rendering commands which get executed in that order. End of problem. And this is what I mean by, f*ck Gfs, give me data-driven programming. k ps. Your case is like Prolog. You know in each case what you want to happen and in what order, you just can't get it out of GFs without ending up on Usenet pissing off Costanza by discussing something more interesting than his paper. k
From: Pascal Costanza on 6 Dec 2009 16:29
Kenneth Tilton wrote: > Pascal Costanza wrote: >> Kenneth Tilton wrote: >>> Alessio Stalla wrote: >>>> On Dec 6, 4:06 am, Raffael Cavallaro >>>> <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> wrote: >>>> [snip] >>>>> Not merely related, but central to this discussion. Your "analysis" is >>>>> just spite. Since your extension to CLOS was not well received, >>>>> then no >>>>> one's should be. >>>> >>>> I'm much more on Pascal's side than Kenny's in this discussion, but... >>>> why do you keep saying the Cells is not well received? I don't believe >>>> so. There are many applications and libraries that use Cells. >>> >>> ...and this is Lisp so Cells is even more plagiarized than used: Mr. >>> Burdick's C4, Mr. Eby's Trellis (for Python), Mr. Jain's incipient >>> Formulate, and this: http://common-lisp.net/project/computed-class/. >>> >>>> As for it not being publication-quality and well documented... writing >>>> and documenting Cells is not Kenny's main job, while writing >>>> publications is part of Pascal's job; if his software and >>>> documentation weren't publication-quality, he wouldn't be doing a good >>>> job. >>> >>> Man, documentation is hard, unrewarding work. And I do admire good >>> doc, such as the Postgres doc and the old Inside Mac books (and the >>> doc for the Apple II Basics and for VAX/VMS). The CLHS is OK, tho it >>> will be named in my upcoming carpal tunnel class action. >>> >>>> The fact that he and his colleagues go to extra lengths to make >>>> their software publicly available and running on multiple CL >>>> implementations is of course very appreciated, not everyone would do >>>> such a thing. >>> >>> And they shouldnt, it's a PITA. Cells runs everywhere, and Celtk and >>> Cells-GTk do not do too badly. Cello has been observed at different >>> times in its life on Linux and the Mac as well as Windows. Lisp >>> implementation does not matter if it is conformant CL. But my >>> experience with the above confirms the experience of many others: >>> doing X for open source is 27 times harder than doing it for oneself, >>> with documentation being part of the burden, portability being another. >>> >>> I'd rather /use/ X (http://www.theoryyalgebra.com/) to make money so >>> I can hire all you deadbeats than spend hundreds of hours working on >>> casting pearls before you swine. >>> >>> But the important thing is getting Raffy to see how he misapplied >>> "sour grapes"! There are so many other insults he fairly could have >>> switched to once his gaffe was exposed. Ah, the vanity of the Usenet >>> denizen, never able to publicly concede a mistake, digging deeper and >>> deeper. Especially those Mexicans. >>> >>> Anyway, I finally persuaded GraphicsMagick to not require separate >>> installation (after belatedly discovering NSIS would support nested >>> installs, but this is still nicer) so I should be able to put >>> together an installer for Stuck On Algebra (the new name) and start >>> my Algebra empire in short order. Get your resumes ready. >> >> None of this has anything to do with the topic of the thread, right? >> > > Did you miss the part [...] As long as you're not missing anything, everything is fine, right? Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ |