July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello

by Dale K. Henrichs

Doru, Are you going to be at ESUG this year? I think there are some features of the Metacello Preview that can be of a great help to your Moose development and I think you and I need to spend time discussing the ins and outs in detail ... I have also done a fair amount or work writing tools for tODE that manipulate sets of configurations using the MetacelloToolBox (Metacello Preview version), so perhaps your goal of "automatic transitive versioning of all nested configurations" is not as far away as you think. And again, I think some deep discussions at a whiteboard and some pair programming is probably the most efficient... Dale ----- Original Message ----- | From: "Tudor Girba" <tudor(a)tudorgirba.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Wednesday, July 24, 2013 11:24:20 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello | | Hi, | | On Jul 24, 2013, at 5:25 PM, Johan Brichau <johan(a)inceptive.be> | wrote: | | > Doru, | > | > What do you understand with 'levels'? Is it referenced projects? | | Yes. Nested projects, each being under development :) | | > Perhaps this is the difference I did not immediately extract from | > your description. Re-reading it with this focus makes the | > difference clear I think. | > | > My use of the toolbox is indeed to generate or update a version for | > a single project where all 'nested' projects are referenced by | > project version. As I understand it, the snapshot version is a | > 'flattened' version containing all packages? | | Yes. | | My end goal would be to be able to create automatic transitive | versioning of all nested configurations, but this requires some more | work, and likely some extension at the level of Metacello. So, until | this happens, we now have the option of snapshotting all packages. | | The cool thing is that if you have something like: | ConfigurationOfMoose depends on ConfigurationOfGlamour | | then in the list of snapshotted packages, you will also get the | version of ConfigurationOfGlamour. Thus, essentially, you obtain the | same thing as if you would load nested configurations. | | The only problem is that because we lose configuration nesting | information, Metacello is unable to resolve possible diamond | conflicts. For example, suppose you have a project that depends on a | certain version X of Glamour, but also would like to load the whole | Moose that loads version Y of Glamour. If you use normal | configurations, Metacello should be able to detect the conflict, but | if you only have flattened versions, you will likely not detect the | conflict so easily. In any case, I think this is acceptable at the | moment. | | Cheers, | Doru | | | | > I think I get it now. thanks | > | > Johan | > | > On 24 Jul 2013, at 12:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: | > | >> Perhaps I missed something in the toolbox, but as far as I know | >> you cannot create a version of a configuration that is composed | >> of multiple sub-projects nested multiple levels deep. | >> | >> Could you describe the way you are using the Metacello Toolbox? | >> | >> Doru | >> | >> | >> On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | >> <johan(a)inceptive.be> wrote: | >> Hi Doru, Stef, | >> | >> May I ask what the difference is with the version generation and | >> updating methods found in MetacelloToolbox ? I want to | >> understand, because I am currently using these of | >> MetacelloToolbox to do the things you describe. | >> | >> Cheers! | >> Johan | >> | >> On 24 Jul 2013, at 09:52, StÃ©phane Ducasse | >> <stephane.ducasse(a)inria.fr> wrote: | >> | >>> | >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor(a)tudorgirba.com> | >>> wrote: | >>> | >>>> Hi, | >>>> | >>>> On Jul 24, 2013, at 8:48 AM, StÃ©phane Ducasse | >>>> <stephane.ducasse(a)inria.fr> wrote: | >>>> | >>>>> | >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | >>>>> <dale.henrichs(a)gemtalksystems.com> wrote: | >>>>> | >>>>>> Stef, | >>>>>> | >>>>>> I haven't completely wrapped my brain around what | >>>>>> SnapshotCello does so I don't have an informed opinion ... | >>>>>> the fact that you found a need to invent SnapshotCello does | >>>>>> speak volumes to the fact that there is a need that is going | >>>>>> unmet:). | >>>>>> | >>>>>> However, I don't like the fact that you end up sending a | >>>>>> non-spec message to make this work (#populateSpec:with:). | >>>>>> Tools like Versioner will not be able to rewrite a method | >>>>>> like this correctly so it is a less than satisfactory | >>>>>> workaround to the method literal limit. | >>>>> Indeed. May be in the future we could recreate a simple | >>>>> compliant spec driven method by interpreting the | >>>>> existing configuration trees but this requires some work. | >>>> | >>>> I do not understand this point. What do you mean by | >>>> "interpreting the configuration trees"? | >>> | >>> I mean going over the configurations with dependencies to | >>> recreate the tree structure but with versions. | >>> May be this is not needed because for versions we do not need | >>> dependencies so just group them per configurations. | >>> | >>>> | >>>> Doru | >>>> | >>>>>> | >>>>>> With that said it _is_ performing a useful function ... | >>>>>> | >>>>>> I have recently come up with an approach to addressing the | >>>>>> method literal limit from a slightly different angle and I | >>>>>> would assume that SnapshotCello could be recast to use this | >>>>>> "approved approach" when the new techinique becomes | >>>>>> available. At that time it would make sense to roll the | >>>>>> SnapshotCello funtionality into the MetacelloToolBox... | >>>>>> | >>>>>> Dale | >>>>>> | >>>>>> [1] | >>>>>> http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html | >>>>>> ----- Original Message ----- | >>>>>> | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | >>>>>> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> | >>>>>> | Cc: "Any question about pharo is welcome" | >>>>>> | <pharo-users(a)lists.pharo.org>, "Pharo Development List" | >>>>>> | <pharo-dev(a)lists.pharo.org> | >>>>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM | >>>>>> | Subject: [Moose-dev] Re: [ann] snapshotcello | >>>>>> | | >>>>>> | Nice to see SnapshotCello coming to live. May be it should | >>>>>> | be | >>>>>> | integrated to Metacello. | >>>>>> | Because everybody may need this cool feature. | >>>>>> | | >>>>>> | Stef | >>>>>> | | >>>>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba | >>>>>> | <tudor(a)tudorgirba.com> | >>>>>> | wrote: | >>>>>> | | >>>>>> | > Hi, | >>>>>> | > | >>>>>> | > Stef and I developed Snapshotcello, a little utility that | >>>>>> | > enables | >>>>>> | > you to freeze a snapshot of a given configuration based on | >>>>>> | > what is | >>>>>> | > already loaded in your current image. | >>>>>> | > | >>>>>> | > The idea is simple. You develop against the latest | >>>>>> | > versions of all | >>>>>> | > packages, and commit your changes for each package. When | >>>>>> | > you are | >>>>>> | > ready for a release, you assemble your image, and generate | >>>>>> | > a | >>>>>> | > snapshot version that can be reloaded later. | >>>>>> | > | >>>>>> | > Here is an example of how it can work to take a snapshot | >>>>>> | > of a | >>>>>> | > development version: | >>>>>> | > Snapshotcello new | >>>>>> | > configurationClass: ConfigurationOfMoose; | >>>>>> | > configurationVersion: #development; | >>>>>> | > publishVersion: '4.8-snapshot' | >>>>>> | > | >>>>>> | > You can find more details here: | >>>>>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… | >>>>>> | > | >>>>>> | > You can get the code at: | >>>>>> | > Gofer new | >>>>>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | >>>>>> | > package: 'ConfigurationOfSnapshotcello'; | >>>>>> | > load. | >>>>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | >>>>>> | > loadDevelopment | >>>>>> | > | >>>>>> | > Cheers, | >>>>>> | > Doru | >>>>>> | > | >>>>>> | > -- | >>>>>> | > www.tudorgirba.com | >>>>>> | > | >>>>>> | > "Every successful trip needs a suitable vehicle." | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > _______________________________________________ | >>>>>> | > Moose-dev mailing list | >>>>>> | > Moose-dev(a)iam.unibe.ch | >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>>> | | >>>>>> | _______________________________________________ | >>>>>> | Moose-dev mailing list | >>>>>> | Moose-dev(a)iam.unibe.ch | >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>> | >>>>> | >>>>> _______________________________________________ | >>>>> Moose-dev mailing list | >>>>> Moose-dev(a)iam.unibe.ch | >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>> | >>>> -- | >>>> www.tudorgirba.com | >>>> | >>>> "From an abstract enough point of view, any two things are | >>>> similar." | >>> | >>> | >> | >> | >> | >> | >> -- | >> www.tudorgirba.com | >> | >> "Every thing has its own flow" | > | > | | -- | www.tudorgirba.com | | "Every now and then stop and ask yourself if the war you're fighting | is the right one." | | | | |

