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

StringMorph>>decimalPlaces:?

by StÃ©phane Ducasse

Hi guys I wonder if we could not remove decimalPlaces: and friends from UpdatingStringMorph because UpdatingStringMorph is already not really good. so cleaning. Stef

May 30, 2013

Re: [Pharo-dev] RPackage and overrides

by StÃ©phane Ducasse

> I don't see the point. Overrides are not an executable concept, they are a package management concept. At execution, only methods do exist. How two overrides (or even one method and one override) work are the duty of the package management system. yes :) > If the package management system forbid loading two overrides, it's fine by me. If, as an integrator, you reject any fix with an override, its fine by me. If you decide to let it pass, then its fine by me too ;) For me so far I'm pragmatic. I will push design that avoid override but I will be pragmatic because sometimes we need that. > > What I don't like is, we have a way to say we are hacking into the system in a not so nice way to hook somethin. It's bad, it looks bad, but it's documented and appears as such. Now, hiding it as an extension is making a lot worse: it's an override, we can do it, and its hidden unless you chase the package which changed when it shouldn't (and in some cases, like loading a package with an hidden override in an image with unsaved changes can make the search for it an interesting task...) > > An override is a hook when the underlying system you hook into wasn't planned to be used that way. Which I say is probably a sign of bad design :( Not necessarily but often it shows that we could anticipate more. > >> Maybe something on the sub-method level? Packages could register methods to be called before and after like in CLOSâ¦ > > This looks really complex. We have a lot of reflective features available to allow for nice hooks (flags and just plain subclass queries as in Monticello repositories), no need to think about how to make clever overrides (Unless you want to make a paper and get it into, say, Scala :)). > >> But as I said: my brain is full. I just can't think about it now. > > But I'm enjoying that :) Me too. I worked a lot on method extension (basically the PhD of alex) and we did not find a good solution. May selector namespace but this requires a lot of work.

May 30, 2013

Re: [Pharo-dev] RPackage and overrides

by StÃ©phane Ducasse

For marcus and igor. Now when we work on the core you have some methods with some behavior and since you want to have a small kernel you define some methods in a certain way. Now after you want to load code on top and suddenly you want to change the behavior to use the loaded package. And I do not see how you do it without override (yes you can define a block and get all the core behavior customisable via block and propose setters fro these blocks. Of course there is a risk that another package may override the same methods but the risk is low.

May 30, 2013

Re: [Pharo-dev] A primitive to create a temporary directory?

by Igor Stasenko

On 29 May 2013 15:04, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi, > > is there a primitive to create a temporary directory without any race > condition issue? > i don't think so > Best > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > -- Best regards, Igor Stasenko.

May 30, 2013

Re: [Pharo-dev] RPackage and overrides

by Igor Stasenko

On 29 May 2013 09:07, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 29, 2013, at 9:04 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Le 28/05/2013 22:23, stephane ducasse a Ã©crit : >>> >>> >>>> I have a question about RPackage and overrides. >>>> >>>> RPackage consider that an override method is an extension, right? >>> >>> for RPackage a package is a list of method definitions and class definition. >>> There is no specific tagging for overriding methods that would magically reappear when >>> their overriding method would be unloaded. >> >> Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping). >> >>> I do not know if this answer your question. >> >> Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same. >> >> What do you think? Is it important to classify overrides as such, or just let them be extensions ? > > The thing is that overrides don't work. As soon as 2 packages override the same method ==> which one is it? > > Therefore, overrides as a *concept* make no sense. And thus modeling them makes no sense. > Nobody ever should do overrides, because it will just not work as soon as it is used a lot. > +1 package should be able to only tell what it contains: - classes - extension methods To tell, if given extension method overrides existing method or not, package must have knowledge about the system it is going to be installed into. And since such knowledge is external to package, you should not manage it at package level - it is a global system level (package manager or alike). If you attempt to deal with that at package level, you'll introduce more problems than solve. > Marcus -- Best regards, Igor Stasenko.

May 30, 2013

Re: [Pharo-dev] Running coverage breaks the VM

by Guillermo Polito

