December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

by StÃ©phane Ducasse

I know. Still showing the way is often important. On Dec 8, 2010, at 7:24 PM, Yanni Chiu wrote: > Lukas and Philippe brought it to its current state. I just did the first version. > > On 08/12/10 12:21 PM, StÃ©phane Ducasse wrote: >> Yes Thanks Yanni for your code. >> We have a lot of ideas on what to do with automated build servers :) >> This is just the start. I was dreaming on that while listening pelrine talk at ESUG 2002 on Cruse control... >> May be we should have built something by then .... >> >> Stef > >

Dec. 8, 2010

Re: [Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

by Francisco Ortiz PeÃ±aloza

Levente, that's weird, i'm sending you a screenshot i'm running PharoCore 12271 with Ocompletion-ul.88 loaded I really like how you clear the way with these two questions, - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor? Using OCompletion is ok i think, in another email i said that having two way autocompletion with the TextEditor element and the recent WHATEVER used list above dont make sense to me, but some argue that they use their mouse to go to a recently used class. i think the finder window should be minimal, just the input text element -no recent used list- and have autocompletion (ie. web autocompletion). As web users we see that a lot, i will not miss the recent WHATEVER list. On your second question, imho we're trying to find a Smalltalk class or Smalltalk WHATEVER, could be better to have a SmalltalkEditor instance instead of TextEditor one. Cheers, Francisco [image: PharoScreenshot.1.png] On Wed, Dec 8, 2010 at 4:20 AM, Alain Plantec <alain.plantec(a)free.fr> wrote: > I agree with Levente. The basic completion (cmd-q) is also only usable with > a SmalltalkEditor. > Cheers > Alain > > Le 08/12/2010 03:58, Levente Uzonyi a Ã©crit : > > On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote: >> >> So Levente you're saying that given the following use case you musn't add >>> #model to TextEditor but change TextEditor collaboration with an instance >>> of >>> SmalltalkEditor >>> >>> OCompletion works well to edit code in the system browser as is, the DNU >>> occurs when as an example you do a class find (Cmd+f) on SystemBrowser >>> and >>> you start typing on that "Class name or fragment" window looking for >>> something. >>> >> >> Adding the accessor is fine of course, it may be useful for other things >> too. I'm saying that OCompletion is intended to work in places where code >> completion is necessary and those places are usually SmalltalkEditors. There >> are two things to think about: >> - should OCompletion be used in that panel? >> - should that panel use TextEditor instead of SmalltalkEditor? >> >> Btw using the latest version of PharoCore (12271) I can't reproduce the >> error in the way you described it. >> >> >> Levente >> >> >>> Cheers, >>> Francisco >>> >>> On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>> On Tue, 7 Dec 2010, pharo(a)googlecode.com wrote: >>>> >>>> Status: Accepted >>>> >>>>> Owner: guillermopolito >>>>> >>>>> New issue 3385 by guillermopolito: TextEditor doest not understand >>>>> #model >>>>> http://code.google.com/p/pharo/issues/detail?id=3385 >>>>> >>>>> The accessor should be added to load last version of OCompletion in >>>>> Core >>>>> 1.2 >>>>> >>>>> >>>>> >>>>> OCompletion shouldn't be used in a TextEditor. OCompletion is for >>>> Smalltalk >>>> code completion, while TextEditor is intended to be a text editor (ask >>>> Juan). That's why OCompletion adds the model accessor to SmalltalkEditor >>>> and >>>> not to TextEditor. >>>> >>>> >>>> Levente >>>> >>>> >>>> >>> >> >> > >

Dec. 8, 2010

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

by Yanni Chiu

Lukas and Philippe brought it to its current state. I just did the first version. On 08/12/10 12:21 PM, StÃ©phane Ducasse wrote: > Yes Thanks Yanni for your code. > We have a lot of ideas on what to do with automated build servers :) > This is just the start. I was dreaming on that while listening pelrine talk at ESUG 2002 on Cruse control... > May be we should have built something by then .... > > Stef

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by Eliot Miranda

