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

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

by Eliot Miranda

Hi Martin & Mariano, regarding filtering. Yesterday my colleague Yaron and I successfully finished our port of Fuel to Newspeak and are successfully using it to save and restore our data sets; thank you, its a cool framework. We had to implement two extensions, the first of which the ability to save and restore Newspeak classes, which is complex because these are instantiated classes inside instantiated Newspeak modules, not static Smalltalk classes in the Smalltalk dictionary. The second extension is the ability to map specific objects to nil, to prune objects on the way out. I want to discuss this latter extension. In our data set we have a set of references to objects that are logically not persistent and hence not to be saved. I'm sure that this will be a common case. The requirement is for the pickling system to prune certain objects, typically by arranging that when an object graph is pickled, references to the pruned objects are replaced by references to nil. One way of doing this is as described below, by specifiying per-class lists of instance variables whose referents shoudl not be saved. But this can be clumsy; there may be references to objects one wants to prune from e.g. more than one class, in which case one may have to provide multiple lists of the relevant inst vars; there may be references to objects one wants to prune from e.g. collections (e.g. sets and dictionaries) in which case the instance variable list approach just doesn't work. Here are two more general schemes. VFirst, most directly, Fuel could provide two filters, implemented in the default mapper, or the core analyser. One is a set of classes whose instances are not to be saved. Any reference to an instance of a class in the toBePrunedClasses set is saved as nil. The other is a set of instances that are not to be saved, and also any reference to an instance in the toBePruned set is saved as nil. Why have both? It can be convenient and efficient to filter by class (in our case we had many instances of a specific class, all of which should be filtered, and finding them could be time consuming), but filtering by class can be too inflexible, there may indeed be specific instances to exclude (thing for example of part of the object graph that functions as a cache; pruning the specific objects in the cache is the right thing to do; pruning all instances of classes whose instances exist in the cache may prune too much). As an example here's how we implemented pruning. Our system is called Glue, and we start with a mapper for Glue objects, FLGlueMapper: FLMapper subclass: #FLGlueMapper instanceVariableNames: 'prunedObjectClasses newspeakClassesCluster modelClasses' classVariableNames: '' poolDictionaries: '' category: 'Fuel-Core-Mappers' It accepts newspeak objects and filters instances in the prunedObjectsClasses set, and as a side-effect collects certain classes that we need in a manifest: FLGlueMapper>>accepts: anObject "Tells if the received object is handled by this analyzer. We want to hand-off instantiated Newspeak classes to the newspeakClassesCluster, and we want to record other model classes. We want to filter-out instances of any class in prunedObjectClasses." ^anObject isBehavior ifTrue: [(self isInstantiatedNewspeakClass: anObject) ifTrue: [true] ifFalse: [(anObject inheritsFrom: GlueDataObject) ifTrue: [modelClasses add: anObject]. false]] ifFalse: [prunedObjectClasses includes: anObject class] It prunes by mapping instances of the prunedObjectClasses to a special cluster. It can do this in visitObject: since any newspeak objects it is accepting will be visited in its visitClassOrTrait: method (i.e. it's implicit that all arguments to visitObjects: are instances of the prunedObjectsClasses set). FLGlueMapper>>visitObject: anObject analyzer mapAndTrace: anObject to: FLPrunedObjectsCluster instance into: analyzer clustersWithBaselevelObjects FLPrunedObjectsCluster is a specialization of the nil,true,false cluster that maps its objects to nil: FLNilTrueFalseCluster subclass: #FLPrunedObjectsCluster instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Fuel-Core-Clusters' FLPrunedObjectsCluster >>serialize: aPrunedObject on: aWriteStream super serialize: nil on: aWriteStream So this would generalize by the analyser having an e.g. FLPruningMapper as the first mapper, and this having a prunedObjects and a priunedObjectClasses set and going something like this: FLPruningMapper>>accepts: anObject ^(prunedObjects includes: anObject) or: [prunedObjectClasses includes: anObject class] FLPruningMapper >>visitObject: anObject analyzer mapAndTrace: anObject to: FLPrunedObjectsCluster instance into: analyzer clustersWithBaselevelObjects and then one would provide accessors in FLSerialzer and/or FLAnalyser to add objects and classes to the prunedObjects and prunedObjectClasses set. For efficiency one could arrange that the FLPruningMapper was not added to the sequence of mappers unless and until objects or classes were added to the prunedObjects and prunedObjectClasses set. I think both Yaron and I feel the Fuel framework is comprehensible and flexible. We enjoyed using it and while we took two passes at coming up with the pruning scheme we liked (our first was based on not serializing specific ins vars and was much more complex than our second, based on pruning instances of specific classes) we got there quickly and will very little frustration along the way. Thank you very much. Finally, a couple of things. First, it may be more flexible to implement fuelCluster as fuelClusterIn: anFLAnalyser so that if one is trying to override certain parts of the mapping framework an implementation can access the analyser to find existing clusters, e.g. MyClass>>fuelClusterIn: anFLAnalyser ^self shouldBeInASpecialCluster ifTrue: [anFLAnalyser clusterWithId: MySpecialCluster id] ifFalse: [super fuelClusterIn: anFLAnalyser] This makes it easier to find a specific unique cluster to handle a group of objects specially. Lastly, the class-side cluster ids are a bit of a pain. It would be nice to know a) are these byte values or general integer values, i.e. can there be more than 256 types of cluster?, and b) is there any meaning to the ids? For example, are clusters ordered by id, or is this just an integer tag? Also, some class-side code to assign an unused id would be nice. You might think of virtualizing the id scheme. For example, if FLCluster maintained a weak array of all its subclasses then the id of a cluster could be the index in the array, and the array could be cleaned up occasionally. Then each fuel serialization could start with the list of cluster class names and ids, so that specific values of ids are specific to a particular serialization. again thanks for a great framework. best, Eliot On Mon, Jun 13, 2011 at 10:16 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Thu, Jun 9, 2011 at 3:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi Martin and Mariano, >> >> a couple of questions. What's the right way to exclude certain >> objects from the serialization? Is there a way of excluding certain inst >> vars from certain objects? >> >> > > Eliot and the rest....Martin implemented this feature in > Fuel-MartinDias.258. For the moment, we decided to put > #fuelIgnoredInstanceVariableNames at class side. > > Behavior >> fuelIgnoredInstanceVariableNames > "Indicates which variables have to be ignored during serialization." > > ^#() > > > MyClass class >> fuelIgnoredInstanceVariableNames > ^ #('instVar1') > > > The impact in speed is nothing, so this is good. Now....we were thinking if > it is common to need that 2 different instances of the same class need > different instVars to ignore. Is this common ? do you usually need this ? > We checked in SIXX and it is at instance side. Java uses the prefix > 'transient' so it is at class side... > > thanks > > > -- > Mariano > http://marianopeck.wordpress.com > >