July 24, 2013

Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: [ann] snapshotcello

by Dale K. Henrichs

----- Original Message ----- | From: "Tudor Girba" <tudor(a)tudorgirba.com> | To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> | Cc: "Moose-related development" <moose-dev(a)iam.unibe.ch>, "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Wednesday, July 24, 2013 12:07:48 AM | Subject: Re: [Pharo-users] [Moose-dev] Re: [ann] snapshotcello | | Hi, | | On Jul 23, 2013, at 11:51 PM, "Dale K. Henrichs" | <dale.henrichs(a)gemtalksystems.com> wrote: | | > Stef, | > | > I haven't completely wrapped my brain around what SnapshotCello | > does so I don't have an informed opinion ... the fact that you | > found a need to invent SnapshotCello does speak volumes to the | > fact that there is a need that is going unmet:). | | What is not clear? I would be interested in describing our scenario | in more details because I think this is a development pattern. But, | I need some concrete questions to start from. I do not completely understand what SnapshotCello is actually doing let alone why it is doing what it is doing ... So I need to spend time with it to "wrap my brain around it" then I can ask concrete questions.... | | > However, I don't like the fact that you end up sending a non-spec | > message to make this work (#populateSpec:with:). Tools like | > Versioner will not be able to rewrite a method like this correctly | > so it is a less than satisfactory workaround to the method literal | > limit. | | I still do not understand why Versionner would be affected by the | current versions given that we are only generating versions that | should be immutable hence no need for management. I made my comments without having wrapped my head around SnapshotCello and it is my standard reaction to non-spec-based message sends ... I reserve the right to someday switch to a non-class-based implementation for Metacello and problems like too many literals in a method will no longer be a problem (and the tool many literals issue is but one of the forces driving me away from class-based specs), but specs that are generated dynamically based on data gleaned from arbitrary message sends will not be mappable. So I continue to repeat the message that Metacello does not support the dynamic generation of specs. In your particular case you are probably living within acceptable bounds, but the very existence of "message sends within a spec" may encourage other folks to try their hand at dynamic generation....and we are off to the races:) So I continue to repeat the message that Metacello does not support the dynamic generation of specs. | | > With that said it _is_ performing a useful function ... | > | > I have recently come up with an approach to addressing the method | > literal limit from a slightly different angle and I would assume | > that SnapshotCello could be recast to use this "approved approach" | > when the new techinique becomes available. At that time it would | > make sense to roll the SnapshotCello funtionality into the | > MetacelloToolBox... | | Having a different way to store the information should be no problem. | I am curious about your ideas. I've tossed out some of my ideas in a post in the metacello mailing list[1]. And that would be a good place to discusss this further... Dale [1] http://forum.world.st/Loading-problem-in-Seaside-tc4699965.html

