November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Old ClassBuilder remove!

by Stephan Eggermont

Nicolas wrote: >It has to be more simple than thatâ¦ Probably. I donât do this often enough. >Why not searching for allReferences to true and false, and gather the class of referents? How is that going to give me the values of the instVars? >This would also remove the limitation of first 10 instancesâ¦ Taking a look at all instances just takes a bit longer... Iâm open to suggestions. Stephan

Nov. 22, 2013

Re: [Pharo-dev] Slot class builder: Anonymous class modification

by Camille Teruel

On 22 nov. 2013, at 16:27, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 22 November 2013 16:25, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 22 November 2013 16:04, Camille Teruel <camille.teruel(a)gmail.com> wrote: > Hi everyone, > > With Esteban, we bumped into a problem with anonymous subclasses and the slot class builder. > The problem is that once an anonymous class is created is not possible to modify it. > Here is the problem: > For creating an anonymous class with the new class builder API you do something like: > > myAnonymousClass := AnonymousClassInstaller make: [ :classBuilder | > classBuilder > superclass: Object; > name: #MyAnonymousClass; > .... ] > > What happens is that the class builder asks the class installer if the class named #MyAnonymousClass exists or not to know if this a class to be created or to be modified. > Here, the strategy of the anonymous class installer is to always answer no. So ok, now you have you're anonymous class. > But what happens when you do something like: > > myAnonymousClass addInstVarNamed: #newIV > > Since the class has no clue of what class installer was used to create it, it instantiate a new one, and a PharoClassInstaller ! > This new class installer then says to the class builder that there is no class named MyAnonymousClass so it creates it! And it install it in the system dictionary! > And myAnonymousClass is not modified. > > So there is several problem here: > - a class doesn't know which class installer was used to create it > - even if the class would know that, the anonymous class installer would always say that it doesn't know it and a new class would be created > > So one possible solution for that is to have one class installer per environment (so add one iv in SystemDictionary right now), like that a class would know what class installer was used to create it. > What would happen then is that you don't create anonymous classes anymore, that is to say a class not installed in any environment, but instead you create a class that exist in an environment separated from the system dictionary. > > What do you think? > > > i think that this expression: > > myAnonymousClass addInstVarNamed: #newIV > > should create and answer new original class. > And don't take me wrong a 'new class' means just a new class object, which is not installed/registered anywhere, because it is done at next step (if its necessary). > > I'm not sure what this 'class installer' thingy comes from and it looks completely irrelevant. We must have clear separation between operations which creating new classes > and installing/registering them inside environment. The first is handled by the class builder, the second by the class installer > Because anonymous class is not one which has no name, it is one which is not registered in any public place. For the rest , it should behave in same way as public one. > > The fact that IDE tries to hide it and simulate as if you modified existing class is not really important here, because it is higher-level > contracts and responsibilities. +1 > > > imo, a better term to use for it would be 'private class' , because anonymous is a bit fuzzy. + 1 > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko.

Nov. 22, 2013

Re: [Pharo-dev] Slot class builder: Anonymous class modification

by Igor Stasenko

On 22 November 2013 16:25, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 22 November 2013 16:04, Camille Teruel <camille.teruel(a)gmail.com>wrote: > >> Hi everyone, >> >> With Esteban, we bumped into a problem with anonymous subclasses and the >> slot class builder. >> The problem is that once an anonymous class is created is not possible to >> modify it. >> Here is the problem: >> For creating an anonymous class with the new class builder API you do >> something like: >> >> myAnonymousClass := AnonymousClassInstaller make: [ :classBuilder | >> classBuilder >> superclass: Object; >> name: #MyAnonymousClass; >> .... ] >> >> What happens is that the class builder asks the class installer if the >> class named #MyAnonymousClass exists or not to know if this a class to be >> created or to be modified. >> Here, the strategy of the anonymous class installer is to always answer >> no. So ok, now you have you're anonymous class. >> But what happens when you do something like: >> >> myAnonymousClass addInstVarNamed: #newIV >> >> Since the class has no clue of what class installer was used to create >> it, it instantiate a new one, and a PharoClassInstaller ! >> This new class installer then says to the class builder that there is no >> class named MyAnonymousClass so it creates it! And it install it in the >> system dictionary! >> And myAnonymousClass is not modified. >> >> So there is several problem here: >> - a class doesn't know which class installer was used to create it >> - even if the class would know that, the anonymous class installer would >> always say that it doesn't know it and a new class would be created >> >> So one possible solution for that is to have one class installer per >> environment (so add one iv in SystemDictionary right now), like that a >> class would know what class installer was used to create it. >> What would happen then is that you don't create anonymous classes >> anymore, that is to say a class not installed in any environment, but >> instead you create a class that exist in an environment separated from the >> system dictionary. >> >> What do you think? >> >> >> i think that this expression: > > myAnonymousClass addInstVarNamed: #newIV > > should create and answer new original class. > And don't take me wrong a 'new class' means just a new class object, which > is not installed/registered anywhere, because it is done at next step (if > its necessary). > > I'm not sure what this 'class installer' thingy comes from and it looks > completely irrelevant. We must have clear separation between operations > which creating new classes > and installing/registering them inside environment. > Because anonymous class is not one which has no name, it is one which is > not registered in any public place. For the rest , it should behave in same > way as public one. > > The fact that IDE tries to hide it and simulate as if you modified > existing class is not really important here, because it is higher-level > contracts and responsibilities. > > imo, a better term to use for it would be 'private class' , because anonymous is a bit fuzzy. > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Nov. 22, 2013

Re: [Pharo-dev] Slot class builder: Anonymous class modification

by Igor Stasenko

On 22 November 2013 16:04, Camille Teruel <camille.teruel(a)gmail.com> wrote: > Hi everyone, > > With Esteban, we bumped into a problem with anonymous subclasses and the > slot class builder. > The problem is that once an anonymous class is created is not possible to > modify it. > Here is the problem: > For creating an anonymous class with the new class builder API you do > something like: > > myAnonymousClass := AnonymousClassInstaller make: [ :classBuilder | > classBuilder > superclass: Object; > name: #MyAnonymousClass; > .... ] > > What happens is that the class builder asks the class installer if the > class named #MyAnonymousClass exists or not to know if this a class to be > created or to be modified. > Here, the strategy of the anonymous class installer is to always answer > no. So ok, now you have you're anonymous class. > But what happens when you do something like: > > myAnonymousClass addInstVarNamed: #newIV > > Since the class has no clue of what class installer was used to create it, > it instantiate a new one, and a PharoClassInstaller ! > This new class installer then says to the class builder that there is no > class named MyAnonymousClass so it creates it! And it install it in the > system dictionary! > And myAnonymousClass is not modified. > > So there is several problem here: > - a class doesn't know which class installer was used to create it > - even if the class would know that, the anonymous class installer would > always say that it doesn't know it and a new class would be created > > So one possible solution for that is to have one class installer per > environment (so add one iv in SystemDictionary right now), like that a > class would know what class installer was used to create it. > What would happen then is that you don't create anonymous classes anymore, > that is to say a class not installed in any environment, but instead you > create a class that exist in an environment separated from the system > dictionary. > > What do you think? > > > i think that this expression: myAnonymousClass addInstVarNamed: #newIV should create and answer new original class. And don't take me wrong a 'new class' means just a new class object, which is not installed/registered anywhere, because it is done at next step (if its necessary). I'm not sure what this 'class installer' thingy comes from and it looks completely irrelevant. We must have clear separation between operations which creating new classes and installing/registering them inside environment. Because anonymous class is not one which has no name, it is one which is not registered in any public place. For the rest , it should behave in same way as public one. The fact that IDE tries to hide it and simulate as if you modified existing class is not really important here, because it is higher-level contracts and responsibilities. -- Best regards, Igor Stasenko.

Nov. 22, 2013

Slot class builder: Anonymous class modification

by Camille Teruel

Hi everyone, With Esteban, we bumped into a problem with anonymous subclasses and the slot class builder. The problem is that once an anonymous class is created is not possible to modify it. Here is the problem: For creating an anonymous class with the new class builder API you do something like: myAnonymousClass := AnonymousClassInstaller make: [ :classBuilder | classBuilder superclass: Object; name: #MyAnonymousClass; .... ] What happens is that the class builder asks the class installer if the class named #MyAnonymousClass exists or not to know if this a class to be created or to be modified. Here, the strategy of the anonymous class installer is to always answer no. So ok, now you have you're anonymous class. But what happens when you do something like: myAnonymousClass addInstVarNamed: #newIV Since the class has no clue of what class installer was used to create it, it instantiate a new one, and a PharoClassInstaller ! This new class installer then says to the class builder that there is no class named MyAnonymousClass so it creates it! And it install it in the system dictionary! And myAnonymousClass is not modified. So there is several problem here: - a class doesn't know which class installer was used to create it - even if the class would know that, the anonymous class installer would always say that it doesn't know it and a new class would be created So one possible solution for that is to have one class installer per environment (so add one iv in SystemDictionary right now), like that a class would know what class installer was used to create it. What would happen then is that you don't create anonymous classes anymore, that is to say a class not installed in any environment, but instead you create a class that exist in an environment separated from the system dictionary. What do you think?

Nov. 22, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Nicolas Cellier

It has to be more simple than that... Why not searching for allReferences to true and false, and gather the class of referents? This would also remove the limitation of first 10 instances... 2013/11/22 Stephan Eggermont <stephan(a)stack.nl> > Camillo wrote: > >I love these scripts :P.. > >maybe you should make gists [1] out of them :) > > Good idea > > https://gist.github.com/StephanEggermont/7598946 > >

Nov. 22, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30590 Home: https://github.com/pharo-project/pharo-core

Nov. 22, 2013

[pharo-project/pharo-core] 6f77b8: 30590

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f77b8b243e746857d1157baf1408f5d01e8d361 https://github.com/pharo-project/pharo-core/commit/6f77b8b243e746857d1157ba… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-22 (Fri, 22 Nov 2013) Changed paths: M Morphic-Base.package/MorphTreeListManager.class/README.md M Morphic-Base.package/MorphTreeListManager.class/definition.st M Morphic-Base.package/MorphTreeListManager.class/instance/accessing/lastClickedMorph_.st A Morphic-Base.package/MorphTreeListManager.class/instance/accessing/removeOnlyLastSelected.st A Morphic-Base.package/MorphTreeListManager.class/instance/accessing/removeOnlyLastSelected_.st M Morphic-Base.package/MorphTreeListManager.class/instance/initialization/initialize.st M Morphic-Base.package/MorphTreeListManager.class/instance/keyboard managing/setSelectionIndexFromKeyboard_multiSelection_event_.st M Morphic-Base.package/MorphTreeListManager.class/instance/mouse managing/mouseDown_on_.st M Morphic-Base.package/MorphTreeListManager.class/instance/mouse managing/mouseUp_on_.st M Morphic-Base.package/MorphTreeListManager.class/instance/selection change/selectMorph_multiple_.st M Morphic-Base.package/MorphTreeListManager.class/instance/selection change/setSelectedMorph_.st M Morphic-Base.package/MorphTreeListManager.class/instance/selection change/shiftSelectMorph_.st A Morphic-Base.package/MorphTreeMorph.class/instance/selection/removeOnlyLastSelected_.st A Morphic-Base.package/MorphTreeNodeModel.class/instance/protocol/lastClicked_.st A Morphic-Base.package/MorphTreeNodeModel.class/instance/protocol/selected_.st M Morphic-Base.package/MorphTreeNodeMorph.class/instance/accessing/selected_.st M Polymorph-Tools-Diff.package/DiffMorph.class/instance/updating/update_with_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script245.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30590.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30590 12221 Fix a warning raised by the monkey in DiffMorph https://pharo.fogbugz.com/f/cases/12221 12214 Propagate the notion of last node clicked to the node model https://pharo.fogbugz.com/f/cases/12214 http://files.pharo.org/image/30/30590.zip

Nov. 22, 2013

Re: [Pharo-dev] [OT] World Hello Day - November 21, 2013

by Norbert Hartl

Am 22.11.2013 um 13:07 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > But we are getting off topic a bit: I think it is not about clever, geeky ways of saying hello, but about saying hello to actual people. Sure, but there is also no reason to say hello only one day a year. Make it an every day habit. So doing it _not_ on one day a year what be quite a good idea. Norbert

Nov. 22, 2013

Re: [Pharo-dev] [OT] World Hello Day - November 21, 2013

by Alexandre Bergel

=-=-=-==-=-=-==-=-=-==-=-=-= | view el | view := ROView new. el := ROElement on: 'hello world'. el + ROLabel. view add: el. el translateTo: 100 @ -20. view open. ROLinearMove new for: el to: 100 @ 100; after: [ ROBlink new on: el ] =-=-=-==-=-=-==-=-=-==-=-=-= Alexandre On Nov 22, 2013, at 9:07 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > A day too late: > > ZnClient new > http; > host: 'zn.stfx.eu'; > path: 'echo'; > contents: 'Hello World !'; > post. > > But we are getting off topic a bit: I think it is not about clever, geeky ways of saying hello, but about saying hello to actual people. > > On 21 Nov 2013, at 13:17, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> VTermOutputDriver stdout red: 'Hello '; blue: 'World'. >> >> :P >> >> On 2013-11-21, at 12:47, phil(a)highoctane.be wrote: >> >>> FileStream stdout nextPutAll: 'Hello World' >>> >>> Works with an eval from the CLI >>> >>> On Thursday, November 21, 2013, Torsten Bergmann wrote: >>> see: http://en.wikipedia.org/wiki/World_Hello_Day >>> >>> so: >>> >>> Transcript show: 'HelloWorld' >>> >>> >>> >>> -- >>> --- >>> Philippe Back >>> Dramatic Performance Improvements >>> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 >>> Mail:phil@highoctane.be | Web: http://philippeback.eu >>> Blog: http://philippeback.be | Twitter: @philippeback >>> Youtube: http://www.youtube.com/user/philippeback/videos >>> >>> High Octane SPRL >>> rue cour Boisacq 101 | 1301 Bierges | Belgium >>> >>> Pharo Consortium Member - http://consortium.pharo.org/ >>> Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com >>> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller >>> >>> >>> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 22, 2013