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

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

by StÃ©phane Ducasse

> In Metacello there are more than one way to "visit specs": > > - raw specs > - merged specs > - specs by section > - resolved specs > - there are more > > If you are reasoning about the packages visible for a particular combination of attributes (#common, #pharo, etc.) then you are interested in the 'merged specs'. > > If you are interested in looking at the individual statements that are composed into the merged specs, then you need to look at the raw specs, again against a particular combination of attributes. > > If you are editting a spec or interested in extracting the list of all packages referenced independent of attribute, then you need to look at the specs by section ... in which case you have the choice of looking at the raw specs or merged specs for each section visited. You also probably need to control whether or not imports are followed or not. > > If you are interested in knowing the exact package version and repository that a spec resolves to, then you need to look at resolved specs against a particular combination of attributes. > > So I guess I need to know a little bit more about what you are thinking when you say "visitor on metacello spec." > > Dale I see. But when I close my eyes and think about the metacello domain. I see trees of projects baseline, versions packages required packages the fact that the information is merged, resolvedâ¦. should give back trees and I would like to be able to visit these structures so that we can build analysis such as snapcello on top. So probably that a visitor would have to be attached a strategy while navigating. Stef

July 25, 2013

Re: [Pharo-dev] thisContext and block

by StÃ©phane Ducasse

:) On Jul 25, 2013, at 1:20 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Thu, Jul 25, 2013 at 1:17 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 25 juil. 2013, at 13:12, ClÃ©ment Bera wrote: > >> Perhaps you should add some value message so that the assertions are actually run, shouldn't you ? > > I always felt that e-mails lack an unsend command :D > > Or gmail quotes should work properly :P > > >> 2013/7/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> For the people following I added a test to show the homeContext of a block >> >> >> | homeContext b1 | >> homeContext := thisContext. >> b1 := [| b2 | >> self assert: thisContext closure == b1. >> self assert: b1 outerContext == homeContext. >> self assert: b1 home = homeContext. >> b2 := [self assert: thisContext closure == b2. >> self assert: b2 outerContext closure outerContext == homeContext]. >> self assert: b2 home = homeContext. >> b2 value]. >> b1 value >> >> >> >> >>> >>> >>> On Tue, Jul 23, 2013 at 2:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> thanks! >>> It makes a lot of sense. >>> I will play with another example because I want to really understand the outerContext of closure vs the home context. >>> >>> The outerContext is a link in the static chain. Each block is created inside some context. This is the block's outerContext. If the block is not nested then the outerCOntext will also be the home context But if the block is nested inside another block activation, then the outerContext refers to that block activation, and the block activation's block's outerContext is the home context. So there are as many outerContext steps as there are nesting levels. >>> >>> | homeContext b1 | >>> homeContext := thisContext. >>> b1 := [| b2 | >>> self assert: thisContext closure == b1. >>> self assert: b1 outerContext == homeContext. >>> b2 := [self assert: thisContext closure == b2. >>> self assert: b2 outerContext closure outerContext == homeContext]. >>> b2 value]. >>> b1 value >>> >>> Ignore the "bN appears to be undefined at this point" and evaluate the above. No assert fails. >>> >>> Draw a picture. >>> >>> >>> Stef >>> >>> On Jul 23, 2013, at 6:58 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>>> This is because of compilation optimization. >>>> >>>> 2013/7/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> Hi >>>> >>>> when I execute the following >>>> >>>> first >>>> "Bexp new first" >>>> | temp | >>>> temp := 2. >>>> [ temp. >>>> thisContext inspect.] value. >>>> ^ temp >>>> >>>> tmp in the inspector is nil and does not hold 2 and I was wondering why. >>>> I thought that thisContext was returning the blockContext >>>> In the outercontext of thisContext blockClosure, tmp is also nil. >>>> >>>> >>>> This is because here 'temp.' is evaluated for effect (the value is not stored anywhere) and it has no side effect (reading a variable cannot lead to a modification of state of another object). So the compiler removes it. As it is removed, it is the same as if it was not in the block. So the block cannot access temp. Now write 'temp:= #foo' or 'temp foo' you will get it. >>>> >>>> first >>>> "Bexp new first" >>>> | temp | >>>> temp := 2. >>>> [ temp. >>>> temp traceCr. >>>> thisContext inspect.] value. >>>> ^ temp >>>> >>>> output 2 on the transcript. >>>> >>>> In this case 'temp.' is still removed, but the value of temp still need to be copied in the block for ' temp traceCr.'.'temp traceCr' is also evaluated for effect, but has the side effect to output the transcript, so the compiler cannot remove it. >>>> >>>> Basically the is very few things that the compiler removes, and one of them is variable read for effect, because you are sure it cannot lead to any issue. >>>> >>>> Stef >>>> >>>> >>> >>> >>> >>> >>> -- >>> best, >>> Eliot >> >> > >

July 25, 2013

Re: [Pharo-dev] X11 window manager in Pharo