July 24, 2013

Re: [Pharo-dev] [Moose-dev] Re: [ann] snapshotcello

by Tudor Girba

Hi, I would be happy to blend Snapshotcello into Metacello. Cheers, Doru On Jul 24, 2013, at 9:05 PM, "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> wrote: > > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > | Cc: "Moose-related development" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" > | <pharo-users(a)lists.pharo.org> > | Sent: Tuesday, July 23, 2013 11:48:27 PM > | Subject: Re: [Pharo-dev] [Moose-dev] Re: [ann] snapshotcello > | > | > | On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs > | <dale.henrichs(a)gemtalksystems.com> wrote: > | > | > Stef, > | > > | > I haven't completely wrapped my brain around what SnapshotCello > | > does so I don't have an informed opinion ... the fact that you > | > found a need to invent SnapshotCello does speak volumes to the > | > fact that there is a need that is going unmet:). > | > > | > However, I don't like the fact that you end up sending a non-spec > | > message to make this work (#populateSpec:with:). Tools like > | > Versioner will not be able to rewrite a method like this correctly > | > so it is a less than satisfactory workaround to the method literal > | > limit. > | > | Indeed. May be in the future we could recreate a simple compliant > | spec driven method by interpreting the > | existing configuration trees but this requires some work. > > Absolutely and it would be work that I'd be willing to do ... From that perspective SnapshotCello is a very good spec for what you and the Moose team need. > > Dale > -- www.tudorgirba.com "Every thing has its own flow."

