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

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality

by Eliot Miranda

On Fri, Sep 16, 2011 at 12:08 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/9/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > 2011/9/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> I don't really know. I have implemented what Eliot say in the first > option > >> and it is working for me. > >> Do you (Henry/Lukas/Nicolas/Eliot) agree to have this first solution and > >> then improve it if necessary ? > >> > >> thanks > >> > > > > I agree on Mariano/Eliot solution. It is a good pragmatic short term > workaround. > > In the long term, I wish I can say goodbye to my new super power, it's > > a too dangerous power. > > So I wish the VM would change (along with ClassBuilder and Tools). > Yes, I agree. It just takes time to get there. > > > > Nicolas > > > > Or maybe after reading: > > literal1 := self literalAt: numLits. > literal2 := method literalAt: numLits. > ^ (literal1 == literal2) or: [literal1 key isNil == literal2 key > isNil and: [literal1 value == literal2 value]]. > > I we are sure that the last literal is always an Association > If it's not then one is playing fast and loose with the system. But if the method doesn't contain a super send then as far as the VM is concerned it doesn't need an association, and that might be the case with, for example, shared inst var accessors in Newspeak. So instead of assuming its an association write it something like ^literal1 class == literal2 class and: [literal1 isVariableBinding ifTrue: [literal1 key = literal2 key and: [literal1 value = literal2 value]] ifFalse: [literal1 = literal2]] > Nicolas > > >> On Fri, Sep 16, 2011 at 8:12 PM, StÃ©phane Ducasse > >> <stephane.ducasse(a)inria.fr> wrote: > >>> > >>> Mariano > >>> > >>> So should we intgerate a fix? > >>> > >>> Stef > >>> > >>> On Sep 15, 2011, at 11:27 PM, Mariano Martinez Peck wrote: > >>> > >>> > > >>> > > >>> > > >>> > BUT, it doesn't mean that Association is always used for globals. > >>> > CompiledMethod equality is failing because of the last literal, the > one that > >>> > maps class name (symbol) and point to the real class. So...when I > >>> > materialize, both CMs have non-identical associations for the last > literal, > >>> > but equal. > >>> > > >>> > As Henrik says the last literals are ideally #== to each other. > >>> > However, no Squeak dialect makes any attempt to keep the class0side > >>> > associations equal. Look at a class-side method and you'll see it's > last > >>> > literal is nil->SomeClass class. Now since this association doesn't > exist > >>> > in Smalltalk (unlike last literals on the instance side) the compiler > merely > >>> > creates distinct ones for each class-side method. > >>> > > >>> > > >>> > Thanks Eliot for that point. In fact, I have just checked and you are > >>> > right. The tests that are failing for me is those where class side > methods > >>> > are involded. In this case, the last literal of the original CM and > the > >>> > materialized, gives false in #literalEqual: hence, originalCM = > >>> > materializedCM is false :( > >>> > > >>> > > >>> > > >>> > Personally I don't think one can defend the position where method > >>> > equality is different for instance-side or class-side methods so > there must > >>> > be some solutions: > >>> > > >>> > 1. special case comparison of the last literal (the methodClass > >>> > literal), comparing keys and insisting that the keys be #== and the > values > >>> > be #== (can't just define it as keys #== since all similar class-side > >>> > methods will be equal irrespective of their actual class). > >>> > > >>> > > >>> > This one seems the easier and fixes my problem :) > >>> > > >>> > sameLiteralsAs: method > >>> > "Compare my literals to those of method. This is needed to > compare > >>> > compiled methods." > >>> > > >>> > | numLits literal1 literal2 | > >>> > (numLits := self numLiterals) ~= method numLiterals > >>> > ifTrue: [ ^ false ]. > >>> > "The last literal requires special checking instead of using > >>> > #literalEqual:" > >>> > 1 to: numLits - 1 do: [ :index | > >>> > literal1 := self literalAt: index. > >>> > literal2 := method literalAt: index. > >>> > (literal1 == literal2 or: [ literal1 literalEqual: literal2 > ]) > >>> > ifFalse: [ > >>> > (index = 1 and: [ #(117 120) includes: self primitive > ]) > >>> > ifTrue: [ > >>> > literal1 isArray > >>> > ifTrue: [ > >>> > (literal2 isArray and: [ literal1 > >>> > allButLast = literal2 allButLast ]) > >>> > ifFalse: [ self halt. ^ false ] ] > >>> > ifFalse: [ > >>> > "ExternalLibraryFunction" > >>> > (literal1 analogousCodeTo: literal2) > >>> > ifFalse: [ self halt. ^ false ] ] > ] > >>> > ifFalse: [ > >>> > index = (numLits - 1) > >>> > ifTrue: [ > >>> > "properties" > >>> > (self properties analogousCodeTo: > method > >>> > properties) > >>> > ifFalse: [ self halt. ^ false ] ] > >>> > ifFalse: [ self halt. ^ false ] ] ] ]. > >>> > literal1 := self literalAt: numLits. > >>> > literal2 := method literalAt: numLits. > >>> > ^ ((literal1 key == literal2 key) and: [literal1 value == > literal2 > >>> > value]). > >>> > > >>> > > >>> > > >>> > 2. special case comparison of the last literal (the methodClass > >>> > literal), insisting only that the class of the literal be the same if > it > >>> > isVariableBinding. > >>> > > >>> > 3. make the compile unique class-side methodClass literals. i.e. if > a > >>> > class already has a class-side method then the compiler or method > dictionary > >>> > insertion code must find that existing association and reuse it > >>> > > >>> > Other ideas? > >>> > > >>> > >From my point of view, that literal, the last one does not need to > be > >>> > identical to assume 2 CMs are equal. They just need to be equal. > >>> > > >>> > > >>> > -- > >>> > Mariano > >>> > http://marianopeck.wordpress.com > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > best, > >>> > Eliot > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Mariano > >>> > http://marianopeck.wordpress.com > >>> > > >>> > >>> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > >> > > > > -- best, Eliot

