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

Re: [Pharo-project] New class factory for tests (and other use cases)

by Alexandre Bergel

Hi Adrian, I like the idea of your class factory. For years I have been using something very similar to create throwable classes. For example, in the package Spy (available on squeaksource) I have a class AbstractSpyTest and the following methods: AbstractSpyTest>>createClassNamed: AbstractSpyTest>>createClassNamed:superclass: then, within a test method, I can do: testMyExample | cls | cls := self createClassNamed: #C1. cls compile: 'giveMyFive ^ 5'. ... in the tearDown method I have: AbstractSpyTest>>tearDown super tearDown. classes ifNotNil: [:clss | clss do: #removeFromSystem ]. where 'classes' is an instance variable of AbstractSpyTest I used this piece of code for many years already, and I have always been happy so far. I also take care that the classes are created in a class category different from the one of my application. You propose: > class := ClassFactory newSubclass: Point with: [ :f | > f metaSide compile: 'somePoint ^ self x: 2 y: 3'. > f compile: '+ arg ^ self x + arg x ..... 3' ]. > > ]. I find this difficult to remember. Do you manage automatic class removing in the tearDown? Cheers, Alexandre On 28 Dec 2009, at 23:07, Adrian Kuhn wrote: > `ClassFactoryForTestCase` is a awesome tool when you need to create > throw-away > classes for tests. And the new akuhn/SUnit includes a DSL that makes > creating > anonymous classes even simpler! > > The new DSL is put in a new class to avoid compatibility issues. To > create an > anonymous class just do > > class := ClassFactory newClass. > > this creates a new subclass of Object. The creates classes is > automatically > reclaimed by garbage collection when no longer used. That is, tear > down of > class factory is not required anymore. > > The class is created without logging and not registered with the > system. That > is, `Object subclasses` does not include the created class. > > To create a subclass of a specific class do > > class := ClassFactory newSubclass: Point. > > To create a subclass with accessors do > > class := ClassFactory newSubclass: Point with: [ :f | > f compileAccessorsFor: 'color' ]. > > If you want getters or setters only, use `#compileSetterFor:` or > `#compilerGetterFor:`. If you want an instance variable without > accessor, use > `#declareInstVar:`. > > To create a subclass with methods do > > class := ClassFactory newSubclass: Point with: [ :f | > f compile: 'answer ^ 42' ]. > > NB: please note that class factory compiles silently without logging. > > To create a method on the class side do > > class := ClassFactory newSubclass: Point with: [ :f | > f forClass: [ :cf | > cf compile: 'somePoint ^ self x: 2 y: 3' ]]. > > In fact, the class side factory `cf` supports the same protocol as > the instance > side factory. Please note that creating instance variables on the > class side > creates "class instances variables" and not "instance class > variables". That > is, they are local to the creates class but not to subclasses of the > created > class. Typically this should not be a limitation since you only > create one > class without further subclasses. > > Also, please note that the created classes and all instances created > from that > class are ment to be thrown away after their use. The created class > is not > registered with the system, and thus when you change the instance > size of its > superclass the created instances will not be updated. > > Gofer it > disablePackageCache; > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load > > --AA > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 29, 2009

Re: [Pharo-project] My idea of Metacello configurations for Pharo

by Mariano Martinez Peck

