April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Let's get rid of Core vs. Full

by GermÃ¡n Arduino

As I can understand the proposal of Marcus is not have anymore an image without the minimal set of tools for development. And I full agree with this option. Allways is possible to shrink the image in a next step if needed. In other words, to me Core is not useful witthout a minimal set of dev tools and I'm doing production deployments with such tools with no problems. By other hand, as most of the images are in remote servers I need to use them via VNC and with the dev tools. Just my opinion. Cheers. 2011/4/4 Tudor Girba <tudor.girba(a)gmail.com>: > This is what I understood from what Marcus said, too :) > > Cheers, > Doru > > > On 4 Apr 2011, at 15:57, StÃ©phane Ducasse wrote: > >> This is my ideas. >> >>> My proposition for 1.3: >>> 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) >>> 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser >>> 3) If it is possible, develop Core image into this reduced full image. >> >> > > -- > www.tudorgirba.com > > "Every thing should have the right to be different." > > > > >

April 4, 2011

Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)

by StÃ©phane Ducasse

In fact he got a better changeClassToThatOf: implementation and got kind of initform for slots. Stef > I do read French too, no problem. > > I'm having a look at > > http://fredrivard.ifrance.com/fredrivard/pub/dicl/dicl.ps > > That seems related. > > On 04/04/2011 09:20 PM, Alexandre Bergel wrote: >> he he. I am not sure Fred wrote in English. >> http://scg.unibe.ch/scgbib?_k=qQPhJdNf&query=rivard >> >> Cheers, >> Alexandre >> >> >> On 4 Apr 2011, at 14:15, Toon Verwaest wrote: >> >>> Do you have an exact reference on this? >>> >>> On 04/04/2011 05:55 PM, StÃ©phane Ducasse wrote: >>>>> Another very cool thing that we can do now (which would require 3 lines of change in my system though), is that the slot can also be responsible for instance migration. There are four cases: >>>>> 1- the instance variable didn't exist and now it does >>>>> 2- the instance variable existed but disappeared >>>>> 3- the metaobject changed (new semantics) >>>>> 4- the metaobject stayed the same >>>>> >>>> Did you check the work of fred rivard because he was managing the dynamic change of class and managing slot reinitialization? >>>> >>>> >>>>> Basically the only case that is "handled" by standard Pharo is case 1; and what you do there is putting nil in the field. In our model the slot could do something more interesting when it's migrating the instances. And we could tackle the other cases too. I think it's starting to get ideal to implement an active context on top ;-) >>>>> >>>>> cheers, >>>>> Toon >>> > >

April 4, 2011

Re: [Pharo-project] Transcript rant

by StÃ©phane Ducasse

On Apr 4, 2011, at 8:22 PM, Toon Verwaest wrote: > >> Ok so how do we make progress? > My favorite strategy: reimplement and replace. > If this means I'll have to do it... I can, but not this month. It will of course mean that everybody who relies on the old code will break... so we might need a transitional compatibility class; although I think that these users should just rewrite their code. It doesn't make sense whatsoever. we could simply revert the changes of CUIS. > > I don't have too much knowledge about the whole architecture though; and I'd prefer to spend time on getting my classbuilder in a state that it can be incorporated safely. That would be progress. yes I prefer knowing you working on that :) > > cheers, > Toon >

April 4, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by StÃ©phane Ducasse

> Ok guys so I want a solution :). >> So how can we improve Announcement to cover different cases? >> >> Stef >> > Both solutions lead to remaining subscribers being notified when an error occurs. > So which is decided upon, depends on which of their respective benefits are valued more. > For that, it'd be nice if more than 2 people chimed in on. :) :) Me too Thanks a lot for the analysis and pros and cons! I have the impression but I would really like to hear other voices on it that the ease of debugging is a big plus for me. But robustness is important too. > Short summary (not guaranteed to be 100% objective) > > Curtailing -> > - Your image may crash in some cases, more specifically if you: > 1) have errors in subscribers to announcements made in system-critical processes, as they will be suspended while debugging. > 2) deliver announcements in a separate thread from where they're announced, and the announcing thread does so regularily. > + Easy to debug. Entire call-chain available, no modification to state caused by subsequent subscribers. Restart should always lead in bug being reproduceable. > > The remove-from-subscriptions part of Error-handling and ifCurtailed could be combined as well, in which case #2 no longer applies. > > Error handling -> > - Hard/impossible to debug because: > 1) If your error was in ordering, debugger will step through flawlessly if restarted. > 2) You start at the context of the subscriptions action, no idea where it came from. > + More robust, none of the cases mentioned in Curtailing will crash your image. > > > With the different pros/cons mentioned above in mind, here are .cs with example implementations for what both Igor / I would like. (minus remove-from-subscriptions for ifCurtailed: ) > > Cheers, > Henry > <AnnouncementErrorHandling.zip>