Sept. 16, 2011

[Pharo-project] Minimal buildable Pharo image with GUI?

by Dimitry Golubovsky

Pavel, Pavel wrote: > Metacello is currently not supported by PharoKernel Gofer image. You > must load packages manulay (something like > http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker…) > We have no list of packages you need. But you may try the same > mechanism used in uMorphic to get code necessary for you applications. Well, a script like this would perhaps be a good starting point. I need a minimal GUI functionality to show a simple dialog form, and network. A typical task I need to solve is to download an image to the Android device. So the form would ask the image file URL, whether to use HTTP proxy, where to save on SD card. Another task: to show list of installed images, let a user tap on one, (re-)launch the VM with that image. I might do this in Java, but why? ;) Few points to clarify: - The "PharoKernel with Gofer" image: where to download? - My script would probably load some Morphic packages (where the example script loads Seaside): does there exist a dependency graph of them? Or any idea which one to load first (e. g. Morphic-kernel or Morphic-basic), and others in which sequence? Thanks. PS uMorphic is also interesting: the message you referred to is of August: has there been any progress since? -- Dimitry Golubovsky Anywhere on the Web

Sept. 16, 2011

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality

by Nicolas Cellier

2011/9/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2011/9/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> I don't really know. I have implemented what Eliot say in the first option >> and it is working for me. >> Do you (Henry/Lukas/Nicolas/Eliot) agree to have this first solution and >> then improve it if necessary ? >> >> thanks >> > > I agree on Mariano/Eliot solution. It is a good pragmatic short term workaround. > In the long term, I wish I can say goodbye to my new super power, it's > a too dangerous power. > So I wish the VM would change (along with ClassBuilder and Tools). > > Nicolas > Or maybe after reading: literal1 := self literalAt: numLits. literal2 := method literalAt: numLits. ^ (literal1 == literal2) or: [literal1 key isNil == literal2 key isNil and: [literal1 value == literal2 value]]. I we are sure that the last literal is always an Association Nicolas >> On Fri, Sep 16, 2011 at 8:12 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> Mariano >>> >>> So should we intgerate a fix? >>> >>> Stef >>> >>> On Sep 15, 2011, at 11:27 PM, Mariano Martinez Peck wrote: >>> >>> > >>> > >>> > >>> > BUT, it doesn't mean that Association is always used for globals. >>> > CompiledMethod equality is failing because of the last literal, the one that >>> > maps class name (symbol) and point to the real class. So...when I >>> > materialize, both CMs have non-identical associations for the last literal, >>> > but equal. >>> > >>> > As Henrik says the last literals are ideally #== to each other. >>> > Â However, no Squeak dialect makes any attempt to keep the class0side >>> > associations equal. Look at a class-side method and you'll see it's last >>> > literal is nil->SomeClass class. Â Now since this association doesn't exist >>> > in Smalltalk (unlike last literals on the instance side) the compiler merely >>> > creates distinct ones for each class-side method. >>> > >>> > >>> > Thanks Eliot for that point. In fact, I have just checked and you are >>> > right. The tests that are failing for me is those where class side methods >>> > are involded. In this case, the last literal of the original CM and the >>> > materialized, gives false in #literalEqual: Â hence, Â originalCM = >>> > materializedCM is false :( >>> > >>> > >>> > >>> > Personally I don't think one can defend the position where method >>> > equality is different for instance-side or class-side methods so there must >>> > be some solutions: >>> > >>> > 1. special case comparison of the last literal (the methodClass >>> > literal), comparing keys and insisting that the keys be #== and the values >>> > be #== (can't just define it as keys #== since all similar class-side >>> > methods will be equal irrespective of their actual class). >>> > >>> > >>> > This one seems the easier and fixes my problem :) >>> > >>> > sameLiteralsAs: method >>> > Â Â "Compare my literals to those of method. This is needed to compare >>> > compiled methods." >>> > >>> > Â Â | numLits literal1 literal2 | >>> > Â Â (numLits := self numLiterals) ~= method numLiterals >>> > Â Â Â Â ifTrue: [ ^ false ]. >>> > Â Â "The last literal requires special checking instead of using >>> > #literalEqual:" >>> > Â Â 1 to: numLits - 1 do: [ :index | >>> > Â Â Â Â literal1 := self literalAt: index. >>> > Â Â Â Â literal2 := method literalAt: index. >>> > Â Â Â Â (literal1 == literal2 or: [ literal1 literalEqual: literal2 ]) >>> > Â Â Â Â Â Â ifFalse: [ >>> > Â Â Â Â Â Â Â Â (index = 1 and: [ #(117 120) includes: self primitive ]) >>> > Â Â Â Â Â Â Â Â Â Â ifTrue: [ >>> > Â Â Â Â Â Â Â Â Â Â Â Â literal1 isArray >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (literal2 isArray and: [ literal1 >>> > allButLast = literal2 allButLast ]) >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ self halt. ^ false ] ] >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "ExternalLibraryFunction" >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (literal1 analogousCodeTo: literal2) >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ self halt. ^ false ] ] ] >>> > Â Â Â Â Â Â Â Â Â Â ifFalse: [ >>> > Â Â Â Â Â Â Â Â Â Â Â Â index = (numLits - 1) >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "properties" >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (self properties analogousCodeTo: method >>> > properties) >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ self halt. ^ false ] ] >>> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ self halt. ^ false ] ] ] ]. >>> > Â Â literal1 := self literalAt: numLits. >>> > Â Â literal2 := method literalAt: numLits. >>> > Â Â ^ ((literal1 key == literal2 key) and: [literal1 value == literal2 >>> > value]). >>> > >>> > >>> > >>> > 2. special case comparison of the last literal (the methodClass >>> > literal), insisting only that the class of the literal be the same if it >>> > isVariableBinding. >>> > >>> > 3. make the compile unique class-side methodClass literals. Â i.e. if a >>> > class already has a class-side method then the compiler or method dictionary >>> > insertion code must find that existing association and reuse it >>> > >>> > Other ideas? >>> > >>> > >From my point of view, that literal, the last one does not need to be >>> > identical to assume 2 CMs are equal. They just need to be equal. >>> > >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> > >>> > >>> > >>> > -- >>> > best, >>> > Eliot >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >

