Peter Hildebrandt wrote:
Well, there's something wrong with the cells cvs again, so it would not let me commit my latest changes. You can grab the latest version here:
Hmmm, a little trouble there. PicoZip on WinXP cannot read it, WinZip on Vista (my new laptop for the eclm talk) complains but then seems to open it. The complaint looks like winzip just is not handling Vista.
Maybe just tar.gz it? I appreciate the trouble you took making a zip, btw.
Question 2: the above does not include a Cells directory (unless the expansion broke). I will be trying to build it (looks like I have to hack the ACL .lpr files for a while) in the meantime.
My suggestions:
(1) Cairo Drawing Area
I have the cairo drawing area thing working by now and put in a simple example (creates boxes and circles and random positions, then they react on mouse over, can be selected, dragged around, and you can use a select box (like in windows explorer) to select and move many shapes at once). I finally took the time and get the kids slot to work properly, so you can have ruled kids slots on your drawing primitives and have cells create other shapes for you (say, you want to draw a sun -- then you start with a yellow filled circle and have a kids rule creating some lines for the rays. The number of rays may depend on a widget (and so can the length), and you have a "declarative drawing").
Isn't that fun? I remember when we made kids a Cell (almost immediately). I was sure the wheels would fall off. It Just Worked(tm) and I started to suspect Cells would scale pretty well.
(2) Tree View
From the stuff present in the demo I personally like the tree view
example, since it lets you explore the actual object hierarchy of the demo. I don't even know whethe something like this could be done in C at all.
Omigod! I did an inspector at one point and used it to inspect the inspector window itself. Then I navigated down to the actual widgets in view and watched as the inspector showed things like the mouse-over state dynamically (without asking the inspector to refresh). I seem to recall adding some Cells internals to make it work, tho. In this screenshot:
http://www.tilton-technology.com/cloucell.jpg
...the widget being inspected is the four-widget row just above "Class: Ixrow".
(3) Cells Tree View
Works like a charm -- as long as you don't delete stuff from the observed structure (I ran into a conceptual problem with cells3 here, gonna ask you on the cells list when I have the time to deal with that). Anyway, I deactivated the delete button, and the rest is still pretty nice.
I look forward to the IR, maybe you have run into something I want to add to Cells to better handle things going away (a frequent problem). In my latest app I am running into a lot of problems with what is generally called referential integrity, specifically external references to kids that have been not-to-be'd. eg, my window's keep a reference to the "focus", which might be in a math problem the student decides to delete. uh-oh. Sprinkling (setf (focus w) nil) all over the place broke down when it ended up erasing a new value that had been set by code that tried to handle the problem by, say, moving the focus to the next problem when deleting the current problem.
Man, imperative programming sucks. :)
(4) Threading
It is relly nice and lispy to use the repl to change properties of the windows currently displayed and to add and remove widgets interactively (especially if you have a background in C) -- but I don't know whether that works in MS Windows. Just checked, bordeaux-threads on windows does not support Allegro. Bummer.
I will be doing repl stuff during my talk -- ACL runs a separate process from the IDE to execute Lisp. We just need to have a breather in the event loop handling to give the IDE enough cycles to be responsive.
(5) MAYBE: cells-ode + open gl
That'd be really neat -- if I figure out the opengl drawing area and port my current physics simulator code to cells-ode as a backend plus gtk-gl as a front end. They say there's a weekend coming up, so stay tuned.
OK, don't make yourself crazy on my account. In fact, I already have Cells-gtk as I had it last running on my laptop, I might just leave it at that. I am going to try to get to Celtk, Cello, TripleCells (lite integration with an RDF triple-store), Cells-Gtk, and OpenAIR (the cells/ajax bit andy is doing). Whew!
cheers, ken
OK, don't make yourself crazy on my account. In fact, I already have Cells-gtk as I had it last running on my laptop, I might just leave it at that. I am going to try to get to Celtk, Cello, TripleCells (lite integration with an RDF triple-store), Cells-Gtk, and OpenAIR (the cells/ajax bit andy is doing). Whew!
Will they be recording this stuff? I've seen you mention the TripleCells stuff before and am intrigued. Is it basically automatic serialization of cells instances? That would be the best database ever! You could define a lispy report language that had access to a directory full of cells families.
-- ac
Andy Chambers wrote:
OK, don't make yourself crazy on my account. In fact, I already have Cells-gtk as I had it last running on my laptop, I might just leave it at that. I am going to try to get to Celtk, Cello, TripleCells (lite integration with an RDF triple-store), Cells-Gtk, and OpenAIR (the cells/ajax bit andy is doing). Whew!
Will they be recording this stuff?
We'll be trying. :)
I've seen you mention the TripleCells stuff before and am intrigued. Is it basically automatic serialization of cells instances? That would be the best database ever!
Scary right? The database -- it's alive!!! I actually did that on the trial management project, which was different because that itself was persistent CLOS. RDF is just this lower-level deal, but as such could readily adapt to being a persistent CLOS-alike. But on the CTM project we had Franz's full-blown persistent CLOS implementation dancing to the Cells:
a persistent slot could depend on other persistent slots of the same or other persistent instances.
s dynamic slot of a persistent instance could depend on persistent or non-persistent slots.
dynamic instances could depend on persistent or dynamic slots of persistent instances
And then I added a couple of things, one of which was depending on the /population/ of a peristent class, kind of like depending on a dynamic kids slot.
Then we added a little IPC so one process could scan in a new document and then another process showing a GUI list widget of documents would suddenly show a new one -- no "refresh view" required.
Only took a couple of weeks, IIRC, in part because Franz did a nice job on their metaclass and Cells at the time was metaclass based.
You could define a lispy report language that had access to a directory full of cells families.
Sure. You could do something like have the report itself be a DB object and have it automatically updated when its inputs changed, with suitable laziness so it does not regenerate itself on every I/O. A lot of times one gets batches of reports that require a common view of the DB and shops write extraction programs to generate a pre-digested breakdown off which several reports can run.
And it is a great way to get tons of business logic into the database. Our favorite trick was to scan in two pages of a three page form. 2dbarcodes linked a page back to the DB form (we generated documents from the DB as well as scanned and ICRed them) so we knew how many pages to expect. The code to scan just wrote out what it found, but the Cells logic said "there is a missing page error" on this form simply with a rule that looked like:
(cond ((< <pages-scanned> <pages-printed>) (make-instance 'user-error ....
etc etc where user-error was a persistent class. Slot-values linked it to the form in question, so anyone opening the application immediately saw a hot list of problems. It was trivial then to add code to show them the form with the problem and the scan history related to that form, and because of our audit trail we could also tell them which user had done the scanning on which machine. Made for great demo. :)
So far the RDF version is just very light proof of concept, I do not really need it, just thought it would be fun to do and only took a couple of days.
Back to OpenAIR...
kt
Ken,
On Fri, Apr 11, 2008 at 1:03 PM, Ken Tilton kennytilton@optonline.net wrote:
Hmmm, a little trouble there. PicoZip on WinXP cannot read it, WinZip on Vista (my new laptop for the eclm talk) complains but then seems to open it. The complaint looks like winzip just is not handling Vista.
Weird. I used the built-in zipper in ubuntu. But since cvs now magically works for me again, this has become obsolete fortunately.
Question 2: the above does not include a Cells directory (unless the expansion broke). I will be trying to build it (looks like I have to hack the ACL .lpr files for a while) in the meantime.
Yep, I think we never had cells3 be part of cells-gtk3 (I guess part of why we did cells-gtk3 is so that we don't have to include out own fork of cells anymore).
BTW, do you have strong feelings about how to structure the cells-gtk tree? you had flattened it in cvs, I had it restructured to match the old cells-gtk (so I could merge in my patches). Which one do you prefer if any? If you don't care either way I will try and restructure cvs to match the old cells-gtk tree structure for the sake of consistency.
(2) Tree View
Omigod! I did an inspector at one point and used it to inspect the inspector window itself. Then I navigated down to the actual widgets in view and watched as the inspector showed things like the mouse-over state dynamically (without asking the inspector to refresh). I seem to recall adding some Cells internals to make it work, tho. In this screenshot:
Gotta love (+ lisp cells). test-gtk has had that feature for a while, I think (at least longer than I have been on board). I remeber it took me a while to understand what was *really* going on when I saw it first.
(4) Threading
It is relly nice and lispy to use the repl to change properties of the windows currently displayed and to add and remove widgets interactively (especially if you have a background in C) -- but I don't know whether that works in MS Windows. Just checked, bordeaux-threads on windows does not support Allegro. Bummer.
I will be doing repl stuff during my talk -- ACL runs a separate process from the IDE to execute Lisp. We just need to have a breather in the event loop handling to give the IDE enough cycles to be responsive.
Cooperative scheduling, heh? Apparently cells-gtk on Lispworks/Windows has similar issues (there's a work around somewhere in cells-gtk). So far I haven't seen that with sbcl/linux. Maybe threading works better over here, maybe gtk does a better job of keeping the load in the main loop know.
Those issues aside, doing repl stuff while having a gui up is really neat, isn't it?
OK, don't make yourself crazy on my account.
Well, I'd love to have these things up and running in my thesis talk two months from now, so it won't hurt to be a little ahead of schedule.
In fact, I already have Cells-gtk as I had it last running on my laptop, I might just leave it at that. I am going to try to get to Celtk, Cello, TripleCells (lite integration with an RDF triple-store), Cells-Gtk, and OpenAIR (the cells/ajax bit andy is doing). Whew!
Wow, sounds like a great program. It seems next time they could save the trouble of inviting other speakers, and just let you talk for the whole two days. :-)
Anyway, good luck with all of it, and I am looking forward to watching the recording.
Cheers, Peter
Peter Hildebrandt wrote:
BTW, do you have strong feelings about how to structure the cells-gtk tree?
It's all yours. Maybe see if Peter Denno has some thoughts.
Those issues aside, doing repl stuff while having a gui up is really neat, isn't it?
"indistinguishable from magic" springs to mind.
I was really happy when someone opened my eyes to special variables and let me make dependency transparent, mostly for ease of coding, partly to baffle the unitiated. :)
Wow, sounds like a great program. It seems next time they could save the trouble of inviting other speakers, and just let you talk for the whole two days. :-)
That or two minutes, long enough to say, "Listen, just try it, there is no way I can get this across to you." :)
Well, I saw a cool demo for JQuery or OpenLaszlo or something that built something gee-whiz from scratch, I think I want to do that so they do get more of a feel for the beast.
kt
On Saturday 12 April 2008 12:51, Ken Tilton wrote:
Peter Hildebrandt wrote:
BTW, do you have strong feelings about how to structure the cells-gtk tree?
It's all yours. Maybe see if Peter Denno has some thoughts.
Hi Kenny,
What do you have in mind?
-
Andy Chambers -
Ken Tilton -
Peter Denno -
Peter Hildebrandt