On Wed, Dec 8, 2010 at 9:00 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > > > > Indeed. An immature FFI, lack of dll options etc. Integration is indeed > one of the biggest weaknesses. But we're making progress here. So things > may be different in months, if not years. > > Eliot did you get interpret reentrant? > I have a prototype reentrant FFI that can do threaded call-outs and receive threaded callbacks. I was demoing it in Argentina but my demo locks up the UI (not the entire image thoguh) so it is not by any means production-ready. I need to find time to finish it. That's not going to happen in the next two months. I'll see what can be done to get it released in an unfinished state so that others can work on it. best Eliot > Because we are discussing that point with igor and yes we want that to have > :) > > Stef > > >

Dec. 8, 2010

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

by StÃ©phane Ducasse

Yes Thanks Yanni for your code. We have a lot of ideas on what to do with automated build servers :) This is just the start. I was dreaming on that while listening pelrine talk at ESUG 2002 on Cruse control... May be we should have built something by then .... Stef >>>> Gofer it squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfPharo'; >>>> load. >>>> >>>> (ConfigurationOfPharo project version: '1.2-beta2') load. >>>> >>>> Can Hudson help us in building Dev images? >>> >>> Yes, will set up a build for 1.2 today. >> >> I have set one up that takes 1.2 core, runs updates and then tries to >> build dev >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ >> >> It is failing right now. >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console > > This build would flag changes to PharoCore-1.2 that break Pharo(Dev) 1.2-beta2. But those core changes may be legitimate, and the fix needs to be done in Pharo(Dev). > > Maybe there should be a second build for Pharo(Dev) 1.2-baseline. The trigger ought to be any change to a package included in the baseline, but that seems difficult to determine. So, maybe once a day, as well as triggering on a change to ConfigurationOfPharo itself. > > BTW, It's great that we have automated builds. > >

Dec. 8, 2010

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

by Dale Henrichs

On 12/08/2010 09:09 AM, Yanni Chiu wrote: > On 08/12/10 6:48 AM, Marcus Denker wrote: >> >> On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote: >> >>> >>> On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote: >>> >>>> Gofer it squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfPharo'; >>>> load. >>>> >>>> (ConfigurationOfPharo project version: '1.2-beta2') load. >>>> >>>> Can Hudson help us in building Dev images? >>> >>> Yes, will set up a build for 1.2 today. >> >> I have set one up that takes 1.2 core, runs updates and then tries to >> build dev >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ >> >> It is failing right now. >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console > > This build would flag changes to PharoCore-1.2 that break Pharo(Dev) > 1.2-beta2. But those core changes may be legitimate, and the fix needs > to be done in Pharo(Dev). > > Maybe there should be a second build for Pharo(Dev) 1.2-baseline. The > trigger ought to be any change to a package included in the baseline, > but that seems difficult to determine. So, maybe once a day, as well as > triggering on a change to ConfigurationOfPharo itself. > > BTW, It's great that we have automated builds. > With the next release of Metacello there will be support for programmatically updating a config, so if the baseline build runs clean for pharo dev, the development version could be updated automagically ... folks would always be able to load the dev version and know that at least the tests ran clean and that you are within a safe distance of the absolute bleeding edge... Dale

Dec. 8, 2010

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

by Yanni Chiu

On 08/12/10 6:48 AM, Marcus Denker wrote: > > On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote: > >> >> On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote: >> >>> Gofer it squeaksource: 'MetacelloRepository'; >>> package: 'ConfigurationOfPharo'; >>> load. >>> >>> (ConfigurationOfPharo project version: '1.2-beta2') load. >>> >>> Can Hudson help us in building Dev images? >> >> Yes, will set up a build for 1.2 today. > > I have set one up that takes 1.2 core, runs updates and then tries to > build dev > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ > > It is failing right now. > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console This build would flag changes to PharoCore-1.2 that break Pharo(Dev) 1.2-beta2. But those core changes may be legitimate, and the fix needs to be done in Pharo(Dev). Maybe there should be a second build for Pharo(Dev) 1.2-baseline. The trigger ought to be any change to a package included in the baseline, but that seems difficult to determine. So, maybe once a day, as well as triggering on a change to ConfigurationOfPharo itself. BTW, It's great that we have automated builds.