Sept. 16, 2011

Re: [Pharo-project] Fuel or image segments (project files)

by Dimitry Golubovsky

Mariano, On Fri, Sep 16, 2011 at 2:57 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > [skip] >> >> I am not saving any code, only data. But if Fuel provided a way to >> overlay application-specific code over the generic image, this way of >> binary deployment would be very convenient. > > Yes, "Fuel" *would* provide a way to manage code. I won't be Fuel, but a > tool build on top of Fuel. Fuel is just a plain serializer. On top of that, > we have started to prototype a code exporter/loader. > So far, you can see what it is in the package FuelPackageLoader. We could > export Seaside and load it in a clean image. It took less than 15 seconds :) OK, great. > But...be aware we are not taking into account/doing a lot of stuff that > Monticello does, like: > - System notifications > - Validations > - Recompilations > -Conflicts with classes already present in the image where we load > -others Well I doubt that project loader in old Squeak did (m)any of these. Thanks. -- Dimitry Golubovsky Anywhere on the Web

Sept. 16, 2011

Re: [Pharo-project] Fuel or image segments (project files)

by Mariano Martinez Peck

On Thu, Sep 15, 2011 at 2:40 PM, Dimitry Golubovsky <golubovsky(a)gmail.com>wrote: > Hi, > > Martin Dias wrote: > > > About Fuel ... Hopefully we might be capable of doing that in some > months... > > at the moment you can find some limitations, especially if you were using > > DiskProxy (do you?). > > I am not sure if I use DiskProxy. Since I was constrained to use an > oldish 3.9 image, I had to find what worked through some experiments. > > What I use now (maybe that looks ugly these days, but works the way I > need): > > To save the current status of the application: > > > "---------------------------------------------------------------------------------------------------------------------" > Project current storeOnServerInnards. > > "---------------------------------------------------------------------------------------------------------------------" > > This bypasses the dialog that asks for saved project file name and > location, and just saves a new version of project file in the > directory of the image file, and in the Squeaklets directory > underneath. > > Versioning is important for me because if something goes wrong during > the saving of a project I can simply load a previous version manually. > > To load the last saved version of the project with given name: > > > "---------------------------------------------------------------------------------------------------------------------" > loadProject: aString > "load a project from a file whose name is like XXX.nnn.pr from the > default > directory where XXX are letters, and nnn are numbers. A project > with the > highest version will be loaded" > | files dir | > dir := FileDirectory default. > files := (dir fileNames select: [ :fn | | prts | > prts := fn findBetweenSubStrs: '.'. > ((prts size = 3) and: [(prts at: 1) = aString & (prts at: 3) > = 'pr'] ). > ]) asOrderedCollection sort: [ :e1 :e2 | | en1 en2 | > en1 := (e1 findBetweenSubStrs: '.') at: 2. > en2 := (e2 findBetweenSubStrs: '.') at: 2. > (en1 asInteger) > (en2 asInteger). > ]. > ^files ifNotEmpty: [ > ProjectLoading openFromDirectory: dir andFileName: (files > at: 1). > Smalltalk garbageCollect. > ] ifEmpty: [ nil ]. > > "---------------------------------------------------------------------------------------------------------------------" > > so that's ProjectLoading openFromDirectory:andFileName: > > So...all the above can be replaced by Fuel by using the methods provided by it: aFileStream := (StandardFileStream fileNamed: ('whatever') ) binary. serializer := FLSerializer on: aFileStream. serializer serialize: aMethod. aFileStream close. And to load: aFileStream := (StandardFileStream fileNamed: ('whatever')) binary. materializer := FLMaterializer on: aFileStream. materializer materialize. What it is important is to know whether you are using specific hooks of IS or not. If you do not use special hooks in Fuel, then all the transitive closure from the Porject instance will be serialized. > I am not saving any code, only data. But if Fuel provided a way to > overlay application-specific code over the generic image, this way of > binary deployment would be very convenient. > Yes, "Fuel" *would* provide a way to manage code. I won't be Fuel, but a tool build on top of Fuel. Fuel is just a plain serializer. On top of that, we have started to prototype a code exporter/loader. So far, you can see what it is in the package FuelPackageLoader. We could export Seaside and load it in a clean image. It took less than 15 seconds :) But...be aware we are not taking into account/doing a lot of stuff that Monticello does, like: - System notifications - Validations - Recompilations -Conflicts with classes already present in the image where we load -others We do not use the ClassBuilder but instead we create an instance of Class by hand and we set and initialize all the required stuff. Once we can have a clean and nice ClassBuilder we would like to add notifications, validations, etc. > Especially given the tablet's CPU is very slow, loading large mcz's > from Monticello repos and compiling them may take terrible time. > Exactly! > > Thanks. > > PS Saving methods did not work in the old Squeak image anyway... Even on a > PC. > > -- > Dimitry Golubovsky > > Anywhere on the Web > -- Mariano http://marianopeck.wordpress.com