July 24, 2013

Re: [Pharo-dev] [Moose-dev] Re: [ann] snapshotcello

by Dale K. Henrichs

----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Cc: "Moose-related development" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" | <pharo-users(a)lists.pharo.org> | Sent: Tuesday, July 23, 2013 11:48:27 PM | Subject: Re: [Pharo-dev] [Moose-dev] Re: [ann] snapshotcello | | | On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | <dale.henrichs(a)gemtalksystems.com> wrote: | | > Stef, | > | > I haven't completely wrapped my brain around what SnapshotCello | > does so I don't have an informed opinion ... the fact that you | > found a need to invent SnapshotCello does speak volumes to the | > fact that there is a need that is going unmet:). | > | > However, I don't like the fact that you end up sending a non-spec | > message to make this work (#populateSpec:with:). Tools like | > Versioner will not be able to rewrite a method like this correctly | > so it is a less than satisfactory workaround to the method literal | > limit. | | Indeed. May be in the future we could recreate a simple compliant | spec driven method by interpreting the | existing configuration trees but this requires some work. Absolutely and it would be work that I'd be willing to do ... From that perspective SnapshotCello is a very good spec for what you and the Moose team need. Dale

July 24, 2013

Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello

by Tudor Girba

Hi, On Jul 24, 2013, at 5:25 PM, Johan Brichau <johan(a)inceptive.be> wrote: > Doru, > > What do you understand with 'levels'? Is it referenced projects? Yes. Nested projects, each being under development :) > Perhaps this is the difference I did not immediately extract from your description. Re-reading it with this focus makes the difference clear I think. > > My use of the toolbox is indeed to generate or update a version for a single project where all 'nested' projects are referenced by project version. As I understand it, the snapshot version is a 'flattened' version containing all packages? Yes. My end goal would be to be able to create automatic transitive versioning of all nested configurations, but this requires some more work, and likely some extension at the level of Metacello. So, until this happens, we now have the option of snapshotting all packages. The cool thing is that if you have something like: ConfigurationOfMoose depends on ConfigurationOfGlamour then in the list of snapshotted packages, you will also get the version of ConfigurationOfGlamour. Thus, essentially, you obtain the same thing as if you would load nested configurations. The only problem is that because we lose configuration nesting information, Metacello is unable to resolve possible diamond conflicts. For example, suppose you have a project that depends on a certain version X of Glamour, but also would like to load the whole Moose that loads version Y of Glamour. If you use normal configurations, Metacello should be able to detect the conflict, but if you only have flattened versions, you will likely not detect the conflict so easily. In any case, I think this is acceptable at the moment. Cheers, Doru > I think I get it now. thanks > > Johan > > On 24 Jul 2013, at 12:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Perhaps I missed something in the toolbox, but as far as I know you cannot create a version of a configuration that is composed of multiple sub-projects nested multiple levels deep. >> >> Could you describe the way you are using the Metacello Toolbox? >> >> Doru >> >> >> On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau <johan(a)inceptive.be> wrote: >> Hi Doru, Stef, >> >> May I ask what the difference is with the version generation and updating methods found in MetacelloToolbox ? I want to understand, because I am currently using these of MetacelloToolbox to do the things you describe. >> >> Cheers! >> Johan >> >> On 24 Jul 2013, at 09:52, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> Hi, >>>> >>>> On Jul 24, 2013, at 8:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>>>> >>>>>> Stef, >>>>>> >>>>>> I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). >>>>>> >>>>>> However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. >>>>> Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the >>>>> existing configuration trees but this requires some work. >>>> >>>> I do not understand this point. What do you mean by "interpreting the configuration trees"? >>> >>> I mean going over the configurations with dependencies to recreate the tree structure but with versions. >>> May be this is not needed because for versions we do not need dependencies so just group them per configurations. >>> >>>> >>>> Doru >>>> >>>>>> >>>>>> With that said it _is_ performing a useful function ... >>>>>> >>>>>> I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... >>>>>> >>>>>> Dale >>>>>> >>>>>> [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html >>>>>> ----- Original Message ----- >>>>>> | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>>>>> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> >>>>>> | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" >>>>>> | <pharo-dev(a)lists.pharo.org> >>>>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM >>>>>> | Subject: [Moose-dev] Re: [ann] snapshotcello >>>>>> | >>>>>> | Nice to see SnapshotCello coming to live. May be it should be >>>>>> | integrated to Metacello. >>>>>> | Because everybody may need this cool feature. >>>>>> | >>>>>> | Stef >>>>>> | >>>>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> >>>>>> | wrote: >>>>>> | >>>>>> | > Hi, >>>>>> | > >>>>>> | > Stef and I developed Snapshotcello, a little utility that enables >>>>>> | > you to freeze a snapshot of a given configuration based on what is >>>>>> | > already loaded in your current image. >>>>>> | > >>>>>> | > The idea is simple. You develop against the latest versions of all >>>>>> | > packages, and commit your changes for each package. When you are >>>>>> | > ready for a release, you assemble your image, and generate a >>>>>> | > snapshot version that can be reloaded later. >>>>>> | > >>>>>> | > Here is an example of how it can work to take a snapshot of a >>>>>> | > development version: >>>>>> | > Snapshotcello new >>>>>> | > configurationClass: ConfigurationOfMoose; >>>>>> | > configurationVersion: #development; >>>>>> | > publishVersion: '4.8-snapshot' >>>>>> | > >>>>>> | > You can find more details here: >>>>>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… >>>>>> | > >>>>>> | > You can get the code at: >>>>>> | > Gofer new >>>>>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; >>>>>> | > package: 'ConfigurationOfSnapshotcello'; >>>>>> | > load. >>>>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) >>>>>> | > loadDevelopment >>>>>> | > >>>>>> | > Cheers, >>>>>> | > Doru >>>>>> | > >>>>>> | > -- >>>>>> | > www.tudorgirba.com >>>>>> | > >>>>>> | > "Every successful trip needs a suitable vehicle." >>>>>> | > >>>>>> | > >>>>>> | > >>>>>> | > >>>>>> | > >>>>>> | > _______________________________________________ >>>>>> | > Moose-dev mailing list >>>>>> | > Moose-dev(a)iam.unibe.ch >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> | >>>>>> | >>>>>> | _______________________________________________ >>>>>> | Moose-dev mailing list >>>>>> | Moose-dev(a)iam.unibe.ch >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> | >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "From an abstract enough point of view, any two things are similar." >>> >>> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

July 24, 2013

Re: [Pharo-dev] Loading scripts vs. configs with #stable and config browser (was: [ann] snapshotcello)

by Sean P. DeNigris

StÃ©phane Ducasse wrote > + 1 :) > This is why I'm working on the PackageCatalog :) +1 and... cool! PackageCatalog is very needed... where is the code hosted? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-Loading-scripts-vs-configs-with-stable-and-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 24, 2013

