- cells-devel - mailman3.common-lisp.net

[cells-devel] Re: [cells-gtk-devel] cells-gtk3 without libcellsgtk / threads
by Peter Hildebrandt 19 May '08

19 May '08

Ingo, thanks again for the patch. I it is now in CVS. > 1. If libcellsgtk is not used (gtk-init...) never seems to be called. Yep, stupid typo of mine. Sorry about that. > 2. Also if used in a single threading environment (like clisp) > (g-thread-init...) and (gdk-threads-init) do get called which > results in an error. Hmm, I never changed that, I think. They were always called in cells-gtk if IIRC. However, if it does no harm to leave them out, then that seems the right thing to do. Are you on windows or linux? I'm just guessing, but it might be the case that it is a GTK issue and not a cells-gtk issue whether to call them: On linux GTK supports threads, so it might be necessary to call those (even if you don't use threads yourself). On windows it doesn't, so maybe you can't call them. In this case, we should condition on :unix vs. :windows. But again, I'm just guessing. If you're on linux, then forget everything I said. As to the call-next-method thing, the background is this: Cells uses progn method combination for observers, which is not available on clisp (or at least, used to not be available on clisp). Therefore cells needed to imitate it by using standard method combination and (call-next-method) in every method. You see a lot of these calls in cells-gtk: fritz@babyfoot:~/cells-gtk3/cells-gtk$ grep clisp *.lisp actions.lisp: #+clisp (call-next-method)) buttons.lisp: #+clisp (call-next-method)) buttons.lisp: #+clisp (call-next-method)) ... However, I see that cells3 only uses this imitation on corman lisp now: fritz@babyfoot:~/lisp/cells3.cvs$ grep progn cells.lisp (:method-combination progn)) (defmethod slot-value-observe #-(or cormanlisp) progn So maybe this means that clisp now supports progn method combination, which the error message suggests: #<STANDARD-GENERIC-FUNCTION SLOT-VALUE-OBSERVE>: CALL-NEXT-METHOD is invalid within PROGN methods Than it would be time to remove all those calls to call-next-method from cells-gtk. I'd suggest you just go ahead and deactivate all those calls (e.g by conditioning on :no-progn-combination instead of :clisp), which should remove those warnings. Cheers, Peter

1 0

Re: [cells-devel] Current DP ... not GE pulse ... of cell ...?
by Ken Tilton 15 May '08

15 May '08

[ccing cells-devel because usefully on topic] Peter Hildebrandt wrote: >> Me, too. The question is why can't you just abort the backtrace, fix the >>mistake, and re-run. You mentioned you had to restart Lisp, obviously a bad >>thing, but not my case so I am wondering ...well, I'll keep reading. > > > So what happens is, I get an error, like this: > New as of Cells3: parent must be supplied to make-instance of SYMBOL kid ME > [Condition of type SIMPLE-ERROR] > > Restarts: > 0: [ABORT] Return to SLIME's top level. > 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B183A51}>) > > --> so all I can do is ABORT. (SBCL is not so generous with the restarts) > > Then I drop to the repl, and do a cells-reset, which releases the > stop. Then sooner or later I run into something like: > > Current DP 1 not GE pulse 4194 of cell (#1=(#2=BN344) > . <vld>)<4194:A > PARENT-NODES/#2#BN345 = #1#> > [Condition of type SIMPLE-ERROR] > > Restarts: > 0: [CONTINUE] Retry assertion. > 1: [ABORT] Return to SLIME's top level. > 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B183A51}>) > > CONTINUE won't help (the assertion obviously keeps failing), and if I > ABORT and go to the repl, I keep getting similar errors whenever I do > something cellsy. > > At this point I usually restart the lisp process to clear things up -- > which is ugly and annoying ;-) > ...snip... > >>Or is GTk still talking to the old Lisp model via callbacks? Or... <g> > > > This could indeed be true. Generally the old application is still > hanging around after a failure (frozen while i'm at the repl) and > comes back to live when i run a new instance. Then of course there is > this zombie window out there talking to gtk ... that might be an > issue. I can kinda guarantee that old state is still in play. There is nothing fancy going on with these DPs. If you were off by one and only after a backtrace I would think /maybe/ there was some interaction, but that just sounds like old state. btw, I only see this if I run and forget to take down the prior window (perhaps with the backtrace still active, but either way). The prior window gets events (Tcl sees nothing of the backtrace) and goes to work but the single global DP has been reset. To confirm, if like me you have a root instance, you might give it a gensym as the md-name and then, when you backtrace compare (md-name (u^ <root-class>)) with the name of the root most recently created. Hopefully that confirms the problem and then you really know on what you are working, always helps. > > Maybe after all what i need to do is play with handlers and unwind > protects in cells-gtk to get it to clean up in case of an error. That might work. This glue business (to other worlds) always gets tricky at the edges. You might consider extending cells-gtk-reset (if there be such a thing, if not make one) to look around for the Undead and clean up at that point, if automatic cleanup will make debugging hard. kt