by Igor Stasenko

On 25 July 2013 14:14, laurent laffont <laurent.laffont(a)gmail.com> wrote: > >>> >>> I will have one full week dedicated to Pharo, now I must decide what to >>> do. One fun thing would be to write a X11 window manager (based on >>> TilingWindowManager), so I could run Emacs, shells and all stuff in Pharo, >>> even Pharo in Pharo :) >> >> >> You mean implementing a native interface using X11? > > > > No. Just write an alternative to all this stuff > https://en.wikipedia.org/wiki/X_window_manager#X_window_managers ... but in > Pharo. > I think you can look at http://www.smalltalkhub.com/#!/~PharoExtras/NBOpenGL there is NBXLib-Core package, used to create window for opengl. Sure thing, it don't needs to be made or used explicitly for opengl. > > Laurent -- Best regards, Igor Stasenko.

July 25, 2013

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

by Dale K. Henrichs

Stef, In Metacello there are more than one way to "visit specs": - raw specs - merged specs - specs by section - resolved specs - there are more If you are reasoning about the packages visible for a particular combination of attributes (#common, #pharo, etc.) then you are interested in the 'merged specs'. If you are interested in looking at the individual statements that are composed into the merged specs, then you need to look at the raw specs, again against a particular combination of attributes. If you are editting a spec or interested in extracting the list of all packages referenced independent of attribute, then you need to look at the specs by section ... in which case you have the choice of looking at the raw specs or merged specs for each section visited. You also probably need to control whether or not imports are followed or not. If you are interested in knowing the exact package version and repository that a spec resolves to, then you need to look at resolved specs against a particular combination of attributes. So I guess I need to know a little bit more about what you are thinking when you say "visitor on metacello spec." Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Wednesday, July 24, 2013 11:47:51 PM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello | | Hi dale | | do you plan to write a visitor on metacello spec? | | Stef | | On Jul 24, 2013, at 9:38 PM, Dale K. Henrichs | <dale.henrichs(a)gemtalksystems.com> wrote: | | > 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 25, 2013

Re: [Pharo-dev] X11 window manager in Pharo

by laurent laffont

> >> I will have one full week dedicated to Pharo, now I must decide what to >> do. One fun thing would be to write a X11 window manager (based on >> TilingWindowManager), so I could run Emacs, shells and all stuff in Pharo, >> even Pharo in Pharo :) >> > > You mean implementing a native interface using X11? > No. Just write an alternative to all this stuff https://en.wikipedia.org/wiki/X_window_manager#X_window_managers ... but in Pharo. Laurent > > >> >> I've tried some months ago to translate this example >> https://github.com/mackstann/tinywm/blob/master/annotated.c but I lack >> of NativeBoost knowledge (I suppose it's the right tool to use). >> > > I think so too :) > > >> >> Has anyone tried this before ? Hints ? >> > > The only thing I know is that Carla Griggio is working on Mars for Gsoc, > and for that she is working on Gtk bindings in linux... But I cannot tell > more because I really do not understand what you want to do with X11 :). > > >> >> >> Laurent >> > >

July 25, 2013

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

by Dale K. Henrichs

That's going to make working out Metacello details a bit difficult:( Dale ----- Original Message ----- | From: "Tudor Girba" <tudor(a)tudorgirba.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Thursday, July 25, 2013 1:08:30 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] | snapshotcello | Unfortunately, I will not be able to join :( | Doru | On Wed, Jul 24, 2013 at 9:38 PM, Dale K. Henrichs < | dale.henrichs(a)gemtalksystems.com > wrote: | | 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." | | | | | | | | | | | | | | | | | | | | | | -- | www.tudorgirba.com | "Every thing has its own flow"

July 25, 2013

Re: [Pharo-dev] X11 window manager in Pharo

by Guillermo Polito

On Thu, Jul 25, 2013 at 1:54 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Hi, > > I will have one full week dedicated to Pharo, now I must decide what to > do. One fun thing would be to write a X11 window manager (based on > TilingWindowManager), so I could run Emacs, shells and all stuff in Pharo, > even Pharo in Pharo :) > You mean implementing a native interface using X11? > > I've tried some months ago to translate this example > https://github.com/mackstann/tinywm/blob/master/annotated.c but I lack > of NativeBoost knowledge (I suppose it's the right tool to use). > I think so too :) > > Has anyone tried this before ? Hints ? > The only thing I know is that Carla Griggio is working on Mars for Gsoc, and for that she is working on Gtk bindings in linux... But I cannot tell more because I really do not understand what you want to do with X11 :). > > > Laurent >

July 25, 2013

X11 window manager in Pharo

by laurent laffont

Hi, I will have one full week dedicated to Pharo, now I must decide what to do. One fun thing would be to write a X11 window manager (based on TilingWindowManager), so I could run Emacs, shells and all stuff in Pharo, even Pharo in Pharo :) I've tried some months ago to translate this example https://github.com/mackstann/tinywm/blob/master/annotated.c but I lack of NativeBoost knowledge (I suppose it's the right tool to use). Has anyone tried this before ? Hints ? Laurent