Fwd: [vwnc] Doodling with Cairo...

by stephane ducasse

Begin forwarded message: > From: Michael Lucas-Smith <michael.lucassmith(a)gmail.com> > Subject: Re: [vwnc] Doodling with Cairo... > Date: July 24, 2013 12:31:24 PM GMT+02:00 > To: stewart(a)xtra.co.nz > Cc: vwnc(a)cs.uiuc.edu > > Hi Stewart, > > Gizmo was just something Travis Griggs and I made to experiment with CairoGraphics. We wanted to see how it would perform, what kinds of issues we might run in to using Cairo resources in widgets, that sort of thing. > > The doodle layout algorithm is a variant of the CSS layout algorithm, significantly simplified, by me as a way to avoid having to do a full on layout algorithm but still get the majority of what we needed to experimenting. This approach to layout is not the future for the UI, we have other plans there using a constraint based solver that has been proven in production code both in Smalltalk and in other languages. > > As an experiment, it was a complete success - we sold ourselves on the idea that Cairo was completely viable for our customers to use for this kind of work (ie: custom widgets) and potentially for doing the core widgets too. Some of the people in the community have gone even further, making graphics contexts that use CairoGraphics and whole suits of widgets. It's inspiring and very cool. > > So, you've stumbled upon some of the humble beginnings - I frankly didn't realise we'd put that stuff in the open repository, I thought we'd left it in our private repository. Have fun with it if you want.. somewhere in there is my fancy clock that moves the numbers instead of the clock hands and also a Dr. Who animation. > > Cheers, > Michael > > On 10/01/2008, at 2:34 AM, Stewart MacLean <stewart(a)xtra.co.nz> wrote: > >> Hi, >> >> Iâve been experimenting with the various Cairo bits and pieces trying to figure out how to get a nice looking tree/UI â some interesting stuff! (thanks for the previous pointers, everyone). >> >> One of which is the Gizmo â which on first impression I wondered whatâs with all these pink rectangles? >> >> But delving deeper it looks like a pretty cool open ended framework â Iâve been experimenting with nesting and it sort of works, but not sure if Iâm configuring it correctly. >> >> The Cairo Wrapper Kit is a piece of art, but Iâm struggling to get my head around it â wrapper hell? >> >> Anyway, I was wondering where the âDoodle Layout Algorithmâ came from? â all I can find are references to a constraint based object visualization system from the mid 90âs. >> >> BTW, I know Smalltalk is generally self documenting code, but some âbig pictureâ class/package documentation with these lovely experiments would make them a lot more accessible! >> >> Cheers, >> >> Stewart >> >> >> Gizmo>>layoutFromIndex: index >> "** The Doodle Layout Algorithm ** >> 1) Use desiredLayoutBlock to find out what we want as our bounds inside the availableExtent given to us. Store this in @desired. >> 2) Figure out what extent we want to offer our children based on our @desired bounds. Store this in @offered. >> @desired may contain a width/height of BlockClosure. In this case, we offer the >> available space for that dimension to our children >> 3) Offer the @offered space to each child, storing their @requested space >> 4) Keep a record of the @maximum extent that our children reach inside us so that we can decide how to clip correctly. >> 5) <pluggable> Use our child layout algorithm to position and size the @requested space as the @bounds of the child >> 6) Return our @desired bounds to our parent as a requested space replacing any BlockClosure with details from our children's @maximum extent. >> ." >> >> >> _______________________________________________ >> vwnc mailing list >> vwnc(a)cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

