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

Re: [Pharo-project] [squeak-dev] Cog+NativeBoost @ Mac OS

by Levente Uzonyi

On Thu, 9 Dec 2010, Igor Stasenko wrote: > Hello, > > since recently i got access to macs, i were finally able to add NB > support for Mac OS. > I built the Cog VM with NativeBoost plugin , which you can download at > NativeBoost project page [1]. > > At image side you just load NativeBoost-Installer package > and then evaluate: > > NBInstaller install. > > > Should i also build Squeak VM with NB plugin, or i could stick with Cog? :) What about adding NativeBoost to the official VMs? There could be a command line option to enable/disable it. What do you think? Levente > > [1] http://code.google.com/p/nativeboost/downloads/list > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 9, 2010

[Pharo-project] Just another struggling newbie

by Chip Nowacek

Hello everyone, While I should have introduced myself before I ran into trouble, it is trouble that has brought me here. I guess I'm glad something provided the excuse to meet you. First, a short introduction... I'm really new to Smalltalk. Kent Beck said it's a good choice for my project. Technically, I come from the database architecture world - though I am more entrepreneur now than techie. I'm starting up a new company and Kent suggested building a prototype myself instead of bringing someone else in - so here I am. I'm trying to move from Squeak because Pharo feels a little more developer oriented. We'll see how it goes. To the matter: I don't understand why I can't accept a change to my comment in one of my classes. When I try to accept in the OB Package Browser, about a dozen calls in, #Utility is being sent #changeStamp and doesn't understand it. I am in the midst of sorting through the stack trying to figure out what happened. As you might imagine, it's a little discouraging for such a basic function to blow up. What makes it worse, I'm probably the cause of the problem - I just don't know what I screwed up. I am working in Pharo 1.1.1 and have loaded Magma and O2 per: DEVImageWorkspaces openExternalProjectWorkspace I created a package for my stuff according to that which I have read so far. Maybe I did that correctly. My classes are in a category within that package. With introductions complete, I don't intend my future posts to be so long-winded. Thanks for whatever patience you've been able to afford me. Chip

Dec. 9, 2010

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

by Levente Uzonyi

On Thu, 9 Dec 2010, StÃ©phane Ducasse wrote: > BTW > when giving feedback consider that the guy doing that is spending a lot of time and this will be his master > and that the code was not optimize and that there is no dedicated primitive in play. > > So we will see at the end and I was thinking that our little community would be much more positive but > we will continue because we believe that there is some value in that. Don't get me wrong, I'm not saying that Fuel is not useful. I'm saying that improving code loading performance is not that important. Levente > > Stef >

Dec. 9, 2010

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

by Levente Uzonyi

On Thu, 9 Dec 2010, StÃ©phane Ducasse wrote: > It does! > It seems that you did not work in VW2.5 and 3.0 and when parcels arrived loading was realllllly a big difference > I do not see why this would not the same with Fuel. No I didn't, but the version number of VW is around 7.x now, so I guess the CPUs and VMs are now several times faster. Does it really matter if it takes 200ms or 20ms to load a package? Levente > > Stef > >>>>>> The difference is that in Fuel there is no managment for "shared objects". >>> Fuel is not for swapping (there are no stubs/proxies and becomes), and the >>> idea is that you write on a file, ALL (not only those objects that are ONLY >>> accessible by the roots, like in ImageSegment) the objects reachable from >>> user defined roots. >>> >>> Fuel is similar to ReferenceStream and subclasses, a XML serializer, or any >>> serializers, etc...but MOSTLY, to Parcels. It is very similar to VisualWorks >>> parcel. >>> >>> Another important thing is that it is binary. The idea is that maybe in a >>> future we have a Monticello that doesn't need a mcz (code) + Compiler, but >>> instead, just load binary code (fuel files). This would be muuuch faster >>> that current Monticello, and even more, for minimal images, we wouldn't need >>> a Compiler. >>> Finally, Fuel is designed (like Parcels) to be very fast at loading time :) >> >> Well, I doubt if speed is really important, since you're loading everything at most once. And the current tools are really fast IMHO. The following numbers are from Squeak: >> [ Compiler recompileAll ] timeToRun. 29083. >> CompiledMethod allInstances size. 60701. >> [ CompiledMethod allInstancesDo: [ :each | each getSource ] ] timeToRun. 1133. >> So the compiler is compiling 2087 methods per second on average. You can load 53575 methods per second from a file on average. If it's zipped, than it may be a bit slower, say a factor of 2-3x slowdown. So you can still load and compile more than 1800 methods per second. I guess thats fast enough. >> >> Even if Fuel can be 10x faster, it doesn't really make a difference IMHO. >> >> >> Levente >> >>> >>> Cheers >>> >>> Mariano >>> >>> >>> >>> >>>> It looks exciting! >>>> >>>> Alexandre >>>> >>>> >>>>> >>>>>> >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On 8 Dec 2010, at 13:50, 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 >>>>>>> >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > > >

Dec. 9, 2010

Re: [Pharo-project] [ANN 1.2beta] pre-build beta#12272

by Lukas Renggli

Perfect. The lag is no problem, even desired. Lukas On 9 December 2010 15:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Dec 9, 2010, at 3:21 PM, Lukas Renggli wrote: > >> Cool, is there also a fixed URL that I can refer to? >> >> Sometime like we previously had for stable versions? >> > > Yes: > > http://www.pharo-project.org/pharo-download/unstable-core > > but this lags a bit (link update is not yet automatic) > > Â Â Â Â Marcus > >> Lukas >> >> On 9 December 2010 14:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> Â Â Â Â https://gforge.inria.fr/frs/download.php/28042/PharoCore-1.2beta-12272.zip >>> >>> -- >>> Marcus Denker Â -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Lukas Renggli www.lukas-renggli.ch

Dec. 9, 2010

Re: [Pharo-project] [ANN 1.2beta] pre-build beta#12272

by Marcus Denker

On Dec 9, 2010, at 3:21 PM, Lukas Renggli wrote: > Cool, is there also a fixed URL that I can refer to? > > Sometime like we previously had for stable versions? > Yes: http://www.pharo-project.org/pharo-download/unstable-core but this lags a bit (link update is not yet automatic) Marcus > Lukas > > On 9 December 2010 14:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> https://gforge.inria.fr/frs/download.php/28042/PharoCore-1.2beta-12272.zip >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 9, 2010

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

by pharo＠googlecode.com

Comment #6 on issue 3385 by marcus.denker: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 I would add a new bug entry...

Dec. 9, 2010

Re: [Pharo-project] [ANN 1.2beta] pre-build beta#12272

by Lukas Renggli

Cool, is there also a fixed URL that I can refer to? Sometime like we previously had for stable versions? Lukas On 9 December 2010 14:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Â Â Â Â https://gforge.inria.fr/frs/download.php/28042/PharoCore-1.2beta-12272.zip > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Lukas Renggli www.lukas-renggli.ch

Dec. 9, 2010

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

by pharo＠googlecode.com

Comment #5 on issue 3385 by rydier: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 Also see the ensuing discussion the commit message created on mailing list: http://forum.world.st/Issue-3385-in-pharo-TextEditor-doest-not-understand-m… Should we create a new issue to find a better solution as discussed here for 1.3 rather than reopen this one?

Dec. 9, 2010

Re: [Pharo-project] Issue 3391 in pharo: BlockClosure>>assertWithDescription: sends #logFailure:

by pharo＠googlecode.com

Updates: Status: Closed Comment #4 on issue 3391 by marcus.denker: BlockClosure>>assertWithDescription: sends #logFailure: http://code.google.com/p/pharo/issues/detail?id=3391 I removed the call to #logFailure 12273

Dec. 9, 2010