From kennytilton at optonline.net Fri Jul 4 17:32:39 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Fri, 04 Jul 2008 13:32:39 -0400 Subject: [cells-devel] Re: cells and allegrocache. In-Reply-To: <908731.94716.qm@web55501.mail.re4.yahoo.com> References: <908731.94716.qm@web55501.mail.re4.yahoo.com> Message-ID: <486E5EB7.60805@optonline.net> I am responding by posting to cells-devel: > I hope you don't mind I ask how or what is the best way to persist cells in general. There is nothing genersl, because the process involves understanding Cells and ones persistent library and then writing several hundred lines of cleverness to make them work together with very specific leverage of the mechanisms offered by the persistence library. I believe for most people who use cells would also want them to persist them somehow. I loved it when I did it. Did you see my triple-cells hack? You build the FFI to get to Redland RDF and use that for persistence. I like RDF better anyway as a data model, perisstent or not. And Allegrocache seems to be complicated to be used with cells in this case. Yes, it would be pretty tricky for anyone not versed in Cells, and even then a solid amount of work. There is no magic hint to give you, it is just a question of glue: how does one make two mechanisms work together? cheers, ken From kennytilton at optonline.net Fri Jul 4 23:35:25 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Fri, 04 Jul 2008 19:35:25 -0400 Subject: [cells-devel] Re: cells and allegrocache. In-Reply-To: <486E5EB7.60805@optonline.net> References: <908731.94716.qm@web55501.mail.re4.yahoo.com> <486E5EB7.60805@optonline.net> Message-ID: <486EB3BD.3030706@optonline.net> Lost some quotations. More explitly I was asked: >> I hope you don't mind I ask how or what is the best way to persist > cells in general. I responded: There is nothing genersl, because the process involves understanding Cells [too mush to tell] and ones persistent library and then writing several hundred lines of cleverness to make them work together with very specific leverage of the mechanisms offered by the persistence library. I was asked: > I believe for most people who use cells would also > want them to persist them somehow. > I responded: I loved it when I did it. Did you see my triple-cells hack? You [could start with that, thn] build the FFI to get to Redland RDF and use that for persistence. I like RDF better anyway as a data model, perisstent or not. I was asked: > And Allegrocache seems to be > complicated to be used with cells in this case. > I respondend: Yes, it would be pretty tricky for anyone not versed in Cells, and even then a solid amount of work. There is no magic hint to give you, it is just a question of glue: how does one make two mechanisms work together? kt From kentilton at gmail.com Sat Jul 5 01:02:25 2008 From: kentilton at gmail.com (Kenny) Date: Fri, 04 Jul 2008 21:02:25 -0400 Subject: [cells-devel] It was a good name in theory....Name That Software! Contest Message-ID: <486EC821.8010609@gmail.com> I was gonna call it Theory Y Algebra just to confuse people but nobody noticed the second Y and thought it was Theory Algebra, missing the whole point. Then i was going to call it Practical Algebra since it is all about practice, but too many things are called Practical Algebra. So I went back to my original idea, good old solid simple but anglo-elegant Tiltons Algebra and that is what it will be unless i go with a goofy name, like a candidate that got a strong positive reaction from one focus group member: Stuck on Algebra! Bit of a pun there since it can mean you are having trouble with it or that you love it. Not much of a contest since I am not asking for other names, but what do you think? __ Tiltons Algebra __ Stuck On Algebra! Voting ends in a week! Thx, kenny From mikko.ahonen at grupposoftware.com Tue Jul 8 22:18:53 2008 From: mikko.ahonen at grupposoftware.com (Mikko Ahonen) Date: Wed, 9 Jul 2008 01:18:53 +0300 Subject: [cells-devel] Inheritance from model, not model-object? Message-ID: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> Hello, Am I misunderstanding something, or should "model-object" in this error be replaced with "model"? "If no superclass of X inherits directly or indirectly from model-object, model-object must be included as a direct super-class in the defmodel form for X" Btw, cells seems very intuitive way to do GUI programming. I am new to both Lisp and GUI programming. The first thing I thought after getting mingled in some complicated callback hierarchies was that there must be a better way in Lisp to do this. And luckily I found cells. Thanks. Best regards, Mikko Ahonen -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennytilton at optonline.net Tue Jul 8 22:41:47 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Tue, 08 Jul 2008 18:41:47 -0400 Subject: [cells-devel] Inheritance from model, not model-object? In-Reply-To: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> References: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> Message-ID: <4873ED2B.9080308@optonline.net> Mikko Ahonen wrote: > Hello, > > Am I misunderstanding something, or should "model-object" in this error > be replaced with "model"? > > "If no superclass of X inherits directly or indirectly from > model-object, model-object must be included as a direct super-class in > the defmodel form for X" My intention with the bifurcation of model-object and model is that model-object would have everything needed for Cells, while model has the stuff I normally use. But the idea was that if someone really wanted to go nuts with experimenting with variations on Cells, model-object would be the bare minimum needed for Cells itself. The other stuff is about the important business of managing a bunch of cells-driven objects, but one could do that in lotsa ways. If you saw something in model absolutely necessary for Cells to work, I goofed. :) > > Btw, cells seems very intuitive way to do GUI programming. Yeah, I have been doing it for years and I still am amazed at how easy it is to build highly dynamic interfaces that really add value for the user. We really flipped over it when we stumbled on it by accident back in '95. > I am new to > both Lisp and GUI programming. The first thing I thought after getting > mingled in some complicated callback hierarchies was that there must be > a better way in Lisp to do this. And luckily I found cells. Thanks. Cool. Philip Eby also talks about callback madness as motivating his Cells clone, Trellis (a Python project). I never thought about it as a callback thing, but it seems to be a recurring theme. :) cheers, ken From mikko.ahonen at grupposoftware.com Tue Jul 8 23:25:18 2008 From: mikko.ahonen at grupposoftware.com (Mikko Ahonen) Date: Wed, 9 Jul 2008 02:25:18 +0300 Subject: [cells-devel] Inheritance from model, not model-object? In-Reply-To: <4873ED2B.9080308@optonline.net> References: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> <4873ED2B.9080308@optonline.net> Message-ID: <5fd426040807081625y235db93doe948c28b685b53ba@mail.gmail.com> On Wed, Jul 9, 2008 at 1:41 AM, Kenny Tilton wrote: Thanks for the quick reply, If you saw something in model absolutely necessary for Cells to work, I > goofed. :) > My question was based on error message that indicated that model-object was not exported (or something) when I was trying to inherit from model-object. I looked into doc/*.lisp, test-cells/* and also cello, and only found references to model, not model-object. I figured that perhaps model-object was some left-over from previous versions, or something. This is what I got: "Error during finalization of class #: Cannot compute the class precedence list of # because the following class is not finalized #" (this is LispWorks 5.1 on OS X if it makes any difference, and extending a GUI component) Works fine with model, though. Cool. Philip Eby also talks about callback madness as motivating his Cells > clone, Trellis (a Python project). I never thought about it as a callback > thing, but it seems to be a recurring theme. :) > Not that I would know much about GUIs, but perhaps it depends on the model used in the GUI library. I am now experimenting with LispWorks CAPI. For example this screen become a hassle immediately with callbacks, even if it is quite simple in principle: User is editing two-level hierarchical data. Thus, parent objects have children. This view shows single parent. The form on the right is used to edit a single child. On the left I have preview of each child for this parent. The child previews are clickable, and select the object for editing. When I edit the data, the underlying model should obviously change. So should the preview, if corresponding fields change, as well as the title and some other parts of the view as well. Best regards, Mikko Ahonen -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennytilton at optonline.net Wed Jul 9 01:04:12 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Tue, 08 Jul 2008 21:04:12 -0400 Subject: [cells-devel] Inheritance from model, not model-object? In-Reply-To: <5fd426040807081625y235db93doe948c28b685b53ba@mail.gmail.com> References: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> <4873ED2B.9080308@optonline.net> <5fd426040807081625y235db93doe948c28b685b53ba@mail.gmail.com> Message-ID: <48740E8C.7070405@optonline.net> Mikko Ahonen wrote: > On Wed, Jul 9, 2008 at 1:41 AM, Kenny Tilton > wrote: > > Thanks for the quick reply, > > If you saw something in model absolutely necessary for Cells to > work, I goofed. :) > > > My question was based on error message that indicated that model-object > was not exported (or something) when I was trying to inherit from > model-object. Oh, I am forever having to export things that should have been exported in the first place except I never actually do that (go through a library, think about what should and should not be exported, then do so). So, yeah, model-object should be exported. In case it was not clear, please do not take any failure to export as a /definite/ sign that you have gone wrong. Mind you, Cells has been used so heavily and is so small that normally anything that should be exported is exported, but this design bit is where I thought "well, someone might want to do this differently, let's not lock anything in" and we just have not yet run into that someone. ) > > I looked into doc/*.lisp, test-cells/* and also cello, and only found > references to model, not model-object. I figured that perhaps > model-object was some left-over from previous versions, or something. I understand. No, as I said "model" is my preferred way of managing an object-space if you will, and that is all my code (and some of Frank's) so it just looks as if model rules the Cells world. > > This is what I got: > > "Error during finalization of class #: Cannot > compute the class precedence list of # > because the following class is not finalized # MODEL-OBJECT 223FBB43>" > > (this is LispWorks 5.1 on OS X if it makes any difference, and extending > a GUI component) > > Works fine with model, though. Go with model, the family class and lots of other good stuff assumes that. You might be able to leverage some of that code. > > Cool. Philip Eby also talks about callback madness as motivating his > Cells clone, Trellis (a Python project). I never thought about it as > a callback thing, but it seems to be a recurring theme. :) > > > Not that I would know much about GUIs, but perhaps it depends on the > model used in the GUI library. I am now experimenting with LispWorks CAPI. OK, that is the second explanation: with Cells we really have to build an abstraction that hides the callbacks, so in my GUI work the first three days are spent hiding the callbacks so I forget they are there. :) If you look at Celtk or Cells-Gtk you'll see how I feed information from callbacks into the cells web so I can forget they are there. (Cello is just a wrapper for celtk.) > > For example this screen become a hassle immediately with callbacks, even > if it is quite simple in principle: > > User is editing two-level hierarchical data. Thus, parent objects have > children. This view shows single parent. The form on the right is used > to edit a single child. On the left I have preview of each child for > this parent. The child previews are clicAkable, and select the object for > editing. When I edit the data, the underlying model should obviously > change. So should the preview, if corresponding fields change, as well > as the title and some other parts of the view as well. ISTR Peter H. tackling something similar with Cells-GTk and having to extend the GTk wrapper to be more aware of such things. You remind me of a recent mindfuck: I have this math application that has a cool wysiwyg math editor. Kids can be working on multi-problem assignments, but I show them only one at a time. A grid of little blank rectangles signifies the collection, and they click on any to call up that problem for work. I had already done textual tooltips, and it occurred to me that my gui was so cool I could just as easily make a hairy math expression into a tooltip. Now I knew they might need time to think so these tooltips do not go away after a few seconds as per standard. And a tooltip sure does not capture the edit focus. Omigod. Without writing a line of code I tried it: yep. If I moved the mouse over the icon for a problem and got the tooltip, I could then continue editing the problem and see both the problem and its tooltip change at the same time! Not an important feature , just an amazing manifestation of the power of the paradigm: a behavior like that /by accident/! btw, if you are going to stick with CAPI the way to go is replicate the Celtk/Cells-Gtk/OpenAIR family of wrappers with sufficient glue to more or less make CAPI disappear. I am pretty busy these days, but I have an obscure interest in seeing that happen, and it is not all that hard, I'd be happy to help. Otoh, Cells-Gtk or Celtk free you from a Lispworks lock-in (not that that is a bad thing). kt From mikko.ahonen at grupposoftware.com Wed Jul 9 07:41:51 2008 From: mikko.ahonen at grupposoftware.com (Mikko Ahonen) Date: Wed, 9 Jul 2008 10:41:51 +0300 Subject: [cells-devel] Inheritance from model, not model-object? In-Reply-To: <48740E8C.7070405@optonline.net> References: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> <4873ED2B.9080308@optonline.net> <5fd426040807081625y235db93doe948c28b685b53ba@mail.gmail.com> <48740E8C.7070405@optonline.net> Message-ID: <5fd426040807090041y257eb223u4f17555cb09881b3@mail.gmail.com> On Wed, Jul 9, 2008 at 4:04 AM, Kenny Tilton wrote: > Go with model, the family class and lots of other good stuff assumes that. > You might be able to leverage some of that code. > OK. > OK, that is the second explanation: with Cells we really have to build an > abstraction that hides the callbacks, so in my GUI work the first three days > are spent hiding the callbacks so I forget they are there. :) I ended up writing some wrappers around CAPI already to simplify some setf-ery, so this is not a biggie. This way setf-every was not too bad, but when I extrapolated the work that needs to be done, the vision was callback hell. > If you look at Celtk or Cells-Gtk you'll see how I feed information from > callbacks into the cells web so I can forget they are there. (Cello is just > a wrapper for celtk.) I'll look into them more deeply. > Not an important feature , just an amazing manifestation of the power of > the paradigm: a behavior like that /by accident/! Sounds very cool. So far the biggest mind-fuck with my limited experience of cells is how it completely turns programming on its' head. Almost everything turns into dataflow, which seems to at least temporarily increase the number of cells. The thought process is interesting. For example, I denote the selection of preview by flipping background and foreground colors. The parent container knows the selected child. In setf-ery, the (setf selected) method of the child would change the colors. First idea is to make each child have selected cell watching the selected cell of parent. Then define observer on the selected of the child to actually change the colors. When I did that, I realized the need to ask for the colors from the parent, and setf them to local variables. Next, I noticed that hey, maybe foreground and background could be cells instead of local variables, and watching for the selected cell of the child. I ended up with one-line and 3 line observers for background and foreground, instead of single 15-line observer for the selected. Now the next thought is that perhaps I could get rid of some of the intermediate cells, in this case the selected cell of the child. I guess when you turn programming on its' head, the dataflow becomes the "difficult part". My intuition says that at least to some point more intermediate cells makes dataflow more visible and reusable. So I kept the selected. But this may be because my background is in C shop where code readability was emphasized. > btw, if you are going to stick with CAPI the way to go is replicate the > Celtk/Cells-Gtk/OpenAIR family of wrappers with sufficient glue to more or > less make CAPI disappear. I am pretty busy these days, but I have an obscure > interest in seeing that happen, and it is not all that hard, I'd be happy to > help. Otoh, Cells-Gtk or Celtk free you from a Lispworks lock-in (not that that is > a bad thing). > Great. On this project I work with an user interface designer who is very visually oriented. Tk is a non-starter because the controls do not have a polished look. (Yeah, I know.). CAPI provides native GUI controls that are barely sufficient. But CAPI already limits us, however. For example, OS X Cocoa supports three sizes of controls, whereas CAPI has only one. I also don't like vendor lock-ins. What I would prefer would be an open-sourced version of something like CAPI, and cells-CAPI to go along with it. I think splitting this into two different projects is better than single one, because you can get those cells skeptics involved, too. I think open source CAPI could be one of the biggest things missing from Lisp right now. The first step into that direction would be to develop open source cells-CAPI. Perhaps it would also get more people interested in cells. I am ready to incrementally work towards something like this during this project, but of course, my deadline is impossible (like always). Best regards, Mikko Ahonen -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennytilton at optonline.net Wed Jul 9 13:38:25 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Wed, 09 Jul 2008 09:38:25 -0400 Subject: [cells-devel] Inheritance from model, not model-object? In-Reply-To: <5fd426040807090041y257eb223u4f17555cb09881b3@mail.gmail.com> References: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> <4873ED2B.9080308@optonline.net> <5fd426040807081625y235db93doe948c28b685b53ba@mail.gmail.com> <48740E8C.7070405@optonline.net> <5fd426040807090041y257eb223u4f17555cb09881b3@mail.gmail.com> Message-ID: <4874BF51.1@optonline.net> Mikko Ahonen wrote: > On Wed, Jul 9, 2008 at 4:04 AM, Kenny Tilton > wrote: > > Go with model, the family class and lots of other good stuff assumes > that. You might be able to leverage some of that code. > > > OK. > > > OK, that is the second explanation: with Cells we really have to > build an abstraction that hides the callbacks, so in my GUI work the > first three days are spent hiding the callbacks so I forget they are > there. :) > > > I ended up writing some wrappers around CAPI already to simplify some > setf-ery, so this is not a biggie. This way setf-every was not too bad, > but when I extrapolated the work that needs to be done, the vision was > callback hell. Yes. Brooks identified this as the big problem with software development in general: an exponential explosion of complexity as the number and kinds of data points grows in ever larger applications, because these data points tend to be interdependent. Any one change must be propagated reliably to all the right other data points, in the right order. That is not only hard, it is also not fun, nice to have that managed automatically just as modern languages manage memeory automatically. > > > If you look at Celtk or Cells-Gtk you'll see how I feed information > from callbacks into the cells web so I can forget they are there. > (Cello is just a wrapper for celtk.) > > > I'll look into them more deeply. > > > Not an important feature , just an amazing manifestation of the > power of the paradigm: a behavior like that /by accident/! > > > Sounds very cool. So far the biggest mind-fuck with my limited > experience of cells is how it completely turns programming on its' head. > Almost everything turns into dataflow, ... Yes, programming reverses direction. Instead of a programmer sitting there handling a state change figuring out how to push the change throughout the rest of the application, they just write standalone black-box rules and the Cells engine tkes any change and pulls the change thru the rest of the application. And it is hard to do just a little dataflow, because once you start on this the cells is where the action is, so to see a change other things must be cells, too. The good news is that cells are more fun anyway, so it is OK that one gets forced into using cells everywhere. :) which seems to at least > temporarily increase the number of cells. I won't have time to write it up, but I inadvertently stress-tested Cells. My app got a little sluggish on some things when I had about five thousand instances and over eighty thousand Cells. I fixed my bug and got it down to a couple thousand instances and (IIRC) twenty thousand Cells and things are quite zippy. They absolutely screamed when I activated OpenGL display lists a couple of places, but then i got into some imaging bugs and I really do not have time to mess with OpenGL right now. Anyway, I was surprised and made a mental note to stop thinking about Cells as expensive. They may even be faster: i did another benchmark to see how much work was being done on each change to ensure the Cells integrity and it was much less than I thought. I knew cells guaranteed that only rules that needed to run would run and that that would make things optimal, but what I also saw was that the integrity rules did not force Cells to visit almost every cell to see if it should run, as I had feared. So i would wait for performance to become a problem. If/when it does, you can probably uses synaptic Cells to minimize recomputation, or perhaps the application will suggest a new cells trick -- recent work on a Cells-ODE had me implement user control over propagation so one could do a bunch of state changes and propagate just once. ie, where the user knows multiple state changes can safely be treated as one, they can now get that by wrapping them in with-user-propagation (or whatever I called it). > > The thought process is interesting. For example, I denote the selection > of preview by flipping background and foreground colors. The parent > container knows the selected child. In setf-ery, the (setf selected) > method of the child would change the colors. First idea is to make each > child have selected cell watching the selected cell of parent. > > Then define observer on the selected of the child to actually change the > colors. When I did that, I realized the need to ask for the colors from > the parent, and setf them to local variables. Next, I noticed that hey, > maybe foreground and background could be cells instead of local > variables, and watching for the selected cell of the child. I ended up > with one-line and 3 line observers for background and foreground, > instead of single 15-line observer for the selected. Welcome to the club. Feels like a free lunch, eh? :) > > Now the next thought is that perhaps I could get rid of some of the > intermediate cells, in this case the selected cell of the child. I guess > when you turn programming on its' head, the dataflow becomes the > "difficult part". My intuition says that at least to some point more > intermediate cells makes dataflow more visible and reusable. So I kept > the selected. But this may be because my background is in C shop where > code readability was emphasized. > > > btw, if you are going to stick with CAPI the way to go is replicate > the Celtk/Cells-Gtk/OpenAIR family of wrappers with sufficient glue > to more or less make CAPI disappear. I am pretty busy these days, > but I have an obscure interest in seeing that happen, and it is not > all that hard, I'd be happy to help. > > > Otoh, Cells-Gtk or Celtk free you from a Lispworks lock-in (not that > that is a bad thing). > > > Great. > > On this project I work with an user interface designer who is very > visually oriented. Tk is a non-starter because the controls do not have > a polished look. (Yeah, I know.). Do you know about the Tile package? I believe they are trying to be more native on the widgets. There is Tile support in Celtk, just not sure how robust it is -- I make all my own widgets using OpenGL. Does your designer need "native", or do they just need "beautiful"? Perhaps they would get off on designing their own widgets. > CAPI provides native GUI controls that > are barely sufficient. But CAPI already limits us, however. For example, > OS X Cocoa supports three sizes of controls, whereas CAPI has only one. > > I also don't like vendor lock-ins. What I would prefer would be an > open-sourced version of something like CAPI, and cells-CAPI to go along > with it. I think splitting this into two different projects is better > than single one, because you can get those cells skeptics involved, too. > I think open source CAPI could be one of the biggest things missing from > Lisp right now. > > The first step into that direction would be to develop open source > cells-CAPI. Perhaps it would also get more people interested in cells. I think that will require OpenAIR, the web 2.0 incarnation of cells. As for getting more people interested: Cells picks up one new user every year, and it looks like you are the one for 2008 -- I have six months before I have to worry about finding another user. > I am ready to incrementally work towards something like this during this > project, but of course, my deadline is impossible (like always). Talk to your designer, and check out my beach rants on Google video. What I am sensing is that widget sets are terribly constraining when it comes to building fluent GUI experiences for users. Does your designer also have an interest in the user experience, as well as the visual quality? In cello I have core classes like view and control and then i just make up an interactive screen element as i need it, with whatever rendering and event handling I have in mind. Instead of forcing my design into the pigeonholes determined by a fixed widget set, I just follow the application and the GUI elements follow me. :) cheers, ken From dwvdsfc at common-lisp.net Wed Jul 9 14:59:27 2008 From: dwvdsfc at common-lisp.net (Florence) Date: Wed, 09 Jul 2008 23:59:27 +0900 Subject: [cells-devel] Viagra and Cialis will help you anytime. Message-ID: <4874D24F.3000901@common-lisp.net> Can't find proper medication for your penis? Legal and quality medications at low price only. Cheap way to boost your sexual strength! Forget about problems with Canadian pharmacy! http://harngu.edikalpeng.com/?62829468 High-quality service is guaranteed From larry at theclapp.org Wed Jul 9 15:00:43 2008 From: larry at theclapp.org (Larry Clapp) Date: Wed, 9 Jul 2008 11:00:43 -0400 Subject: [cells-devel] Inheritance from model, not model-object? In-Reply-To: <4874BF51.1@optonline.net> References: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> <4873ED2B.9080308@optonline.net> <5fd426040807081625y235db93doe948c28b685b53ba@mail.gmail.com> <48740E8C.7070405@optonline.net> <5fd426040807090041y257eb223u4f17555cb09881b3@mail.gmail.com> <4874BF51.1@optonline.net> Message-ID: <20080709150043.GC16804@cupid.theclapp.org> On Wed, Jul 09, 2008 at 09:38:25AM -0400, Kenny Tilton wrote: > As for getting more people interested: Cells picks up one new user > every year, and it looks like you are the one for 2008 -- I have six > months before I have to worry about finding another user. :) I am changing jobs soon, and I'm hopeful that I'll be able to build a good business case for using both CL and Cells. I use Lispworks, but I might have to "settle" for ECL or SBCL. We'll see. I'm especially hopeful re: Cells because we're gonna be building v3 of an application that started life as an Excel spreadsheet. -- L From kennytilton at optonline.net Wed Jul 9 16:10:31 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Wed, 09 Jul 2008 12:10:31 -0400 Subject: [cells-devel] Inheritance from model, not model-object? In-Reply-To: <20080709150043.GC16804@cupid.theclapp.org> References: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> <4873ED2B.9080308@optonline.net> <5fd426040807081625y235db93doe948c28b685b53ba@mail.gmail.com> <48740E8C.7070405@optonline.net> <5fd426040807090041y257eb223u4f17555cb09881b3@mail.gmail.com> <4874BF51.1@optonline.net> <20080709150043.GC16804@cupid.theclapp.org> Message-ID: <4874E2F7.3040703@optonline.net> Larry Clapp wrote: > On Wed, Jul 09, 2008 at 09:38:25AM -0400, Kenny Tilton wrote: >> As for getting more people interested: Cells picks up one new user >> every year, and it looks like you are the one for 2008 -- I have six >> months before I have to worry about finding another user. > > :) > > I am changing jobs soon, and I'm hopeful that I'll be able to build a > good business case for using both CL and Cells. I use Lispworks, but > I might have to "settle" for ECL or SBCL. We'll see. > > I'm especially hopeful re: Cells because we're gonna be building v3 of > an application that started life as an Excel spreadsheet. I remember someone mentioning that a big problem in tall buildings was the amount of business logic hidden in spreadsheets. I have this dream fantasy of getting rich just by writing a parser that would convert a spreadsheet to the equivalent Lisp/Cells application where they could see the rules anyway. kt From mikko.ahonen at grupposoftware.com Thu Jul 10 21:54:58 2008 From: mikko.ahonen at grupposoftware.com (Mikko Ahonen) Date: Fri, 11 Jul 2008 00:54:58 +0300 Subject: [cells-devel] Inheritance from model, not model-object? In-Reply-To: <4874BF51.1@optonline.net> References: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> <4873ED2B.9080308@optonline.net> <5fd426040807081625y235db93doe948c28b685b53ba@mail.gmail.com> <48740E8C.7070405@optonline.net> <5fd426040807090041y257eb223u4f17555cb09881b3@mail.gmail.com> <4874BF51.1@optonline.net> Message-ID: <5fd426040807101454k6c94746bwe9171066b7c19b6e@mail.gmail.com> > So i would wait for performance to become a problem. If/when it does, you > can probably uses synaptic Cells to minimize recomputation, or perhaps the > application will suggest a new cells trick -- recent work on a Cells-ODE > had me implement user control over propagation so one could do a bunch of > state changes and propagate just once. ie, where the user knows multiple > state changes can safely be treated as one, they can now get that by > wrapping them in with-user-propagation (or whatever I called it). > > Great. Luckily, the performance will probably not be a problem in this project. Welcome to the club. Feels like a free lunch, eh? :) > Yes. when I saw Cells, I immediately also figured that if I had been more experienced, this kind of approach would have helped me with the nastiest programming challenge I have ever encountered: state management of database hot-standby feature. There, each instance is independent, but they must also keep track of each others (assumed) state. And there are both asynchronous and synchronous events coming in. Doing everything manually really sucked big time. > Do you know about the Tile package? I believe they are trying to be more > native on the widgets. There is Tile support in Celtk, just not sure how > robust it is -- I make all my own widgets using OpenGL. I briefly looked at Tile. Looks like it could do the trick, but some stuff I get free. > Does your designer need "native", or do they just need "beautiful"? Perhaps > they would get off on designing their own widgets. The requirement is "beautiful". I just see "native" as the trade-off between effort and beautifulness which everybody can agree on for this version of the end-product. If the project succeeds we will go to self-designed widgets. As for getting more people interested: Cells picks up one new user every > year, and it looks like you are the one for 2008 -- I have six months before > I have to worry about finding another user. > :) Talk to your designer, and check out my beach rants on Google video. What I > am sensing is that widget sets are terribly constraining when it comes to > building fluent GUI experiences for users. Heh, I checked the beach rants. The math learning application seemed really cool. > Does your designer also have an interest in the user experience, as well as > the visual quality? In cello I have core classes like view and control and > then i just make up an interactive screen element as i need it, with > whatever rendering and event handling I have in mind. Instead of forcing my > design into the pigeonholes determined by a fixed widget set, I just follow > the application and the GUI elements follow me. :) True, we are mostly interested in the user experience, eye-candy is secondary. Our needs are actually not very complicated, widget-wise. Drag and drop is the most complex feature we need. Otherwise, it is just data entry. My approach is basically the same as yours. I created class for the preview etc. I just probably use little bit higher level widgets as building blocks. Minimally, clickable image with coordinate information is sufficient to create a buttons etc. LispWorks seems to be perfect fit for this first project. Building the UI is really hassle-free, and end-result seems reasonably good. > I remember someone mentioning that a big problem in tall buildings was the amount of > business logic hidden in spreadsheets. I have this dream fantasy of getting rich just by writing > a parser that would convert a spreadsheet to the equivalent Lisp/Cells application where they > could see the rules anyway. If you want to become filthy rich, write a FileMaker to Lisp/Cells/Postgres converter with royalty-free deployment. Right now, each deployed application instance costs $$$. Application would actually be quite straightforward, as you can already copy-paste FileMaker views as XML. Of course, you would bankrupt billion-dollar business as a side-effect, so beware for the sunglassed men in black helicopters. Best regards, Mikko Ahonen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikko.ahonen at grupposoftware.com Thu Jul 10 22:29:29 2008 From: mikko.ahonen at grupposoftware.com (Mikko Ahonen) Date: Fri, 11 Jul 2008 01:29:29 +0300 Subject: [cells-devel] Controlling order of initialization? Message-ID: <5fd426040807101529v182f6eebk2bf55b75fb3ea52e@mail.gmail.com> Hmm, here follows a question about controlling the order of initialization. For example, let's assume we want to create a radio button group with individual radio buttons as kids. The invidual radio buttons are generated automatically based on the arguments passed to make-instance of the radio button groups. Thus, the kids are generated in the initialize-instance of the radio button group. They must get created before call to apply-next-method. The problem is that when I generate the child here, it wants to read stuff from the parent, which is not yet completely initialized. For example, it wants to read which kid is selected (parent's selected cell) before any kids even exist! I guess this is more generic problem of controlling the order of initialization of children, and perhaps delaying it until after the initialization of the parent. How do people usually go about doing this? I can think of some work-arounds. For example set parent's selected cell to nil, and then ignore this value in kids. Or define some new state cell in the parent, which children watch for. But isn't this a quite generic need in cells programs? Best regards, Mikko Ahonen -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennytilton at optonline.net Thu Jul 10 22:36:53 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Thu, 10 Jul 2008 18:36:53 -0400 Subject: [cells-devel] Inheritance from model, not model-object? In-Reply-To: <5fd426040807101454k6c94746bwe9171066b7c19b6e@mail.gmail.com> References: <5fd426040807081518g16976326kf277a15f47d5b43d@mail.gmail.com> <4873ED2B.9080308@optonline.net> <5fd426040807081625y235db93doe948c28b685b53ba@mail.gmail.com> <48740E8C.7070405@optonline.net> <5fd426040807090041y257eb223u4f17555cb09881b3@mail.gmail.com> <4874BF51.1@optonline.net> <5fd426040807101454k6c94746bwe9171066b7c19b6e@mail.gmail.com> Message-ID: <48768F05.8020405@optonline.net> Mikko Ahonen wrote: > > So i would wait for performance to become a problem. If/when it > does, you can probably uses synaptic Cells to minimize > recomputation, or perhaps the application will suggest a new cells > trick -- recent work on a Cells-ODE had me implement user control > over propagation so one could do a bunch of state changes and > propagate just once. ie, where the user knows multiple state changes > can safely be treated as one, they can now get that by wrapping them > in with-user-propagation (or whatever I called it). > > > Great. Luckily, the performance will probably not be a problem in this > project. > Kenny wrote: > Welcome to the club. Feels like a free lunch, eh? :) Based on the past few days' experience allow me to qualify that. Cells has a cost, but it is a linear one: sorting out dependency screw-ups. Sometimes I create in one lexical block of code quite a deep structure, and if I happen not to wrap the initialization of a child in a rule and that initialization hits another cell (very likely) then the containing rule of that initialization (which wold have been the factory for that level of widgets!) ends up dependent on something it should not depeend on. What is astonishing to me is that this normally works, even though it means that subtree of the GUI hierarchy was being forever re-instantiated! But I have become accustomed to being astonished this way, because it has happened from the beginning: things that should not work tend to go quite well 99% of the time. In this case I had a classic foreign reference (my GUI "math keypad" looked at the Algebra being edited so it could offer little keys for the variables in use) and when some structure got pulled out from under it it ended up looking at dead instances. So I just fixed things so the foreign reference was in a rule and would stay current with the changing landscape. One thing that is going on, btw, is improvements for Cells debugging, including in part me figuring out something I had missed about the ACL IDE. But re debugging, this brings me round to my main reason for responding. At ECLM I was approached after my talk by an engineer from Lispworks. He astutely guessed that Cells presented challenges for debugging. I confirmed that one direction of improvement for Cells would be enhance diagnostics and debugging. But that was not the point I was getting at. I ended up playfully suggesting CAPI get a Cells layer, hoping to land a project to do so. The engineer scoffed at the idea, saying there would have to be a lot of value in it for their customers before they would consider such a travesty, and he did not see any value. :) Since he already had seen Cells and how it worked, I suggested to him the problem might be that he is a compiler person, not an application developer. He actually assented to this, without budging. So I have been enjoying greatly that the newest Cells fan is also a heavy CAPI user, and it was so easy for you to see the advantages. I am reminded of the first folks shown Visialc. Most were programmers, one was a businessman. The programmers were bored by it, the businessman wanted to acquire the product. :) Sounds like you are doing great with your new product. Good luck with it! kt From kennytilton at optonline.net Fri Jul 11 02:04:13 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Thu, 10 Jul 2008 22:04:13 -0400 Subject: [cells-devel] Controlling order of initialization? In-Reply-To: <5fd426040807101529v182f6eebk2bf55b75fb3ea52e@mail.gmail.com> References: <5fd426040807101529v182f6eebk2bf55b75fb3ea52e@mail.gmail.com> Message-ID: <4876BF9D.7040100@optonline.net> Mikko Ahonen wrote: > Hmm, here follows a question about controlling the order of initialization. > > For example, let's assume we want to create a radio button group with > individual radio buttons as kids. The invidual radio buttons are > generated automatically based on the arguments passed to make-instance > of the radio button groups. > > Thus, the kids are generated in the initialize-instance of the radio > button group. They must get created before call to apply-next-method. > The problem is that when I generate the child here, it wants to read > stuff from the parent, which is not yet completely initialized. For > example, it wants to read which kid is selected (parent's selected cell) > before any kids even exist! > > I guess this is more generic problem of controlling the order of > initialization of children, and perhaps delaying it until after the > initialization of the parent. How do people usually go about doing this? > > I can think of some work-arounds. For example set parent's selected cell > to nil, and then ignore this value in kids. Or define some new state > cell in the parent, which children watch for. > > But isn't this a quite generic need in cells programs? Yes, and in the first few days I suspected this (instances coming and going while being interdependent) was where the apparent wonderfulness of Cells would fall apart. :) When it didn't I had another reason to suspect we were onto something Deeply Correct. But you do have to stay with the Cells paradigm, and it sounds like you are just a bit outside that if you are making kids in initialize-instance. Instead, make them in a rule on the kids slot of family. But "kids" was generalized recently so you can also make them in a rule on any slot for which you also specify ":owning t", a Cells extension. There should be a pile of examples in the test code. kt From achambers.home at googlemail.com Sat Jul 12 15:30:15 2008 From: achambers.home at googlemail.com (Andy Chambers) Date: Sat, 12 Jul 2008 16:30:15 +0100 Subject: [cells-devel] gui-geometry Message-ID: Hi Kenny, Is the gui-geometry in cells what powers layout in cello? Would it be worth somehow getting celtk to use this or should I just bite the bullet and jump to cello? If the former, when you have time, would you mind writing up a short guided tour of gui-geometry? Even if it was just to explain what all the abbreviations like :lx, :ly etc meant. Did you base it on some other framework and I could look up the docs for that? I was trying to port some of the demos in the tcl examples directory but I don't think the current celtk layout system is flexible enough to implement them exactly. Cheers, Andy ps Openair is still coming along. I got the xref stuff working on the lisp side but think I stumbled across a bug in jquery so nested widgets aren't being expanded properly. I'll come back to it again soon but I've got the GUI itch at the moment since I'm doing lots of xml stuff at work. -- ---- Andy Chambers Formedix Ltd From kennytilton at optonline.net Sat Jul 12 19:33:14 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Sat, 12 Jul 2008 15:33:14 -0400 Subject: [cells-devel] gui-geometry In-Reply-To: References: Message-ID: <487906FA.2030109@optonline.net> Andy Chambers wrote: > Hi Kenny, > > Is the gui-geometry in cells what powers layout in cello? Yes, and all my GUIs other than the Celtk stuff where I played along and used the pack mechanism. > Would it be > worth somehow getting celtk to use this or should I just bite the > bullet and jump to cello? It depends on whether you want a widget set. With Cello one gets raw control, event, and rendering primitives one assembles as needed into interactive GUI elements. The True Lisp Way, all the power in the world. With Celtk or Cells-Gtk you get a standard widget set but then are locked in to those. If you are fine with a fixed widget set, I believe you can combine gui-geometry with the Tk "place" mechanism and have a more powerful scheme than the Tk "pack" mechanism. I would add geometer to some class at the top of the Celtk hierarchy work out how best to deal with Tk place capabilities. They look rough, so I think you would build a hierarchy of rows and stacks of Tk widgets where nothng correpsonded to the lisp rows/stacks (geo-inline) on the Tk side, then have teh observers on the six geo params translate to global values in the toplevel window (and always specify "-in ." when placing). My only concern is whether you will then get "flashing" as things get repositioned dynamically, if you plan on doing that. Could turn out to be a lost cause. > > If the former, when you have time, would you mind writing up a short > guided tour of gui-geometry? Even if it was just to explain what all > the abbreviations like :lx, :ly etc meant. Did you base it on some > other framework and I could look up the docs for that? I am pretty busy, so here goes (and i will start by saying my approach translates (haha, pun unintended) nicely to OpenGLs view of coordinates, but that doc wont help). No big deal, the idea could not be simpler: I will describe an OpenGL-like geometry in which up is positive and negative is down, the opposite of most GUIs (so be careful!). I /do/ have some support in gui-geometry for the idea that the signs for up and down may vary -- look for macros like down and up that take care of using the right sign given some global parameter I forget. Every geometer (widget) has its own coordinate system defined by a local bounding rectangle, left top right and bottom. The word "local" gives us the "l", the individual bounds give us another l for left then r, t, and b for an end result of ll, lt, lr, and lb. We allow ll and lb to be specified because sometimes it is useful to specify negative values. ie, the origin (0 0) would not be at the bottom left corner. As an aside, i have never tried making those positive such that the origin would lie outside the bounding box, but that should be OK. In hierachies of geometers, their geometries nest. (px py) tell us where in our parent our origin falls. That's it! The arithmetic gets confusing when one tries fancy things like "I want to /appear/ ten pixels below a nephew widget" because then you take their geometry and translate up to the nearest common ascendant and then back down, but it is straightforward in the end and I have scads of litte utilities in there doing that, one will usually work. But i rarely do that any more. > > I was trying to port some of the demos in the tcl examples directory > but I don't think the current celtk layout system is flexible enough > to implement them exactly. Do they use pack or place? I /thought/ I set up Celtk to handle any packing one might need... bottomline is that a design imperative of Celtk was to be able to use Tk geometry (and everything else) from Lisp, so if something won't port I Just Screwed Up(tm). If they use place, I understand. Everything I found when I started was based on packing and i actually missed place at first. > ps Openair is still coming along. Is it gone from c-l.net? I looked yesterday and did not see it. Someone mentioned they would like to do AJAX+Cells is why I looked. I keep hoping this happens, it could be big for Lisp if it turns out as well as it seemed it would. > I got the xref stuff working on the > lisp side but think I stumbled across a bug in jquery so nested > widgets aren't being expanded properly. Glad to hear you got that far. Did you make a bug report? I'll come back to it again > soon but I've got the GUI itch at the moment since I'm doing lots of > xml stuff at work. > OK, it's all good. You might consider Cello or Cells-Gtk where Peter H is doing amazing things including pulling in OpenGL and Cairo. But I like Cello. Well, brace yourself for OpenGL. :) Tho I do have a burgeoning DSL for making pretty things appear that hides OpenGL. cheers, ken From kennytilton at optonline.net Sat Jul 12 19:55:16 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Sat, 12 Jul 2008 15:55:16 -0400 Subject: [cells-devel] gui-geometry In-Reply-To: References: Message-ID: <48790C24.60100@optonline.net> Andy Chambers wrote: > Hi Kenny, > > Is the gui-geometry in cells what powers layout in cello? Would it be > worth somehow getting celtk to use this or should I just bite the > bullet and jump to cello? I just realized I got lost in there somewhere: the Tcl examples /should/ port OK, with caveat that PLACE will require a little new glue and yes I still may have done an imperfect job of Just Exposing Tcl/Tk. Tk pack is pretty powerful, and even the place mechanism has some cute bells and whistles. It is not clear to me how much gui-geometry offers you over those unless you are really planning on having some fun with dynamic shifting GUIs, in which case yeah. I think it comes down to what I said last time: if you can do without the widgets, cello is great fun. A bear to build the first time, but folks here should be able to help. I believe Frank left a roadmap somewhere, at least in a cells-devel mailing. (We should add it to the doc in cvs, I htink.) kt From achambers.home at googlemail.com Sat Jul 12 23:18:48 2008 From: achambers.home at googlemail.com (Andy Chambers) Date: Sun, 13 Jul 2008 00:18:48 +0100 Subject: [cells-devel] gui-geometry In-Reply-To: <487906FA.2030109@optonline.net> References: <487906FA.2030109@optonline.net> Message-ID: On Sat, Jul 12, 2008 at 8:33 PM, Kenny Tilton wrote: > Is it gone from c-l.net? I looked yesterday and did not see it. Someone > mentioned they would like to do AJAX+Cells is why I looked. I keep hoping > this happens, it could be big for Lisp if it turns out as well as it seemed > it would. Nope. http://common-lisp.net/project/openair/ I think they setup two though which might be a little confusing. I'll have to ask them to delete the "openAIR" one. >> I got the xref stuff working on the >> lisp side but think I stumbled across a bug in jquery so nested >> widgets aren't being expanded properly. > > Glad to hear you got that far. Did you make a bug report? Not yet. Will do so though ---- Andy Chambers From peter.hildebrandt at gmail.com Sun Jul 13 10:22:26 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Sun, 13 Jul 2008 12:22:26 +0200 Subject: [cells-devel] gui-geometry In-Reply-To: <487906FA.2030109@optonline.net> References: <487906FA.2030109@optonline.net> Message-ID: <7758b2680807130322q6bf8dmbe7605bb681f160a@mail.gmail.com> On Sat, Jul 12, 2008 at 9:33 PM, Kenny Tilton wrote: > It depends on whether you want a widget set. With Cello one gets raw > control, event, and rendering primitives one assembles as needed into > interactive GUI elements. The True Lisp Way, all the power in the world. > > With Celtk or Cells-Gtk you get a standard widget set but then are locked in > to those. I just realized that all the time while I was arguing in favor of a fixed widget set, I have been walking towards raw control through the backdoor: I think my cairo-drawing-area widget ended up bringing in a cellosy GUI through the back door. The widget offers a canvas, a basic set of geometric prmitives such as lines, arcs, rectangles, and text, and some interactive functionality such as propagating drag and drop, select, and click events. Then I use the primitives to create my own widgets, in my case edges and vertices in a graph. Other (gtk) widgets such as a list view show the data of the currently selected graph element and enable the user to change the properties. Long story short, designing interactive dynamic GUI elements representing the underlying dynamic data structures is the Lisp Way, and it is so intriguing that one may follow it without even noticing (or: once you are on the Cells Way you can't avoid it). Or, from a different angle, there's something cellosy about cells-gtk3 now :-) Everybody have fun hacking, Peter (There's hardly any coding for me now but I get to do declarative programming in Excel -- as long as I don't call it that way :-)) > > If you are fine with a fixed widget set, I believe you can combine > gui-geometry with the Tk "place" mechanism and have a more powerful scheme > than the Tk "pack" mechanism. I would add geometer to some class at the top > of the Celtk hierarchy work out how best to deal with Tk place capabilities. > They look rough, so I think you would build a hierarchy of rows and stacks > of Tk widgets where nothng correpsonded to the lisp rows/stacks (geo-inline) > on the Tk side, then have teh observers on the six geo params translate to > global values in the toplevel window (and always specify "-in ." when > placing). > > My only concern is whether you will then get "flashing" as things get > repositioned dynamically, if you plan on doing that. Could turn out to be a > lost cause. > >> If the former, when you have time, would you mind writing up a short >> guided tour of gui-geometry? Even if it was just to explain what all >> the abbreviations like :lx, :ly etc meant. Did you base it on some >> other framework and I could look up the docs for that? > > I am pretty busy, so here goes (and i will start by saying my approach > translates (haha, pun unintended) nicely to OpenGLs view of coordinates, but > that doc wont help). No big deal, the idea could not be simpler: > > I will describe an OpenGL-like geometry in which up is positive and negative > is down, the opposite of most GUIs (so be careful!). I /do/ have some > support in gui-geometry for the idea that the signs for up and down may vary > -- look for macros like down and up that take care of using the right sign > given some global parameter I forget. > > Every geometer (widget) has its own coordinate system defined by a local > bounding rectangle, left top right and bottom. The word "local" gives us the > "l", the individual bounds give us another l for left then r, t, and b for > an end result of ll, lt, lr, and lb. We allow ll and lb to be specified > because sometimes it is useful to specify negative values. ie, the origin (0 > 0) would not be at the bottom left corner. As an aside, i have never tried > making those positive such that the origin would lie outside the bounding > box, but that should be OK. > > In hierachies of geometers, their geometries nest. (px py) tell us where in > our parent our origin falls. > > That's it! The arithmetic gets confusing when one tries fancy things like "I > want to /appear/ ten pixels below a nephew widget" because then you take > their geometry and translate up to the nearest common ascendant and then > back down, but it is straightforward in the end and I have scads of litte > utilities in there doing that, one will usually work. But i rarely do that > any more. > > >> >> I was trying to port some of the demos in the tcl examples directory >> but I don't think the current celtk layout system is flexible enough >> to implement them exactly. > > Do they use pack or place? I /thought/ I set up Celtk to handle any packing > one might need... bottomline is that a design imperative of Celtk was to be > able to use Tk geometry (and everything else) from Lisp, so if something > won't port I Just Screwed Up(tm). > > If they use place, I understand. Everything I found when I started was based > on packing and i actually missed place at first. > > >> ps Openair is still coming along. > > Is it gone from c-l.net? I looked yesterday and did not see it. Someone > mentioned they would like to do AJAX+Cells is why I looked. I keep hoping > this happens, it could be big for Lisp if it turns out as well as it seemed > it would. > >> I got the xref stuff working on the >> lisp side but think I stumbled across a bug in jquery so nested >> widgets aren't being expanded properly. > > Glad to hear you got that far. Did you make a bug report? > > I'll come back to it again >> >> soon but I've got the GUI itch at the moment since I'm doing lots of >> xml stuff at work. >> > > OK, it's all good. You might consider Cello or Cells-Gtk where Peter H is > doing amazing things including pulling in OpenGL and Cairo. But I like > Cello. Well, brace yourself for OpenGL. :) Tho I do have a burgeoning DSL > for making pretty things appear that hides OpenGL. > > cheers, ken > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel > From kennytilton at optonline.net Sun Jul 13 11:45:02 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Sun, 13 Jul 2008 07:45:02 -0400 Subject: [cells-devel] gui-geometry In-Reply-To: <7758b2680807130322q6bf8dmbe7605bb681f160a@mail.gmail.com> References: <487906FA.2030109@optonline.net> <7758b2680807130322q6bf8dmbe7605bb681f160a@mail.gmail.com> Message-ID: <4879EABE.3040909@optonline.net> Peter Hildebrandt wrote: > On Sat, Jul 12, 2008 at 9:33 PM, Kenny Tilton wrote: >> It depends on whether you want a widget set. With Cello one gets raw >> control, event, and rendering primitives one assembles as needed into >> interactive GUI elements. The True Lisp Way, all the power in the world. >> >> With Celtk or Cells-Gtk you get a standard widget set but then are locked in >> to those. > > I just realized that all the time while I was arguing in favor of a > fixed widget set, I have been walking towards raw control through the > backdoor: I think my cairo-drawing-area widget ended up bringing in a > cellosy GUI through the back door. > > The widget offers a canvas, a basic set of geometric prmitives such as > lines, arcs, rectangles, and text, and some interactive functionality > such as propagating drag and drop, select, and click events. Then I > use the primitives to create my own widgets, in my case edges and > vertices in a graph. Other (gtk) widgets such as a list view show the > data of the currently selected graph element and enable the user to > change the properties. > > Long story short, designing interactive dynamic GUI elements > representing the underlying dynamic data structures is the Lisp Way, > and it is so intriguing that one may follow it without even noticing > (or: once you are on the Cells Way you can't avoid it). Aha! The Unbearable Inevitability of The Lisp Way. Maybe my beach rant was not as silly as I thought it was: there is little chance even a fine widget set will be able to do everything we need from it, and clever hackers will roll up their sleeves and produce ad hoc interactive graphic elements from more primitive tools for drawing and event-handling rather than ship inferior applications so... all roads lead to Cello in the abstract. The funny thing is that until a few months ago I thought Cello Just Sucked because it did not have very many widgets -- but that wasn't a bug, it was a feature! So this is similar to your punch line only worse: i was following The Lisp Way without knowing it /and/ apologizng for it at the same time -- I remember trying without success to talk Frank G out of using Cello because of the missing widgets! Speaking of which, this weekend was a target release date for my Algebra app but last week led to a few days of refactoring to do a very nice and overdue generalization of the application's understanding of what constitutes a math problem. Thank god for my RDF experience -- instead of adding a few slots to a CLOS class I just said to hell with it, subject-predicate-object, I am done. > > Or, from a different angle, there's something cellosy about cells-gtk3 now :-) Have you had this experience?: I started to build the Algebra software using pretty much a Tk interface, intending to do Cello just inside the Togl widget where I would really need the lisp way. In about two seconds I decided it would be a horror programming one application with two application frameworks at the same time. Or do you have Cello/Gtk partitioned cleanly enough that they coexist gracefully? Possibly because of the evolutionary path in which Cello/Gtk was /always/ within the GTk framework? kt From kennytilton at optonline.net Sun Jul 13 11:54:33 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Sun, 13 Jul 2008 07:54:33 -0400 Subject: [cells-devel] gui-geometry In-Reply-To: <7758b2680807130322q6bf8dmbe7605bb681f160a@mail.gmail.com> References: <487906FA.2030109@optonline.net> <7758b2680807130322q6bf8dmbe7605bb681f160a@mail.gmail.com> Message-ID: <4879ECF9.7040005@optonline.net> >>> If the former, when you have time, would you mind writing up a short >>> guided tour of gui-geometry? Even if it was just to explain what all >>> the abbreviations like :lx, :ly etc meant. Did you base it on some >>> other framework and I could look up the docs for that? >> I am pretty busy, so here goes (and i will start by saying my approach >> translates (haha, pun unintended) nicely to OpenGLs view of coordinates, but >> that doc wont help). No big deal, the idea could not be simpler: >> >> I will describe an OpenGL-like geometry in which up is positive and negative >> is down, the opposite of most GUIs (so be careful!). I /do/ have some >> support in gui-geometry for the idea that the signs for up and down may vary >> -- look for macros like down and up that take care of using the right sign >> given some global parameter I forget. >> >> Every geometer (widget) has its own coordinate system defined by a local >> bounding rectangle, left top right and bottom. The word "local" gives us the >> "l", the individual bounds give us another l for left then r, t, and b for >> an end result of ll, lt, lr, and lb. We allow ll and lb to be specified >> because sometimes it is useful to specify negative values. ie, the origin (0 >> 0) would not be at the bottom left corner. As an aside, i have never tried >> making those positive such that the origin would lie outside the bounding >> box, but that should be OK. >> >> In hierachies of geometers, their geometries nest. (px py) tell us where in >> our parent our origin falls. >> >> That's it! The OpenGL tie in, by the way, is that all drawing is done relative to an abstract origin. In OpenGL I will create a chunk of code to draw the wheel of a car, standing on edge, hubcap to right, with the center of the axis running through the the hub as (0 0 0). My caller can then use glTranslate and glRotate to draw four wheels around a car, all hubcaps facing out, and even have then spinning. Likewise, all my drawing in GUIs using gui-geometry is done relative to an origin. kt From peter.hildebrandt at gmail.com Sun Jul 13 12:37:55 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Sun, 13 Jul 2008 14:37:55 +0200 Subject: [cells-devel] gui-geometry In-Reply-To: <4879EABE.3040909@optonline.net> References: <487906FA.2030109@optonline.net> <7758b2680807130322q6bf8dmbe7605bb681f160a@mail.gmail.com> <4879EABE.3040909@optonline.net> Message-ID: <7758b2680807130537n4b9d74bdp3df6a95dd11f7a0c@mail.gmail.com> On Sun, Jul 13, 2008 at 1:45 PM, Kenny Tilton wrote: > Peter Hildebrandt wrote: >> >> On Sat, Jul 12, 2008 at 9:33 PM, Kenny Tilton >> wrote: >>> >>> It depends on whether you want a widget set. With Cello one gets raw >>> control, event, and rendering primitives one assembles as needed into >>> interactive GUI elements. The True Lisp Way, all the power in the world. >>> >>> With Celtk or Cells-Gtk you get a standard widget set but then are locked >>> in >>> to those. >> >> I just realized that all the time while I was arguing in favor of a >> fixed widget set, I have been walking towards raw control through the >> backdoor: I think my cairo-drawing-area widget ended up bringing in a >> cellosy GUI through the back door. >> >> The widget offers a canvas, a basic set of geometric prmitives such as >> lines, arcs, rectangles, and text, and some interactive functionality >> such as propagating drag and drop, select, and click events. Then I >> use the primitives to create my own widgets, in my case edges and >> vertices in a graph. Other (gtk) widgets such as a list view show the >> data of the currently selected graph element and enable the user to >> change the properties. >> >> Long story short, designing interactive dynamic GUI elements >> representing the underlying dynamic data structures is the Lisp Way, >> and it is so intriguing that one may follow it without even noticing >> (or: once you are on the Cells Way you can't avoid it). > > Aha! The Unbearable Inevitability of The Lisp Way. Maybe my beach rant was > not as silly as I thought it was: there is little chance even a fine widget > set will be able to do everything we need from it, and clever hackers will > roll up their sleeves and produce ad hoc interactive graphic elements from > more primitive tools for drawing and event-handling rather than ship > inferior applications so... all roads lead to Cello in the abstract. Indeed. As programs grow more complex, dynamic, and/or customized (which is why we use Lisp, isn't it?), there will inevitably be situations which cannot be translated into standard widgets. OTOH, there's still the OO-and-nothing-else school of thought where everything stems from predefined templates, objects, snippets or whatever they call it. If your application is built from standard parts, the UI can be as well. But once you start tailoring your app to the problem and not to your toolbox, things start to look entirely different :-) > The funny thing is that until a few months ago I thought Cello Just Sucked > because it did not have very many widgets -- but that wasn't a bug, it was a > feature! So this is similar to your punch line only worse: i was following > The Lisp Way without knowing it /and/ apologizng for it at the same time -- > I remember trying without success to talk Frank G out of using Cello because > of the missing widgets! At this point I'd like to state clearly and boldy: "It depends". See below. > Speaking of which, this weekend was a target release date for my Algebra app > but last week led to a few days of refactoring to do a very nice and > overdue generalization of the application's understanding of what > constitutes a math problem. Thank god for my RDF experience -- instead of > adding a few slots to a CLOS class I just said to hell with it, > subject-predicate-object, I am done. There's is beauty to generalization, isn't there? I like to say that my thesis work itself was trivial -- the hard part was finding the right level of abstraction. > >> >> Or, from a different angle, there's something cellosy about cells-gtk3 now >> :-) > > Have you had this experience?: I started to build the Algebra software using > pretty much a Tk interface, intending to do Cello just inside the Togl > widget where I would really need the lisp way. In about two seconds I > decided it would be a horror programming one application with two > application frameworks at the same time. Or do you have Cello/Gtk > partitioned cleanly enough that they coexist gracefully? Possibly because of > the evolutionary path in which Cello/Gtk was /always/ within the GTk > framework? Back to my point from above: I believe it depends strongly on the problem domain. In other words, I like to find the appropriate UI match for every piece of internal functionality. In my case, there was a graph, so the appropriate UI representation is -- a graph. Needs custom drawing, custom interaction, etc pp -- I considered using draggable gtk widgets for about 5 minutes -- then decided to do everything myself. (Here's where my confusion came in, btw: first, it was only supposed to be a static visualization. Then I realized, thanks to cells, making it reflect state dynamically was a no-brainer. Once I was that far, I figured adding interaction could not be that hard. That's what I meant by "through the back-door"). On the other hand, every part of the graph is described by attribute-value pairings, hence a simple list view (attribute in the left columns, (editable) value in the right) is a good-enough match. So why bother inventing a list view with scrolling, in-place editing etc when someone has done it before? That's where I am glad to have gtk (or any other widget-rich system) at hand. Thanks to cells as the common layer, custom widgets and standard widgets interact absolutely seemless :-) And from the user perspective, cairo drawing blends in beautifully since Gtk uses cairo for drawing itself, so both use the same antialiasing etc. From a placing perspective I trust Gtk, which offers all kinds of layout containers to represent pretty much everything imaginable (cells-gtk was missing some gtk widgets, so cells-gtk3 has a few more :-)). And since custom widgets are still widgets, no need to mess with that. One great episode in terms of gui-coexistence was when I realized my models would be too complex to fit on the screen, ie. the custom widget needs scrolling. While I was still wondering about how to leverage cairo's translation functions to implement scrolling, I came across gtk-scrolled-window -- so I placed my custom widget inside a scrolled-window, and it Just Worked. So, yes, custom and standard stuff interacts nicely and seemless over here :-) I bet I could do the same with opengl and gtk if I had the time (right now opengl just adds a non-interactive canvas to visualize stuff with a few simple models representing spheres, boxes, and the famous teapot. Of course those can depend on internal state and thus change dynamically, but that goes without saying ...) I believe the choice depends on what types of widgets you need. Text entry fields hardly warrant including tk or gtk, but if you need open/save dialogs or editable tree views (as in my case), gtk/tk might save you a lot of rather boring reinventing-the-wheel. Additionally those standard functions look and work the way the user expects them to, which might be a plus, too. Cheers, Peter > > kt > > From kennytilton at optonline.net Tue Jul 15 20:46:13 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Tue, 15 Jul 2008 16:46:13 -0400 Subject: [cells-devel] Cells bug! Message-ID: <487D0C95.50405@optonline.net> Well, I think this is right, not sure if it was like that for a reason, but this does cause rules to run for no reason after a certain precide series of events I won't bore you with. Look for one new line below: (defmethod md-slot-value-assume (c raw-value propagation-code) (assert c) #+shhh (trc c "md-slot-value-assume entry" (c-state c)) (without-c-dependency (let ((prior-state (c-value-state c)) (prior-value (c-value c)) (absorbed-value (c-absorb-value c raw-value))) (c-pulse-update c :slotv-assume) ; --- head off unchanged; this got moved earlier on 2006-06-10 --- (when (and (not (eq propagation-code :propagate)) (find prior-state '(:valid :uncurrent)) (c-no-news c absorbed-value prior-value)) (trc nil "(setf md-slot-value) > early no news" propagation-code prior-state prior-value absorbed-value) (count-it :nonews) ===new==> (setf (c-value-state c) :valid) ; in case it was :uncurrent (return-from md-slot-value-assume absorbed-value)) ...etc unchanged... Not committing to CVS cuz I don't want to break things, kinda too bust with Algebra to handle any fallout. kt From kennytilton at optonline.net Fri Jul 25 06:36:56 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Fri, 25 Jul 2008 02:36:56 -0400 Subject: [cells-devel] Re: [cells-gtk-devel] installation notes, type error in test-gtk In-Reply-To: <873e58110807241948p7987fa79o59103a9487c16aa2@mail.gmail.com> References: <873e58110807231821t6268cd9k67ecb764f0b1d3ff@mail.gmail.com> <4888237E.8090308@optonline.net> <873e58110807241948p7987fa79o59103a9487c16aa2@mail.gmail.com> Message-ID: <48897488.5040306@optonline.net> Laziz Foo wrote: >> While you are waiting for a genuine GTk person to respond, all I can say is >> that it looks as if the code in CFFI that automatically tries to do the >> right thing with Lisp data to get it into a form the C function will >> tolerate is failing to do the right thing. Since this code is pretty >> common/well tested, all I can think is that perhaps a recompile in and >> around the specific function gtk-window-set-title (gwst) might do the trick. >> Or just bail on your Lisp, restart, then do a full rebuild from scratch >> (ASDF :force t) IIRC. Possibly during your brave struggles (congrats on >> making it this far, btw) you got one thing compiled before something else >> and the order should have been the opposite. pardon the hand-waving. >> >> I presume you are running demo code untouched, or I would worry that "GTK >> Testing" should be wrapped in with-c-string or something. >> >> Congrats again and thanks for the notes. >> >> kt > > > With the patch supplied by Ingo, and the widgets.lisp change mentioned > in his June email, I'm good to go. Thanks for the kind words, and > your entertaining blog entries @ smuglispweenie. Thanks! So I have lost track, is this Cells-Gtk3 (with Cells 3 Inside) or Oldskool Cells-Gtk? Cells3 integrity clearly is to be preferred, but I miss the good old days of Cells Classic when I just SETfed here and SETFed there and let the data converge /eventually/ on correct values. :) kt From kennytilton at optonline.net Fri Jul 25 15:38:29 2008 From: kennytilton at optonline.net (Kenny Tilton) Date: Fri, 25 Jul 2008 11:38:29 -0400 Subject: [cells-devel] Re: [cells-gtk-devel] installation notes, type error in test-gtk In-Reply-To: <873e58110807250417h2944ef2ax683baceca25bb2a0@mail.gmail.com> References: <873e58110807231821t6268cd9k67ecb764f0b1d3ff@mail.gmail.com> <4888237E.8090308@optonline.net> <873e58110807241948p7987fa79o59103a9487c16aa2@mail.gmail.com> <48897488.5040306@optonline.net> <873e58110807250417h2944ef2ax683baceca25bb2a0@mail.gmail.com> Message-ID: <4889F375.5080500@optonline.net> Laziz Foo wrote: >> Thanks! So I have lost track, is this Cells-Gtk3 (with Cells 3 Inside) or >> Oldskool Cells-Gtk? > > > This is cells-gtk3. Oldschool works out of the box, but I wanted the > cairo stuff. And you got help from someone other than Peter H so it sounds as if CG3 has taken hold. Cool. So it is a battle to death between Cello and Cells-Gtk3 for GUI supremacy? Awesome. > It's a case of scratching my own itch-- every > stock/futures charting app I've used (both windows and linux) are > inadequate in ways that are important to me; might as well write my > own. > > Your propaganda has convinced me that somehow I would have > greenspunned Cells, or given up on the project entirely while chasing > state issues around. Ah, good, the spam is working. Yes, the paradigm is inevitable so one ends up automating dataflow one way or another. Over on c.l.l someone is explaining how Qt's signals/slots eliminate the need for Cells. Whatever. I just like the mounting evidence that dataflow is inevitable. I would add it to the prior art in the Cells manifesto but it is getting ridiculous, I might just edit that down to "It's everywhere." > >> Cells3 integrity clearly is to be preferred, but I miss the good old days of >> Cells Classic when I just SETfed here and SETFed there and let the data >> converge /eventually/ on correct values. :) > > In one of my previous go-rounds w/ lisp, I used cells-classic to > investigate globex tick data. C.l.l. cells reactions/concerns do not > match the reality of downloading it and doing something useful > quickly, despite the lack of documentation. Damn. I'll have to find some other way to keep Cells to myself. perhaps it is time to start seeding CVS with insidious bugs... > It also occurs to me that > if the 'yobbos' really wanted to popularize lisp, they'd find some way > to use cells-*tk to create a Visual Studio-like thingy that would > enable any CTO's nephew to say, "Oh lisp-- yeah, I do that." It would not help, I think. Programming is receding into the background (or India or Russia or China) of culture. Once was a time lotsa people wired up electronics. The career is still there for the odd weirdo, but -- well, it's like shade-tree auto mechanics: gone along with the simple technology. Happy hacking. kt