July 24, 2013

Fwd: [vwnc] Doodling with Cairo...

by StÃ©phane Ducasse

Begin forwarded message: > From: "Stewart MacLean" <stewart(a)xtra.co.nz> > Subject: [vwnc] Doodling with Cairo... > Date: January 9, 2008 4:34:08 PM GMT+01:00 > To: <vwnc(a)cs.uiuc.edu> > Reply-To: stewart(a)xtra.co.nz > > Hi, > > Iâve been experimenting with the various Cairo bits and pieces trying to figure out how to get a nice looking tree/UI â some interesting stuff! (thanks for the previous pointers, everyone). > > One of which is the Gizmo â which on first impression I wondered whatâs with all these pink rectangles? > > But delving deeper it looks like a pretty cool open ended framework â Iâve been experimenting with nesting and it sort of works, but not sure if Iâm configuring it correctly. > > The Cairo Wrapper Kit is a piece of art, but Iâm struggling to get my head around it â wrapper hell? > > Anyway, I was wondering where the âDoodle Layout Algorithmâ came from? â all I can find are references to a constraint based object visualization system from the mid 90âs. > > BTW, I know Smalltalk is generally self documenting code, but some âbig pictureâ class/package documentation with these lovely experiments would make them a lot more accessible! > > Cheers, > > Stewart > > > Gizmo>>layoutFromIndex: index > "** The Doodle Layout Algorithm ** > 1) Use desiredLayoutBlock to find out what we want as our bounds inside the availableExtent given to us. Store this in @desired. > 2) Figure out what extent we want to offer our children based on our @desired bounds. Store this in @offered. > @desired may contain a width/height of BlockClosure. In this case, we offer the > available space for that dimension to our children > 3) Offer the @offered space to each child, storing their @requested space > 4) Keep a record of the @maximum extent that our children reach inside us so that we can decide how to clip correctly. > 5) <pluggable> Use our child layout algorithm to position and size the @requested space as the @bounds of the child > 6) Return our @desired bounds to our parent as a requested space replacing any BlockClosure with details from our children's @maximum extent. > ." > > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