Sept. 16, 2011

Re: [Pharo-project] anyone have a more up-to-date MethodWrappers for Squeak than MethodWrappers3.9-pmm.10?

by Eliot Miranda

On Fri, Sep 16, 2011 at 11:08 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Sep 16, 2011, at 12:18 AM, Eliot Miranda wrote: > > > Hi All, > > > > does this test look right to you? Isn't the line "self > assert:wrapper wasActive" just bogus? > > > > MwMethodWrapperTest>>testWasActive > > > > | wrapper | > > wrapper := self wrapperClass on: #methodOne inClass: MwClassA. > > self deny: wrapper wasActive. > > wrapper install. > > self deny: wrapper wasActive. > > wrapper uninstall. > > self assert: wrapper wasActive. > > ^^^^^^^^^^^^^^ > looks suspicious to me. > I played a lot with the internals of MW on VW and I do not see this test as > making sense. > > > > self > > should: [wrapper install] > > raise: Error. > > Similarly (may be this is the squeak/phaor implementation) but normally > installing/uninstalling should be revertable without this last test. > Thanks! That makes sense to me too (and the final "self should: [wrapper install] raise: Error" does not raise an error with the current code). > > > > > > On Tue, Sep 13, 2011 at 2:42 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi All, > > > > the most up-to-date MethodWrappers I can find is for Squeak 3.9, > pre-closures. Anyone have anything compatible with Squeak 4.1/4.2/Pharo > 1.1/1.2/1.3? > > > > -- > > best, > > Eliot > > > > > > > > > > -- > > best, > > Eliot > > > > > -- best, Eliot

