From ktilton at nyc.rr.com Mon Dec 6 20:55:26 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 06 Dec 2004 15:55:26 -0500 Subject: [cells-gtk-devel] Lispworks Cells-Gtk2 Milestone Message-ID: <41B4C73E.8000605@nyc.rr.com> OK, some small success making Vasilis Margioulas's Cells-Gtk for CLisp and Gtk2 portable: Vasilis's original version has been removed from the Cells project CVS tree and installed (again, it seems) in the Cells-Gtk project here: http://common-lisp.net/cgi-bin/viewcvs.cgi/clisp-cgtk/?cvsroot=cells-gtk As for the new UFFI-ized version, that is here: http://common-lisp.net/cgi-bin/viewcvs.cgi/root/?cvsroot=cells-gtk That now works under AllegroCL and Lispworks on win32. The source as it stands as of this writing shows only one of the nine test panels Vasilis provided. The others can be brought into play by de-commenting them in test-gtk.lisp. (You cannot miss it.) They all might work in AllegroCL (they did before all the work to get Lispworks working), but under Lispworks who knows, this is where I stopped to share since a couple of people had offered to work on the Lispworks port. The UFFI-ization was done weirdly, because I was hoping to keep it working under CLisp which is not supported by UFFI. So for a while I conditionalized the code for #+/-CLisp, and definitions were left as CLisp-y and translated to UFFI by macrology, instead of just globally editing everything to actually be UFFI code. Now I think I want to fork UFFI into what will become a different portable FFI not necessarily backward-compatible with UFFI. I gather there has been talk of doing so for a while. I would add callbacks, CLisp, booleans, and some handy utilities I have developed for dealing with FF. This will include providing friendly wrappers which will, for native FFIs which do not do it automatically, translate between nil/t and 0/1, or nil and a null pointer. Anyway, just do not freak out at the weird way the UFFI-ization went, I changed horses midstream and it shows. Contributors are welcome, as always. In case you missed the incentive, here are four of the nine panels: http://common-lisp.net/project/cells-gtk/ Those shots come from Vasilis's original CLisp release, running on Linux. I would be especially interested if some brave soul wants to try building GTK2 under X11 on Mac OS/X and see if AllegroCL or Lispworks can run Cells-gtk over there as well. No reason other OS/X Lisps cannot try, but then I would expect more UFFI-ization issues to fall out. If anyone does, screenshots as well as patches are of course welcome. kenny -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From ktilton at nyc.rr.com Thu Dec 23 01:05:56 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 22 Dec 2004 20:05:56 -0500 Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> Message-ID: <41CA19F4.6070401@nyc.rr.com> Andras Simon wrote: > >>> I'll send you a tarball later today. It'll have everything but the >>> tree demo working. But, because of that, an announcement may be just >>> a bit too early. >> >> >> Ah, yes. That tree demo was a monster. I actually did that in two >> steps, because it itself has two sub-demos: "listbox" and "treebox". >> So I commented out one until I got the other working. Each took days. >> :( Hope what I did carries over to CMU. > > > It definitely did! Both parts of the tree demo work out of the box; > it's just that they're so bloody slow that I gave up before the window > came up. But now I put 1 in the :init-value slot of the h-scale, and > that helped. Nice guess! How slow was "slow"? I have seen like a 3-4 second pause, no more. Never investigated. If your "slow" is much out of line with the Clisp original (using CLisp FFI -- did you ever try building that to see if it would fly?) or if it s out of line with ACL and Lispworks on win32, I will suspect the CMUCL FFI interacting with UFFI, a known problem. As for Cells being the problem, one never knows, but the original pure CLisp version uses Cells, and Cells are pretty solid as a rule. I am going to spend some time merging any changes I made ot get a clean compile under LW on Mac OS/X and then update CVS with everything. Then off to cll to emtion the CMUCL coverage. kenny -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From asimon at math.bme.hu Thu Dec 23 11:14:10 2004 From: asimon at math.bme.hu (Andras Simon) Date: Thu, 23 Dec 2004 12:14:10 +0100 (CET) Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: <41CA19F4.6070401@nyc.rr.com> References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> Message-ID: [resending now that I'm subscribed to the list] [to Kenny: commenting out the listbox works now, so I left out the part complaining about it] On Wed, 22 Dec 2004, Kenny Tilton wrote: > > > Andras Simon wrote: > > > > > > > I'll send you a tarball later today. It'll have everything but the > > > > tree demo working. But, because of that, an announcement may be just > > > > a bit too early. > > > > > > > > > Ah, yes. That tree demo was a monster. I actually did that in two > > > steps, because it itself has two sub-demos: "listbox" and "treebox". > > > So I commented out one until I got the other working. Each took days. > > > :( Hope what I did carries over to CMU. > > > > > > It definitely did! Both parts of the tree demo work out of the box; it's > > just that they're so bloody slow that I gave up before the window came > > up. But now I put 1 in the :init-value slot of the h-scale, and that > > helped. > > Nice guess! How slow was "slow"? I have seen like a 3-4 second pause, no > more. Never investigated. > > If your "slow" is much out of line with the Clisp original (using CLisp > FFI -- did you ever try building that to see if it would fly?) or if it s > out of line with ACL and Lispworks on win32, I will suspect the CMUCL FFI > interacting with UFFI, a known problem. It's very much out of line with ACL. I don't have numbers, but it must be something like thousands of times slower. > As for Cells being the problem, one never knows, but the original pure > CLisp version uses Cells, and Cells are pretty solid as a rule. I thought that maybe cells/CMUCL was to blame. The funny thing is that all the other demos are pretty fast. Perhaps it's time to take a hard look at the compilation notes and warnings. (A CMUCL expert would come in handy.) > > I am going to spend some time merging any changes I made ot get a clean > compile under LW on Mac OS/X and then update CVS with everything. Then off > to cll to emtion the CMUCL coverage. Given that the tree view demo makes the startup time for the whole demo unacceptably long, I suggest #-cmu-ing out "Tree-view" in test-gtk.lisp before going public. Andras From asimon at math.bme.hu Fri Dec 24 00:16:47 2004 From: asimon at math.bme.hu (Andras Simon) Date: Fri, 24 Dec 2004 01:16:47 +0100 (CET) Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: <41CA19F4.6070401@nyc.rr.com> References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> Message-ID: The following hack almost solves the tree demo slowness problem. diff -b -u -r /tmp/root/gtk-ffi/gtk-core.lisp ../gtk-ffi/gtk-core.lisp --- /tmp/root/gtk-ffi/gtk-core.lisp 2004-12-16 05:51:17.000000000 +0100 +++ ../gtk-ffi/gtk-core.lisp 2004-12-24 01:02:20.444497200 +0100 @@ -67,8 +67,15 @@ (defmacro with-g-value ((var) &body body) `(call-with-g-value (lambda (,var) , at body))) +#+cmu +(ffx:def-type g-value-type + (* (alien:struct gtk-ffi::g-value + (gtk-ffi::g-type (array (alien:signed 32) 16))))) + (defun call-with-g-value (fn) + (declare (optimize (speed 3) (safety 0) (space 0))) (let ((gva (ffx:fgn-alloc 'g-value 1 :with-g-value))) + #+cmu (declare (type g-value-type gva)) (unwind-protect (progn (dotimes (n 16) Can someone translate the above deftype into a more uffi-friendly form, so it doesn't have to be conditionalized? Kenny, I see that you didn't #-cmu-ized out the tree demo in test-gtk.lisp. I wonder if people can sit through the minutes (hours?) it takes the demo window to come up... Andras From ktilton at nyc.rr.com Fri Dec 24 01:51:20 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 23 Dec 2004 20:51:20 -0500 Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> Message-ID: <41CB7618.7040604@nyc.rr.com> Andras Simon wrote: > The following hack almost solves the tree demo slowness problem. > > diff -b -u -r /tmp/root/gtk-ffi/gtk-core.lisp ../gtk-ffi/gtk-core.lisp > --- /tmp/root/gtk-ffi/gtk-core.lisp 2004-12-16 05:51:17.000000000 > +0100 > +++ ../gtk-ffi/gtk-core.lisp 2004-12-24 01:02:20.444497200 +0100 > @@ -67,8 +67,15 @@ > (defmacro with-g-value ((var) &body body) > `(call-with-g-value (lambda (,var) , at body))) > > +#+cmu > +(ffx:def-type g-value-type > + (* (alien:struct gtk-ffi::g-value > + (gtk-ffi::g-type (array (alien:signed > 32) 16))))) > + > (defun call-with-g-value (fn) > + (declare (optimize (speed 3) (safety 0) (space 0))) > (let ((gva (ffx:fgn-alloc 'g-value 1 :with-g-value))) > + #+cmu (declare (type g-value-type gva)) > (unwind-protect > (progn > (dotimes (n 16) Cool, thx. I will work that in. > > Can someone translate the above deftype into a more uffi-friendly > form, so it doesn't have to be conditionalized? > > Kenny, I see that you didn't #-cmu-ized out the tree demo in > test-gtk.lisp. I wonder if people can sit through the minutes (hours?) > it takes the demo window to come up... uh-oh. I must have just missed it. Was that in a patch, or was I being given undue credit for ability to handle the obvious on my own? :) Probably the latter. Well, do we still need it disabled after the above? If so, you are talking about the whole "tree-view" tab, yes? Not just the treebox sub-tab? kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From asimon at math.bme.hu Fri Dec 24 02:08:51 2004 From: asimon at math.bme.hu (Andras Simon) Date: Fri, 24 Dec 2004 03:08:51 +0100 (CET) Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: <41CB7618.7040604@nyc.rr.com> References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> <41CB7618.7040604@nyc.rr.com> Message-ID: On Thu, 23 Dec 2004, Kenny Tilton wrote: >> Kenny, I see that you didn't #-cmu-ized out the tree demo in >> test-gtk.lisp. I wonder if people can sit through the minutes (hours?) it >> takes the demo window to come up... > > uh-oh. I must have just missed it. Was that in a patch, or was I being given > undue credit for ability to handle the obvious on my own? :) Probably the I just mentioned it in passing (or did I? I meant to, anyway :-) But it doesn' matter because... > latter. Well, do we still need it disabled after the above? If so, you are > talking about the whole "tree-view" tab, yes? Not just the treebox sub-tab? ...speed is now tolerable, so we don't need it disabled. Andras From ktilton at nyc.rr.com Fri Dec 24 02:11:31 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 23 Dec 2004 21:11:31 -0500 Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: <41CB7618.7040604@nyc.rr.com> References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> <41CB7618.7040604@nyc.rr.com> Message-ID: <41CB7AD3.3010501@nyc.rr.com> >> >> >> diff -b -u -r /tmp/root/gtk-ffi/gtk-core.lisp ../gtk-ffi/gtk-core.lisp >> --- /tmp/root/gtk-ffi/gtk-core.lisp 2004-12-16 05:51:17.000000000 >> +0100 >> +++ ../gtk-ffi/gtk-core.lisp 2004-12-24 01:02:20.444497200 +0100 >> @@ -67,8 +67,15 @@ >> (defmacro with-g-value ((var) &body body) >> `(call-with-g-value (lambda (,var) , at body))) >> >> +#+cmu >> +(ffx:def-type g-value-type >> + (* (alien:struct gtk-ffi::g-value >> + (gtk-ffi::g-type (array (alien:signed >> 32) 16))))) >> + >> (defun call-with-g-value (fn) >> + (declare (optimize (speed 3) (safety 0) (space 0))) >> (let ((gva (ffx:fgn-alloc 'g-value 1 :with-g-value))) >> + #+cmu (declare (type g-value-type gva)) >> (unwind-protect >> (progn >> (dotimes (n 16) > > > Cool, thx. I will work that in. Done. And I knocked out tree-view for CMU. I also noticed why the tabs were coming up "Page 1,2,3". Duh. Fixed. > > >> >> Can someone translate the above deftype into a more uffi-friendly >> form, so it doesn't have to be conditionalized? > By the way, looks like your FFI is coming up to speed. :) Agreed that all-UFFI is better, but at this core level a little conditionalization should not hurt. Hopefully those hoping to use this code for GUI development will never need to touch this code. I did the same getting Lispworks up to speed. I just want to get a nice, portable, friendly, Cells-y GUI framework out there for Common Lisp. Niceties will fall into place if the thing catches on with users. But thanks for your attention to detail. kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From asimon at math.bme.hu Fri Dec 24 02:36:33 2004 From: asimon at math.bme.hu (Andras Simon) Date: Fri, 24 Dec 2004 03:36:33 +0100 (CET) Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: <41CB7AD3.3010501@nyc.rr.com> References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> <41CB7618.7040604@nyc.rr.com> <41CB7AD3.3010501@nyc.rr.com> Message-ID: On Thu, 23 Dec 2004, Kenny Tilton wrote: > Done. And I knocked out tree-view for CMU. I also noticed why the tabs were > coming up "Page 1,2,3". Duh. Fixed. Speaking of Page 1,2,3: the items in the tree-box look like pointers to strings instead of strings proper, but this has to wait until tomorrow or until I learn enough about gtk and cells to find out how to control what gets in there, whichever comes last. >>> Can someone translate the above deftype into a more uffi-friendly form, >>> so it doesn't have to be conditionalized? >> > By the way, looks like your FFI is coming up to speed. :) I wish it did. Instead, I just did (print (type-of gva)), saw that the result was always the same, and declared gva's type accordingly. > > Agreed that all-UFFI is better, but at this core level a little > conditionalization should not hurt. Hopefully those hoping to use this code > for GUI development will never need to touch this code. I did the same > getting Lispworks up to speed. I just want to get a nice, portable, friendly, > Cells-y GUI framework out there for Common Lisp. Niceties will fall into > place if the thing catches on with users. But thanks for your attention to > detail. But won't porting be easier if there are less conditionalizations? Andras From ktilton at nyc.rr.com Fri Dec 24 04:28:11 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 23 Dec 2004 23:28:11 -0500 Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> <41CB7618.7040604@nyc.rr.com> <41CB7AD3.3010501@nyc.rr.com> Message-ID: <41CB9ADB.6070701@nyc.rr.com> > Speaking of Page 1,2,3: the items in the tree-box look like pointers > to strings instead of strings proper, but this has to wait until > tomorrow or until I learn enough about gtk and cells to find out how > to control what gets in there, whichever comes last. Not sure to what you refer, but my touchstone is Vasilis's original, and when I fired that up I saw the same things there. This might mean we have the same bug as Vasilis, or that that that is what he meant to display, or that my memory is mistaken. :) > I wish it did. Instead, I just did (print (type-of gva)), saw that the > result was always the same, and declared gva's type accordingly. Diabolical. "Find out where my people are going so I may lead them." :) > > But won't porting be easier if there are less conditionalizations? Absolutely, but "fatigue doth make cowards of us all". :) I guess I have seen enough FFI for a while. I remember when I used to do Lisp and OpenGL.... . Seriously, thanks for pitching in. kenny From asimon at math.bme.hu Fri Dec 24 13:18:26 2004 From: asimon at math.bme.hu (Andras Simon) Date: Fri, 24 Dec 2004 14:18:26 +0100 (CET) Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: <41CB9ADB.6070701@nyc.rr.com> References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> <41CB7618.7040604@nyc.rr.com> <41CB7AD3.3010501@nyc.rr.com> <41CB9ADB.6070701@nyc.rr.com> Message-ID: This (crucial) one somehow got lost during the merge: Index: gtk-ffi/gtk-utilities.lisp =================================================================== RCS file: /project/cells-gtk/cvsroot/root/gtk-ffi/gtk-utilities.lisp,v retrieving revision 1.6 diff -u -r1.6 gtk-utilities.lisp --- gtk-ffi/gtk-utilities.lisp 23 Dec 2004 16:34:51 -0000 1.6 +++ gtk-ffi/gtk-utilities.lisp 24 Dec 2004 13:09:15 -0000 @@ -74,7 +74,7 @@ (gdk-threads-leave))) (ffx:ff-defun-callable :cdecl :int button-press-event-handler - ((widget (* :void)) (signal (* gdk-event-button)) (data (* :void))) + ((widget :pointer-void) (signal (* gdk-event-button)) (data :pointer-void)) (declare (ignorable data)) (let ((event (gdk-event-button-type signal))) (when (eql (event-type event) :button_press) Andras From asimon at math.bme.hu Fri Dec 24 16:38:03 2004 From: asimon at math.bme.hu (Andras Simon) Date: Fri, 24 Dec 2004 17:38:03 +0100 (CET) Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: <41CC3B4A.2000804@nyc.rr.com> References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> <41CB7618.7040604@nyc.rr.com> <41CB7AD3.3010501@nyc.rr.com> <41CB9ADB.6070701@nyc.rr.com> <41CC3B4A.2000804@nyc.rr.com> Message-ID: On Fri, 24 Dec 2004, Kenny Tilton wrote: > > Done. btw, if you think you will be working on cells-gtk a lot we should look > at setting you up with cvs write access. I do plan to work on it for at least a week or two (until the holidays are over). But if you don't mind getting patches, I'm happy without write access. Otherwise, I have a cl-net account (for slime hacking), if that makes a difference. > Now going back to that performance problem, I meant to confess that that > WITH-G-VALUE stuff was a real hack of a way to get past a limitation of UFFI. > If that is still a performance problem, let's figure out a better way. I think it's not a problem anymore. > Taking off now for a couple of days to visit family for the holidays. Catch > you all on the rebound. Have a nice time! Andras From ktilton at nyc.rr.com Fri Dec 24 15:52:42 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 24 Dec 2004 10:52:42 -0500 Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> <41CB7618.7040604@nyc.rr.com> <41CB7AD3.3010501@nyc.rr.com> <41CB9ADB.6070701@nyc.rr.com> Message-ID: <41CC3B4A.2000804@nyc.rr.com> Andras Simon wrote: > > This (crucial) one somehow got lost during the merge: > > Index: gtk-ffi/gtk-utilities.lisp > =================================================================== > RCS file: /project/cells-gtk/cvsroot/root/gtk-ffi/gtk-utilities.lisp,v > retrieving revision 1.6 > diff -u -r1.6 gtk-utilities.lisp > --- gtk-ffi/gtk-utilities.lisp 23 Dec 2004 16:34:51 -0000 1.6 > +++ gtk-ffi/gtk-utilities.lisp 24 Dec 2004 13:09:15 -0000 > @@ -74,7 +74,7 @@ > (gdk-threads-leave))) > > (ffx:ff-defun-callable :cdecl :int button-press-event-handler > - ((widget (* :void)) (signal (* gdk-event-button)) (data (* :void))) > + ((widget :pointer-void) (signal (* gdk-event-button)) (data > :pointer-void)) > (declare (ignorable data)) > (let ((event (gdk-event-button-type signal))) > (when (eql (event-type event) :button_press) Done. btw, if you think you will be working on cells-gtk a lot we should look at setting you up with cvs write access. Now going back to that performance problem, I meant to confess that that WITH-G-VALUE stuff was a real hack of a way to get past a limitation of UFFI. If that is still a performance problem, let's figure out a better way. Taking off now for a couple of days to visit family for the holidays. Catch you all on the rebound. kenny From asimon at math.bme.hu Fri Dec 24 17:05:26 2004 From: asimon at math.bme.hu (Andras Simon) Date: Fri, 24 Dec 2004 18:05:26 +0100 (CET) Subject: [cells-gtk-devel] Re: Cells-gtk now UFFI-ized, running under AllegroCL and Lispworks on win32, next stop OS/X. In-Reply-To: <41CB9ADB.6070701@nyc.rr.com> References: <41C5A5ED.1060602@nyc.rr.com> <6A9FEA70-51FD-11D9-A69F-000D936D1552@nyc.rr.com> <41C820C5.4080009@nyc.rr.com> <41C8A6D9.7030909@nyc.rr.com> <41C8FA0D.8000305@nyc.rr.com> <41C96728.1000000@nyc.rr.com> <41C971D1.5000705@nyc.rr.com> <41CA19F4.6070401@nyc.rr.com> <41CB7618.7040604@nyc.rr.com> <41CB7AD3.3010501@nyc.rr.com> <41CB9ADB.6070701@nyc.rr.com> Message-ID: On Thu, 23 Dec 2004, Kenny Tilton wrote: > >> Speaking of Page 1,2,3: the items in the tree-box look like pointers to >> strings instead of strings proper, but this has to wait until tomorrow or >> until I learn enough about gtk and cells to find out how to control what >> gets in there, whichever comes last. > > Not sure to what you refer, but my touchstone is Vasilis's original, and when > I fired that up I saw the same things there. This might mean we have the same > bug as Vasilis, or that that that is what he meant to display, or that my > memory is mistaken. :) What I mean is that in the string column of the Tree-view/Listbox demo CMUCL has # instead of "Item 1" as in Allegro, and the Widget class column of Treebox has this same pointer nonsense instead of "GTK-APP", "NOTEBOOK" that Allegro has. > >> I wish it did. Instead, I just did (print (type-of gva)), saw that the >> result was always the same, and declared gva's type accordingly. > > Diabolical. "Find out where my people are going so I may lead them." :) Call it exploratory programming :-) Andras