May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo is exploding

by StÃ©phane Ducasse

>> > > I will quote GermÃ¡n (I hope he will not mind): "lot and lot of > things... Lot of new things each day. Not time to stabilize nothing. Stabilize what? What changed so that german cannot work? In 1.4? Come on. > Is needed such acceleration? ... My point is, I'm trying to move a > business with Smalltalk and the acceleration of Pharo is well know by > me (from other companies) and sooner or later, impact in my job and > I'm a very LITTLE software house can't migrate my products all the > time." Then why do you have to migrate? Why not milestoning. I do not migrate all my applications everyday. > We simply have to accept that some developers can have this feelings > and try to find a way how to limit it. May be we should do a break and do nothing? > I think that some official > Pharo blog (maybe written by Esteban) would be very helpful. Some kind > of not very extensive technical information source that will help > people to stay in touch with Pharo progress. Ok we will do a private mailing-list. > That will explain what is > being changed in Pharo and why. I think that developers than will see > the changes like positive not as alien ones. Why people do not register to pharo-users? > > -- Pavel > >>> I do not think that the way out from this is to slow down. On the >>> contrary. We simply have to do this era of a lot of big changes as >>> short as possible ;-) >> >> >

May 16, 2012

Re: [Pharo-project] [Pharo-consortium] We need your Pharo successes

by Damien Cassou

On Wed, May 16, 2012 at 5:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Could you do a 3 slides presentation so that we can advertise it. 3 slides were already attached to the email -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 16, 2012

Re: [Pharo-project] [Pharo-consortium] We need your Pharo successes

by StÃ©phane Ducasse

excellent news! Could you do a 3 slides presentation so that we can advertise it. Stef > Stephane, > > I have a web application in early beta that I think might be worthy to add to this list. It's not yet a success story but with a little exposure I hope it will be. It still has plenty of rough edges but is about 95% functional with new features added weekly. I hope to go into a more public beta in June or July. Attached are the slides that talk about it more in depth. The site is www.todocommander.com . This is built in Seaside 3.0 in Pharo (1.3) and uses Magma as its database. > > Thanks for your consideration, > -Brian Tabone > > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr>; A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr>; pharo-consortium(a)lists.gforge.inria.fr > Sent: Tuesday, May 15, 2012 4:11 PM > Subject: Re: [Pharo-project] [Pharo-consortium] We need your Pharo successes > > Thanks Esteban for your cool slides: > > https://gforge.inria.fr/frs/download.php/30774/lawsuit3slides.pdf > > https://gforge.inria.fr/frs/download.php/30773/ibizlog3slides.pdf > > We want more! > > Stef > > > > <ToDoCommander.pdf>

May 16, 2012

Re: [Pharo-project] About process startups

by Guillermo Polito

On Wed, May 16, 2012 at 4:30 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Instead of a block, your Process would perform an instance method like > #run upon exec, while forking would just mean instantiating Process > (and populating shared objetcs as ivars) ? > Very much like Threads in other languages (Boost, Qt, etc...)... > > I find forking a block very light weight and powerfull, so your > proposition effectively helps mainly for naming and classifying things > (sic - I mean organizing). Note that almost all cases will be > singleton. > > Maybe some isKindOf: will be required in the VM, did you check? > Maybe easier. Each reified process will just do the same [ self doSomeLoop ] forkNamed: 'asdasd'. that is now hidden in class side of whatever classes. So, nothing changes from the vm side, a lightweight process can still be created from a block, and the well known processes are something we can find easily :). > > Nicolas > > 2012/5/16 Guillermo Polito <guillermopolito(a)gmail.com>: > > I'm playing with the process initialization for the bootstrap, and some > > things come to my mind. > > > > There are some classes that startup processes on the class side > initialize, > > like > > > > WeakArray -> Finalization process > > Delay -> Timer event loop > > > > What it is not clear to me is if those processes should be installed when > > the class is initialized, or when it is startupped for the first time. > > Also, I can't stop thinking that the processes in the image are all > spread > > and not clear. If I want to know where the processes are defined, it's > kind > > of a mess. > > > > Is having specialized objects for our processes undesired by some reason > I > > can't see? I'd like to have objects like > > > > MorphicUIProcess > > FinalizationProcess > > TimeEventProcess > > ... > > and so on > > > > Guille > >