Ok, I was playing with flushing caches and stuff... Its still a bit obsure to me why the example in the workspace works and the code coverage doesnot. However, I managed to hack the VM to make it work :). It looks like the VM is treating the objects as methods, as cog methods. So I added the following validation in the commonSend: methodHeader2 = longAt((GIV(newMethod) + BaseHeaderSize) + (HeaderIndex << ShiftForWord)); if (isCogMethodReference(methodHeader2) *&& isCompiledMethodHeader (methodHeader2)*) { /* begin externalizeIPandSP */ assert((((usqInt)localIP)) != (ceReturnToInterpreterPC())); GIV(instructionPointer) = oopForPointer(localIP); GIV(stackPointer) = localSP; GIV(framePointer) = localFP; executeCoggedNewMethodmethodHeader(1, methodHeader2); } And it works :). I cc Eliot, so maybe he has an idea... Guille On Thu, May 30, 2013 at 5:43 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Yes, this is a problem with Cog and Method wrappers it seems. Camille > found not so long ago that when installing a method wrapper with instance > variables, the VM just crashes. I think this should be the case. > > Anyway, I was just playing a bit because I want to use method wrappers for > some experiments. > So, the following looks like working when using wrappers with no inst vars. > > method := MyA>>#a. > [ > MyA methodDictionary at: #a put: MyWrapper new. > anA := MyA new. > res := anA a. > ] ensure: [ > MyA methodDictionary at: #a put: method. > method flushCache. > ]. > res > > Doing the same with a wrapper with inst vars just crashes the vm. However, > if flushing the method cache after installing the method in the method > dictionary, makes it work... > > method := MyA>>#a. > [ > MyA methodDictionary at: #a put: MyWrapperWithInstVar new. > method flushCache. > anA := MyA new. > res := anA a. > ] ensure: [ > MyA methodDictionary at: #a put: method. > method flushCache. > ]. > res > > So it looks like a problem in the JIT cache not cleared :). > > Now, I was looking at the TestCoverage class, to see how to make it work, > but not results yet :P. > > Guille > > > On Sun, May 26, 2013 at 6:48 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > >> Hi, >> >> I wanted to see FileSystem's coverage, so I >> * downloaded 3.0 via curl http://get.pharo.org/30+vm | bash, >> * fired up the image, >> * opened the TestRunner, >> * highlighted the three FileSystem packages, >> * "select all"ed, >> * pressed "Run Coverage" >> >> and the VM crashed with a segfault. I tried with a few other packages, >> and every time I tried to run coverage the VM died with the same >> message: >> >> Segmentation fault Sun May 26 15:46:45 2013 >> >> >> pharo VM version: 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3 >> Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 >> uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >> With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >> Revision: git://gitorious.org/cogvm/blessed.git Commit: >> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 >> +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 >> Build host: Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed >> Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux >> plugin path: /home/frank/Downloads/pharo-3.0/pharo-vm/ [default: >> /home/frank/Downloads/pharo-3.0/pharo-vm/] >> >> >> C stack backtrace: >> pharo-vm/pharo[0x80a0c0c] >> pharo-vm/pharo[0x80a0f28] >> [0x408410] >> [0x77744f1e] >> [0x777447c8] >> [0x7819010f] >> [0x777454f9] >> [0x777447c8] >> [0x7818e112] >> [0x777fc687] >> [0x777456ea] >> [0x77744668] >> >> >> Smalltalk stack dump: >> 0xbfc98e4c I [] in InteractiveResolverTest(TestCase)>runCase >> 0x78f0bfc8: a(n) InteractiveResolverTest >> 0xbfc98e6c M BlockClosure>ensure: 0x78fa4c34: a(n) BlockClosure >> 0xbfc98e90 I InteractiveResolverTest(TestCase)>runCase 0x78f0bfc8: >> a(n) InteractiveResolverTest >> 0xbfc98eb4 I [] in TestResult>runCase: 0x78f0bdcc: a(n) TestResult >> 0xbfc98ed0 M BlockClosure>on:do: 0x78fa4a30: a(n) BlockClosure >> 0xbfc98ef8 I TestResult>runCase: 0x78f0bdcc: a(n) TestResult >> 0xbfc98f1c I InteractiveResolverTest(TestCase)>run: 0x78f0bfc8: a(n) >> InteractiveResolverTest >> 0xbfc98f3c M [] in TestSuite>run: 0x78f0bfb0: a(n) TestSuite >> 0xbfc98f5c M OrderedCollection>do: 0x78f0bfdc: a(n) OrderedCollection >> 0xbfc9fdf0 I [] in TestSuite>run: 0x78f0bfb0: a(n) TestSuite >> 0xbfc9fe10 M BlockClosure>ensure: 0x78fa48e4: a(n) BlockClosure >> 0xbfc9fe34 I TestSuite>run: 0x78f0bfb0: a(n) TestSuite >> 0xbfc9fe58 I [] in TestRunner>runSuite: 0x78e405bc: a(n) TestRunner >> 0xbfc9fe80 I BlockClosure>cull:cull: 0x78f9c050: a(n) BlockClosure >> 0xbfc9feb0 I [] in TestRunner>executeSuite:as: 0x78e405bc: a(n) TestRunner >> 0xbfc9fed0 M BlockClosure>ensure: 0x78f9c420: a(n) BlockClosure >> 0xbfc9fef4 I TestRunner>executeSuite:as: 0x78e405bc: a(n) TestRunner >> 0xbfc9ff1c I TestRunner>runSuite: 0x78e405bc: a(n) TestRunner >> 0xbfc9ff3c M [] in TestRunner>collectCoverageFor: 0x78e405bc: a(n) >> TestRunner >> 0xbfc9ff5c M BlockClosure>ensure: 0x78f9bfcc: a(n) BlockClosure >> 0xbfc97e54 M [] in TestRunner>collectCoverageFor: 0x78e405bc: a(n) >> TestRunner >> 0xbfc97e74 M BlockClosure>ensure: 0x78f0dd7c: a(n) BlockClosure >> 0xbfc97ea8 I BlockClosure>valueUnpreemptively 0x78f0dd7c: a(n) >> BlockClosure >> 0xbfc97ed4 I TestRunner>collectCoverageFor: 0x78e405bc: a(n) TestRunner >> 0xbfc97ef8 M TestRunner>runCoverage 0x78e405bc: a(n) TestRunner >> 0xbfc97f18 I PluggableButtonMorph>performAction: 0x78e6c24c: a(n) >> PluggableButtonMorph >> 0xbfc97f38 M [] in PluggableButtonMorph>mouseUp: 0x78e6c24c: a(n) >> PluggableButtonMorph >> 0xbfc97f5c M Array(SequenceableCollection)>do: 0x78ed9f14: a(n) Array >> 0xbfc93e08 M PluggableButtonMorph>mouseUp: 0x78e6c24c: a(n) >> PluggableButtonMorph >> 0xbfc93e28 M PluggableButtonMorph(Morph)>handleMouseUp: 0x78e6c24c: >> a(n) PluggableButtonMorph >> 0xbfc93e44 M MouseButtonEvent>sentTo: 0x78ed9eec: a(n) MouseButtonEvent >> 0xbfc93e60 M PluggableButtonMorph(Morph)>handleEvent: 0x78e6c24c: a(n) >> PluggableButtonMorph >> 0xbfc93e7c M PluggableButtonMorph(Morph)>handleFocusEvent: 0x78e6c24c: >> a(n) PluggableButtonMorph >> 0xbfc93ea4 M [] in HandMorph>sendFocusEvent:to:clear: 0x77b1c270: a(n) >> HandMorph >> 0xbfc93ec0 M [] in PasteUpMorph>becomeActiveDuring: 0x7796b824: a(n) >> PasteUpMorph >> 0xbfc93edc M BlockClosure>on:do: 0x78ed9e5c: a(n) BlockClosure >> 0xbfc93f08 M PasteUpMorph>becomeActiveDuring: 0x7796b824: a(n) >> PasteUpMorph >> 0xbfc93f2c M HandMorph>sendFocusEvent:to:clear: 0x77b1c270: a(n) HandMorph >> 0xbfc93f54 M HandMorph>sendEvent:focus:clear: 0x77b1c270: a(n) HandMorph >> 0xbfc92e44 M HandMorph>sendMouseEvent: 0x77b1c270: a(n) HandMorph >> 0xbfc92e68 M HandMorph>handleEvent: 0x77b1c270: a(n) HandMorph >> 0xbfc92e94 M HandMorph>processEvents 0x77b1c270: a(n) HandMorph >> 0xbfc92eac M [] in WorldState>doOneCycleNowFor: 0x7797ab44: a(n) >> WorldState >> 0xbfc92ed0 M Array(SequenceableCollection)>do: 0x77846894: a(n) Array >> 0xbfc92eec M WorldState>handsDo: 0x7797ab44: a(n) WorldState >> 0xbfc92f08 M WorldState>doOneCycleNowFor: 0x7797ab44: a(n) WorldState >> 0xbfc92f24 M WorldState>doOneCycleFor: 0x7797ab44: a(n) WorldState >> 0xbfc92f40 M PasteUpMorph>doOneCycle 0x7796b824: a(n) PasteUpMorph >> 0xbfc92f60 I [] in MorphicUIManager>? 0x7797ebd4: a(n) MorphicUIManager >> 0x77c9891c s [] in BlockClosure>? >> >> Most recent primitives >> class >> class >> class >> class >> class >> class >> class >> >> >