On Tue, Dec 29, 2009 at 9:27 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Looks good! > You haven't mentioned unloading. This is an important topic in my > opinion. > > Yes, that's true. I am 100% agree. However, these were my little next steps for the Metacello configurations for Pharo. Regarding the unload, I really don't know who should provide that, Metacello ? Monticello ? Pharo it self? Does someone know about this? The main problem are the overrides because you should go back to anothe version, and I don't know if you have it or you loose it. Thanks Mariano > Alexandre > > On 29 Dec 2009, at 15:11, Mariano Martinez Peck wrote: > > > Hi folks. I just wanted to write down my ideas of the Metacello > > configurations for our Pharo Images. The idea is to use Metacello to > > manage the dependencies and version of the packages, have a history > > of the releases and be more modular. You will be able to take a core > > image and easily load what you want. We will have a > > ConfigurationOfPharo and that's what you will probably use. However, > > this conf depends and delegates to another configurations (the conf > > of each package). So, the first step is to make each little conf to > > work, and then, we focus in the pharo one. > > > > So....lists of points: > > > > 1) I have been writing several configurations so far. One > > configuration per external project that is loaded in Pharo Dev > > images. Examples: Shout, OCompletion, RefactoringBrowser, > > OmniBroswer, O2, etc.. > > The idea is to implement and be sure each of this conf is working > > before doing the ConfigurationOfPharo. > > > > 2) All configurations will be published here: > http://www.squeaksource.com/MetacelloRepository > > This repository is like the ibiblio for maven, or the Universe for > > the apt-get, or similar. In a near future we will have tools that > > work with this (Esteban Lorenzano is working in Loader for example). > > > > 3) Each configuration must be PERFECTLY loaded in a Pharo Core image > > without doing or installing nothing. To do this, I have to declare > > properly the dependencies. > > This mean, that you will be able to take a core image load the > > ConfigurationOfShout for exameple, or OCompletion and you will be > > able to load it. Metacello will take care of all the dependencies. > > You will also be able to install part of the project and not all > > (for example, only core or core + tests, or whatever). > > > > 4) I started with the Dev packages. We will do this test first to > > see if Metacello really help us in our project. If this goes well, > > then, in a second step, we will take care about the Web images. > > > > 5) I started with the 1.0 Dev packages. 1.1 is unestable and several > > external packages even don't load in it. So, will do 1.1 in a second > > step. > > > > 6) As there were no versions of Metacello in all the external > > projects, I started with 1.0 in ALL. Shout 1.0, OCompletion 1.0, RB > > 1.0, etc. This has nothing to do with Pharo 1.0. They are just the > > version number. And after this is released, we really need PLEASE, > > that the maintainers of those packages also creates the following > > versions for them. > > > > 7) I took as a base, the versions of the 10496 image. I have been > > using this image since in was release, 12 hours a day, and seems to > > be very stable to me. I mean, the version 1.0 of > > ConfigurationOfPharo will be like the 10496 image. When everything > > is done and working, create a new image will be very easy. > > > > 8) We need some features from Metacello which are in the todo list. > > So, we will have to wait a bit for them. > > > > OK, that's all. What do you think? > > > > Soon I will send an email for the configurations of all projects and > > will ask for help and feedback from their developers. > > > > Cheers, > > > > Mariano > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2009

Re: [Pharo-project] ImageSegment fixes in Inbox

by StÃ©phane Ducasse

cool mariano Since this code is complex did you ask sheridan to have a look? On Dec 29, 2009, at 9:19 PM, Mariano Martinez Peck wrote: > Hi! After several days of surfing the beatiful ImageSegment code, I fixed several issues. I commit to Inbox the SLICE-FixesToImageSegment. > > > This are the changes in my commit: > > - Removed Beeper beepPrimitive from ImageSegment >> install > - Fix to writeToFile. See issue 1204 > http://code.google.com/p/pharo/issues/detail?id=1204 > - Now ImageSegment >> discoverActiveClasses answer the number of them > - New method ImageSegment >> unActiveClasses > - Fix to ImageSegment >> swapOutInactiveClasses. I have to hold the allSymbols and to > exclude the Multilingual and Kernel package from the swap. This should fix issues > 1203 and 1204. > - The errors for wrong states now print the current state and also the expected one. > - Fix issue 207. > > > Take a clean image and evaluate: > > Smalltalk at: #MDFaultDict put: Dictionary new. > > Then > > | count | > count := ImageSegment discoverActiveClasses. > Transcript show: 'Classes forced: ', count asString. > > Do something > > And finally evaluate > > | count | > count := ImageSegment activeClasses size. > Transcript show: 'Classes active ', count asString. > > or > > | count | > count := ImageSegment unActiveClasses size. > Transcript show: 'Classes active ', count asString. > > Whit this, there is no trace. Even if puting the dictionary. > A simple hack to see this is to change activeClasses to use > recoverFromMDFaultWithTrace instead of recoverFromMDFault > If you do that, you will be able to inspect Smalltalk at: #MDFaultDict > > > I also fixed the swapOutInactiveClasses. The image have several emergency windows before this. > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 29, 2009

Re: [Pharo-project] My idea of Metacello configurations for Pharo

by Alexandre Bergel