June 15, 2011

Re: [Pharo-project] [Metacello] #currentVersion is wrong?

by Dale Henrichs

Mariano, For some reason in Pharo1.3a-13259 the package Metacello-Help-DaleHenrichs.9 is loaded instead of Metacello-Help-dkh.11 (all other Metacello packages are correct for 1.0-beta.29). So that forces the version of Metacello to be 1.0-beta.28.5, which forces the version of Pharo to be 1.2.2. If you load Metacello-Help-dkh.11: (ConfigurationOfMetacello project version: '1.0-beta.29') load. and check the version of Pharo, you'll find that it is 'correct'. Now, I'm not sure what the old version of help is being loaded ... Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: metacello(a)googlegroups.com, "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> | Sent: Friday, June 10, 2011 6:03:46 AM | Subject: [Metacello] #currentVersion is wrong? | | Hi Dale. If I took the latest Pharo 1.3 from hudson: | https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/214/ | | and I print | ConfigurationOfPharo project currentVersion | | I get ->>>>> >=1.2.2 [ConfigurationOfPharo] | | But in fact, that's not true. It should be 1.3-beta2 | [ConfigurationOfPharo] | | I've checked and the real version loaded is 1.3-beta2 so I think it | is a problem of #currentVersion. | | Thanks | | -- | Mariano | http://marianopeck.wordpress.com | |

June 15, 2011

Re: [Pharo-project] [squeak-dev] Morphic on HTML+CSS

by Janko MivÅ¡ek

S, Colin Putney piÅ¡e: >> In light of recent Microsoft surprising U-turn announcement [1] that in >> Windows 8 it swithes to HTML5 (HTML5+CSS+JavaScript) instead of .NET+WPF >> and Silverlight for desktop app development it is IMO a right time to >> think about: >> >> 1. is this a clear signal that HTML5 for ALL apps, both desktop and the >> web is inevitable? > > No. Apple isn't going that way, and Microsoft is just dipping its toe > in the water. > >> 2. is this a clear signal that we need to rebuild Morphic on top of >> HTML+CSS, to leverage all Morphic advantages and come back >> to bleeding edge again? > > Dan Ingalls has done it already: http://lively-kernel.org/ Lively is a project to watch and study, but Lively is JavaScript only, not using HTML and CSS, as far as I know. Separation of design with CSS is namely something which really raised the creativity fo designers on the web. This can help building better and nicely looking Smalltalk apps too! Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

