From ktilton at nyc.rr.com Fri May 6 18:05:06 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 06 May 2005 14:05:06 -0400 Subject: [cells-gtk-devel] Re: [cells-devel] cells-gtk status In-Reply-To: <17019.43943.917207.729648@gargle.gargle.HOWL> References: <17019.43943.917207.729648@gargle.gargle.HOWL> Message-ID: <427BB1D2.7030804@nyc.rr.com> rpgoldman at real-time.com wrote: >Would it be possible for someone on the list to clue us in on the >status of Cells-gtk now that there is a new version of Cells? > >A while ago there was a lot of email traffic that seemed to be >concerned with this issue, but as a newcomer, I really didn't follow >it. It SEEMED like there was some version skew, but I didn't >understand. > As I understand it, the folks in cells-gtk maintain a tarball known to have everything you need, including cells and utils-kt, isoloating the crew from any tossing and turning in the Cells world. My understanding was that cells-gtk worked OK with cells after a tweak or two, but I might be mistaken, and at any rate they will not pull Cells-2 into the tarball without making sure it all works. Note, btw, that cells-gtk already uses a version including the new technology of cells-2, just not the actual source release that Mr. Brudick made. ie, Just grab the tarball and you probably do not need to worry about any cells-2 release issues. kenny From peter.denno at nist.gov Fri May 6 18:14:05 2005 From: peter.denno at nist.gov (Peter Denno) Date: Fri, 6 May 2005 14:14:05 -0400 Subject: [cells-gtk-devel] Re: [cells-devel] cells-gtk status In-Reply-To: <17019.43943.917207.729648@gargle.gargle.HOWL> References: <17019.43943.917207.729648@gargle.gargle.HOWL> Message-ID: <200505061414.05944.peter.denno@nist.gov> On Friday 06 May 2005 13:38, rpgoldman at real-time.com wrote: > Would it be possible for someone on the list to clue us in on the > status of Cells-gtk now that there is a new version of Cells? In my work I switched to a new version of cells April 28 -- whatever was available then. I haven't noticed any difference. As I have read on this list, cells 2.0 is mostly just reorganization (bringing utils-kt under the cells directory). I hope to do some work on cells-gtk in the next few weeks (adding some abilities to combo-box -- it can be made to use the tree model to allow hierarchical organization, look into use with sbcl ... among other things). At that time, I'll make a tarball using the current version of 2.0...but I don' think it should matter much. Or has there been some substantial changes that are affecting the use of cells-gtk ??? > A while ago there was a lot of email traffic that seemed to be > concerned with this issue, but as a newcomer, I really didn't follow > it. It SEEMED like there was some version skew, but I didn't > understand. Maybe you are referring to a discussion between myself and Kenny Tilton on the cells-gtk list about the /possibility/ of that occurring over time ??? -- - Best regards, Peter From peter.denno at nist.gov Fri May 6 18:24:17 2005 From: peter.denno at nist.gov (Peter Denno) Date: Fri, 6 May 2005 14:24:17 -0400 Subject: [cells-gtk-devel] Re: [cells-devel] cells-gtk status In-Reply-To: <427BB1D2.7030804@nyc.rr.com> References: <17019.43943.917207.729648@gargle.gargle.HOWL> <427BB1D2.7030804@nyc.rr.com> Message-ID: <200505061424.18373.peter.denno@nist.gov> Hi, I agree with Kenny's assessment. One note: If you are using cells-gtk under windows (and not clisp) then Martin Svenson points out that you need this one patch (not in the tarball). Martin's email: Hi. I was trying to get cells-gtk working with Allegro CL 7.0 and discovered a small error in the #+win32 part of gtk-ffi.lisp (defun libname (lib) ? ?#+(or win32 mswindows) ? ?(concatenate 'string ? ? ?"/Program Files/Common Files/GTK/2.0/bin/" ? ? ?(ecase lib ? ? ? ?(:gobject "libgobject-2.0-0.dll") ? ? ? ?(:glib "libglib-2.0-0.dll") ? ? ? ?(:gthread "libgthread-2.0-0.dll") ? ? ? ?(:gdk "libgdk-win32-2.0-0.dll") ? ? ? ?(:cgtk "libcellsgtk"))) The (:gtk "libgtk-win32-2.0-0.dll") clause is missing. After adding that, it works like a charm. Thank you, I look forward to updates and more examples! :-) // Martin. On Friday 06 May 2005 14:05, Kenny Tilton wrote: > rpgoldman at real-time.com wrote: > >Would it be possible for someone on the list to clue us in on the > >status of Cells-gtk now that there is a new version of Cells? > > > >A while ago there was a lot of email traffic that seemed to be > >concerned with this issue, but as a newcomer, I really didn't follow > >it. It SEEMED like there was some version skew, but I didn't > >understand. > > As I understand it, the folks in cells-gtk maintain a tarball known to > have everything you need, including cells and utils-kt, isoloating the > crew from any tossing and turning in the Cells world. > > My understanding was that cells-gtk worked OK with cells after a tweak > or two, but I might be mistaken, and at any rate they will not pull > Cells-2 into the tarball without making sure it all works. Note, btw, > that cells-gtk already uses a version including the new technology of > cells-2, just not the actual source release that Mr. Brudick made. > > ie, Just grab the tarball and you probably do not need to worry about > any cells-2 release issues. > > kenny > > > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel -- - Best regards, Peter From ktilton at nyc.rr.com Fri May 6 18:35:13 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 06 May 2005 14:35:13 -0400 Subject: [cells-gtk-devel] Cells 2 Synapses... In-Reply-To: <200505061414.05944.peter.denno@nist.gov> References: <17019.43943.917207.729648@gargle.gargle.HOWL> <200505061414.05944.peter.denno@nist.gov> Message-ID: <427BB8E1.9070702@nyc.rr.com> ... look broken, in the case where the only dependency would be on the synapse. Well, I am sure they have been broken for longer than that. Anyway, once I fix them I will also get onto cleaning up the CVS tree under the Cells project, and then post the Cells 2 code there. The CVS tree then becomes the official version. kenny From peter.denno at nist.gov Sat May 7 22:49:31 2005 From: peter.denno at nist.gov (Peter Denno) Date: Sat, 7 May 2005 18:49:31 -0400 Subject: [cells-gtk-devel] Re: [cells-devel] Next Steps In-Reply-To: <427D338F.8090307@nyc.rr.com> References: <427D0F6E.1040800@nyc.rr.com> <427D338F.8090307@nyc.rr.com> Message-ID: <200505071849.31966.peter.denno@nist.gov> On Saturday 07 May 2005 17:30, Kenny Tilton wrote: > No, come to think of it second will be some easier work: > > (a) a check that Cells is not *stop*ped, which will be avoidable with a > new special I will set when working under typical window manager > environments (a long story, wherein the app cannot be successfully > killed because the IDE keeps allowing OS events thru to application > windows). This sounds good. I think we in cells-gtk-land are suffering from something like this. -- - Best regards, Peter From ktilton at nyc.rr.com Sun May 8 02:39:11 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 07 May 2005 22:39:11 -0400 Subject: [cells-gtk-devel] Re: [cells-devel] Next Steps In-Reply-To: <200505071849.31966.peter.denno@nist.gov> References: <427D0F6E.1040800@nyc.rr.com> <427D338F.8090307@nyc.rr.com> <200505071849.31966.peter.denno@nist.gov> Message-ID: <427D7BCF.1080104@nyc.rr.com> Peter Denno wrote: >On Saturday 07 May 2005 17:30, Kenny Tilton wrote: > > >>No, come to think of it second will be some easier work: >> >>(a) a check that Cells is not *stop*ped, which will be avoidable with a >>new special I will set when working under typical window manager >>environments (a long story, wherein the app cannot be successfully >>killed because the IDE keeps allowing OS events thru to application >>windows). >> >> > >This sounds good. I think we in cells-gtk-land are suffering from something >like this. > Oh, tell me more. I have had to wrestle these things to the ground time and again. You all are likely dealing with a Lisp thru the Slime or ILisp intermediary, which will complicate things. The good news is that it just takes a few days of intense head-banging and then everything is under control. As Lispniks the ability to stop and start gracefully is not something we can relinquish, full stop. Don't hesitate to check with me if you are getting hung up on normally survivable backtraces. kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From jcm at FreeBSD-uk.eu.org Tue May 10 14:32:33 2005 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Tue, 10 May 2005 15:32:33 +0100 Subject: [cells-gtk-devel] Need help with FreeBSD installation Message-ID: <20050510143233.GC91836@dogma.freebsd-uk.eu.org> Hi all, I'm looking to try cells-gtk and I'm have trouble getting it installed. Here's my system: DragonFlyBSD (like FreeBSD-4.x) CMUCL Lisp gtk-2.8.? I was running (load "load") and got an error that it couldn't find libgtk. The library is definitely there, as I use xfce-4 for my window manager, and it is based on gtk2. If anyone has any ideas I can try, I'd be much obliged. And please CC me, as I'm not subscribed at the moment. Jonathon McKitrick -- My other computer is your Windows box. From ktilton at nyc.rr.com Tue May 10 14:56:26 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 10 May 2005 10:56:26 -0400 Subject: [cells-gtk-devel] Need help with FreeBSD installation In-Reply-To: <20050510143233.GC91836@dogma.freebsd-uk.eu.org> References: <20050510143233.GC91836@dogma.freebsd-uk.eu.org> Message-ID: <4280CB9A.3070400@nyc.rr.com> Jonathon McKitrick wrote: >Hi all, > >I'm looking to try cells-gtk and I'm have trouble getting it installed. >Here's my system: > >DragonFlyBSD (like FreeBSD-4.x) >CMUCL Lisp >gtk-2.8.? > >I was running (load "load") and got an error that it couldn't find libgtk. > Here is where "load" is looking: (let ((libpath (cond ((directory "/usr/lib/libgtk*") "/usr/lib/") ((directory "/opt/gnome/lib/libgtk*") "/opt/gnome/lib/")))) (if libpath (error "Cannot find a path containing libgtk"))) Where exactly do you have libgtk? Anyway, the idea is simply to get the above code working, either by moving libgtk or by tweaking your copy of the code (and possibly submitting a patch if you think others would benefit). hth, kt From peter.denno at nist.gov Tue May 10 15:23:03 2005 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 10 May 2005 11:23:03 -0400 Subject: [cells-gtk-devel] Need help with FreeBSD installation In-Reply-To: <4280CB9A.3070400@nyc.rr.com> References: <20050510143233.GC91836@dogma.freebsd-uk.eu.org> <4280CB9A.3070400@nyc.rr.com> Message-ID: <200505101123.04218.peter.denno@nist.gov> Hi, Note also that these directories are set in a few places. I hope to fix this in the next tarball, but for the time being, take a look at each of them: fgrep gnome `find . -name \*.lisp` ./root/cells-gtk/gtk-app.lisp: ... ./root/gtk-ffi/gtk-ffi.lisp: ... ./load.lisp: ... On Tuesday 10 May 2005 10:56, Kenny Tilton wrote: > Jonathon McKitrick wrote: > >Hi all, > > > >I'm looking to try cells-gtk and I'm have trouble getting it installed. > >Here's my system: > > > >DragonFlyBSD (like FreeBSD-4.x) > >CMUCL Lisp > >gtk-2.8.? > > > >I was running (load "load") and got an error that it couldn't find libgtk. > > Here is where "load" is looking: > > (let ((libpath (cond ((directory "/usr/lib/libgtk*") "/usr/lib/") > ((directory "/opt/gnome/lib/libgtk*") > "/opt/gnome/lib/")))) > (if libpath > (error "Cannot find a path containing libgtk"))) > > Where exactly do you have libgtk? Anyway, the idea is simply to get the > above code working, either by moving libgtk or by tweaking your copy of > the code (and possibly submitting a patch if you think others would > benefit). > > hth, kt > > > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel -- - Best regards, Peter From rm at seid-online.de Tue May 10 16:11:55 2005 From: rm at seid-online.de (rm at seid-online.de) Date: Tue, 10 May 2005 18:11:55 +0200 Subject: [cells-gtk-devel] Need help with FreeBSD installation Message-ID: <20050510161155.GD26030@seid-online.de> On Tue, May 10, 2005 at 10:56:26AM -0400, Kenny Tilton wrote: > > > Jonathon McKitrick wrote: > > >Hi all, > > > >I'm looking to try cells-gtk and I'm have trouble getting it installed. > >Here's my system: > > > >DragonFlyBSD (like FreeBSD-4.x) > >CMUCL Lisp > >gtk-2.8.? > > > >I was running (load "load") and got an error that it couldn't find libgtk. > > > > Here is where "load" is looking: > > (let ((libpath (cond ((directory "/usr/lib/libgtk*") "/usr/lib/") > ((directory "/opt/gnome/lib/libgtk*") > "/opt/gnome/lib/")))) > (if libpath > (error "Cannot find a path containing libgtk"))) This code does fail with SBCL as well. Looks like the "/usr/lib/libgtk*" doesn't match. Adding a file type ("/usr/lib/libgtk*.so") or at least a file type wildcard ("/usr/lib/libgtk*.*") solves _Taht_ problem. BTW, there should be no need to provide a libpath - most dynamic linkers will work without a path (actually, chances are higher that you get the systems correct library version). With SBCL a simple (load-shared-object "libgtk-x11-2.0.so") will do. > Where exactly do you have libgtk? Anyway, the idea is simply to get the > above code working, either by moving libgtk or by tweaking your copy of > the code (and possibly submitting a patch if you think others would > benefit). Seems like the lib-loading is spread over a bunch of files. Wouldn't it make sense to centralize before we submit OS/Implementation specific patches :-) Cheers Ralf Mattes > > hth, kt > > > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel From rm at seid-online.de Tue May 10 16:12:22 2005 From: rm at seid-online.de (rm at seid-online.de) Date: Tue, 10 May 2005 18:12:22 +0200 Subject: [cells-gtk-devel] Need help with FreeBSD installation Message-ID: <20050510161222.GE26030@seid-online.de> On Tue, May 10, 2005 at 11:23:03AM -0400, Peter Denno wrote: > Hi, > > Note also that these directories are set in a few places. I hope to fix this > in the next tarball, but for the time being, take a look at each of them: Good new (just suggested this in a reply to Kenny's mail). BTW, SBCL uses load-shared-object nowadays. Cheers Ralf Mattes From jcm at FreeBSD-uk.eu.org Tue May 10 16:27:07 2005 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Tue, 10 May 2005 17:27:07 +0100 Subject: [cells-gtk-devel] Need help with FreeBSD installation In-Reply-To: <200505101123.04218.peter.denno@nist.gov> References: <20050510143233.GC91836@dogma.freebsd-uk.eu.org> <4280CB9A.3070400@nyc.rr.com> <200505101123.04218.peter.denno@nist.gov> Message-ID: <20050510162707.GD91836@dogma.freebsd-uk.eu.org> On Tue, May 10, 2005 at 11:23:03AM -0400, Peter Denno wrote: : > Where exactly do you have libgtk? Anyway, the idea is simply to get the : > above code working, either by moving libgtk or by tweaking your copy of : > the code (and possibly submitting a patch if you think others would : > benefit). I did some digging and found a few things. In FreeBSD, graphics libraries are in /usr/X11R6/lib, while other libraries are in /usr/local/lib. I fixed the paths where needed, and split one of the loop commands to load the non-X11 libs first, then the X11 libs. The current problem I have is that our pthread functions are in libc_r. So when ffi tries to load libgthread, this symbol is undefined. What could I do as a workaround? From ktilton at nyc.rr.com Tue May 10 18:40:04 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 10 May 2005 14:40:04 -0400 Subject: [cells-gtk-devel] Need help with FreeBSD installation In-Reply-To: <20050510162707.GD91836@dogma.freebsd-uk.eu.org> References: <20050510143233.GC91836@dogma.freebsd-uk.eu.org> <4280CB9A.3070400@nyc.rr.com> <200505101123.04218.peter.denno@nist.gov> <20050510162707.GD91836@dogma.freebsd-uk.eu.org> Message-ID: <42810004.9020701@nyc.rr.com> Jonathon McKitrick wrote: >On Tue, May 10, 2005 at 11:23:03AM -0400, Peter Denno wrote: >: > Where exactly do you have libgtk? Anyway, the idea is simply to get the >: > above code working, either by moving libgtk or by tweaking your copy of >: > the code (and possibly submitting a patch if you think others would >: > benefit). > >I did some digging and found a few things. > >In FreeBSD, graphics libraries are in /usr/X11R6/lib, while other libraries >are in /usr/local/lib. > >I fixed the paths where needed, and split one of the loop commands to load the >non-X11 libs first, then the X11 libs. > >The current problem I have is that our pthread functions are in libc_r. So >when ffi tries to load libgthread, this symbol is undefined. What could I do >as a workaround? > I am not strong on this X/Linux stuff, but can you sneak a load of libc_r in front of the libgthread? And take notes, this may be useful. You might even chalk up a port! :) kenny From rm at seid-online.de Tue May 10 18:48:17 2005 From: rm at seid-online.de (rm at seid-online.de) Date: Tue, 10 May 2005 20:48:17 +0200 Subject: [cells-gtk-devel] Need help with FreeBSD installation In-Reply-To: <42810004.9020701@nyc.rr.com> References: <20050510143233.GC91836@dogma.freebsd-uk.eu.org> <4280CB9A.3070400@nyc.rr.com> <200505101123.04218.peter.denno@nist.gov> <20050510162707.GD91836@dogma.freebsd-uk.eu.org> <42810004.9020701@nyc.rr.com> Message-ID: <20050510184817.GF26030@seid-online.de> On Tue, May 10, 2005 at 02:40:04PM -0400, Kenny Tilton wrote: > > I am not strong on this X/Linux stuff, but can you sneak a load of > libc_r in front of the libgthread? And take notes, this may be useful. > You might even chalk up a port! :) This is mean :-) He's on BSD - remember? I'm willing to port to recent SBCLs on Linux - as soon as the lib-loading stuff is refactored (i hate duplicated code). To the OP: i'm not strong with BSD's dynamic loader but shouldn't libgthread pull in all required libraries? Cheeers Ralf Mattes > kenny > > > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel From peter.denno at nist.gov Tue May 10 19:10:55 2005 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 10 May 2005 15:10:55 -0400 Subject: [cells-gtk-devel] Need help with FreeBSD installation In-Reply-To: <20050510161155.GD26030@seid-online.de> References: <20050510161155.GD26030@seid-online.de> Message-ID: <200505101510.55378.peter.denno@nist.gov> On Tuesday 10 May 2005 12:11, rm at seid-online.de wrote: > This code does fail with SBCL as well. Looks like the "/usr/lib/libgtk*" > doesn't match. Adding a file type ("/usr/lib/libgtk*.so") or at least a > file type wildcard ("/usr/lib/libgtk*.*") solves _Taht_ problem. > > BTW, there should be no need to provide a libpath - most dynamic linkers > will work without a path (actually, chances are higher that you get the > systems correct library version). With SBCL a simple > > ?(load-shared-object "libgtk-x11-2.0.so") > > will do. So have you managed to get cells-gtk to work under SBCL? That would be a first AFAIK. -- - Best regards, Peter From peter.denno at nist.gov Tue May 10 19:16:39 2005 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 10 May 2005 15:16:39 -0400 Subject: [cells-gtk-devel] Need help with FreeBSD installation In-Reply-To: <20050510184817.GF26030@seid-online.de> References: <20050510143233.GC91836@dogma.freebsd-uk.eu.org> <42810004.9020701@nyc.rr.com> <20050510184817.GF26030@seid-online.de> Message-ID: <200505101516.40349.peter.denno@nist.gov> On Tuesday 10 May 2005 14:48, rm at seid-online.de wrote: > I'm willing to port to recent SBCLs on Linux - as soon as the lib-loading > stuff is refactored (i hate duplicated code). This is definitely something we should do, if we can -- I think (needs to be proven) that there is an issue with the order in which thing are loaded -- it differs in cmucl from some of the other lisps (???) and therefore we have things spread out a bit. Still I'm sure it could be cleaner. -- - Best regards, Peter From rm at seid-online.de Tue May 10 19:57:09 2005 From: rm at seid-online.de (rm at seid-online.de) Date: Tue, 10 May 2005 21:57:09 +0200 Subject: [cells-gtk-devel] Need help with FreeBSD installation Message-ID: <20050510195709.GH26030@seid-online.de> On Tue, May 10, 2005 at 03:10:55PM -0400, Peter Denno wrote: > On Tuesday 10 May 2005 12:11, rm at seid-online.de wrote: > > This code does fail with SBCL as well. Looks like the "/usr/lib/libgtk*" > > doesn't match. Adding a file type ("/usr/lib/libgtk*.so") or at least a > > file type wildcard ("/usr/lib/libgtk*.*") solves _Taht_ problem. > > > > BTW, there should be no need to provide a libpath - most dynamic linkers > > will work without a path (actually, chances are higher that you get the > > systems correct library version). With SBCL a simple > > > > ?(load-shared-object "libgtk-x11-2.0.so") > > > > will do. > > So have you managed to get cells-gtk to work under SBCL? That would be a first > AFAIK. Not yet, i just fiund some time abd had another look at it. The support for callbacks from foriegn code is a rather, erm, moving target. There are several fragments of code drifting arround the net anmd then there's a callback branch in the sbcl CVS repository. The drifting code i used stopped working after some changes in the sbcl kernel (due to API changes). But i'll keep going ... Cheers RalfD > -- > - Best regards, > Peter > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel From peter.denno at nist.gov Tue May 10 20:31:02 2005 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 10 May 2005 16:31:02 -0400 Subject: [cells-gtk-devel] Need help with FreeBSD installation In-Reply-To: <20050510195709.GH26030@seid-online.de> References: <20050510195709.GH26030@seid-online.de> Message-ID: <200505101631.02994.peter.denno@nist.gov> On Tuesday 10 May 2005 15:57, rm at seid-online.de wrote: > > So have you managed to get cells-gtk to work under SBCL? That would be a > > first AFAIK. > > Not yet, i just fiund some time abd had another look at it. The support for > callbacks from foriegn code is a rather, erm, moving target. There are > several fragments of code drifting arround the net anmd then there's a > callback branch in the sbcl CVS repository. The drifting code i used > stopped working after some changes in the sbcl kernel (due to API changes). > But i'll keep going ... Excellent! Go for it! > > ?Cheers RalfD -- - Best regards, Peter From jcm at FreeBSD-uk.eu.org Thu May 12 12:07:28 2005 From: jcm at FreeBSD-uk.eu.org (Jonathon McKitrick) Date: Thu, 12 May 2005 13:07:28 +0100 Subject: [cells-gtk-devel] Need help with FreeBSD installation In-Reply-To: <20050510184817.GF26030@seid-online.de> References: <20050510143233.GC91836@dogma.freebsd-uk.eu.org> <4280CB9A.3070400@nyc.rr.com> <200505101123.04218.peter.denno@nist.gov> <20050510162707.GD91836@dogma.freebsd-uk.eu.org> <42810004.9020701@nyc.rr.com> <20050510184817.GF26030@seid-online.de> Message-ID: <20050512120727.GA42563@dogma.freebsd-uk.eu.org> On Tue, May 10, 2005 at 08:48:17PM +0200, rm at seid-online.de wrote: : On Tue, May 10, 2005 at 02:40:04PM -0400, Kenny Tilton wrote: : > : > I am not strong on this X/Linux stuff, but can you sneak a load of : > libc_r in front of the libgthread? And take notes, this may be useful. : > You might even chalk up a port! :) : : This is mean :-) He's on BSD - remember? : I'm willing to port to recent SBCLs on Linux - as soon as the lib-loading : stuff is refactored (i hate duplicated code). : To the OP: i'm not strong with BSD's dynamic loader but shouldn't libgthread : pull in all required libraries? That's what I would have thought. Oh well. Actually, I think I'm going to switch to a web-based GUI. I did GTK with python, so now I'll try HTML. But thanks anyway for the help. Jonathon McKitrick -- My other computer is your Windows box. From rm at seid-online.de Thu May 12 14:05:04 2005 From: rm at seid-online.de (rm at seid-online.de) Date: Thu, 12 May 2005 16:05:04 +0200 Subject: [cells-gtk-devel] Need help with FreeBSD installation Message-ID: <20050512140504.GB4645@seid-online.de> On Thu, May 12, 2005 at 01:07:28PM +0100, Jonathon McKitrick wrote: > On Tue, May 10, 2005 at 08:48:17PM +0200, rm at seid-online.de wrote: > : On Tue, May 10, 2005 at 02:40:04PM -0400, Kenny Tilton wrote: > : > > : > I am not strong on this X/Linux stuff, but can you sneak a load of > : > libc_r in front of the libgthread? And take notes, this may be useful. > : > You might even chalk up a port! :) > : > : This is mean :-) He's on BSD - remember? > : I'm willing to port to recent SBCLs on Linux - as soon as the lib-loading > : stuff is refactored (i hate duplicated code). > : To the OP: i'm not strong with BSD's dynamic loader but shouldn't libgthread > : pull in all required libraries? > > That's what I would have thought. Well, have you tried providing "" as the path? On Linux this works fine. What does BSD use as a dynamic loader? Oh well. Actually, I think I'm going to > switch to a web-based GUI. I did GTK with python, so now I'll try HTML. Eeeek, i'm not too big a fan of web-based GUIs (anything with slighz complexity starts to get nasty pretty soon). Have fun :-) Cheers Ralf Mattes From jonny at drugphish.ch Fri May 13 21:41:07 2005 From: jonny at drugphish.ch (Jonathan Heusser) Date: Fri, 13 May 2005 23:41:07 +0200 Subject: [cells-gtk-devel] making a text-buffer inputp Message-ID: <42851EF3.9060606@drugphish.ch> Forgive my very newbie question. I'm trying to change a text-buffer to the value of an entry with a click on a button. My button code looks like this: (mk-button :md-name :b :label "send" :on-clicked (callback (w e d) (setf (buffer (upper self buttons)) (md-value (fm-other :entry)))) After pressing enter on this button I got the error that the buffer has to be initialized as inputp. Then I tried to initialize it as follows (it was just a guess): (buffer :accessor buffer :initarg :buffer :initform (c-input () (mk-text-buffer :text (format nil "bla")) But it's still not working as it should. Either my setf on the buffer is wrong or this initialisation. Can you lead me on the right track? Thanks Jonathan Heusser -- ACF8 4AC4 E7E4 1C72 44C5 4E55 2CF0 79E9 84B6 4AD3 From ktilton at nyc.rr.com Fri May 13 21:50:34 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 13 May 2005 17:50:34 -0400 Subject: [cells-gtk-devel] making a text-buffer inputp In-Reply-To: <42851EF3.9060606@drugphish.ch> References: <42851EF3.9060606@drugphish.ch> Message-ID: <4285212A.9010901@nyc.rr.com> Jonathan Heusser wrote: >Forgive my very newbie question. >I'm trying to change a text-buffer to the value of an entry with a click >on a button. > >My button code looks like this: >(mk-button :md-name :b :label "send" :on-clicked > (callback (w e d) > (setf (buffer (upper self buttons)) > (md-value (fm-other :entry)))) > >After pressing enter on this button I got the error that the buffer has >to be initialized as inputp. >Then I tried to initialize it as follows (it was just a guess): > Good guess. > (buffer :accessor buffer :initarg :buffer > :initform (c-input () (mk-text-buffer > :text (format nil "bla")) > >But it's still not working as it should. Either my setf on the buffer is >wrong or this initialisation. >Can you lead me on the right track? > Sure. Some questions: 1. Can you define "still not working"? Runtime error? Incorrect result? No result? 2. Are you using the same SETF form? 3. Should buffer just be a string? I do not have Cells-gtk in front of me. If not, is the md-value of the :entry widget a string or a text-buffer instance? kenny From peter.denno at nist.gov Fri May 13 21:53:31 2005 From: peter.denno at nist.gov (Peter Denno) Date: Fri, 13 May 2005 17:53:31 -0400 Subject: [cells-gtk-devel] making a text-buffer inputp In-Reply-To: <42851EF3.9060606@drugphish.ch> References: <42851EF3.9060606@drugphish.ch> Message-ID: <200505131753.32363.peter.denno@nist.gov> On Friday 13 May 2005 17:41, Jonathan Heusser wrote: > Forgive my very newbie question. No problem. > I'm trying to change a text-buffer to the value of an entry with a click > on a button. > > My button code looks like this: > (mk-button :md-name :b :label "send" :on-clicked > (callback (w e d) > (setf (buffer (upper self buttons)) > (md-value (fm-other :entry)))) > > After pressing enter on this button I got the error that the buffer has > to be initialized as inputp. > Then I tried to initialize it as follows (it was just a guess): > (buffer :accessor buffer :initarg :buffer > > :initform (c-input () (mk-text-buffer > : > :text (format nil "bla")) I think you want :text (c-in "bla") here. Here is an example, from my code (it will work with a little editing). Also, I think there is a demo thing that adds text to a buffer. (defmodel |BACKGROUND OUTPUT| (vbox) () (:default-initargs :kids (list (mk-vbox :expand t :fill t :kids (list (mk-button :label "Clear" :on-clicked (callback (w e d) (setf (text (buffer (unique-widget :backout-text))) (format nil "~A" (gensym))))) (mk-scrolled-window :kids (list (mk-text-view :md-name :backout-text :buffer (mk-text-buffer :tag-table (list :red-foreground :red-background :yellow-foreground :yellow-background :green-foreground :green-background :blue-foreground :blue-background :black-foreground :black-background :white-foreground :white-background) :text (c-in "")))))))))) > > But it's still not working as it should. Either my setf on the buffer is > wrong or this initialisation. > Can you lead me on the right track? > > Thanks > Jonathan Heusser -- - Best regards, Peter From jonny at drugphish.ch Fri May 13 22:07:47 2005 From: jonny at drugphish.ch (Jonathan Heusser) Date: Sat, 14 May 2005 00:07:47 +0200 Subject: [cells-gtk-devel] making a text-buffer inputp In-Reply-To: <200505131753.32363.peter.denno@nist.gov> References: <42851EF3.9060606@drugphish.ch> <200505131753.32363.peter.denno@nist.gov> Message-ID: <42852533.40304@drugphish.ch> > (mk-button :label "Clear" > :on-clicked > (callback (w e d) > (setf (text (buffer (unique-widget :backout-text))) > > That was it! My buffer is now declared with: (buffer :accessor buffer :initarg :buffer :initform (mk-text-buffer :text (c-in ""))) and the button form: (mk-button :md-name :b :label "send" :on-clicked (callback (w e d) (incf (nclics (upper self buttons))) (setf (text (buffer (upper self buttons))) (md-value (fm-other :entry)))))))) It's working like that. Thanks. That's fast help :). Jonathan -- ACF8 4AC4 E7E4 1C72 44C5 4E55 2CF0 79E9 84B6 4AD3 From ktilton at nyc.rr.com Fri May 13 23:25:55 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 13 May 2005 19:25:55 -0400 Subject: [cells-gtk-devel] making a text-buffer inputp In-Reply-To: <200505131753.32363.peter.denno@nist.gov> References: <42851EF3.9060606@drugphish.ch> <200505131753.32363.peter.denno@nist.gov> Message-ID: <42853783.40507@nyc.rr.com> Peter Denno wrote: >On Friday 13 May 2005 17:41, Jonathan Heusser wrote: > > >I think you want :text (c-in "bla") here. > Agreed. Hope it works. Even so, I am curious how Cells internals ended up calling ADOPT-CT on the string. If possible, I would like to shield users from that kind of error by detecting the error further upstream. This is a general policy of mine, so any time anyone gets a nasty error from Cell internals I would be happy to look into adding some programmer friendliness if a detailed report (preferably the failing source) is forwarded. The good news is that I myself no longer find myself poking around Cells internals to resolve application programming problems, but that might just mean I am in part figuring things out in my head based on long experience. kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From jonny at drugphish.ch Fri May 13 22:00:16 2005 From: jonny at drugphish.ch (Jonathan Heusser) Date: Sat, 14 May 2005 00:00:16 +0200 Subject: [cells-gtk-devel] making a text-buffer inputp In-Reply-To: <4285212A.9010901@nyc.rr.com> References: <42851EF3.9060606@drugphish.ch> <4285212A.9010901@nyc.rr.com> Message-ID: <42852370.4020404@drugphish.ch> > 1. Can you define "still not working"? Runtime error? Incorrect > result? No result? Sure. With the mentioned buffer initialization an the following button form: (mk-button :md-name :b :label "send" :on-clicked (callback (w e d) (incf (nclics (upper self buttons))) (setf (buffer (upper self buttons)) (fm-other :entry))))))) It doesn't drop into the debugger but nothing happens at all. I'm just pressing the button and no reaction. Although the "nclics" gets increased (which I have displayed on a label). With this button form: (mk-button :md-name :b :label "send" :on-clicked (callback (w e d) (incf (nclics (upper self buttons))) (setf (buffer (upper self buttons)) (md-value (fm-other :entry)))))))) I get the following error when clicking on the button: No matching method for the generic function #, when called with arguments ("test"). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR] > 2. Are you using the same SETF form? See above. > 3. Should buffer just be a string? I do not have Cells-gtk in front of > me. If not, is the md-value of the :entry widget a string or a > text-buffer instance? yes just a string. Thanks Jonathan -- ACF8 4AC4 E7E4 1C72 44C5 4E55 2CF0 79E9 84B6 4AD3 From ktilton at nyc.rr.com Fri May 20 22:14:21 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 20 May 2005 18:14:21 -0400 Subject: [cells-gtk-devel] Ooops: with-c-cache Message-ID: <428E613D.9030800@nyc.rr.com> Ooops. I yanked this new macro out of the use case just before posting everything to CVS, forgetting some of you old Cells hands would likely not update from CVS before trying the use case. Here is with-c-cache, not found in cells/constructirs.lisp (defmacro with-c-cache ((fn) &body body) (let ((new (gensym))) `(or (bwhen (,new (progn , at body)) (funcall ,fn ,new .cache)) .cache))) kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From ktilton at nyc.rr.com Thu May 26 19:19:19 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 26 May 2005 15:19:19 -0400 Subject: [cells-gtk-devel] Re: Cells-gtk In-Reply-To: References: Message-ID: <42962137.4020204@nyc.rr.com> Fred Gilham wrote: >Just FYI, I tried running cells-gtk under CMUCL and FreeBSD. I got it >to compile by fiddling with the library pathnames in gtk-ffi.lisp and >creating links in /usr/local/lib to all the necessary C libraries. >Then I tried running test-gtk::gtk-demo. It got to the point of >displaying a small icon. Then it got an error: > >Error in function LISP::ASSERT-ERROR: The assertion CELLS-GTK::CB failed. > [Condition of type SIMPLE-ERROR] > >which I assume had something to do with callbacks. > The error is coming from an output method generated by the def-gtk macro, which in part writes code thus: (def-c-output ,slot-name ((self ,class)) (when new-value (callback-register self ,(intern (string signal-slot) :keyword) new-value) (let ((cb (cdr (assoc ',signal-slot *widget-callbacks*)))) (assert cb) #+shhtk (trc nil "in def-c-output gtk-signal-connect pcb:" cb ',slot-name (id self)) (gtk-signal-connect (id self) ,(string-downcase (string signal-slot)) cb)))) It would be nice if the assertion were changed to something like: (assert cb () "whoa, callback ~a not defined in *widget-callbacks*" ',signal-slot) The defined CBs are: (defparameter *widget-callbacks* (list (cons 'clicked (ff-register-callable 'clicked-handler)) (cons 'changed (ff-register-callable 'changed-handler)) (cons 'activate (ff-register-callable 'activate-handler)) (cons 'value-changed (ff-register-callable 'value-changed-handler)) (cons 'day-selected (ff-register-callable 'day-selected-handler)) (cons 'selection-changed (ff-register-callable 'selection-changed-handler)) (cons 'toggled (ff-register-callable 'toggled-handler)) (cons 'delete-event (ff-register-callable 'delete-event-handler)) (cons 'modified-changed (ff-register-callable 'modified-changed-handler)))) If it seems as if the missing signal is in fact defined, I would start thinking about case sensitivity or packages as the usual suspects. hth, kenneth From peter.denno at nist.gov Thu May 26 20:12:47 2005 From: peter.denno at nist.gov (Peter Denno) Date: Thu, 26 May 2005 16:12:47 -0400 Subject: [cells-gtk-devel] Re: Cells-gtk In-Reply-To: <42962137.4020204@nyc.rr.com> References: <42962137.4020204@nyc.rr.com> Message-ID: <200505261612.48301.peter.denno@nist.gov> On Thursday 26 May 2005 15:19, Kenny Tilton wrote: > It would be nice if the assertion were changed to something like: > > ? ? ? (assert cb () "whoa, callback ~a not defined in > *widget-callbacks*" ',signal-slot) Agreed. I'll make this change. -- - Best regards, Peter From ktilton at nyc.rr.com Thu May 26 20:21:55 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 26 May 2005 16:21:55 -0400 Subject: [cells-gtk-devel] Re: Cells-gtk In-Reply-To: <200505261612.48301.peter.denno@nist.gov> References: <42962137.4020204@nyc.rr.com> <200505261612.48301.peter.denno@nist.gov> Message-ID: <42962FE3.7020003@nyc.rr.com> Peter Denno wrote: >On Thursday 26 May 2005 15:19, Kenny Tilton wrote: > > >>It would be nice if the assertion were changed to something like: >> >> (assert cb () "whoa, callback ~a not defined in >>*widget-callbacks*" ',signal-slot) >> >> > >Agreed. I'll make this change. > > > Great, thx Peter. I know the information would be available in the backtrace, but it might also help to display right in the error message the symbol-package (tho I would not be surprised if that happens automatically). Fred, when your next 30min window opens let us know what the enhanced error shows. And try to see if there is a package or case-sensitivity thing going on. kt -- Cells? : http://www.common-lisp.net/project/cells/ Cello? : http://www.common-lisp.net/project/cello/ Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From peter.denno at nist.gov Thu May 26 20:52:59 2005 From: peter.denno at nist.gov (Peter Denno) Date: Thu, 26 May 2005 16:52:59 -0400 Subject: [cells-gtk-devel] Re: Cells-gtk In-Reply-To: <42962137.4020204@nyc.rr.com> References: <42962137.4020204@nyc.rr.com> Message-ID: <200505261652.59918.peter.denno@nist.gov> On Thursday 26 May 2005 15:19, Kenny Tilton wrote: > Fred Gilham wrote: > >Just FYI, I tried running cells-gtk under CMUCL and FreeBSD. ?I got it > >to compile by fiddling with the library pathnames in gtk-ffi.lisp and > >creating links in /usr/local/lib to all the necessary C libraries. The way we look for gtk libraries is quite flawed. It didn't even work on my system after a minor OS update. Does anyone here have ideas or examples of how to do this better? At the very least, I'll put a warning in INSTALL.TXT, and something in the FAQ. -- - Best regards, Peter From rm at seid-online.de Thu May 26 21:05:42 2005 From: rm at seid-online.de (rm at seid-online.de) Date: Thu, 26 May 2005 23:05:42 +0200 Subject: [cells-gtk-devel] Re: Cells-gtk] Message-ID: <20050526210542.GC29156@seid-online.de> On Thu, May 26, 2005 at 04:52:59PM -0400, Peter Denno wrote: > On Thursday 26 May 2005 15:19, Kenny Tilton wrote: > > Fred Gilham wrote: > > >Just FYI, I tried running cells-gtk under CMUCL and FreeBSD. ?I got it > > >to compile by fiddling with the library pathnames in gtk-ffi.lisp and > > >creating links in /usr/local/lib to all the necessary C libraries. > > > The way we look for gtk libraries is quite flawed. It didn't even work on my > system after a minor OS update. Does anyone here have ideas or examples of > how to do this better? Hmm, i can't speak for all OSs but at least for Linux and BSD one should _not_ provide a path to the call to dlopen (unless one really needs to load a library from a nonstandard place). Cheers Ralf Mattes > At the very least, I'll put a warning in INSTALL.TXT, and something in the > FAQ. > > -- > - Best regards, > Peter > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel ----- End forwarded message ----- From peter.denno at nist.gov Thu May 26 22:30:52 2005 From: peter.denno at nist.gov (Peter Denno) Date: Thu, 26 May 2005 18:30:52 -0400 Subject: [cells-gtk-devel] Re: Cells-gtk] In-Reply-To: <20050526210542.GC29156@seid-online.de> References: <20050526210542.GC29156@seid-online.de> Message-ID: <200505261830.52950.peter.denno@nist.gov> On Thursday 26 May 2005 17:05, rm at seid-online.de wrote: > On Thu, May 26, 2005 at 04:52:59PM -0400, Peter Denno wrote: > > On Thursday 26 May 2005 15:19, Kenny Tilton wrote: > > > Fred Gilham wrote: > > > >Just FYI, I tried running cells-gtk under CMUCL and FreeBSD. ?I got it > > > >to compile by fiddling with the library pathnames in gtk-ffi.lisp and > > > >creating links in /usr/local/lib to all the necessary C libraries. > > > > The way we look for gtk libraries is quite flawed. It didn't even work on > > my system after a minor OS update. Does anyone here have ideas or > > examples of how to do this better? > > Hmm, i can't speak for all OSs but at least for Linux and BSD one should > _not_ provide a path to the call to dlopen (unless one really needs to load > a library from a nonstandard place). Hi Ralf, Thanks. I think you mentioned this before, but now it is starting to sink in. It works (just loading "libglib-2.0.so" etc). So for linux/cmucl at least, we don't need all this searching for paths to the libraries. I'll need to check what lispworks and allegro are doing. For each of macosx and windows we look in only one place for the libraries. -- - Best regards, Peter From rm at seid-online.de Thu May 26 23:20:23 2005 From: rm at seid-online.de (rm at seid-online.de) Date: Fri, 27 May 2005 01:20:23 +0200 Subject: [cells-gtk-devel] Re: Cells-gtk] In-Reply-To: <200505261830.52950.peter.denno@nist.gov> References: <20050526210542.GC29156@seid-online.de> <200505261830.52950.peter.denno@nist.gov> Message-ID: <20050526232023.GD29156@seid-online.de> On Thu, May 26, 2005 at 06:30:52PM -0400, Peter Denno wrote: > On Thursday 26 May 2005 17:05, rm at seid-online.de wrote: > > On Thu, May 26, 2005 at 04:52:59PM -0400, Peter Denno wrote: > > > On Thursday 26 May 2005 15:19, Kenny Tilton wrote: > > > > Fred Gilham wrote: > > > > >Just FYI, I tried running cells-gtk under CMUCL and FreeBSD. ?I got it > > > > >to compile by fiddling with the library pathnames in gtk-ffi.lisp and > > > > >creating links in /usr/local/lib to all the necessary C libraries. > > > > > > The way we look for gtk libraries is quite flawed. It didn't even work on > > > my system after a minor OS update. Does anyone here have ideas or > > > examples of how to do this better? > > > > Hmm, i can't speak for all OSs but at least for Linux and BSD one should > > _not_ provide a path to the call to dlopen (unless one really needs to load > > a library from a nonstandard place). > > Hi Ralf, > > Thanks. I think you mentioned this before, but now it is starting to sink in. > It works (just loading "libglib-2.0.so" etc). So for linux/cmucl at least, we > don't need all this searching for paths to the libraries. > > I'll need to check what lispworks and allegro are doing. Well, i can't imagine that they don't use the "native" loader of the OS. Anything else would be asking for pain - but then, with Lispers you never know :-) > For each of macosx and windows we look in only one place for the libraries. Never worked with windows - i think on OSX it _would_ be possible to use a more generic loading, but that depends on the way a dll i set up (framework vs. Unix style dll). Cheers RalfD > > > -- > - Best regards, > Peter From ktilton at nyc.rr.com Fri May 27 00:13:20 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 26 May 2005 20:13:20 -0400 Subject: [cells-gtk-devel] Re: Cells-gtk] In-Reply-To: <200505261830.52950.peter.denno@nist.gov> References: <20050526210542.GC29156@seid-online.de> <200505261830.52950.peter.denno@nist.gov> Message-ID: <42966620.3060603@nyc.rr.com> Peter Denno wrote: >On Thursday 26 May 2005 17:05, rm at seid-online.de wrote: > > >>On Thu, May 26, 2005 at 04:52:59PM -0400, Peter Denno wrote: >> >> >>>On Thursday 26 May 2005 15:19, Kenny Tilton wrote: >>> >>> >>>>Fred Gilham wrote: >>>> >>>> >>>>>Just FYI, I tried running cells-gtk under CMUCL and FreeBSD. I got it >>>>>to compile by fiddling with the library pathnames in gtk-ffi.lisp and >>>>>creating links in /usr/local/lib to all the necessary C libraries. >>>>> >>>>> >>>The way we look for gtk libraries is quite flawed. It didn't even work on >>>my system after a minor OS update. Does anyone here have ideas or >>>examples of how to do this better? >>> >>> >>Hmm, i can't speak for all OSs but at least for Linux and BSD one should >>_not_ provide a path to the call to dlopen (unless one really needs to load >>a library from a nonstandard place). >> >> > >Hi Ralf, > >Thanks. I think you mentioned this before, but now it is starting to sink in. >It works (just loading "libglib-2.0.so" etc). So for linux/cmucl at least, we >don't need all this searching for paths to the libraries. > >I'll need to check what lispworks and allegro are doing. > >For each of macosx and windows we look in only one place for the libraries. > Oy, this discussion reminds me that I have been meaning to extend hello-c to Just Work(tm) on loading libraries. Back when Cello got ported to Linux, Frank Goenninger added a bunch of fancy code to Cello to get libraries loaded. I had the same thought then: let's do this in Hello-C, not Cello or Cells-Gtk. Gee, for once the Open Source fairy is whining at other people to do work for him. :) But seriously, please, whoever tackles this, put any fixes in Hello-C and send me what you do and I will commit it to Hello-C. thx, kenzo -- Cells? : http://www.common-lisp.net/project/cells/ Cello? : http://www.common-lisp.net/project/cello/ Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From peter.denno at nist.gov Fri May 27 03:06:56 2005 From: peter.denno at nist.gov (Peter Denno) Date: Thu, 26 May 2005 23:06:56 -0400 Subject: [cells-gtk-devel] Re: Cells-gtk] In-Reply-To: <42966620.3060603@nyc.rr.com> References: <20050526210542.GC29156@seid-online.de> <200505261830.52950.peter.denno@nist.gov> <42966620.3060603@nyc.rr.com> Message-ID: <200505262306.57404.peter.denno@nist.gov> On Thursday 26 May 2005 20:13, Kenny Tilton wrote: > >Hi Ralf, > > > >Thanks. I think you mentioned this before, but now it is starting to sink > > in. It works (just loading "libglib-2.0.so" etc). So for linux/cmucl at > > least, we don't need all this searching for paths to the libraries. > > > >I'll need to check what lispworks and allegro are doing. > > > >For each of macosx and windows we look in only one place for the > > libraries. > > Oy, this discussion reminds me that I have been meaning to extend hello-c > to Just Work(tm) on loading libraries. Back when Cello got ported to Linux, > Frank Goenninger added a bunch of fancy code to Cello to get libraries > loaded. I had the same thought then: let's do this in Hello-C, not Cello or > Cells-Gtk. > > Gee, for once the Open Source fairy is whining at other people to do work > for him. :):) But seriously, please, whoever tackles this, put any fixes in > Hello-C and send me what you do and I will commit it to Hello-C. But I am not adding fancy code, I am removing fancy code. It appears that our design was built on the faulty premise that we had to specify the full path to the library. At least on linux, (I've tested cmucl and lispworks so far) we don't have to. (Unless, as Ralf points out, it isn't one of the places the system looks for libraries). On macosx and win32 we always had a hard-coded path. We still do, but I moved that to the configuration file. It doesn't matter with win32 because the user presumably followed our directions to place the GTK libs where we want them. There isn't any new code in hello-c/uffi to make this happen. -- - Best regards, Peter From ktilton at nyc.rr.com Wed May 18 18:35:17 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 18 May 2005 14:35:17 -0400 Subject: [cells-gtk-devel] New Cells Use Case, comments welcome Message-ID: <428B8AE5.5000401@nyc.rr.com> Sorry for spaming all the groups, but the occasion (Cells doc) is rare enough I thought everyone should be included. From here on is a standalone example (with Cells loaded) that reads data from itself. It models tracking of an index of stocks. I plan a few more notes, but thought I would invite comments/requests for clarification now. Here goes: (in-package :cells) #| The deal is this: explanations of chunks of code appear /below/ them. Now here are Ron's functional requirements: process a stream of messages from an imagined source of financial data. Actually, Ron has an intermediate process reading a real source and producing a somewhat-digested stream in Lisp-friendly format. Sample: (:date 5123 :weekday 3) (:index ((AA 29.30 7.3894672) (AIG 53.30 7.3894672)(AXP 53.00 7.3894672) (BA 59.87 7.3894672) (C 46.80 7.3894672) (CAT 87.58 7.3894672) (DD 47.74 7.3894672) (DIS 26.25 7.3894672) (GE 36.10 7.3894672) (GM 27.77 7.3894672) (HD 36.75 7.3894672) (HON 35.30 7.3894672) (HPQ 21.00 7.3894672) (IBM 76.47 7.3894672) (INTC 23.75 7.3894672) (JNJ 68.73 7.3894672) (JPM 35.50 7.3894672) (KO 43.76 7.3894672) (MCD 29.80 7.3894672) (MMM 76.76 7.3894672) (MO 65.99 7.3894672) (MRK 34.42 7.3894672) (MSFT 25.36 7.3894672) (PFE 27.5 7.3894672) (PG 54.90 7.3894672) (SBC 23.8 7.3894672) (UTX 100.96 7.3894672) (VZ 36.75 7.3894672) (WMT 48.40 7.3894672) (XOM 56.50 7.3894672))) (:trade INTC 0.001932 :last 23.75) (:trade MSFT 0.001932 :last 25.36) (:trade INTC 0.011931 :last 23.75) (:trade MSFT 0.011931 :last 25.36) (:trade MSFT 0.041965 :last 25.32) (:trade UTX 0.067027 :last 101.39) ...etc... Date messages encode date as (+ (* (- year 2000) 1000) julian-days). Weekday is dicey, so the tutorial deduces the Lisp weekday and stores that. Index messages define which tickers are in the index and their weights. Entries are: (ticker-symbol initial-price index-weight) Trade messages are (ticker-symbol ticker-minute :LAST price) Ticker-minute is time since open, in minutes. Negative indicates pre-open trading. To get the ball rolling, we just want to print out each trade as received, with the addition of an indicator as to which way the price moved: -1, 0, or 1 for down, unchanged, or up. For the index, we want to track the minute of the last trade affecting the index, the weighted index value, and the last move of each index entry. |# (defparameter *trc-trades* t) #+test (run-trading-day) (defun run-trading-day () (cell-reset) (let ((*trc-trades* nil) (t-day (make-be 'trading-day))) ;; - always call CELLS-RESET when starting a test run ;; - (make-be ...) -> (to-be (make-instance ...)) ;; - TO-BE jumpstarts a Cells instance into the flow. (FN to-be) #+not (with-open-file (t-data (make-pathname :directory '(:absolute "0dev" "cells" "Use Cases" "dow-jones") :name "stock-exchange" :type "lisp")) (with-metrics (nil t "run-trading-day") (loop for message = (read t-data nil :eof) until (eq message :eof) do (setf (message t-day) message))) ) (with-open-file (t-data (make-pathname :directory '(:absolute "0dev" "cells" "Use Cases" "dow-jones") :name "stock-exchange" :type "lisp")) (with-metrics (t t "run-trading-day") (loop with in-data = nil do (if (not in-data) (setf in-data (msg-start (read-line t-data nil :eof))) (let ((message (read t-data nil :eof))) (count-it :dow-message) (if (eql (car message) :close) (loop-finish) (setf (message t-day) message))))))) (trc "index value = " (value (car (indexes t-day)))))) ;; --- trading day --------------------------------- ;; (defmodel trading-day () ((message :initarg :message :accessor message :initform (c-in nil) ;; c-in -> c-input, how data enters a model (see FN c-input) :cell :ephemeral) ;; handling transient phenomena in a steady-state paradigm (FN ephemeral) (date :initarg :date :accessor date :initform (c? (or .cache ;; advanced trick using prior value (see FN date/.cache) (when (eql :date (car (^message))) (destructuring-bind (&key date weekday) (^message) (declare (ignore weekday)) ;; derive from date (encode-julian-date (+ 2000 (floor date 1000)) (mod date 1000))))))) (weekday :initarg :weekday :accessor weekday :initform (c? (when (^date) (multiple-value-bind (second minute hour date month year day daylight-p zone) (decode-universal-time (^date)) (declare (ignorable second minute hour date month year daylight-p zone)) day)))) ;; not much new here, but astute readers will wonder if this cell gets optimized away ;; when (^date) on its second evaluation uses its .cache and gets optimized away. ;; ;; yes. Just checked to be sure. (trade :cell :ephemeral :initarg :trade :accessor trade :initform (c? (when (eql :trade (car (^message))) (message-to-trade (^message))))) ;; ;; nothing new here, but note that again we use the :ephemeral option ;; (indexes :initarg :indexes :accessor indexes :initform (c? (with-c-cache ('cons) (when (eql :index (car (^message))) (make-be 'index :trading-day self :index-def (second (^message))))))) (tickers :cell nil :reader tickers :initform (make-hash-table :rehash-size 50)) )) (def-c-output trade ((self trading-day) trade) ;; FN def-c-output (when trade ;; FN trade setf optimization (push trade (trades (ensure-ticker self (trade-ticker-sym trade)))))) (defun trading-day-ticker (day sym) (gethash sym (tickers day))) (defun (setf trading-day-ticker) (ticker day sym) (setf (gethash sym (tickers day)) ticker)) (defun ensure-ticker (trading-day ticker-sym &optional price minute) (or (trading-day-ticker trading-day ticker-sym) (setf (trading-day-ticker trading-day ticker-sym) (make-be 'ticker :ticker-sym ticker-sym :trades (c-in (when price (list (make-trade :ticker-sym ticker-sym :minute minute :price price)))))))) (defmodel ticker (model) ((ticker-sym :cell nil :initarg :ticker-sym :reader ticker-sym) (trades :initarg :trades :accessor trades :initform (c-in nil)) (last-move :reader last-move :initform (c? (bwhen (penult-trade (second (^trades))) (let ((last (trade-price (first (^trades)))) (penult (trade-price penult-trade))) (cond ((< last penult) -1) ((= last penult) 0) (t 1))))) :documentation "Price up, down, or unchanged as 1, -1, or zero"))) ;; ;; Small point: there is no problem with accessing a dependency twice, as above. ;; (defun ticker-price (ticker) (bwhen (trade (car (trades ticker))) (trade-price trade))) (defun ticker-trade-minute (ticker) (bwhen (trade (car (trades ticker))) (trade-minute trade))) (def-c-output trades ((self ticker)) ;; FN trades def-c-output (when *trc-trades* (loop for trade in (set-difference new-value old-value) do (format t "~&at ~a min, ~a at ~a, change ~a" (trade-minute trade) (ticker-sym self) (trade-price trade) (or (^last-move) ""))))) ;; --- index --------------------------------------------------- (defmodel index () ((index-def :cell nil :initarg :index-def :initform nil :accessor index-def) (trading-day :cell nil :initarg :trading-day :initform nil :accessor trading-day) (ticker-weights :initarg :ticker-weights :accessor ticker-weights :initform (c? (loop for (ticker-sym price weight) in (index-def self) collecting (cons (ensure-ticker (trading-day self) ticker-sym price -60) ;; whoa, a mid-rule to-be! (FN ticker-weights rule) weight)))) (state :reader state :initform (let ((moves (make-hash-table :size 50))) (c-formula (:lazy t) ;; do not re-compute on every trade (see FN lazy) (count-it :index-state-calc) (clrhash moves) ;; Re-use OK since fresh cons triggers dataflow (FN state rule) (let ((minutes (loop for (ticker . nil) in (ticker-weights self) maximizing (ticker-trade-minute ticker)))) (without-c-dependency ;; dependency on trade minute suffices (see FN without-c-dependency) (loop for (ticker . weight) in (ticker-weights self) summing (* weight (ticker-price ticker)) into value do (setf (gethash (ticker-sym ticker) moves) (last-move ticker)) finally (return (list minutes value moves)))))))) (value :reader value :initform (c? (second (^state)))) ;; ;; allows dependency on just value, which will not change on unchanged trades (FN value cell) )) (defun index-minutes (index) (first (state index))) (defun index-moves (index) (third (state index))) (defun index-ticker-sym-move (index ticker-sym) (gethash ticker-sym (index-moves index))) (defun index-ticker-move (index ticker) (index-ticker-sym-move index (ticker-sym ticker))) (def-c-output value ((self index)) (when *trc-trades* (trc "index time:" (index-minutes self) :value new-value :was old-value))) ;;; --- trade --------------------------------------------------------------------- (defstruct trade minute ticker-sym price) (defun message-to-trade (message) (destructuring-bind (ticker-sym ticker-min &key last) (rest message) (make-trade :ticker-sym ticker-sym :minute ticker-min :price last))) ;;; --- utilities --------------------------------------------------------- (defun encode-julian-date (year julian) (+ (encode-universal-time 0 0 0 1 1 year ) (* (1- julian) 86400))) ;; seconds in a day ;; I am sorry, that is all there is to tell. So we have a mindless main loop and a few declarations ;; and somehow we get all the functionality desired. [OK, granted, this is a pretty simple ;; batch process which would not be too complicated in non-Cells form. In that regard, it ;; is a good tutorial use case but does not show off Cells very much.] Anyway... ;; ;; It occurs to me that the above notes do not convey how the damn thing works. So let us walk ;; thru a hand-execution of the above sample data. ;; ;; (make-be 'trading-day) -> (to-be (make-instance 'trading-day)) ;; ;; Each ruled Cell gets evaluated. Each Cell slot -- constant, input, or ruled -- is output. ;; So with trading-day: ;; ;; message is input, and has no associated output function ;; ;; date is evaluated: ;;; (or .cache ;;; (when (eql :date (car (^message))) ;;; (destructuring-bind (&key date weekday) ;;; (^message) ;;; (declare (ignore weekday)) ;; derive from date ;;; (encode-julian-date (+ 2000 (floor date 1000)) (mod date 1000))))) ;; ;; .cache is nil, but so is (message self). NIL is returned, there is no output. ;; date now has a dependency on message. ;; ;; weekday is evaluated ;;; (c? (when (^date) ;;; (multiple-value-bind (second minute hour date month year day daylight-p zone) ;;; (decode-universal-time (^date)) ;;; (declare (ignorable second minute hour date month year daylight-p zone)) ;;; day)))) ;; date is nil, so weekday is NIL but has a dependency on date. No output is defined. ;; ;; trade is evaluated ;;; (c? (when (eql :trade (car (^message))) ;;; (message-to-trade (^message))))) ;; message is NIL, so NIL is returned. trade now has a dependency on message. The output ;; method on trade is invoked, but has no interest in NIL new values. ;; ;; indexes is evaluated: ;;; (with-c-cache ('cons) ;;; (when (eql :index (car (^message))) ;;; (make-be 'index ;;; :trading-day self ;;; :index-def (second (^message))))))) ;; message is NIL, so NIL is returned, a dependency on message created. No output defined. ;; ;; (setf (message t-day) ) ;; ;; Many rules are dispatched: date, trade, and indexes. Only date processes :date messages. ;; it returns a converted date, and still has a dependency on message. Weekday has a dependency ;; on date, so that rule gets dispatched. It returns a weekday calculated off the date, and ;; keeps the dependency on that. Other rules return ;; NIL, which is the same value they had before. Nothing else is done (and in this case, that ;; would only have been to call the output method on trade. ;; ;; (setf (message t-day) ) ;; ;; The date rule runs and returns its .cache without accessing any cell. The Cell internals ;; optimize away the fact that date ever had a rule or any kind of cell. It sees weekday ;; was a dependent on date and nothing else, so it optimizes that away, too. Slots end up ;; with the last values calculated, and now look to other rules as if they were constant ;; all along. ;; ;; The trade rule runs and comes up empty again. The indexes rule runs and adds a new ;; index list to its current contents, which happens to be NIL. ;; ;;;; make-be is called on the index instance. Each slot gets processed in turn in a ;;;; fashion similar to that for trading-day. When the ticker-weights rule runs, ticker ;;;; instances for each ticker in the index are created and passed to TO-BE, in the ;;;; function ensure-ticker. No dependencies are created since index-def is not a Cell, ;;;; so the ticker-weights cell gets optimized away. ;;;; ;;;; as each ticker is created and processed by TO-BE: ;;;;;;; ;;;; the state rule is evaluated and computes an initial index state off the data ;;;; provided in the index-def. state ends up with dependencies on each ticker in the ;;;; index. ;; [rest under construction] ;; ;;; ============================================================================= ;;; Footnotes ;;; ============================================================================= ; ;; --- FN to-be -------------------------------------- ;; TO-BE jumpstarts a Cells instance into the flow. Literally, as in ;; the dataflow. It evaluates ruled slots to establish dependencies (those ;; get established during evaluation) and in turn arrange for state change ;; within the model to propagate to the instance's ruled Cells. It also ;; DEF-C-OUTPUTs all cell slots so the outside world is consistent ;; with the model state. More on def-c-output below. ; ;; --- FN c-input ------------------------------------ ;; ;; c-in is short for c-input, which simply means imperative application code ;; can SETF this slot. (Note that this is just the initform for this slot, ;; which can be overridden by subclasses or at make-instance time, and if ;; the override is not another C-IN or C-INPUT, then all bets are off. ie, The ;; SETF ability depends on the type of Cell (if any) associated at run-time ;; with the slot of an instance. It ;; is not an attribute of the slot as with the :cell slot option discussed just below. ;; ;; Anyway, C-IN lets us make a lot of points about Cells. ;; ;; First, no model is ;; an island; the dataflow has to start somewhere. Just as a VisiCalc spreadsheet ;; has cells where you can type, say, different interest rates to see how that ;; effects the rest of a financial model, a Cell-based application model needs ;; some way to interface with the outside world, if only the mouse and keyboard ;; of a GUI application. ;; ;; The way we do that is by having conventional application code feed (SETF) data into ;; the dataflow model at what we call cell inputs. In a typical GUI app, this means ;; having callbacks registered with the window manager. The callbacks then take their ;; arguments (window events such as mouse-downs and key-presses) and setf that ;; info to slots of a window or system instance modelling the window or operating ;; system, slots mediated by c-input Cells. ;; ;; In this simple use case we have just one stream of external inputs (messages ;; from some financial data service) being SETFed into one slot, the message ;; slot of an instance of the trading-day class. ;; ;; Second, the Cells design enforces discipline. So in case you are ;; wondering, no, if you do not bind a C-INPUT to a slot of an instance, you cannot ;; SETF that slot from imperative code. (Aside: (SETF SLOT-VALUE) /is/ a back door ;; allowing you to wreak havoc on your dataflow model if you so choose (but it will ;; wreak havoc).) ;; ;; Third, you might wonder why slots meant as inputs cannot just have no Cell at all ;; associated with them at run-time, and then have the Cell internals accept that ;; as a SETF-able state. Well, it is a long story, but it turns out that a lot of ;; Cells overhead can be avoided if we distinguish a slot whose value will never ;; change from an input slot which will be SETF'ed. A simple example of a constant ;; slot would be the bounding rectangle of a push button. Those values have to be ;; Cells because in other graphical elements sharing the same superclass, the bounding ;; rectangle changes. A good example is the win32-style scroll bar thumb, which changes ;; size to reflect how much of the total file is visible. Anyway, it turns out that ;; a significant performance boost comes from having Cells which happen to access ;; a constant value not record a dependency on that value and, where a rule evaluation ;; turns out not to access any non-constant other Cell slot, likewise convert the ruled ;; slot into a constant slot. Sorry you asked? ;; ;; --- FN ephemeral ----------------------------------------------------------- ;; ;; Whoa, here is an advanced topic. Ephemeral means "fleeting". Before getting into ;; that, the other options for the :cell option are T and NIL. T is the default. ;; NIL means you get a normal slot having nothing to do with Cells. Now about ;; that :ephemeral option: Messages are ;; like events: they happen, then they are no more. This is a problem for ;; Cells, which like a VisiCalc spreadsheet model (say, your household budget) ;; is all about steady-state occasionally perturbed by inputs. That is vague. ;; Here is a concrete example: suppose you have some game where the user has ;; to press a key when two randomly moving shapes overlap. You will have a hit rule ;; that says (abbreviated somewhat): ;; ;; (and (eql (event *sys*) :keypress) (shapes-overlap-p *sys*)) ;; ;; OK, the key is pressed but the shapes do not overlap. No cigar. Now a few ;; seconds later the shapes do overlap. The key is not being pressed, but the ;; EVENT slot of the *sys* instance (modelling the computer system) still ;; says :keypress. bad news. Obviously we need to process an event and then ;; clear the value before processing any other model input. Now perhaps we could ;; simply have imperative code which says: ;; ;; (setf (event *sys*) :keypress) ;; (setf (event *sys*) nil) ;; ;; But that is different. That suggests an application semantic in which the ;; EVENT slot changes from :keypress to NIL. It will trigger all the usual ;; dataflow, to see if the model should react. But in fact what we /really/ ;; need is /not/ to clear the EVENT slot. What we really need is ;; ephemeral SETF behavior from a mechanism designed for steady-state. ;; We need the EVENT slot to take on a value just long enough to perturb our ;; model and then cease to be without fanfare. ;; ;; So we extend the Cells model with the :ephemeral option on a slot, and have ;; Cell internals watch out for that and silently clear the slot once a value ;; has been propagated to other Cells and output (again, outputs ;; are discussed below.) ;; ;; A final newbie note: watch the bouncing options. Ephemerality is a slot option, ;; not something one tailors to the instance. Think about it. Think about the ;; slot names. "message", "event". We want to get ephemeral behavior for these ;; slots no matter what cell (input or ruled) we choose to associate with them. ;; So it is more convenient and reliable to endow the slot itself with ephemerality. ;; in other cases we see different instances enjoying different Cell-ish qualities ;; for the same slot, sometimes constant, sometimes computed, sometimes being ;; SETFed by imperative code outside the dataflow model. These variations are ;; then found in the type of runtime Cell associated with the Cell slot. ;; ;; --- FN date/.cache -------------------------------------------------- ;; ;; ;; There is a lot going on here, too, including some premature optimization. ;; ;; First of all, .cache is just a local variable, bound by the expansion ;; of the C? macro to the latest value calculated for this rule. It starts out as NIL, so ;; the rule next reads the message slot of the same trading-day instance. How so? ;; ;; ^message is a macro written by the defmodel macro. It expands simply to: ;; ;; (message self) ;; ;; It used to expand to more, including vital Cell plumbing. Now I keep it around just ;; because I love that self-documenting quality. And yes, I have adopted the ;; Smalltalk "self" convention over the C++ "this" convention. There is no need ;; to use these (^macros), just code ( self) and you will establish a ;; dependency on the message slot. What does dependency mean? ;; ;; Simply that the next time the message slot changes (the default test between old and ;; new values is EQL, but can be overridden), the Cells engine will immediately kick ;; the DATE rule to see if it wants to compute a different value. ;; ;; A very important point is that dependencies are established automatically simply ;; by invoking the reader or accessor associated with a slot, and that this happens ;; dynamically at run-time, not by inspection of code. A second point is that the ;; dependency is established even if the read takes place in a called function. ;; ;; There is a backdoor. No dependencies are established in code wrapped by ;; the macro WITHOUT-C-DEPENDENCY. ;; ;; Another important point is that dependencies are re-decided completely each time ;; a rule is invoked. So this particular rule is an oddball: it will produce only one value, when a :date ;; message is received ;; and teh first non-NIL value is returned. On the next message (of any kind) .cache will be ;; non-NIL and the rule will simply return that value. ;; During this last evaluation the cell will not access, hence no longer ;; depend on, the message slot or any other slot and it will get optimized away. This ;; improves performance, since the message slot no longer bothers propagating to ;; the date slot and Cell internals no longer have to invoke the rule. Otherwise, every ;; new message for the entire day (none of which would be :date messages) would kick ;; off this rule. ;; ;; --- FN with-c-cache ------------------------------------ ;; ;; I am actually doing something new here. The idea is that again we deviate ;; slightly from the spreadsheet paradigm and want to accumulate data ;; from a stream of ephemeral values. Normally we calculate a slot value in ;; its entirety from data at hand, even if only ephemerally. Here we want ;; to add a newly computed result to a list of prior such results. ;; ;; with-c-cache will accept any two-argument function, and when the enclosed ;; form returns a non-nil value, pass that and the .cache to the specified ;; function. ;; ;; --- FN def-c-output -------------------------------------------- ;; ;; Above is another optimization, and the long-awaited discussion of Cell ;; output. ;; ;; Output reinforces the "no model is an island" theme. We create ;; models to obtain interesting outputs from inputs, where the model ;; provides the interest. For a RoboCup player simulation, the inputs are ;; sensory information about the game, provided in a stream from a server ;; application managing multiple client players and coaches. The outputs are ;; messages to the server indicating player choices about turning, running, ;; and kicking. In between, the game play model is supposed to compute ;; actions producing more or less capable soccer play. ;; ;; --- FN trade setf optimization --------------------------------------- ; ;; But this is strange "output". It actually changes internal model state. ;; It is no output at all, just feeding dataflow back into a different ;; model input. Whassup? ;; ;; Like I said, it is an optimization. A ticker instance could have a ;; rule which watched the message stream looking for trades on that ticker, ;; but then every ticker would be watching the message stream. ;; ;; Instead, we simply leverage an "output" method to procedurally decide which ;; ticker has been traded and directly add the trade to that ticker's list ;; of trades. ;; ;; --- FN trades def-c-output -------------------------------------- ;; ;; Now the above is a proper output. Merely a print trace to standard output, but ;; that happens to be all the output we want just now. In a real trading application, ;; there probably would not be an output on this slot. Some gui widget might "output" ;; by telling the OS to redraw it, or some trader instance might decide to output ;; a buy order to an exchange, but that is about it. ;; ;; --- FN ticker-weights rule -------------------------------------- ;; ;; A curiosity here is that ensure-ticker will often be making and to-be-ing new model ;; instances while this rule is running. No problem, though it would be possible to ;; get into trouble if such destructive (well, constructive) operations triggered ;; dataflow back to this same rule. Here we are safe; it does not. In fact... ;; ;; This rule runs once and then gets optimized away, because in this simple case ;; index-def is a constant, not even a cell. Should we someday want to handle ;; changes to an index during a trading-day, this would have to change. ;; ;; --- FN lazy ------------------------------------------------------ ;; ;; Lazy ruled cells do not get calculated until someone asks their value, ;; and once they are evaluated and dependencies have been established, ;; they merely will be flagged "obsolete" should any of those dependencies ;; change in value. ;; ;; --- FN state rule ------------------------------------------------ ;; ;; c? ends up wrapping its body in a lambda form which becomes the rule for this ;; slot, and here that lambda form will close over the MOVES hash-table. Neat, eh? ;; What is going on is that we do not anticipate in the application design that ;; any cell will depend in isolation on the move of one ticker in the index. So ;; we can allocate just one hashtable at make-instance time and reuse that each ;; time the rule gets evaluated. Cells depending on the state Cell will know ;; when that aggregate value gets recomputed because the finally clause conses ;; up a new list each time. ;; ;; --- FN without-c-dependency ------------------------------------- ;; ;; [to be written] ;; ;; --- FN value Cell -------------------------------------------------- ;; ;; Weird, right? Well, we noticed that many trades came thru at the same price ;; sequentially. The rule above for STATE gets kicked off on each trade, and the ;; index gets recomputed. Because it is an aggregate, we get a new list for state ;; even if the trade was at an unchanged priced and the index value does not change. ;; ;; Now suppose there was some BUY! rule which cared only about the index value, and not ;; the latest minute traded of that value, which /would/ change if a new trade at ;; an unchanged price were received. Because a new list gets consed up (never mind the ;; new trade minute), The BUY! rule would get kicked off because of the new list in the ;; the STATE slot. Not even overriding the default EQL test with EQUAL would work, ;; because the trade minute would have changed. ;; ;; What to do? The above. Let VALUE get recalculated unnecessarily and return unchanged, ;; then code the BUY! rule to use VALUE. VALUE will get kicked off, but not BUY!, which ;; would likely be computationally intense. ;; #| TRADEDATA (:date 5123 :weekday 3) (:index ((AA 29.30 7.3894672) (AIG 53.30 7.3894672)(AXP 53.00 7.3894672) (BA 59.87 7.3894672) (C 46.80 7.3894672) (CAT 87.58 7.3894672) (DD 47.74 7.3894672) (DIS 26.25 7.3894672) (GE 36.10 7.3894672) (GM 27.77 7.3894672) (HD 36.75 7.3894672) (HON 35.30 7.3894672) (HPQ 21.00 7.3894672) (IBM 76.47 7.3894672) (INTC 23.75 7.3894672) (JNJ 68.73 7.3894672) (JPM 35.50 7.3894672) (KO 43.76 7.3894672) (MCD 29.80 7.3894672) (MMM 76.76 7.3894672) (MO 65.99 7.3894672) (MRK 34.42 7.3894672) (MSFT 25.36 7.3894672) (PFE 27.5 7.3894672) (PG 54.90 7.3894672) (SBC 23.8 7.3894672) (UTX 100.96 7.3894672) (VZ 36.75 7.3894672) (WMT 48.40 7.3894672) (XOM 56.50 7.3894672))) (:trade INTC 0.001932 :last 23.75) (:trade MSFT 0.001932 :last 25.36) (:trade INTC 0.011931 :last 23.75) (:trade MSFT 0.011931 :last 25.36) (:trade MSFT 0.041965 :last 25.32) (:trade UTX 0.067027 :last 101.39) (:trade INTC 0.067062 :last 23.82) (:trade MSFT 0.070397 :last 25.37) (:trade INTC 0.070397 :last 23.82) (:trade MSFT 0.074167 :last 25.32) (:trade INTC 0.081800 :last 23.83) (:trade MSFT 0.097178 :last 25.33) (:trade MSFT 0.106488 :last 25.32) (:trade INTC 0.110410 :last 23.82) (:trade INTC 0.124263 :last 23.83) (:trade MSFT 0.130411 :last 25.33) (:trade INTC 0.143792 :last 23.81) (:trade MSFT 0.143792 :last 25.33) (:trade DIS 0.150441 :last 26.25) (:trade INTC 0.160480 :last 23.82) (:trade MSFT 0.160480 :last 25.33) (:trade HPQ 0.166767 :last 21.00) (:trade INTC 0.178832 :last 23.82) (:trade MSFT 0.183710 :last 25.33) (:trade DIS 0.187167 :last 26.25) (:trade AIG 0.193117 :last 53.60) (:trade INTC 0.196399 :last 23.81) (:trade PFE 0.200523 :last 27.51) (:trade MSFT 0.200523 :last 25.33) (:trade GE 0.202185 :last 36.11) (:trade MSFT 0.207199 :last 25.37) (:trade BA 0.209810 :last 59.75) (:trade INTC 0.210524 :last 23.83) (:trade MSFT 0.230556 :last 25.37) (:trade INTC 0.230556 :last 23.83) (:trade BA 0.234812 :last 59.76) (:trade MSFT 0.240580 :last 25.37) (:trade INTC 0.247233 :last 23.83) (:trade MSFT 0.256892 :last 25.37) (:trade UTX 0.257729 :last 101.33) (:trade GE 0.261942 :last 36.11) (:trade AIG 0.267072 :last 53.60) (:trade MSFT 0.272956 :last 25.36) (:trade INTC 0.275617 :last 23.83) (:trade WMT 0.280660 :last 48.40) (:trade SBC 0.284975 :last 23.78) (:trade GE 0.289229 :last 36.10) (:trade MSFT 0.292285 :last 25.35) (:trade DIS 0.295646 :last 26.30) (:trade HPQ 0.303630 :last 21.04) (:trade IBM 0.305629 :last 76.60) (:trade INTC 0.307321 :last 23.81) (:trade INTC 0.310671 :last 23.81) (:trade SBC 0.316331 :last 23.76) (:trade AIG 0.322292 :last 53.60) (:trade MSFT 0.324057 :last 25.36) (:trade MCD 0.324057 :last 29.79) (:trade UTX 0.325694 :last 101.15) (:trade INTC 0.327348 :last 23.81) (:trade IBM 0.336878 :last 76.60) (:trade MSFT 0.342414 :last 25.37) (:trade MSFT 0.345710 :last 25.37) (:trade HD 0.346983 :last 36.82) (:trade BA 0.347295 :last 59.80) (:trade MCD 0.360765 :last 29.80) (:trade HPQ 0.364067 :last 21.03) (:trade MSFT 0.364067 :last 25.37) (:trade SBC 0.367409 :last 23.79) (:trade MSFT 0.392928 :last 25.36) (:trade AIG 0.407453 :last 53.55) (:trade HPQ 0.407533 :last 21.03) (:trade SBC 0.407533 :last 23.79) (:trade MSFT 0.407533 :last 25.36) (:trade INTC 0.407533 :last 23.82) (:trade HPQ 0.407533 :last 21.03) (:trade HD 0.407545 :last 36.84) (:trade BA 0.413185 :last 59.80) (:trade INTC 0.414117 :last 23.81) (:trade PFE 0.420796 :last 27.51) (:trade DIS 0.424120 :last 26.30) (:trade AIG 0.424654 :last 53.58) (:trade INTC 0.427471 :last 23.81) (:trade XOM 0.429865 :last 56.85) (:trade IBM 0.431927 :last 76.65) (:trade HPQ 0.432407 :last 21.04) (:trade HD 0.432507 :last 36.84) (:trade MCD 0.439207 :last 29.80) (:trade MSFT 0.442518 :last 25.36) (:trade DIS 0.442518 :last 26.30) (:trade MSFT 0.453747 :last 25.36) (:trade PFE 0.458821 :last 27.52) (:trade IBM 0.459026 :last 76.66) (:trade HON 0.467342 :last 35.36) (:trade XOM 0.469083 :last 56.88) (:trade INTC 0.470871 :last 23.80) (:trade SBC 0.476712 :last 23.79) (:trade BA 0.476730 :last 59.80) (:trade MCD 0.479248 :last 29.80) (:trade HPQ 0.479248 :last 21.03) (:trade AIG 0.480883 :last 53.57) (:trade MSFT 0.482567 :last 25.36) (:trade INTC 0.482567 :last 23.80) (:trade IBM 0.484223 :last 76.73) (:trade MSFT 0.494243 :last 25.36) (:trade AIG 0.497551 :last 53.57) (:trade PFE 0.497569 :last 27.53) (:trade INTC 0.504245 :last 23.80) (:trade HD 0.504660 :last 36.84) (:trade IBM 0.504849 :last 76.73) (:trade GM 0.507621 :last 30.53) (:trade SBC 0.511484 :last 23.79) (:trade HPQ 0.514265 :last 21.04) (:trade HD 0.514798 :last 36.85) (:trade MSFT 0.517601 :last 25.32) (:trade WMT 0.524286 :last 48.46) (:trade IBM 0.524286 :last 76.74) (:trade INTC 0.529220 :last 23.80) (:trade HPQ 0.536813 :last 21.04) (:trade PG 0.537627 :last 54.91) (:trade PFE 0.540979 :last 27.54) (:trade INTC 0.544290 :last 23.80) (:trade PG 0.547549 :last 54.91) (:trade XOM 0.547624 :last 56.85) (:trade HON 0.547687 :last 35.40) (:trade UTX 0.550986 :last 101.33) (:trade HD 0.555694 :last 36.85) (:trade MSFT 0.560792 :last 25.35) (:trade INTC 0.564337 :last 23.80) (:trade XOM 0.566779 :last 56.85) (:trade BA 0.567359 :last 59.81) (:trade HON 0.581023 :last 35.41) (:trade INTC 0.589796 :last 23.80) (:trade BA 0.596050 :last 59.80) (:trade CAT 0.612134 :last 87.83) (:trade WMT 0.618386 :last 48.44) (:trade INTC 0.620474 :last 23.80) (:trade MCD 0.624417 :last 29.80) (:trade MSFT 0.627748 :last 25.35) (:trade BA 0.630881 :last 59.83) (:trade AIG 0.634410 :last 53.56) (:trade MCD 0.637785 :last 29.79) (:trade HON 0.637785 :last 35.40) (:trade INTC 0.649577 :last 23.79) (:trade BA 0.655889 :last 59.85) (:trade HD 0.662287 :last 36.83) (:trade AIG 0.669431 :last 53.53) (:trade HON 0.671133 :last 35.44) (:trade MCD 0.674457 :last 29.79) (:trade MO 0.683443 :last 66.20) (:trade INTC 0.687668 :last 23.79) (:trade MSFT 0.691181 :last 25.35) (:trade PFE 0.694477 :last 27.54) (:trade MSFT 0.720936 :last 25.35) (:trade GM 0.726237 :last 30.50) (:trade WMT 0.730056 :last 48.40) (:trade IBM 0.740544 :last 76.74) (:trade PG 0.744569 :last 54.91) (:trade HON 0.752103 :last 35.46) (:trade CAT 0.753014 :last 87.85) (:trade MO 0.763918 :last 66.20) (:trade MSFT 0.764592 :last 25.35) (:trade HON 0.771289 :last 35.46) (:trade BA 0.772935 :last 59.75) (:trade JPM 0.773229 :last 35.51) (:trade MSFT 0.774612 :last 25.35) (:trade PG 0.776267 :last 54.91) (:trade AIG 0.781168 :last 53.54) (:trade HD 0.782946 :last 36.87) (:trade CAT 0.784614 :last 87.85) (:trade XOM 0.786285 :last 56.88) (:trade MSFT 0.792950 :last 25.36) (:trade UTX 0.794689 :last 101.40) (:trade INTC 0.797969 :last 23.78) (:trade IBM 0.801301 :last 76.74) (:trade HD 0.809652 :last 36.87) (:trade JPM 0.809652 :last 35.51) (:trade MSFT 0.811489 :last 25.37) (:trade MO 0.812994 :last 66.20) (:trade IBM 0.816563 :last 76.75) (:trade MCD 0.828046 :last 29.77) (:trade UTX 0.829055 :last 101.37) (:trade MSFT 0.833420 :last 25.36) (:trade GM 0.837650 :last 30.50) (:trade IBM 0.838004 :last 76.75) (:trade HON 0.838531 :last 35.47) (:trade XOM 0.841372 :last 56.88) (:trade MCD 0.841894 :last 29.78) (:trade KO 0.853202 :last 43.98) (:trade UTX 0.858235 :last 101.38) (:trade INTC 0.864331 :last 23.82) (:trade PFE 0.869104 :last 27.55) (:trade HON 0.873063 :last 35.48) (:trade IBM 0.873095 :last 76.77) (:trade HD 0.873132 :last 36.87) (:trade XOM 0.884796 :last 56.86) (:trade UTX 0.884820 :last 101.38) (:trade HON 0.888886 :last 35.48) (:trade INTC 0.891420 :last 23.81) (:trade CAT 0.895715 :last 87.86) (:trade MO 0.898111 :last 66.19) (:trade XOM 0.898111 :last 56.87) (:trade IBM 0.899775 :last 76.78) (:trade BA 0.899775 :last 59.83) (:trade MSFT 0.901469 :last 25.38) (:trade HD 0.906673 :last 36.86) (:trade HPQ 0.908113 :last 21.03) (:trade CAT 0.916467 :last 87.85) (:trade BA 0.916467 :last 59.83) (:trade MSFT 0.918773 :last 25.38) (:trade PFE 0.926271 :last 27.57) (:trade MO 0.926288 :last 66.18) (:trade WMT 0.929791 :last 48.40) (:trade KO 0.932333 :last 43.98) (:trade JNJ 0.933224 :last 68.15) (:trade PG 0.936516 :last 54.91) (:trade INTC 0.938989 :last 23.81) (:trade IBM 0.942596 :last 76.78) (:trade XOM 0.944052 :last 56.89) (:trade INTC 0.944885 :last 23.81) (:trade BA 0.946486 :last 59.85) (:trade IBM 0.958178 :last 76.78) (:trade INTC 0.959853 :last 23.81) (:trade JPM 0.959897 :last 35.50) (:trade WMT 0.961498 :last 48.40) (:trade MCD 0.963195 :last 29.77) (:trade HPQ 0.966525 :last 21.03) (:trade AIG 0.968663 :last 53.54) (:trade XOM 0.978210 :last 56.89) (:trade AIG 0.979896 :last 53.55) (:trade CAT 0.979896 :last 87.85) (:trade MCD 0.984732 :last 29.77) (:trade PG 0.985307 :last 54.90) (:trade WMT 0.995716 :last 48.41) (:trade MSFT 1.005256 :last 25.38) (:trade PFE 1.005256 :last 27.55) (:trade JPM 1.008448 :last 35.48) (:trade CAT 1.011343 :last 87.86) (:trade XOM 1.011825 :last 56.88) (:trade INTC 1.012667 :last 23.79) (:trade JNJ 1.018655 :last 68.15) (:trade KO 1.021589 :last 43.99) (:trade INTC 1.026597 :last 23.78) (:trade HD 1.029577 :last 36.85) (:trade MSFT 1.029936 :last 25.39) (:trade JPM 1.033267 :last 35.49) (:trade C 1.064996 :last 46.80) (:trade CAT 1.065946 :last 87.85) (:trade MCD 1.066687 :last 29.75) (:trade MRK 1.066687 :last 34.33) (:trade PFE 1.066687 :last 27.55) (:trade INTC 1.066687 :last 23.79) (:trade INTC 1.066687 :last 23.79) (:trade XOM 1.068360 :last 56.88) (:trade JPM 1.068360 :last 35.49) (:trade XOM 1.068360 :last 56.89) (:trade KO 1.068360 :last 43.99) (:trade MRK 1.070274 :last 34.34) (:trade HON 1.073312 :last 35.49) (:trade PFE 1.080025 :last 27.55) (:trade MCD 1.080025 :last 29.75) (:trade INTC 1.080025 :last 23.79) (:trade AIG 1.083337 :last 53.55) (:trade GM 1.083420 :last 30.55) (:trade XOM 1.086739 :last 56.89) (:trade HON 1.093425 :last 35.49) (:trade HPQ 1.093425 :last 21.03) (:trade INTC 1.093425 :last 23.79) (:trade MSFT 1.093425 :last 25.37) (:trade JPM 1.098339 :last 35.49) (:trade IBM 1.099113 :last 76.86) (:trade XOM 1.104257 :last 56.89) (:trade MCD 1.104268 :last 29.74) (:trade GE 1.108379 :last 36.14) (:trade MSFT 1.108408 :last 25.40) (:trade XOM 1.115052 :last 56.89) (:trade JPM 1.118397 :last 35.50) (:trade GM 1.118397 :last 30.55) (:trade C 1.125426 :last 46.78) (:trade MCD 1.132390 :last 29.74) (:trade WMT 1.133494 :last 48.40) (:trade MRK 1.135099 :last 34.33) (:trade MSFT 1.135099 :last 25.39) (:trade INTC 1.135099 :last 23.78) (:trade INTC 1.146096 :last 23.79) (:trade KO 1.146108 :last 43.99) (:trade WMT 1.155346 :last 48.41) (:trade PG 1.158447 :last 54.90) (:trade WMT 1.162645 :last 48.41) (:trade HON 1.162660 :last 35.52) (:trade KO 1.162672 :last 43.98) (:trade JNJ 1.166783 :last 68.20) (:trade DIS 1.166815 :last 26.34) (:trade HD 1.166856 :last 36.90) (:trade MCD 1.171129 :last 29.74) (:trade INTC 1.175130 :last 23.79) (:trade JPM 1.178485 :last 35.50) (:trade KO 1.178485 :last 43.98) (:trade MSFT 1.184447 :last 25.39) (:trade AIG 1.191811 :last 53.56) (:trade WMT 1.195138 :last 48.41) (:trade MSFT 1.199050 :last 25.39) (:trade MO 1.201440 :last 66.18) (:trade INTC 1.201841 :last 23.80) (:trade DIS 1.201841 :last 26.34) (:trade JNJ 1.202292 :last 68.20) (:trade C 1.205172 :last 46.79) (:trade KO 1.205172 :last 43.98) (:trade WMT 1.209557 :last 48.40) (:trade INTC 1.209927 :last 23.79) (:trade VZ 1.209962 :last 34.75) (:trade MSFT 1.213558 :last 25.37) (:trade C 1.220169 :last 46.79) (:trade DIS 1.220225 :last 26.34) (:trade PFE 1.220225 :last 27.55) (:trade JNJ 1.220921 :last 68.20) (:trade MMM 1.223614 :last 76.70) (:trade INTC 1.226875 :last 23.79) (:trade DIS 1.230230 :last 26.34) (:trade HPQ 1.230230 :last 21.03) (:trade HON 1.230230 :last 35.52) (:trade PFE 1.230230 :last 27.56) (:trade SBC 1.230230 :last 23.78) (:trade C 1.236915 :last 46.79) (:trade MSFT 1.240577 :last 25.40) (:trade DIS 1.243960 :last 26.34) (:trade SBC 1.250258 :last 23.78) (:trade MCD 1.250258 :last 29.74) (:trade MSFT 1.250258 :last 25.40) (:trade INTC 1.253588 :last 23.79) (:trade HON 1.253588 :last 35.53) (:trade MCD 1.257704 :last 29.74) (:trade MSFT 1.262803 :last 25.37) (:trade KO 1.271926 :last 43.99) (:trade JPM 1.271926 :last 35.51) (:trade VZ 1.276339 :last 34.75) (:trade MSFT 1.280283 :last 25.40) (:trade HPQ 1.280283 :last 21.03) (:trade DIS 1.288624 :last 26.34) (:trade GE 1.288664 :last 36.14) (:trade JPM 1.288664 :last 35.51) (:trade AIG 1.290300 :last 53.59) (:trade CAT 1.290300 :last 87.86) (:trade IBM 1.290300 :last 76.85) (:trade SBC 1.291940 :last 23.77) (:trade XOM 1.301948 :last 56.88) (:trade DIS 1.303625 :last 26.34) (:trade AIG 1.304047 :last 53.60) (:trade KO 1.305316 :last 43.99) (:trade JPM 1.305316 :last 35.51) (:trade C 1.305316 :last 46.79) (:trade KO 1.314761 :last 43.99) (:trade DIS 1.316972 :last 26.35) (:trade HON 1.316972 :last 35.54) (:trade CAT 1.317022 :last 87.86) (:trade IBM 1.317022 :last 76.85) (:trade GE 1.318640 :last 36.15) (:trade WMT 1.320354 :last 48.41) (:trade HPQ 1.322354 :last 21.04) (:trade AIG 1.331152 :last 53.59) (:close) |# (defun msg-start (m) (search "TRADEDATA" m)) From peter.denno at nist.gov Mon May 30 14:16:18 2005 From: peter.denno at nist.gov (Peter Denno) Date: Mon, 30 May 2005 10:16:18 -0400 Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball Message-ID: <200505301016.19467.peter.denno@nist.gov> Hi, I created a new tarball of cells-gtk available from the home page http://common-lisp.net/project/cells-gtk/ . The tarball is currently synced to what is in CVS. It contains some new things: - ComboBoxes may now use a TreeModel, thus allowing a hierarchical arrangement of items. The demo has an example of this under the "menus" tab. You need to build libcellsgtk to use TreeModel-style ComboBoxes. - TreeBoxes may now specify :expand-all t to allow the tree to initially display completely expanded. - There is a new procedure to find the gtk libraries. The path need be specified in just one place: gtk-ffi/gtk-ffi.asd. (See details INSTALL.txt) I had hopes that for at least some lisps, it would not be necessary to specify the path to libraries at all. This doesn't seem to be the case. I'll investigate more. - Miscellaneous small improvements - The tarball uses Cells 2. I have tested this on cmucl and Lispworks/Linux. I have not tested it on Windows yet because I don't have a windows box handy and VMWare isn't working on my Linux box. So if you are running Windows, let me know how it goes. -- - Best regards, Peter From ktilton at nyc.rr.com Mon May 30 16:37:33 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 30 May 2005 12:37:33 -0400 Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball In-Reply-To: <200505301016.19467.peter.denno@nist.gov> References: <200505301016.19467.peter.denno@nist.gov> Message-ID: <429B414D.8010302@nyc.rr.com> Peter Denno wrote: >Hi, > >I created a new tarball of cells-gtk available from the home page >http://common-lisp.net/project/cells-gtk/ . The tarball is currently synced >to what is in CVS. It contains some new things: > >- ComboBoxes may now use a TreeModel, thus allowing a hierarchical arrangement >of items. The demo has an example of this under the "menus" tab. You need to >build libcellsgtk to use TreeModel-style ComboBoxes. > >- TreeBoxes may now specify :expand-all t to allow the tree to initially >display completely expanded. > >- There is a new procedure to find the gtk libraries. The path need be >specified in just one place: gtk-ffi/gtk-ffi.asd. (See details INSTALL.txt) I >had hopes that for at least some lisps, it would not be necessary to specify >the path to libraries at all. This doesn't seem to be the case. I'll >investigate more. > >- Miscellaneous small improvements > >- The tarball uses Cells 2. > >I have tested this on cmucl and Lispworks/Linux. I have not tested it on >Windows yet because I don't have a windows box handy and VMWare isn't working >on my Linux box. So if you are running Windows, let me know how it goes. > > > Peter, Thanks for carrying on Vasilis's work so effectively. I have started /trying/ to test under Windows. The build goes OK, tho under ACL 6.2 in load.lisp one cannot say ":version :wild", it has to be ":version :unspecific". But in ACL7 they support :wild so you may not want to bother. I was over on 6.2 because Cells-Gtk had worked there, and under ACL7 I was getting an obscure error loading the GTK dlls. I have not touched those since playing with cgtk, so I thought maybe the ACL loader was doing something different. Nope, same error on ACL 6.2. So as usual with Windows, nothing makes sense and I am slowly installing the latest GTK+ 2.6.7 family of libs to see if I can get Gtk working itself. If that succeeds, I will then finish a little libgtkcells VC++ project to build a win32 dll for that and see if I can get the new stuff working. peace, kenny From peter.denno at nist.gov Mon May 30 17:28:14 2005 From: peter.denno at nist.gov (Peter Denno) Date: Mon, 30 May 2005 13:28:14 -0400 Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball In-Reply-To: <429B414D.8010302@nyc.rr.com> References: <200505301016.19467.peter.denno@nist.gov> <429B414D.8010302@nyc.rr.com> Message-ID: <200505301328.14784.peter.denno@nist.gov> On Monday 30 May 2005 12:37, Kenny Tilton wrote: > > Peter, > > Thanks for carrying on Vasilis's work so effectively. > > I have started /trying/ to test under Windows. The build goes OK, tho > under ACL 6.2 in load.lisp one cannot say ":version :wild", it has to be > ":version :unspecific". But in ACL7 they support :wild so you may not > want to bother. I'll bother, but I'll wait to see what else goes wrong too. Thanks. This must have been a problem all along, since I don't think this changed. > I was over on 6.2 because Cells-Gtk had worked there, > and under ACL7 I was getting an obscure error loading the GTK dlls. I > have not touched those since playing with cgtk, so I thought maybe the > ACL loader was doing something different. Nope, same error on ACL 6.2. > So as usual with Windows, nothing makes sense and I am slowly installing > the latest GTK+ 2.6.7 family of libs to see if I can get Gtk working > itself. > > If that succeeds, I will then finish a little libgtkcells VC++ project > to build a win32 dll for that and see if I can get the new stuff working. I'd be real interested in knowing how that goes. BTW yesterday I had some behavior in cells that I thought might be a bug (it was 3AM so it merits another check, before I report it). I am using, (in my work, and the cells-gtk tarball) the cells 2 tarball rather than the CVS head. Would I be better off with the head...or something else? > > peace, kenny -- - Best regards, Peter From ktilton at nyc.rr.com Mon May 30 18:24:57 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 30 May 2005 14:24:57 -0400 Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball In-Reply-To: <200505301328.14784.peter.denno@nist.gov> References: <200505301016.19467.peter.denno@nist.gov> <429B414D.8010302@nyc.rr.com> <200505301328.14784.peter.denno@nist.gov> Message-ID: <429B5A79.1030606@nyc.rr.com> Peter Denno wrote: >On Monday 30 May 2005 12:37, Kenny Tilton wrote: > > > >>Peter, >> >>Thanks for carrying on Vasilis's work so effectively. >> >>I have started /trying/ to test under Windows. The build goes OK, tho >>under ACL 6.2 in load.lisp one cannot say ":version :wild", it has to be >>":version :unspecific". But in ACL7 they support :wild so you may not >>want to bother. >> >> > >I'll bother, but I'll wait to see what else goes wrong too. > Yep. > Thanks. This must >have been a problem all along, since I don't think this changed. > > > >>I was over on 6.2 because Cells-Gtk had worked there, >>and under ACL7 I was getting an obscure error loading the GTK dlls. I >>have not touched those since playing with cgtk, so I thought maybe the >>ACL loader was doing something different. Nope, same error on ACL 6.2. >>So as usual with Windows, nothing makes sense and I am slowly installing >>the latest GTK+ 2.6.7 family of libs to see if I can get Gtk working >>itself. >> >>If that succeeds, I will then finish a little libgtkcells VC++ project >>to build a win32 dll for that and see if I can get the new stuff working. >> >> > >I'd be real interested in knowing how that goes. > >BTW yesterday I had some behavior in cells that I thought might be a bug (it >was 3AM so it merits another check, before I report it). I am using, (in my >work, and the cells-gtk tarball) the cells 2 tarball rather than the CVS >head. Would I be better off with the head...or something else? > Is that the tarball in the common-lisp.net CVS tree? If so, that is a daily autogen from the source tree, so it should not matter. Were you playing with synapses? they just got sorted out a week or so ago. Otherwise I think anything you find might be new. Understood about the 3AM factor, but I hope any Cells user errs on the side of reporting problems early. Even if it turns out to be an application problem, I might be able to help you debug it faster. Not having documented Cells, I owe y'all that much. kt From asimon at math.bme.hu Tue May 31 00:09:28 2005 From: asimon at math.bme.hu (Andras Simon) Date: Tue, 31 May 2005 02:09:28 +0200 (CEST) Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball In-Reply-To: <200505301016.19467.peter.denno@nist.gov> References: <200505301016.19467.peter.denno@nist.gov> Message-ID: On Mon, 30 May 2005, Peter Denno wrote: > - There is a new procedure to find the gtk libraries. The path need be > specified in just one place: gtk-ffi/gtk-ffi.asd. (See details INSTALL.txt) I > had hopes that for at least some lisps, it would not be necessary to specify > the path to libraries at all. This doesn't seem to be the case. I'll > investigate more. It's even worse than that. Some Linux distributions (Fedora, Debian) don't have .so symlinks to the various .so.x.y.z files (or not to all of them). This is not gtk-specific, I ran into this with postgresql before. Also, I had to change :version from :wild to :newest to please ACL (this seems to be a bug in ACL6.2/Linux). Other than these, both CMU and ACL compiled and ran cl-gtk without a hitch. Nice! Andras From ktilton at nyc.rr.com Tue May 31 01:42:04 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 30 May 2005 21:42:04 -0400 Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball In-Reply-To: <200505301328.14784.peter.denno@nist.gov> References: <200505301016.19467.peter.denno@nist.gov> <429B414D.8010302@nyc.rr.com> <200505301328.14784.peter.denno@nist.gov> Message-ID: <429BC0EC.1070309@nyc.rr.com> Peter Denno wrote: >>I was over on 6.2 because Cells-Gtk had worked there, >>and under ACL7 I was getting an obscure error loading the GTK dlls. I >>have not touched those since playing with cgtk, so I thought maybe the >>ACL loader was doing something different. Nope, same error on ACL 6.2. >>So as usual with Windows, nothing makes sense and I am slowly installing >>the latest GTK+ 2.6.7 family of libs to see if I can get Gtk working >>itself. >> >>If that succeeds, I will then finish a little libgtkcells VC++ project >>to build a win32 dll for that and see if I can get the new stuff working. >> >> > >I'd be real interested in knowing how that goes. > The error persists.Loading libgobject, libintl_bind_textdomain_codeset not found in intl.dll. libintl.h shows that as a valid exported label. That is under ACL7. I am trying also from Lispworks Trial, but that seems to be unhappy with the logical-pathname usage in load.lisp: ASDF reports it cannot find Cells. Anyone have a clue on the INTL issue? I did a fresh install of GIMP, which brings down all the gtk stuff. And the GIMP app itself runs fine. kenny From ktilton at nyc.rr.com Tue May 31 01:59:38 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 30 May 2005 21:59:38 -0400 Subject: [cells-devel] Re: [cells-gtk-devel] New cells-gtk capabilities and new tarball In-Reply-To: <429BC0EC.1070309@nyc.rr.com> References: <200505301016.19467.peter.denno@nist.gov> <429B414D.8010302@nyc.rr.com> <200505301328.14784.peter.denno@nist.gov> <429BC0EC.1070309@nyc.rr.com> Message-ID: <429BC50A.3040300@nyc.rr.com> Kenny Tilton wrote: > > > Peter Denno wrote: > >>> I was over on 6.2 because Cells-Gtk had worked there, and under ACL7 >>> I was getting an obscure error loading the GTK dlls. I >>> have not touched those since playing with cgtk, so I thought maybe the >>> ACL loader was doing something different. Nope, same error on ACL 6.2. >>> So as usual with Windows, nothing makes sense and I am slowly >>> installing >>> the latest GTK+ 2.6.7 family of libs to see if I can get Gtk working >>> itself. >>> >>> If that succeeds, I will then finish a little libgtkcells VC++ project >>> to build a win32 dll for that and see if I can get the new stuff >>> working. >>> >> >> >> I'd be real interested in knowing how that goes. > > The error persists.Loading libgobject, libintl_bind_textdomain_codeset > not found in intl.dll. libintl.h shows that as a valid exported label. > > That is under ACL7. I am trying also from Lispworks Trial, but that > seems to be unhappy with the logical-pathname usage in load.lisp: ASDF > reports it cannot find Cells. Sorry. I inadvertently tried to load the "load.lisp" in \cells-gtk\root. (Is that still needed?) Anyway, good/bad news: same error from Lispworks. From rm at seid-online.de Tue May 31 10:56:32 2005 From: rm at seid-online.de (rm at seid-online.de) Date: Tue, 31 May 2005 12:56:32 +0200 Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball] Message-ID: <20050531105632.GB31936@seid-online.de> On Tue, May 31, 2005 at 02:09:28AM +0200, Andras Simon wrote: > > > On Mon, 30 May 2005, Peter Denno wrote: > > > >- There is a new procedure to find the gtk libraries. The path need be > >specified in just one place: gtk-ffi/gtk-ffi.asd. (See details > >INSTALL.txt) I > >had hopes that for at least some lisps, it would not be necessary to > >specify > >the path to libraries at all. This doesn't seem to be the case. I'll > >investigate more. > > It's even worse than that. Some Linux distributions (Fedora, Debian) > don't have .so symlinks to the various .so.x.y.z files (or not to all > of them). This is not gtk-specific, I ran into this with > postgresql before. No, no. no. That's _not_ worse. These links are an essential part of the inner workings of the dynamic loader (/lib/ld.so.1, which is both a library and an application) for (i assume) _all_ distributions of that OS. These links are set up (and updated) by the /sbin/ldconfig utility. This is a needed to support versioned libraries. An application that asks for an unspecific version of library 'foo' will get whatever foo.so points to (the latest version iff your box is configured correctly). Asking for a specific version will result in foo..so. Question to Peter: is there really a Linux/BSD Lisp that does need a path for dll loading? Cheers Ralf Mattes From asimon at math.bme.hu Tue May 31 14:36:15 2005 From: asimon at math.bme.hu (Andras Simon) Date: Tue, 31 May 2005 16:36:15 +0200 (CEST) Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball] In-Reply-To: <20050531105632.GB31936@seid-online.de> References: <20050531105632.GB31936@seid-online.de> Message-ID: On Tue, 31 May 2005 rm at seid-online.de wrote: > > On Tue, May 31, 2005 at 02:09:28AM +0200, Andras Simon wrote: >> It's even worse than that. Some Linux distributions (Fedora, Debian) >> don't have .so symlinks to the various .so.x.y.z files (or not to all >> of them). This is not gtk-specific, I ran into this with >> postgresql before. > > No, no. no. That's _not_ worse. These links are an essential part of the inner > workings of the dynamic loader (/lib/ld.so.1, which is both a library and an > application) for (i assume) _all_ distributions of that OS. > These links are set up (and updated) by the /sbin/ldconfig utility. This is a needed > to support versioned libraries. An application that asks for an unspecific version > of library 'foo' will get whatever foo.so points to (the latest version iff your box > is configured correctly). Asking for a specific version will result in foo..so. That's the problem. There's no foo.so, only foo.so.0.1.23 What should CMUCL and ACL load? Andras From peter.denno at nist.gov Tue May 31 14:41:06 2005 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 31 May 2005 10:41:06 -0400 Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball In-Reply-To: <20050531105146.GA31936@seid-online.de> References: <200505301016.19467.peter.denno@nist.gov> <20050531105146.GA31936@seid-online.de> Message-ID: <200505311041.06890.peter.denno@nist.gov> On Tuesday 31 May 2005 06:51, rm at fabula.de wrote: > Question to Peter: is there really a ?Linux/BSD Lisp that does need a path > for dll loading? It looks like Lispworks needs it. My first test of lispworks was faulty -- paths were specified when I thought they were not. When I didn't specify the path the library was not found. But I am not confident in any of this, because later on I was even having problems with cmucl, which had worked a few times and uses dlopen. So I'll need to investigate this further. -- - Best regards, Peter From rm at seid-online.de Tue May 31 15:12:00 2005 From: rm at seid-online.de (rm at seid-online.de) Date: Tue, 31 May 2005 17:12:00 +0200 Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball] Message-ID: <20050531151200.GF31936@seid-online.de> On Tue, May 31, 2005 at 04:36:15PM +0200, Andras Simon wrote: > > > That's the problem. There's no foo.so, only foo.so.0.1.23 > What should CMUCL and ACL load? That's usually a rather clear sign for a broken istallation. Who (what program) installed foo.so.0.1.23? Did the installation process not run /sbin/ldconfig after installing foo.so.0.1.23? Ralf Mattes > Andras From peter.denno at nist.gov Tue May 31 16:07:21 2005 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 31 May 2005 12:07:21 -0400 Subject: [cells-devel] Re: [cells-gtk-devel] New cells-gtk capabilities =?iso-8859-1?q?and=09new?= tarball In-Reply-To: <429BC50A.3040300@nyc.rr.com> References: <200505301016.19467.peter.denno@nist.gov> <429BC0EC.1070309@nyc.rr.com> <429BC50A.3040300@nyc.rr.com> Message-ID: <200505311207.22107.peter.denno@nist.gov> On Monday 30 May 2005 21:59, Kenny Tilton wrote: > >>> > >>> If that succeeds, I will then finish a little libgtkcells VC++ project > >>> to build a win32 dll for that and see if I can get the new stuff > >>> working. > >> > >> I'd be real interested in knowing how that goes. > > > > The error persists.Loading libgobject, libintl_bind_textdomain_codeset > > not found in intl.dll. libintl.h shows that as a valid exported label. Problem 1 - library loading This is without libcellsgtk? If your installation contains a libcellsgtk library, then that is certainly suspect. Perhaps there is someone here more knowledgeable about how these libraries should be built. In the makefile, I use: all: gcc -c gtk-adds.c `pkg-config --cflags --libs gtk+-2.0` gcc -shared -o libcellsgtk.so gtk-adds.o The gcc -c line is typical for gtk, at least as I can tell from the distribution. The gcc -shared -o line is only what I learned from the gcc man page and reading around a bit. > > That is under ACL7. I am trying also from Lispworks Trial, but that > > seems to be unhappy with the logical-pathname usage in load.lisp: ASDF > > reports it cannot find Cells. Problem 2 - logical pathnames in Lispworks Trial (this is unrelated to the library loading problem, correct?) It is occurring despite switching to :version :unspecific ? What does (truename #P"cells-gtk:cells;") evaluate to? > Sorry. I inadvertently tried to load the "load.lisp" in \cells-gtk\root. > (Is that still needed?) No. I'll remove it. > > Anyway, good/bad news: same error from Lispworks. > > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel -- - Best regards, Peter From asimon at math.bme.hu Tue May 31 16:40:48 2005 From: asimon at math.bme.hu (Andras Simon) Date: Tue, 31 May 2005 18:40:48 +0200 (CEST) Subject: [cells-gtk-devel] New cells-gtk capabilities and new tarball] In-Reply-To: <20050531151200.GF31936@seid-online.de> References: <20050531151200.GF31936@seid-online.de> Message-ID: On Tue, 31 May 2005 rm at seid-online.de wrote: > > On Tue, May 31, 2005 at 04:36:15PM +0200, Andras Simon wrote: >> >> >> That's the problem. There's no foo.so, only foo.so.0.1.23 >> What should CMUCL and ACL load? > > That's usually a rather clear sign for a broken istallation. Who > (what program) installed foo.so.0.1.23? Did the installation process rpm on Fedora, apt-get (I guess) on the Debian boxes I have access to. > not run /sbin/ldconfig after installing foo.so.0.1.23? No idea. But ldconfig -v says libgtk-1.2.so.0 -> libgtk-1.2.so.0.9.1 not libgtk-1.2.so -> libgtk-1.2.so.0.9.1 I don't know if it's ldconfig's job to create these symlinks, but I'd also think that creating them should be part of the installation process. On the other hand, I'd be surprised if the rpm and deb packages shared a (packaging) bug. Andras