Sept. 16, 2011

Re: [Pharo-project] Minimal buildable Pharo image with GUI?

by Pavel Krivanek

On Fri, Sep 16, 2011 at 8:24 PM, Dimitry Golubovsky <golubovsky(a)gmail.com> wrote: > Stephane Ducasse wrote: > >> I would love that too. Just no time to work on it :((((((((( >> Too many admin tasks. I will try to create more space for me. > > OK, maybe I should just try? > > But I need to understand where the starting point is. Say, I pick a > bare PharoKernel, and load it into a VM (headless) with a script like > this (I hope Gofer it is there, but if it's not, what else to use?): > > "-------------------------------------------------------------------------------------------------" > Gofer new > Â Â Â Â squeaksource: 'MetacelloRepository'; > Â Â Â Â package: 'ConfigurationOfXXX > Â Â Â Â load. > > ((Smalltalk at: #ConfigurationOfXXX) project version: 'X.Y') load. > > (Smalltalk saveAs: 'minimal.image') > Â Â Â Â ifFalse: [ Smalltalk snapshot: false andQuit: true ] > "-------------------------------------------------------------------------------------------------" > > This is a variation of LoadVMMaker.st which is used to load the VM > building stuff into Pharo Core. > > What XXX (packages) are needed to be loaded to get at least minimal GUI? > > Now, if in headless mode something fails, where will I see the error dump? Metacello is currently not supported by PharoKernel Gofer image. You must load packages manulay (something like http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker…) We have no list of packages you need. But you may try the same mechanism used in uMorphic to get code necessary for you applications. -- Pavel > Thanks. > > Anyway, in the light of Android usage, such specialized images will be > needed for one-tap installable applications. > > -- > Dimitry Golubovsky > > Anywhere on the Web > >

Sept. 16, 2011

Re: [Pharo-project] Minimal buildable Pharo image with GUI?

by Mariano Martinez Peck

Esteban did such images for the iPhone. He got small images as far as I remember.... On Fri, Sep 16, 2011 at 8:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Hi, > > see > http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg52168.ht… > > -- Pavel > > On Fri, Sep 16, 2011 at 4:45 PM, Dimitry Golubovsky > <golubovsky(a)gmail.com> wrote: > > Hi, > > > > I feel a need in as small as possible Pharo image (ideally > > script-buildable from e. g. PharoKernel) to use on Android as a > > setup/administration tool (I might just bundle it with CogDroid). I > > need basic Morphic (maybe even w/o PolyMorph) and network, perhaps > > that's it. > > > > Has anybody done anything similar? Any ideas? > > > > Thanks. > > > > -- > > Dimitry Golubovsky > > > > Anywhere on the Web > > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 16, 2011

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality

by Nicolas Cellier

2011/9/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > I don't really know. I have implemented what Eliot say in the first option > and it is working for me. > Do you (Henry/Lukas/Nicolas/Eliot) agree to have this first solution and > then improve it if necessary ? > > thanks > I agree on Mariano/Eliot solution. It is a good pragmatic short term workaround. In the long term, I wish I can say goodbye to my new super power, it's a too dangerous power. So I wish the VM would change (along with ClassBuilder and Tools). Nicolas > On Fri, Sep 16, 2011 at 8:12 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Mariano >> >> So should we intgerate a fix? >> >> Stef >> >> On Sep 15, 2011, at 11:27 PM, Mariano Martinez Peck wrote: >> >> > >> > >> > >> > BUT, it doesn't mean that Association is always used for globals. >> > CompiledMethod equality is failing because of the last literal, the one that >> > maps class name (symbol) and point to the real class. So...when I >> > materialize, both CMs have non-identical associations for the last literal, >> > but equal. >> > >> > As Henrik says the last literals are ideally #== to each other. >> > Â However, no Squeak dialect makes any attempt to keep the class0side >> > associations equal. Look at a class-side method and you'll see it's last >> > literal is nil->SomeClass class. Â Now since this association doesn't exist >> > in Smalltalk (unlike last literals on the instance side) the compiler merely >> > creates distinct ones for each class-side method. >> > >> > >> > Thanks Eliot for that point. In fact, I have just checked and you are >> > right. The tests that are failing for me is those where class side methods >> > are involded. In this case, the last literal of the original CM and the >> > materialized, gives false in #literalEqual: Â hence, Â originalCM = >> > materializedCM is false :( >> > >> > >> > >> > Personally I don't think one can defend the position where method >> > equality is different for instance-side or class-side methods so there must >> > be some solutions: >> > >> > 1. special case comparison of the last literal (the methodClass >> > literal), comparing keys and insisting that the keys be #== and the values >> > be #== (can't just define it as keys #== since all similar class-side >> > methods will be equal irrespective of their actual class). >> > >> > >> > This one seems the easier and fixes my problem :) >> > >> > sameLiteralsAs: method >> > Â Â "Compare my literals to those of method. This is needed to compare >> > compiled methods." >> > >> > Â Â | numLits literal1 literal2 | >> > Â Â (numLits := self numLiterals) ~= method numLiterals >> > Â Â Â Â ifTrue: [ ^ false ]. >> > Â Â "The last literal requires special checking instead of using >> > #literalEqual:" >> > Â Â 1 to: numLits - 1 do: [ :index | >> > Â Â Â Â literal1 := self literalAt: index. >> > Â Â Â Â literal2 := method literalAt: index. >> > Â Â Â Â (literal1 == literal2 or: [ literal1 literalEqual: literal2 ]) >> > Â Â Â Â Â Â ifFalse: [ >> > Â Â Â Â Â Â Â Â (index = 1 and: [ #(117 120) includes: self primitive ]) >> > Â Â Â Â Â Â Â Â Â Â ifTrue: [ >> > Â Â Â Â Â Â Â Â Â Â Â Â literal1 isArray >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (literal2 isArray and: [ literal1 >> > allButLast = literal2 allButLast ]) >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ self halt. ^ false ] ] >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "ExternalLibraryFunction" >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (literal1 analogousCodeTo: literal2) >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ self halt. ^ false ] ] ] >> > Â Â Â Â Â Â Â Â Â Â ifFalse: [ >> > Â Â Â Â Â Â Â Â Â Â Â Â index = (numLits - 1) >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "properties" >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (self properties analogousCodeTo: method >> > properties) >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ self halt. ^ false ] ] >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ self halt. ^ false ] ] ] ]. >> > Â Â literal1 := self literalAt: numLits. >> > Â Â literal2 := method literalAt: numLits. >> > Â Â ^ ((literal1 key == literal2 key) and: [literal1 value == literal2 >> > value]). >> > >> > >> > >> > 2. special case comparison of the last literal (the methodClass >> > literal), insisting only that the class of the literal be the same if it >> > isVariableBinding. >> > >> > 3. make the compile unique class-side methodClass literals. Â i.e. if a >> > class already has a class-side method then the compiler or method dictionary >> > insertion code must find that existing association and reuse it >> > >> > Other ideas? >> > >> > >From my point of view, that literal, the last one does not need to be >> > identical to assume 2 CMs are equal. They just need to be equal. >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> > >> > >> > -- >> > best, >> > Eliot >> > >> > >> > >> > >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Sept. 16, 2011

[Pharo-project] Minimal buildable Pharo image with GUI?

by Dimitry Golubovsky

Stephane Ducasse wrote: > I would love that too. Just no time to work on it :((((((((( > Too many admin tasks. I will try to create more space for me. OK, maybe I should just try? But I need to understand where the starting point is. Say, I pick a bare PharoKernel, and load it into a VM (headless) with a script like this (I hope Gofer it is there, but if it's not, what else to use?): "-------------------------------------------------------------------------------------------------" Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfXXX load. ((Smalltalk at: #ConfigurationOfXXX) project version: 'X.Y') load. (Smalltalk saveAs: 'minimal.image') ifFalse: [ Smalltalk snapshot: false andQuit: true ] "-------------------------------------------------------------------------------------------------" This is a variation of LoadVMMaker.st which is used to load the VM building stuff into Pharo Core. What XXX (packages) are needed to be loaded to get at least minimal GUI? Now, if in headless mode something fails, where will I see the error dump? Thanks. Anyway, in the light of Android usage, such specialized images will be needed for one-tap installable applications. -- Dimitry Golubovsky Anywhere on the Web

Sept. 16, 2011