May 16, 2012

Re: [Pharo-project] About process startups

by Nicolas Cellier

Instead of a block, your Process would perform an instance method like #run upon exec, while forking would just mean instantiating Process (and populating shared objetcs as ivars) ? Very much like Threads in other languages (Boost, Qt, etc...)... I find forking a block very light weight and powerfull, so your proposition effectively helps mainly for naming and classifying things (sic - I mean organizing). Note that almost all cases will be singleton. Maybe some isKindOf: will be required in the VM, did you check? Nicolas 2012/5/16 Guillermo Polito <guillermopolito(a)gmail.com>: > I'm playing with the process initialization for the bootstrap, and some > things come to my mind. > > There are some classes that startup processes on the class side initialize, > like > > WeakArray -> Finalization process > Delay -> Timer event loop > > What it is not clear to me is if those processes should be installed when > the class is initialized, or when it is startupped for the first time. > Also, I can't stop thinking that the processes in the image are all spread > and not clear.Â If I want to know where the processes are defined, it's kind > of a mess. > > Is having specialized objects for our processes undesired by some reason I > can't see?Â I'd like to have objects like > > MorphicUIProcess > FinalizationProcess > TimeEventProcess > ... > and so on > > Guille

May 16, 2012

Re: [Pharo-project] About process startups

by Pavel Krivanek

On Wed, May 16, 2012 at 3:27 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I'm playing with the process initialization for the bootstrap, and some > things come to my mind. > > There are some classes that startup processes on the class side initialize, > like > > WeakArray -> Finalization process > Delay -> Timer event loop > > What it is not clear to me is if those processes should be installed when > the class is initialized, or when it is startupped for the first time. > Also, I can't stop thinking that the processes in the image are all spread > and not clear.Â If I want to know where the processes are defined, it's kind > of a mess. > > Is having specialized objects for our processes undesired by some reason I > can't see?Â I'd like to have objects like > > MorphicUIProcess > FinalizationProcess > TimeEventProcess > ... > and so on > > Guille I'm pretty sure that the there is no real binding between the class where the processes are created and the processes themself. The Pharo Kernel terminates all but this processes: InputEventFetcher default instVarNamed: #fetcherProcess. Processor activeProcess. WeakArray runningFinalizationProcess. Processor backgroundProcess. ...and it restarts this process: Delay startTimerEventLoop. I think that to have separate classes for the basic system processes is a good idea. -- Pavel

May 16, 2012

[Pharo-project] About process startups

by Guillermo Polito

I'm playing with the process initialization for the bootstrap, and some things come to my mind. There are some classes that startup processes on the class side initialize, like WeakArray -> Finalization process Delay -> Timer event loop What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Also, I can't stop thinking that the processes in the image are all spread and not clear. If I want to know where the processes are defined, it's kind of a mess. Is having specialized objects for our processes undesired by some reason I can't see? I'd like to have objects like MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on Guille

May 16, 2012

Re: [Pharo-project] [squeak-dev] Re: Implementors of...

by Nicolas Cellier

