- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo is exploding

by Francois Stephany

> Yes let us create a core-dev private mailing-list. Please don't. Just force people to use pharo-users when the question does not fit the criteria for pharo-project.

May 16, 2012

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

by StÃ©phane Ducasse

tx dam :) On May 16, 2012, at 5:06 PM, Damien Cassou wrote: > 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 is exploding

by StÃ©phane Ducasse

On May 16, 2012, at 11:13 AM, Esteban Lorenzano wrote: > > 99% of the changes affects infrastructure and/or replace old tools. Why your work should be affected by that? > I migrated Seaside from 1.3 to 1.4 in 15'... and the "problem" was not Seaside-Pharo incompatibilities, but to adapt configuration to not load OB (just not choose those packages in the metacello config) > Other frameworks like Magritte and Pier ran out of the box. (well... Magritte-Mophic needed a small adjust... and that was like 5') > For more examples, my personal projects (I submitted 3 slides yesterday for two of them), are usually complex projects (both for web and desktop) and I migrated all of them in less than a morning work (I needed to update/modify my metacello configurations for that). > > So... as soon as I know... your feelings are just that: feelings. Not real facts. > And maybe those feelings are because we (as a community) are growing and we need to adapt our communication processes to match current status. But I think that's a good think, not a bad one. + 10000 May be you should paste that into a blog! And can we have a private developer mailing-list :) Because now our movement is questioned and I do not like that. Stef

May 16, 2012

Re: [Pharo-project] Pharo is exploding

by StÃ©phane Ducasse

> > > >> I've recently read the book on UI usability [1], were the author >> states that after ten years of performing user evaluations and >> studies, he can assert that "people stick to the first thing that >> works". >> >> Maybe that's the reason behind this aversion to change. >> > Another idea is that it's an instantiation of the Innovators Dilemma? > > http://www.amazon.com/The-Innovators-Dilemma-Revolutionary-Essentials/dp/00… > > What he shows in the book is that if you ask your customers, they never want change. > But your competitor (especially new one) that does not listen to your customers and > does exactly what they where against will in the end take all your business. > > Because the people that where against all change have no problem to abandon the > unchaning thing when something better comes along. > > Requesting "no change" will *not* give you layality. "You did not want change so you > can't now use the better new stuff, you have to stay with the system you *requested* to > stay as it is". No. The exact same people that request "no change" will move to the better, > too. > > It's a real dilemma. This book is ridiculous too. Nobody will ever want crappy digital camera only the real stuff. Digital camera are non-sense nobody will ever buy them. I want better quality for my "argentic" camera. Stef

May 16, 2012

Re: [Pharo-project] Pharo is exploding

by StÃ©phane Ducasse

We should stop talking for somebody that may not even use our system and write code. Stef

May 16, 2012

Re: [Pharo-project] Pharo is exploding

by StÃ©phane Ducasse

>> > > Part of that is that I started the project "tweet something about Pharo every day". > some 15 months? ago... my idea was that we need to make public what > happens because most people's perception was : Smalltak is dead. > > If people want I can stop. YES PLEASE STOP THIS WAS THE MOST RIDICULOUS EVER IDEA. IMAGINE people could think that we are not dead... >> Not time to stabilize nothing. > > Pharo 1.4 is frozen. We just fix bugs. The same with 1.3. Or even 1.2... > >> 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." >> > You should *not* migrate. That's the idea. Just as one uses a (in the future > unchanging Cuis, I am sorry to hear that), you can use an unchaning Pharo 1.4, > or 1.3. > Only when your project needs it, (because you actively with manpower develop it > for a longer time), you can move to a new version. > >> We simply have to accept that some developers can have this feelings >> and try to find a way how to limit it. 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. 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. >> > > What I think is problematic: Peopler are against Change. But when somone > nevertheless does it, build a great system, the same people that did not allow > us to move will gladly abandon the old system for the new system. > Cuis is a good example. According to the Philosophy of German, it should not exist. > > Maybe we should partition the *mailinglist* by stable and unstable? > This way people using the stable don't see the noise and can focusâ¦ Yes let us create a core-dev private mailing-list. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

May 16, 2012

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