1 0

Re: [cells-devel] Current DP ... not GE pulse ... of cell ...?
by Peter Hildebrandt 15 May '08

15 May '08

On 5/15/08, Ken Tilton <kennytilton(a)optonline.net> wrote: > Ken Tilton wrote: > > > > For me it is just abort/fix/rerun. > > Me too -- unless cells gets into this Current DP is not GE pulse business -- then I can't figure out how to fix that. Peter > I meant "with Celtk". > > kt > >

1 0

[cells-devel] Current DP ... not GE pulse ... of cell ...?
by Peter Hildebrandt 15 May '08

15 May '08

Every now and then I do something silly (like setf'ing a cell w/o initializing it as c-in, and I run into a cells-stop. What is the correct way to recover from this? I used to do a (cells-reset), but all too often the next cells operation runs into something like that: Current DP 28 not GE pulse 1160 of cell ... and somehow I don't get anything done until I restart lisp. So, what is the right way to deal with this? Thanks, Peter PS. The cells-store is working fine in my app, getting close to be ready for general use. I committed a store-items to cells-store.lisp recently. And one day I will rewrite it using proper cells wiring and not my own dirty little glue :)

2 2

[cells-devel] Cells cvs does not compile out of the box on Lispworks for Linux 5.1
by Larry Clapp 11 May '08

11 May '08

Cells cvs does not compile out of the box on Lispworks for Linux 5.1. Is it supposed to? Problems include the lack of the excl and ide.base packages. Thanks for your help. -- Larry Clapp

2 4

[cells-devel] openair project created
by Andy Chambers 08 May '08

08 May '08

Hi Everyone, The openair project has now been setup. Sign up to the mailing list here: http://common-lisp.net/mailman/listinfo/openair-devel The (sparse) project home page is here: http://common-lisp.net/project/openair/ -- Andy

2 1

[cells-devel] Not a test -- don't ignore (Hi, Marco!)
by Ken Tilton 07 May '08

07 May '08

I just added a simplistic new namespace mechanism to Cells that probably will need refinement, but will certainly work for its simplistic design goals: If your sougth (formerly by fm-other) stuff will Just Be There during a datapulse, and be named uniquely and absolutely (no path relative stuff where two things have the same name but are differentiated by being nearer (in some sense) to the seeker) then you can just look them up by name. This arose because I got into a cycle seeking X from Y. I quickly saw that Cells could trivially support "if this cycles return X (in this case nil works)" -- and tho I did not go for it for this time I expect Cells to go there soon -- but then next I saw the problem only arose because I had gotten lazy and structured things unusually such that a namespace search had gone so high..well, it's complicated, but I saw that unlazying my code would probably eliminate the cycle, but one Design Principle of Cells is "Hey, this is supposed to make programming easier, that does not happen if I have to sweat these things I would naturally code." and I have been regularly solving these things by unlazying my code but damnit Lisp is all about being lazy so I thought let's see if there is something still sensible that lets me keep my lazy structuring. And of course the bizarritude of fm-other and its ilk begged to be challenged, because they blindly sail all over the hierarchy looking for things and this invites cycles because rules determing the populations of models may well kick off these searches -- hello cycle! And that was what was happening here so if I could find things without blindly traversing the hierarchy life would be good. Peter Hildebrandt has been working on a more sophisticated alternative scheme to namespacing, but I am in Just Ship! mode and I saw that in my case I did not need cells-ish dependency -- X and Y came into existence during the same datapulse, so a simple registration at make-instance time would work fine, and that is what I did. I think searching the source on "register" will return the unsurprising details. kt

1 0

[cells-devel] test: please ignore
by Marco Antoniotti 06 May '08

06 May '08

... told ya! -- Marco Antoniotti

1 0

[cells-devel] penetrate deeper
by Noreen 25 Apr '08

25 Apr '08

GAIN YOUR PENIS 2 INCH - SIMPLE AS NEVER. NATURAL HERBAL PRODUCT 100% SATISFACTION GUARANTEE! http://babbuyae.com

1 0

Re: [cells-devel] not-to-be and owning slots
by Peter Hildebrandt 23 Apr '08

23 Apr '08

On Tue, Apr 22, 2008 at 2:33 AM, Ken Tilton <kennytilton(a)optonline.net> wrote: > Later on I saw you reporting something weird about .kids not getting > reliably handled. I' d like to run down the "weird" rather than just throw > in parallel code to make .kids work. After I commit lemme know when the > weirdness returns. Sounds good. I wasn't sure as to whether I understood what I was doing. I just saw that not-to-be did not propagate to kids *at all* if I did it the way I suggested. Hold on, one idea: Maybe the problem is with (get (type-of fm) :ownings), i.e. this only picks up the owning defined on the actual class of fm, not the inherited ones? To be honest, I am just doing wild guesswork here, so I better shut up :-) Hope you guys had a good time in Amsterdam. Hopefully next year I will actually make it :-) Cheers, Peter

2 7