April 4, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by StÃ©phane Ducasse

> This is what I understood from what Marcus said, too :) sure I did not mean that marcus was stealing me ideas. But that I was inlined with esteban proposal Stef > > Cheers, > Doru > > > On 4 Apr 2011, at 15:57, StÃ©phane Ducasse wrote: > >> This is my ideas. >> >>> My proposition for 1.3: >>> 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) >>> 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser >>> 3) If it is possible, develop Core image into this reduced full image. >> >> > > -- > www.tudorgirba.com > > "Every thing should have the right to be different." > > > >

April 4, 2011

[Pharo-project] [COTDC] 40#2 - NonReentrantWeakMessageSend

by laurent laffont

Today: NonReentrantWeakMessageSend (ExclusiveWeakMessageSend aborted - no answer) Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

April 4, 2011

Re: [Pharo-project] [COTDC] 41 - ExclusiveWeakMessageSend

by laurent laffont

Beyond my knowledge. Laurent. On Mon, Apr 4, 2011 at 8:07 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: ExclusiveWeakMessageSend > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

April 4, 2011

Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)

by Alexandre Bergel

he he. I am not sure Fred wrote in English. http://scg.unibe.ch/scgbib?_k=qQPhJdNf&query=rivard Cheers, Alexandre On 4 Apr 2011, at 14:15, Toon Verwaest wrote: > Do you have an exact reference on this? > > On 04/04/2011 05:55 PM, StÃ©phane Ducasse wrote: >>> Another very cool thing that we can do now (which would require 3 lines of change in my system though), is that the slot can also be responsible for instance migration. There are four cases: >>> 1- the instance variable didn't exist and now it does >>> 2- the instance variable existed but disappeared >>> 3- the metaobject changed (new semantics) >>> 4- the metaobject stayed the same >>> >> Did you check the work of fred rivard because he was managing the dynamic change of class and managing slot reinitialization? >> >> >>> Basically the only case that is "handled" by standard Pharo is case 1; and what you do there is putting nil in the field. In our model the slot could do something more interesting when it's migrating the instances. And we could tackle the other cases too. I think it's starting to get ideal to implement an active context on top ;-) >>> >>> cheers, >>> Toon > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 4, 2011

Re: [Pharo-project] Transcript rant

by Ricardo Moran

On Mon, Apr 4, 2011 at 11:44 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: (snip) > In this respect an old implementation was much nicer in a sense that > it could be replaced by different stream which responds to same > protocol.. > But now, Transcript is a class, and its much harder to replace it and > as to me it is too hardwired. > Maybe this is good for Cuis, but as to me, i consider Transcript as a > generic/default logging facility in smalltalk system. > I was planning to redirect Transcript to write to stdout when in > headless mode (and when VMs will provide stdio communication out of > the box). > But how i suppose to do it now? Hacking existing class? And then > again, what if someone wants to redirect transcript to socket (and its > easy to imagine where we may need that - suppose you working with > remote image and want to see its transcript). > So, hacking the same class again? > I'm probably missing the point but: why can't you do something like this:? transcript := Smalltalk at: #Transcript. Smalltalk at: #Transcript put: somethingElse. Smalltalk at: #Transcript put: transcript. Cheers, Richo > > P.S. i know that maybe a preferable way to do logging is through 'self > log:' protocol etc.. > but lets face reality: there are a tons of code in system which using > Transcript. And i don't think that we will abandon it in nearest > future. > So, lets just keep it and make it more nicer, but lets separate concerns. > > > -- > Best regards, > Igor Stasenko AKA sig. > >

April 4, 2011

Re: [Pharo-project] syntax highlighting for (stateful) traits (non-local methods)

by Toon Verwaest

> Did you check the work of fred rivard because he was managing the dynamic change of class and managing slot reinitialization? As far as I can tell from his paper he's mostly interested in the "accept instance" to modify instances from one class to another. This forces you to write the full mapping yourself in each class (from old to new). The idea of my migration is rather that the slots themselves are responsible. So this migration behavior is generally shared on slot-level. Default behavior is to just copy all the related fields. In his example it makes sense to script the whole class, since the whole class is only related semantically to what he wants to change; but I guess in most cases there are only small fragments of your class that need special care. Or the whole thing will require such elaborate care that you need waaaay bigger systems (like active context). Just my 2cents. I might have misunderstood it though :)

April 4, 2011