Dec. 8, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by StÃ©phane Ducasse

Thanks martin. Stef On Dec 8, 2010, at 5:50 PM, Martin Dias wrote: > Hi all > > Last months I and Tristan have been working on Fuel project, an object > binary serialization tool. The idea is that objects are much more > times loaded than stored, therefore it is worth to spend time while > storing in order to have faster loading and user experience. We > present an implementation of a pickle format that is based on > clustering similar objects. > > There is a summary of the project below, but more complete information > is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel > > The implementation still needs a lot of work to be really useful, > optimizations should be done, but we'll be glad to get feedback of the > community. > > > = Pickle format = > > The pickle format and the serialization algorithm main idea, is > explained in this slides: > > http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example > > > = Current features = > > - Class shape changing (when a variable has been added, or removed, or > its index changed) > - Serialize most of the basic objects. > - Serialize (almost) any CompiledMethod > - Detection of global or class variables > - Support for cyclic object graphs > - Tests > > > = Next steps = > > - Improve version checking. > - Optimize performance. > - Serialize more kinds of objects: > -- Class with its complete description. > -- Method contexts > -- Active block closures > -- Continuation > - Some improvements for the user: > -- pre and post actions to be executed. > -- easily say 'this object is singleton'. > - Partial loading of a stored graph. > - Fast statistics/brief info extraction of a stored graph. > - ConfigurationOfFuel. > - Be able to deploy materialization behavior only (independent from > the serialization behavior) > > > = Download = > > In a Pharo 1.1 or 1.1.1 evaluate: > > Gofer new > squeaksource: 'Fuel'; > version: 'Fuel-MartinDias.74'; > version: 'FuelBenchmarks-MartinDias.4'; > load. > > > = Benchmarks = > > You can run benchmarks executing this line (results in Transcript): > > FLBenchmarks newBasic run. > > > Thank you! > Martin Dias >

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by StÃ©phane Ducasse

> > > Indeed. An immature FFI, lack of dll options etc. Integration is indeed one of the biggest weaknesses. But we're making progress here. So things may be different in months, if not years. Eliot did you get interpret reentrant? Because we are discussing that point with igor and yes we want that to have :) Stef

Dec. 8, 2010

[Pharo-project] Fuel - a fast object deployment tool

by Martin Dias

Hi all Last months I and Tristan have been working on Fuel project, an object binary serialization tool. The idea is that objects are much more times loaded than stored, therefore it is worth to spend time while storing in order to have faster loading and user experience. We present an implementation of a pickle format that is based on clustering similar objects. There is a summary of the project below, but more complete information is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel The implementation still needs a lot of work to be really useful, optimizations should be done, but we'll be glad to get feedback of the community. = Pickle format = The pickle format and the serialization algorithm main idea, is explained in this slides: http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example = Current features = - Class shape changing (when a variable has been added, or removed, or its index changed) - Serialize most of the basic objects. - Serialize (almost) any CompiledMethod - Detection of global or class variables - Support for cyclic object graphs - Tests = Next steps = - Improve version checking. - Optimize performance. - Serialize more kinds of objects: -- Class with its complete description. -- Method contexts -- Active block closures -- Continuation - Some improvements for the user: -- pre and post actions to be executed. -- easily say 'this object is singleton'. - Partial loading of a stored graph. - Fast statistics/brief info extraction of a stored graph. - ConfigurationOfFuel. - Be able to deploy materialization behavior only (independent from the serialization behavior) = Download = In a Pharo 1.1 or 1.1.1 evaluate: Gofer new squeaksource: 'Fuel'; version: 'Fuel-MartinDias.74'; version: 'FuelBenchmarks-MartinDias.4'; load. = Benchmarks = You can run benchmarks executing this line (results in Transcript): FLBenchmarks newBasic run. Thank you! Martin Dias

Dec. 8, 2010