Looks good! You haven't mentioned unloading. This is an important topic in my opinion. Alexandre On 29 Dec 2009, at 15:11, Mariano Martinez Peck wrote: > Hi folks. I just wanted to write down my ideas of the Metacello > configurations for our Pharo Images. The idea is to use Metacello to > manage the dependencies and version of the packages, have a history > of the releases and be more modular. You will be able to take a core > image and easily load what you want. We will have a > ConfigurationOfPharo and that's what you will probably use. However, > this conf depends and delegates to another configurations (the conf > of each package). So, the first step is to make each little conf to > work, and then, we focus in the pharo one. > > So....lists of points: > > 1) I have been writing several configurations so far. One > configuration per external project that is loaded in Pharo Dev > images. Examples: Shout, OCompletion, RefactoringBrowser, > OmniBroswer, O2, etc.. > The idea is to implement and be sure each of this conf is working > before doing the ConfigurationOfPharo. > > 2) All configurations will be published here: http://www.squeaksource.com/MetacelloRepository > This repository is like the ibiblio for maven, or the Universe for > the apt-get, or similar. In a near future we will have tools that > work with this (Esteban Lorenzano is working in Loader for example). > > 3) Each configuration must be PERFECTLY loaded in a Pharo Core image > without doing or installing nothing. To do this, I have to declare > properly the dependencies. > This mean, that you will be able to take a core image load the > ConfigurationOfShout for exameple, or OCompletion and you will be > able to load it. Metacello will take care of all the dependencies. > You will also be able to install part of the project and not all > (for example, only core or core + tests, or whatever). > > 4) I started with the Dev packages. We will do this test first to > see if Metacello really help us in our project. If this goes well, > then, in a second step, we will take care about the Web images. > > 5) I started with the 1.0 Dev packages. 1.1 is unestable and several > external packages even don't load in it. So, will do 1.1 in a second > step. > > 6) As there were no versions of Metacello in all the external > projects, I started with 1.0 in ALL. Shout 1.0, OCompletion 1.0, RB > 1.0, etc. This has nothing to do with Pharo 1.0. They are just the > version number. And after this is released, we really need PLEASE, > that the maintainers of those packages also creates the following > versions for them. > > 7) I took as a base, the versions of the 10496 image. I have been > using this image since in was release, 12 hours a day, and seems to > be very stable to me. I mean, the version 1.0 of > ConfigurationOfPharo will be like the 10496 image. When everything > is done and working, create a new image will be very easy. > > 8) We need some features from Metacello which are in the todo list. > So, we will have to wait a bit for them. > > OK, that's all. What do you think? > > Soon I will send an email for the configurations of all projects and > will ask for help and feedback from their developers. > > Cheers, > > Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 29, 2009

[Pharo-project] ImageSegment fixes in Inbox

by Mariano Martinez Peck

Hi! After several days of surfing the beatiful ImageSegment code, I fixed several issues. I commit to Inbox the SLICE-FixesToImageSegment. This are the changes in my commit: - Removed Beeper beepPrimitive from ImageSegment >> install - Fix to writeToFile. See issue 1204 http://code.google.com/p/pharo/issues/detail?id=1204 - Now ImageSegment >> discoverActiveClasses answer the number of them - New method ImageSegment >> unActiveClasses - Fix to ImageSegment >> swapOutInactiveClasses. I have to hold the allSymbols and to exclude the Multilingual and Kernel package from the swap. This should fix issues 1203 and 1204. - The errors for wrong states now print the current state and also the expected one. - Fix issue 207. Take a clean image and evaluate: Smalltalk at: #MDFaultDict put: Dictionary new. Then | count | count := ImageSegment discoverActiveClasses. Transcript show: 'Classes forced: ', count asString. Do something And finally evaluate | count | count := ImageSegment activeClasses size. Transcript show: 'Classes active ', count asString. or | count | count := ImageSegment unActiveClasses size. Transcript show: 'Classes active ', count asString. Whit this, there is no trace. Even if puting the dictionary. A simple hack to see this is to change activeClasses to use recoverFromMDFaultWithTrace instead of recoverFromMDFault If you do that, you will be able to inspect Smalltalk at: #MDFaultDict I also fixed the swapOutInactiveClasses. The image have several emergency windows before this.

Dec. 29, 2009

[Pharo-project] Fwd: [update 1.1] #11119

by StÃ©phane Ducasse

11119 ----- - Issue 1711: Cleaning host menu Mike can you confirm that everybody is ok. Tx Stef

Dec. 29, 2009

Re: [Pharo-project] Help with a crash

by Schwab,Wilhelm K

Lukas, You are correct, but there vm crashes that are not logged: I hit that courtesy of uninitialized structure sizes with ODBC. The VM died, and left no trace of it. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, December 29, 2009 12:14 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Help with a crash > lead to ugly side effects in loading specific packages.Â Details > aside, it seems _really_ bad to me for the vm to crash without leaving > behind any traces of what happened. This is not a VM that crashes. In fact everything is still fully functional and running. What Mariano is seeing is the emergency debugger, a very primitive debugger implemented in MorphicUIManager>>onPrimitiveError: used when everything else fails. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 29, 2009