July 25, 2013

Pharo: thanks!

by Torsten Bergmann

------------------------------------------------------------------------------------ In April 2008 "Sapphire" was started as a fork of Squeak (see [1]) when Stef wrote: "Ideally in 3 years from now we would like to have a small kernel and some cool packages that we can load on top." Initially fixes of Squeak 3.10 were harvested from Mantis, then in May 21 2008 Sapphire smalltalk has been renamed into Pharo. Pharo, PharoInbox and PharoTreeted have been opened at SqueakSource. The first image "pharo0.1-10028dev08.05.1.zip" was published in May 2008, it is still available [2]. Attached is a screenshot. You can compare it to the current Pharo release - still it will not show you the many fixes, contributions, changes and the time invested by the community that went into cleaning and bringing the project on the right track. Thanks to all who help(ed) shaping it! [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-April/127815.ht… [2] https://gforge.inria.fr/frs/?group_id=1299. ------------------------------------------------------------------------------------

July 25, 2013

Re: [Pharo-dev] thisContext and block

by Guillermo Polito

On Thu, Jul 25, 2013 at 1:17 PM, Camille Teruel <camille.teruel(a)gmail.com>wrote: > > On 25 juil. 2013, at 13:12, ClÃ©ment Bera wrote: > > Perhaps you should add some value message so that the assertions are > actually run, shouldn't you ? > > > I always felt that e-mails lack an unsend command :D > Or gmail quotes should work properly :P > > 2013/7/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> For the people following I added a test to show the homeContext of a block >> >> >> | homeContext b1 | >> homeContext := thisContext. >> b1 := [| b2 | >> self assert: thisContext closure == b1. >> self assert: b1 outerContext == homeContext. >> self assert: b1 home = homeContext. >> b2 := [self assert: thisContext closure == b2. >> self assert: b2 outerContext closure outerContext == >> homeContext]. >> self assert: b2 home = homeContext. >> b2 value]. >> b1 value >> >> >> >> >> >> >> On Tue, Jul 23, 2013 at 2:02 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> thanks! >>> It makes a lot of sense. >>> I will play with another example because I want to really understand the >>> outerContext of closure vs the home context. >>> >> >> The outerContext is a link in the static chain. Each block is created >> inside some context. This is the block's outerContext. If the block is >> not nested then the outerCOntext will also be the home context But if the >> block is nested inside another block activation, then the outerContext >> refers to that block activation, and the block activation's block's >> outerContext is the home context. So there are as many outerContext steps >> as there are nesting levels. >> >> | homeContext b1 | >> homeContext := thisContext. >> b1 := [| b2 | >> self assert: thisContext closure == b1. >> self assert: b1 outerContext == homeContext. >> b2 := [self assert: thisContext closure == b2. >> self assert: b2 outerContext closure outerContext == >> homeContext]. >> b2 value]. >> b1 value >> >> Ignore the "bN appears to be undefined at this point" and evaluate the >> above. No assert fails. >> >> Draw a picture. >> >> >>> Stef >>> >>> On Jul 23, 2013, at 6:58 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>> wrote: >>> >>> This is because of compilation optimization. >>> >>> 2013/7/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> >>>> Hi >>>> >>>> when I execute the following >>>> >>>> first >>>> "Bexp new first" >>>> | temp | >>>> temp := 2. >>>> [ temp. >>>> thisContext inspect.] value. >>>> ^ temp >>>> >>>> tmp in the inspector is nil and does not hold 2 and I was wondering why. >>>> I thought that thisContext was returning the blockContext >>>> In the outercontext of thisContext blockClosure, tmp is also nil. >>>> >>>> >>> This is because here 'temp.' is evaluated for effect (the value is not >>> stored anywhere) and it has no side effect (reading a variable cannot lead >>> to a modification of state of another object). So the compiler removes it. >>> As it is removed, it is the same as if it was not in the block. So the >>> block cannot access temp. Now write 'temp:= #foo' or 'temp foo' you will >>> get it. >>> >>> >>>> first >>>> "Bexp new first" >>>> | temp | >>>> temp := 2. >>>> [ temp. >>>> temp traceCr. >>>> thisContext inspect.] value. >>>> ^ temp >>>> >>>> output 2 on the transcript. >>>> >>>> In this case 'temp.' is still removed, but the value of temp still need >>> to be copied in the block for ' temp traceCr.'.'temp traceCr' is also >>> evaluated for effect, but has the side effect to output the transcript, so >>> the compiler cannot remove it. >>> >>> Basically the is very few things that the compiler removes, and one of >>> them is variable read for effect, because you are sure it cannot lead to >>> any issue. >>> >>> >>>> Stef >>>> >>>> >>> >>> >> >> >> -- >> best, >> Eliot >> >> >> > >

July 25, 2013