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

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

by Toon Verwaest

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

[Pharo-project] On Pharo 1.2

by Torsten Bergmann

Sorry for changing topic ... but with all these [ANN] replies we cant see if there are really new announcements. When 1.2 Hudson was red nobody seemed to care and now that it is green/blue again discussion starts. Good or bad? At least I wished that happened earlier and a red Hudson shows that we have to do our homework. Pharo 1.2 really took time and I think we can expect further releases to take even longer since the more we clean up the harder it would be to keep compatibility with all the existing (old) packages. We all know a core alone would be useless - we have to decide which packages are maintainable by the community and worth to move forward with Pharo-dev. We have two goals that sometimes collide: -> build a small kernel/core -> build a better Smalltalk (feature rich and with good tools) If we work on cleaned up loadable/unloadable and well tested packages it would be less problematic since we can work in both images and load/unload as needed. That should be the main goal for 1.3. and beyond. Hudson is our watchdog. Nonetheless ... with Pharo 1.1 the open source ST world already changed and we have first companies/people using Pharo. Pharo is an accepted Smalltalk version. Since Pharo 1.2 is a much better and cleaner version I hope this will continue/raise and Pharo will find more new friends to help. :) Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

April 4, 2011

Re: [Pharo-project] Transcript rant

by Toon Verwaest

> 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. 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. cheers, Toon

April 4, 2011

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

by Toon Verwaest

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] syntax highlighting for (stateful) traits (non-local methods)

by Toon Verwaest

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? Nope! Thanks for the link. It's just a very small part of my paper anyway; so it's good to have a more elaborate reference. Basically this is where I'd like to plug in active context.

April 4, 2011

Re: [Pharo-project] Issue 3957 in pharo: MethodWrappers left method after uninstall

by pharo＠googlecode.com

Comment #1 on issue 3957 by marianopeck: MethodWrappers left method after uninstall http://code.google.com/p/pharo/issues/detail?id=3957 Thinking about that, I think that's a bug. I mean, you want to install the wrapper in the class Foo. For me, it should not follow the lookup. It should do just a oldMethod := self wrappedClass methodDict at: self selector which will throw an error if the selector is not defined in the class. I think that doing the lookup can be dangerous. Maybe adding another method like: ObjectAsMethodWrapper onClassOrSuperclasses: Foo selector: #hash that does what is now... what do you think ?

April 4, 2011

Re: [Pharo-project] IPAddressCountry & Iso3166CountryLongitudeLatitude

by Sven Van Caekenberghe

On 04 Apr 2011, at 18:42, Mariano Martinez Peck wrote: > what is the license? I'll explicitely MIT license those 3 classes involved as the repo has no specific license. Sven

April 4, 2011

[Pharo-project] Issue 3957 in pharo: MethodWrappers left method after uninstall

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3957 by lem...(a)gmail.com: MethodWrappers left method after uninstall http://code.google.com/p/pharo/issues/detail?id=3957 Pharo image: Pharo 1.2.1 Latest update: #12345 Virtual machine used: 'Croquet Closure Stack VM [StackInterpreter VMMaker-oscog-IgorStasenko.54]' Class browser used (if applicable): OB Steps to reproduce: 1. create a new class, example Foo 2. install a method wrapper on Foo, on a selector non defined locally. 3. uninstall the method wrapper. 4. now you have the method defined locally, with the inherited behavior. Example: | a | a := ObjectAsMethodWrapper on: Foo selector: #hash. a install. a uninstall. Now you have a hash method on Foo, that should not be there. One solution is to add something like this to the install code: (self wrappedClass localSelectors includes: self selector) ifTrue: [needCleanUp := false.] ifFalse: [needCleanUp := true]. And this to the uninstall code: needCleanUp ifTrue: [self wrappedClass removeSelector: self selector]

April 4, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Mariano Martinez Peck

On Mon, Apr 4, 2011 at 6:46 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Apr 4, 2011, at 6:36 PM, Mariano Martinez Peck wrote: > > > > On Mon, Apr 4, 2011 at 5:33 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On Apr 4, 2011, at 4:58 PM, Mariano Martinez Peck wrote: >> >> > I started to try to release 1.2. Not only I did the list of changes but >> also: >> > >> > 1) I asked if people still wanted the background: >> http://forum.world.st/Do-you-want-to-add-the-background-picture-to-the-imag… >> > results: negative. So, no backgrund. White as it is now. >> > >> > 2) I asked what people wanted that used to be in 1.1: >> http://forum.world.st/Do-we-want-this-for-Pharo-1-2-and-futures-td3350721.h… >> > guess how many replies? TWO. >> > results: I would only nclude the installScript. I guess that Hudson >> could do that very easy, doesn't it ? marcus ? >> > >> >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastSuccessfulBuild/… >> >> > Excellent! and that be included in the zip that hudson creates for the dev > images? > > > It used to be in there. But then people where thinking that it is a startup > file that is executed when the image starts up... maybe by renaming it this > would get clearer? > > ok, I understand. So yes, or a better name or...... if someone really needs to know that the build script was, then it means: 1) that he is aware of PharoCore / PharoDev 2) That he wants to reproduce the build, or fix a bug, or something. For me, both thins means that such guy is not a beginner/newbie. So we can assume that he also knows where to search such file in hudson ? if true...then we don't include the file... > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- Mariano http://marianopeck.wordpress.com

April 4, 2011

Re: [Pharo-project] fancier tab morph

by Tudor Girba

Of course, no pressure :) Cheers, Doru On 4 Apr 2011, at 18:58, Gary Chambers wrote: > When time allows... > > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, April 02, 2011 8:30 AM > Subject: Re: [Pharo-project] fancier tab morph > > > This would be the idea. Gary has reviewed it briefly and said that it looks Ok and we should integrate it in the TabMorph (right now I use subclassing). > > Gary said that he will take a closer look at it soon. > > Cheers, > Doru > > > On 2 Apr 2011, at 09:25, StÃ©phane Ducasse wrote: > >> Doru what about integrating it in 1.3? >> >> Stef >> >> On Apr 2, 2011, at 8:34 AM, Tudor Girba wrote: >> >>> Hi, >>> >>> In the context of Glamour, I worked on a Morphic tab widget a bit more and here is the status (see the screenshots for some examples): >>> - it computes the pages lazily only when you want to first show the page >>> - it provides the possibility of closing the tab >>> - it offers the possibility of rendering a toolbar for each page displayed to the right of the pages. >>> >>> If you want to play with them, you can: >>> - download the latest moose image: >>> http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… >>> >>> - execute the following to get an example of closable tabs: >>> GLMBasicExamples new accumulator openOn: 42 >>> >>> - execute the following to get an example of tabs with different toolbars attached (to the right): >>> GLMBasicExamples new tabsWithDifferentActions openOn: 42 >>> >>> >>> There are still a couple of issues left: >>> - When the title of a tab is too large, it pushes the bounds of the pane beyond what is visible. >>> - Also, when we have multiple tabs, they again go overboard. >>> - Similar things happen with the toolbar. >>> >>> However, the good news is that Gary is looking into this :) >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Relationships are of two kinds: those we choose and those that happen. They both matter." >>> >>> <ClosableTab.png><TabWithActions.png> >> >> > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > > -- www.tudorgirba.com "Presenting is storytelling."

April 4, 2011