July 24, 2013

Re: [Pharo-dev] Pharo VM - More Memory on Mac

by phil＠highoctane.be

Change the plist file value to a bigger one. --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Wed, Jul 24, 2013 at 4:23 PM, Dennis Schenk <d.schenk(a)students.unibe.ch>wrote: > Hi, > > Does anybody know how to get more memory in Pharo VM? See question below. > > Cheers, > Dennis > > > On Tue, May 7, 2013 at 6:08 PM, Dennis Schenk <d.schenk(a)students.unibe.ch>wrote: > >> Hi all, >> >> I know there is already a related question about the Pharo VM on Windows. >> But as it seems, it is kind of hard to get over 512MB there, so I'm trying >> to do stuff on Mac. >> >> When using Cog I was able to use Cog.app --args -memory 2000m to allow >> Cog to run with 2GB of memory. Which then works fine with the same data I >> want to work with in Pharo. But I would like to use Pharo 2.0 and the Pharo >> VM, instead of Pharo 1.4 and the Cog VM. >> >> How would I achieve giving the Pharo VM more memory on Mac? >> >> If I am not mistaken, I currently only have 1GB, which is not enough, my >> image crashed when dealing with large data. >> >> Also, is there a way to check how much memory the VM has available in the >> workspace? I tried some arguments, but could only find out if they had any >> effect by getting to a crash after letting it do some work. >> >> Cheers, >> Dennis >> > >

July 24, 2013

Re: [Pharo-dev] Problem with strings, quotes and scape them

by Chris Cunningham

Doesn't just #printString do this? It escapes single strings into doubles - should do what you want if it is definitely a string. -Chris On Wed, Jul 24, 2013 at 8:34 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. I am a bit lost here and maybe someone can give me a hand. I have > a string that may include a single quote inside. Say I have the > string 'Sell ''13' . This string actually has a SINGLE quote, so if you > print it in a file for example, you get 'Sell '13'. Of course, when you > inspect the string in Pharo, it has 2 single quotes: 'Sell '' 13'. ok? > > Now...what I need is (quite weird I know) is to build a closure as a > string and using the previous string as a literal of the closure. > > Imagine there is no single quote problem in my string, this would work > perfect: > > (Compiler evaluate: '[ ', ' Transcript show: ', 'Sell ' > surroundedBySingleQuotes, ']') value. > > But, if instead of having 'Sell ', I have 'Sell '' 13', like this: > > (Compiler evaluate: '[ ', ' Transcript show: ', 'Sell '' 13' > surroundedBySingleQuotes, ']') value. > > I get a SyntaxError of a unmatched string: > > [ Transcript show: 'Sell ' 13Unmatched string quote -> '] > > So...what can I do? I GUESS the solution is to scape that. If I try > adding 2 more single quotes, like this: > > (Compiler evaluate: '[ ', ' Transcript show: ', 'Sell '''' 13' > surroundedBySingleQuotes, ']') value. > > it seems to work. If this is correct, is there an easy way (a method?) to > scape my string automatically so that it works? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >

July 24, 2013