May 30, 2013

Reflectivity beta

by Camille Teruel

Hello everyone, Reflectivity beta is out ! Reflectivity is a tool that permit to annotate AST nodes with "metalinks". You can put metalinks at different "positions": before: the metalink is executed before the node instead: the metalink is executed instead the node after: the metalink is executed after the node onError: the metalink is executed only if the execution of the node raises an error onSuccess: the metalink is executed only if the execution of the node raises no error When you put metalinks on some node of a method's AST, a wrapper is installed in place of the method. When executed, this wrapper compiles an expanded version of the AST that takes metalinks into account and install the resulting compiled method. Examples: increaseAllNumbersIn: aCompiledMethod "A method that increases all numbers in aCompiledMethod" aCompiledMethod reflectiveAST forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ] putInstead: [ :node | RFMetalink fromExpression: (node value + 1) asString ]. removeMetalinksIn: aCompiledMethod aCompiledMethod reflectiveAST removeAllMetalinks In nautilus, you have a menu entry called 'Edit metalinks' that permit to edit the metalinks of the node corresponding to the selected piece of code. As an example use case, another entry called 'Put breakpoint' adds a metalink that corresponds to 'Halt now' before the selected node. Remember that it is a beta, so you might find errors and things are likely to change. You can load Reflectivity with: Gofer it smalltalkhubUser: 'RMoD' project: 'Reflectivity'; configuration; loadDevelopment Or you can download it from RMoD's CI: https://ci.inria.fr/rmod/job/Reflectivity/ Camille