Re: [Pharo-project] Help with a crash

by Lukas Renggli

I don't think that's a good idea. If you print so many stack frames, then the emergency evaluator is out of screen. Lukas 2009/12/29 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Tue, Dec 29, 2009 at 6:13 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> > lead to ugly side effects in loading specific packages.Â Details aside, >> > it >> > seems _really_ bad to me for the vm to crash without leaving behind any >> > traces of what happened. >> >> This is not a VM that crashes. In fact everything is still fully >> functional and running. What Mariano is seeing is the emergency >> debugger, a very primitive debugger implemented in >> MorphicUIManager>>onPrimitiveError: used when everything else fails. >> > > Thanks Lukas for the explanation. Every day I learn something new :) > > Now I was wondering if we can change the onPrimitiveError:Â to something > like this: > > > onPrimitiveError: aString > > > > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | context | > > > > > Â Â Â (String > Â Â Â Â Â Â streamContents: > Â Â Â Â Â Â Â Â Â [:s | > Â Â Â Â Â Â Â Â Â s nextPutAll: '***System error handling failed***'. > Â Â Â Â Â Â Â Â Â s cr; nextPutAll: aString. > Â Â Â Â Â Â Â Â Â context := thisContext sender sender. > Â Â Â Â Â Â Â Â Â 200 timesRepeat: [context == nil ifFalse: [s cr; print: (context > := context sender)]]. > Â Â Â Â Â Â Â Â Â s cr; nextPutAll: '-------------------------------'. > Â Â Â Â Â Â Â Â Â s cr; nextPutAll: 'Type CR to enter an emergency evaluator.'. > Â Â Â Â Â Â Â Â Â s cr; nextPutAll: 'Type any other character to restart.']) > Â Â Â Â Â Â displayAt: 10 @ 0. > Â Â Â [Sensor keyboardPressed] whileFalse. > Â Â Â Sensor keyboard = Character cr ifTrue: [Transcripter > emergencyEvaluator]. > > Â Â Â World install "init hands and redisplay" > > > > I just changed to 200 timesRepeat instead of 20 so that to have the full > stack, or at least, more than 20 lines and also the point of Â Â displayAt: > 10 @ 0.Â Â because in my case I couldn't see the first letters of the > windows. > > If you are ok, I can put a slice in the inbox and create the issue. > > Thanks > > Mariano > > >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 29, 2009

Re: [Pharo-project] Help with a crash

by Mariano Martinez Peck

On Tue, Dec 29, 2009 at 6:13 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > lead to ugly side effects in loading specific packages. Details aside, > it > > seems _really_ bad to me for the vm to crash without leaving behind any > > traces of what happened. > > This is not a VM that crashes. In fact everything is still fully > functional and running. What Mariano is seeing is the emergency > debugger, a very primitive debugger implemented in > MorphicUIManager>>onPrimitiveError: used when everything else fails. > > Thanks Lukas for the explanation. Every day I learn something new :) Now I was wondering if we can change the onPrimitiveError: to something like this: onPrimitiveError: aString | context | (String streamContents: [:s | s nextPutAll: '***System error handling failed***'. s cr; nextPutAll: aString. context := thisContext sender sender. 200 timesRepeat: [context == nil ifFalse: [s cr; print: (context := context sender)]]. s cr; nextPutAll: '-------------------------------'. s cr; nextPutAll: 'Type CR to enter an emergency evaluator.'. s cr; nextPutAll: 'Type any other character to restart.']) displayAt: 10 @ 0. [Sensor keyboardPressed] whileFalse. Sensor keyboard = Character cr ifTrue: [Transcripter emergencyEvaluator]. World install "init hands and redisplay" I just changed to 200 timesRepeat instead of 20 so that to have the full stack, or at least, more than 20 lines and also the point of displayAt: 10 @ 0. because in my case I couldn't see the first letters of the windows. If you are ok, I can put a slice in the inbox and create the issue. Thanks Mariano > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2009

Re: [Pharo-project] Help with a crash

by Lukas Renggli

> lead to ugly side effects in loading specific packages.Â Details aside, it > seems _really_ bad to me for the vm to crash without leaving behind any > traces of what happened. This is not a VM that crashes. In fact everything is still fully functional and running. What Mariano is seeing is the emergency debugger, a very primitive debugger implemented in MorphicUIManager>>onPrimitiveError: used when everything else fails. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 29, 2009