June 15, 2011

Re: [Pharo-project] starring our project on google

by Dale Henrichs

June 15, 2011

Re: [Pharo-project] starring our project on google

by Eliot Miranda

On Tue, Jun 14, 2011 at 4:57 PM, Steve Taylor <stephen.taylor(a)bom.gov.au>wrote: > On 15/06/11 02:09, Alexandre Bergel wrote: > >> Hi Guys! >> >> Don't forget to star our project: >> http://code.google.com/p/pharo/ >> http://code.google.com/p/moose-technology/ >> http://code.google.com/p/metacello/ >> > > Done. > > May I make a suggestion for the Metacello page? > > The Pharo page starts with "Pharo is.." and a short description. > The Moose page starts with "Moose is..." and a short description. > > The Metacello page should do the same. Actually, every open source project > in the universe should do the same :) > +1000!! I *hate* reading "New in this package, bug 1001 fixed, feature y half-implemented" style intros when I haven't the faintest clue of what the package does. best, Eliot > Cheers, >> Alexandre >> > > > > cheers, > > > > Steve > > > > >

June 15, 2011

Re: [Pharo-project] [Pharo-users] Smalltalk meeting in Frankfurt / Germany 16.6

by StÃ©phane Ducasse

On Jun 15, 2011, at 5:24 PM, Sven Van Caekenberghe wrote: > > On 15 Jun 2011, at 10:48, Marcus Denker wrote: > >> Thomas Holzer will present how Smalltalk is used at HRWorks http://www.hrworks.de > > Thomas was on the last Pharo sprint in Brussels and I had a nice talk with him. > > I think most people don't realize how big a Smalltalk success story HR Works actually is. > > They have hundreds of (often big name) companies as customers, and many tens of thousands of users on a SaaS pay as you go model. Do the math ;-) we did the math. In fact this is great because I follow the success of HRWorks since 1998 or 2000. And I was really proud/touched that they were impressed by our work too. > And all this based on a Smalltalk software product (using a OODB as well). This is really very cool ! > > We just have to convince him to switch to Pharo, at least for some of their stuff... :) First I would like to make sure that what he will present at ESUG will get open-sourced and benefit to the community. > > Sven > >

June 15, 2011

Re: [Pharo-project] [Pharo-users] Smalltalk meeting in Frankfurt / Germany 16.6

by Sven Van Caekenberghe

On 15 Jun 2011, at 10:48, Marcus Denker wrote: > Thomas Holzer will present how Smalltalk is used at HRWorks http://www.hrworks.de Thomas was on the last Pharo sprint in Brussels and I had a nice talk with him. I think most people don't realize how big a Smalltalk success story HR Works actually is. They have hundreds of (often big name) companies as customers, and many tens of thousands of users on a SaaS pay as you go model. Do the math ;-) And all this based on a Smalltalk software product (using a OODB as well). This is really very cool ! We just have to convince him to switch to Pharo, at least for some of their stuff... Sven

June 15, 2011

[Pharo-project] Morph's #flags instVar

by Torsten Bergmann

Hi Bernat, when you add it to Morph you only see an error message. Try adding the instVar #flags to SystemProgressMorph and you get a debugger. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

June 15, 2011

[Pharo-project] Morph's #flags instVar

by Bernat Romagosa

Hi list, In order to get Scat to be able to import Scratch projects, we'd need to add the 'flags' instVar to Morph, but whenever we try an error is triggered. Is there a reason for this behaviour? How can we get to add this variable? Thanks! -- Bernat Romagosa

June 15, 2011

Re: [Pharo-project] [Pharo-users] [PBE-Spanish] Status update 2011-06-15

by StÃ©phane Ducasse

I love these reports. Stef On Jun 15, 2011, at 1:49 PM, NicolÃ¡s Paez wrote: > Hello everyone, > > Here is the status update of the Spanish translation of Pharo By Example book. > Last week we realized that there was a chapter that we were forgetting to translate, ups!, but despite of that we are doing good progress. > > Chapter 01: 54% > > Chapter 02: 78% > > Chapter 03: 100%, already publish > > > > Chapter 04: 100%, already publish > > > > Chapter 05: 86% > > Chapter 06: 7% > > Chapter 07: 100%, not publish yet > > > > Chapter 08: 29% > > > > Chapter 09: 100%, not published yet > > > > Chapter 10: not started > Chapter 11: 100%, already published > > > > Chapter 12: 47% > > Chapter 13: 100%, not published yet > > > > Chapter 14: 100%, not published yet > > > > > Regards, > Nico. > blog: nicopaez.wordpress.com

June 15, 2011