May 30, 2013

Re: [Pharo-dev] Running coverage breaks the VM

by Guillermo Polito

Yes, this is a problem with Cog and Method wrappers it seems. Camille found not so long ago that when installing a method wrapper with instance variables, the VM just crashes. I think this should be the case. Anyway, I was just playing a bit because I want to use method wrappers for some experiments. So, the following looks like working when using wrappers with no inst vars. method := MyA>>#a. [ MyA methodDictionary at: #a put: MyWrapper new. anA := MyA new. res := anA a. ] ensure: [ MyA methodDictionary at: #a put: method. method flushCache. ]. res Doing the same with a wrapper with inst vars just crashes the vm. However, if flushing the method cache after installing the method in the method dictionary, makes it work... method := MyA>>#a. [ MyA methodDictionary at: #a put: MyWrapperWithInstVar new. method flushCache. anA := MyA new. res := anA a. ] ensure: [ MyA methodDictionary at: #a put: method. method flushCache. ]. res So it looks like a problem in the JIT cache not cleared :). Now, I was looking at the TestCoverage class, to see how to make it work, but not results yet :P. Guille On Sun, May 26, 2013 at 6:48 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > Hi, > > I wanted to see FileSystem's coverage, so I > * downloaded 3.0 via curl http://get.pharo.org/30+vm | bash, > * fired up the image, > * opened the TestRunner, > * highlighted the three FileSystem packages, > * "select all"ed, > * pressed "Run Coverage" > > and the VM crashed with a segfault. I tried with a few other packages, > and every time I tried to run coverage the VM died with the same > message: > > Segmentation fault Sun May 26 15:46:45 2013 > > > pharo VM version: 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3 > Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 > uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > Revision: git://gitorious.org/cogvm/blessed.git Commit: > 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 > +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > Build host: Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed > Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux > plugin path: /home/frank/Downloads/pharo-3.0/pharo-vm/ [default: > /home/frank/Downloads/pharo-3.0/pharo-vm/] > > > C stack backtrace: > pharo-vm/pharo[0x80a0c0c] > pharo-vm/pharo[0x80a0f28] > [0x408410] > [0x77744f1e] > [0x777447c8] > [0x7819010f] > [0x777454f9] > [0x777447c8] > [0x7818e112] > [0x777fc687] > [0x777456ea] > [0x77744668] > > > Smalltalk stack dump: > 0xbfc98e4c I [] in InteractiveResolverTest(TestCase)>runCase > 0x78f0bfc8: a(n) InteractiveResolverTest > 0xbfc98e6c M BlockClosure>ensure: 0x78fa4c34: a(n) BlockClosure > 0xbfc98e90 I InteractiveResolverTest(TestCase)>runCase 0x78f0bfc8: > a(n) InteractiveResolverTest > 0xbfc98eb4 I [] in TestResult>runCase: 0x78f0bdcc: a(n) TestResult > 0xbfc98ed0 M BlockClosure>on:do: 0x78fa4a30: a(n) BlockClosure > 0xbfc98ef8 I TestResult>runCase: 0x78f0bdcc: a(n) TestResult > 0xbfc98f1c I InteractiveResolverTest(TestCase)>run: 0x78f0bfc8: a(n) > InteractiveResolverTest > 0xbfc98f3c M [] in TestSuite>run: 0x78f0bfb0: a(n) TestSuite > 0xbfc98f5c M OrderedCollection>do: 0x78f0bfdc: a(n) OrderedCollection > 0xbfc9fdf0 I [] in TestSuite>run: 0x78f0bfb0: a(n) TestSuite > 0xbfc9fe10 M BlockClosure>ensure: 0x78fa48e4: a(n) BlockClosure > 0xbfc9fe34 I TestSuite>run: 0x78f0bfb0: a(n) TestSuite > 0xbfc9fe58 I [] in TestRunner>runSuite: 0x78e405bc: a(n) TestRunner > 0xbfc9fe80 I BlockClosure>cull:cull: 0x78f9c050: a(n) BlockClosure > 0xbfc9feb0 I [] in TestRunner>executeSuite:as: 0x78e405bc: a(n) TestRunner > 0xbfc9fed0 M BlockClosure>ensure: 0x78f9c420: a(n) BlockClosure > 0xbfc9fef4 I TestRunner>executeSuite:as: 0x78e405bc: a(n) TestRunner > 0xbfc9ff1c I TestRunner>runSuite: 0x78e405bc: a(n) TestRunner > 0xbfc9ff3c M [] in TestRunner>collectCoverageFor: 0x78e405bc: a(n) > TestRunner > 0xbfc9ff5c M BlockClosure>ensure: 0x78f9bfcc: a(n) BlockClosure > 0xbfc97e54 M [] in TestRunner>collectCoverageFor: 0x78e405bc: a(n) > TestRunner > 0xbfc97e74 M BlockClosure>ensure: 0x78f0dd7c: a(n) BlockClosure > 0xbfc97ea8 I BlockClosure>valueUnpreemptively 0x78f0dd7c: a(n) BlockClosure > 0xbfc97ed4 I TestRunner>collectCoverageFor: 0x78e405bc: a(n) TestRunner > 0xbfc97ef8 M TestRunner>runCoverage 0x78e405bc: a(n) TestRunner > 0xbfc97f18 I PluggableButtonMorph>performAction: 0x78e6c24c: a(n) > PluggableButtonMorph > 0xbfc97f38 M [] in PluggableButtonMorph>mouseUp: 0x78e6c24c: a(n) > PluggableButtonMorph > 0xbfc97f5c M Array(SequenceableCollection)>do: 0x78ed9f14: a(n) Array > 0xbfc93e08 M PluggableButtonMorph>mouseUp: 0x78e6c24c: a(n) > PluggableButtonMorph > 0xbfc93e28 M PluggableButtonMorph(Morph)>handleMouseUp: 0x78e6c24c: > a(n) PluggableButtonMorph > 0xbfc93e44 M MouseButtonEvent>sentTo: 0x78ed9eec: a(n) MouseButtonEvent > 0xbfc93e60 M PluggableButtonMorph(Morph)>handleEvent: 0x78e6c24c: a(n) > PluggableButtonMorph > 0xbfc93e7c M PluggableButtonMorph(Morph)>handleFocusEvent: 0x78e6c24c: > a(n) PluggableButtonMorph > 0xbfc93ea4 M [] in HandMorph>sendFocusEvent:to:clear: 0x77b1c270: a(n) > HandMorph > 0xbfc93ec0 M [] in PasteUpMorph>becomeActiveDuring: 0x7796b824: a(n) > PasteUpMorph > 0xbfc93edc M BlockClosure>on:do: 0x78ed9e5c: a(n) BlockClosure > 0xbfc93f08 M PasteUpMorph>becomeActiveDuring: 0x7796b824: a(n) PasteUpMorph > 0xbfc93f2c M HandMorph>sendFocusEvent:to:clear: 0x77b1c270: a(n) HandMorph > 0xbfc93f54 M HandMorph>sendEvent:focus:clear: 0x77b1c270: a(n) HandMorph > 0xbfc92e44 M HandMorph>sendMouseEvent: 0x77b1c270: a(n) HandMorph > 0xbfc92e68 M HandMorph>handleEvent: 0x77b1c270: a(n) HandMorph > 0xbfc92e94 M HandMorph>processEvents 0x77b1c270: a(n) HandMorph > 0xbfc92eac M [] in WorldState>doOneCycleNowFor: 0x7797ab44: a(n) WorldState > 0xbfc92ed0 M Array(SequenceableCollection)>do: 0x77846894: a(n) Array > 0xbfc92eec M WorldState>handsDo: 0x7797ab44: a(n) WorldState > 0xbfc92f08 M WorldState>doOneCycleNowFor: 0x7797ab44: a(n) WorldState > 0xbfc92f24 M WorldState>doOneCycleFor: 0x7797ab44: a(n) WorldState > 0xbfc92f40 M PasteUpMorph>doOneCycle 0x7796b824: a(n) PasteUpMorph > 0xbfc92f60 I [] in MorphicUIManager>? 0x7797ebd4: a(n) MorphicUIManager > 0x77c9891c s [] in BlockClosure>? > > Most recent primitives > class > class > class > class > class > class > class > >