Right, either you use a Scanner and duplicate part of Parser's job... Or you use a Parser. For findSelector, I vote for first solution because I want to have a possibility to browse imperfect selection (like not spanning on exact sub-expression boundaries). Said differently, I want a special FaultTolerantParser. Shout has some functionalities of such FaultTolerantParser. For example it does already a good job hiliting unimplemented multi-keyword selectors... I didn't dig if it was enough for cmd+click though... Nicolas 2012/5/16 Camillo Bruni <camillobruni(a)gmail.com>: > you're partly right igor :) > > that's why I added the cmd-click and cmd-shift-click to the code panels > for browsing implementors / senders of without choosing a menu. > > the one problem that remains is that shout only gives you back the tokens > with limited semantic annotations. hence you don't know if something belongs > to a multi-keyword selector or not. > > => that will change once we have full AST nodes around > > On 2012-05-16, at 02:46, Igor Stasenko wrote: > >> i don't understand one thing: >> we have shout, and it parses the source code to highlight it correctly, >> which means that it knows where each keyword selector starts, >> where it ends.. >> still we cannot navigate the code just by clicking on selector part or >> to variable name. >> the most annoying is when you have nested sends.. and sender/implementors often >> fail to work.. >> >> >> On 16 May 2012 01:55, Chris Muller <asqueaker(a)gmail.com> wrote: >>>> In Nautilus, unlike old Browser it now works for multiple keywords, so >>>> things are improving. >>> >>> Mm, I think it was Dan Ingalls who made browsing senders/implementors >>> of multi-argument keyword messages in the code pane working since the >>> 1990's. >>> >>> It works with even gross effort -- in the attached picture I made a >>> sloppy selection of #objectWithOid:ifFound:ifAbsent and press >>> Command+M to get implementors in spite of all of the intermediate code >>> it knows what I wanted. >>> >>>> The main drawback from usability point of view: it is an implicit >>>> feature, invisible to newbie and other out of the context. >>> >>> I was using Squeak for more than 5 years when someone told me about it >>> -- Once discovered, it's great, productivity has been a bit higher >>> ever since. Â People should know about it if they don't already.. >>> >>> >>> >>>> Though in term of number of actions necessary to reach information, >>>> I'm not sure it's a clear win. >>>> There's a balance between simplicity and efficiency. >>>> Isn't it also a step backward in promotion of keyboard navigation over >>>> mouse navigation? >>>> >>>> Nicolas >>>> >>>>> >>>>> Open an entry to be sure it's not lost in the mailing list, and as soon as I can, I will see to add a setting for this :) >>>>> (right now I am more in a "bugs fix" phase that "add new features" one ^^) >>>>> >>>>> Ben >>>>> >>>>> >>>>> >>>>> On May 12, 2012, at 11:47 AM, Hilaire Fernandes wrote: >>>>> >>>>>> Tried from Nautilus: >>>>>> >>>>>> Why when asking 'implementors of ' in the method menu, I only got the >>>>>> implementor of this method. >>>>>> >>>>>> Am I doing something wrong? >>>>>> >>>>>> Look like the browser need a lot of love. >>>>>> >>>>>> Hilaire >>>>>> >>>>>> -- >>>>>> Dr. Geo -- http://www.drgeo.eu >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

May 16, 2012

[Pharo-project] [update 2.0] #20075

by Esteban Lorenzano

20075 ----- This update begins the path towards modularization of Pharo builds, replacing old ScripLoader with new MetacelloScriptLoader. Still not much to see... :) Issue 5906: Better comment for Class>>#copy http://code.google.com/p/pharo/issues/detail?id=5906 Issue 5898: Fixing version browsing and ring historical behavior http://code.google.com/p/pharo/issues/detail?id=5898 Issue 5895: Change History separator in nautilus history http://code.google.com/p/pharo/issues/detail?id=5895 Issue 5894: Mini improvement in MethodWidget API http://code.google.com/p/pharo/issues/detail?id=5894

May 16, 2012

Re: [Pharo-project] WTF -> instVar called 'behaviors' in first slot

by Mariano Martinez Peck

On Wed, May 16, 2012 at 1:27 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > any direct users of #instVarAt: maybe? > > Yes. FLPackage is serialized by Fuel, so as any other object, Fuel will send #instVarAt: to trace all its instvars. But I guess that should not be a problem. > On 2012-05-16, at 12:45, Mariano Martinez Peck wrote: > > > Hi guys. Today we had something really strange with Pharo 2.0. We are > serializing FLPackage: > > > > Object subclass: #FLPackage > > instanceVariableNames: 'extensionMethods behaviors mustInitialize > preLoadActions postLoadActions additionalObjects' > > classVariableNames: 'MustInitializeByDefault' > > poolDictionaries: '' > > category: 'FuelPackageLoader' > > > > That definition, where 'extensionMethods' is before 'behaviors' it works > perfect. However, when just switching the oder to: > > > > Object subclass: #FLPackage > > instanceVariableNames: 'behaviors extensionMethods mustInitialize > preLoadActions postLoadActions additionalObjects' > > classVariableNames: 'MustInitializeByDefault' > > poolDictionaries: '' > > category: 'FuelPackageLoader' > > > > > > The serialization of PharoCore fails because a problem with a metaclass > of HTTPSocket. > > > > Any idea what can happen? > > > > thanks > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

May 16, 2012