May 30, 2013

Re: [Pharo-dev] New mailing list on Gmane

by Jimmie Houchin

Thanks. On 05/30/2013 02:39 AM, Marcus Denker wrote: > Hello, > > In general it seems that at Gmane the lists are not owned by anyone but instead you need > to ask the admins. > > Yesterday I used the UI here: > > http://gmane.org/info.php?group=gmane.comp.lang.smalltalk.pharo.devel > > to send a request to update the list. > > I have not heard anything yet. > > For importing, there is a description here: > http://gmane.org/import.php > > We should check it when the list is working again. > > Marcus > > On May 30, 2013, at 8:38 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > >> Hello, >> >> I frequently read the Pharo list on Gmane. Since the mailing list move to a new server, none of the messages are being sent to Gmane. >> >> There have been no new messages since May 15. It would be nice if the service to Gmane could be resumed. And if possible to populate the missed messages. >> >> Just wanted to let the list know. >> >> Thanks. >> >> Jimmie >>

May 30, 2013

Re: [Pharo-dev] RPackage and overrides

by Goubier Thierry

Le 30/05/2013 14:27, Marcus Denker a Ã©crit : > > On May 30, 2013, at 2:22 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Le 30/05/2013 14:09, StÃ©phane Ducasse a Ã©crit : >>> >>> On May 30, 2 >>>> Yes. I can say true become: false, too. >>>> >>>> Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes >>>> the image package dirty. So later, when I know what I want, I will move that change to the image. >>>> >>>> You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. >>>> Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things. >>>> >>>> So this is more something we should add a rule for in Code Crititqueâ¦ >>> >>> I'm not sure. Because something you really need them. >> >> I'd be worried then. >> >> Either we have a need for extension where only an override will do... Then why not modeling it and critique it when appropriate? Hiding it under an extension won't make the problem disappear, it will just hide it. >> >> > > But it just does not work: two overrides. Which will be called? Overrides are like halt: you use is while developing and for hacks, but shipped packages just can not use it, because there is just no semantic > of multiple overrides. I don't see the point. Overrides are not an executable concept, they are a package management concept. At execution, only methods do exist. How two overrides (or even one method and one override) work are the duty of the package management system. If the package management system forbid loading two overrides, it's fine by me. If, as an integrator, you reject any fix with an override, its fine by me. If you decide to let it pass, then its fine by me too ;) What I don't like is, we have a way to say we are hacking into the system in a not so nice way to hook somethin. It's bad, it looks bad, but it's documented and appears as such. Now, hiding it as an extension is making a lot worse: it's an override, we can do it, and its hidden unless you chase the package which changed when it shouldn't (and in some cases, like loading a package with an hidden override in an image with unsaved changes can make the search for it an interesting task...) > The only solution is to have system where extensions are private to you, but than the normal use case for overrides is to "hook into something". An override is a hook when the underlying system you hook into wasn't planned to be used that way. Which I say is probably a sign of bad design :( > Maybe something on the sub-method level? Packages could register methods to be called before and after like in CLOSâ¦ This looks really complex. We have a lot of reflective features available to allow for nice hooks (flags and just plain subclass queries as in Monticello repositories), no need to think about how to make clever overrides (Unless you want to make a paper and get it into, say, Scala :)). > But as I said: my brain is full. I just can't think about it now. But I'm enjoying that :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 30, 2013