- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] e4dcdb: 30856

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: e4dcdb646718637bcb03d89564764067ba8f4800 https://github.com/pharo-project/pharo-core/commit/e4dcdb646718637bcb03d895… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-29 (Fri, 29 Aug 2014) Changed paths: M Gofer-Tests.package/GoferResource.class/instance/running/setUpMonticelloRepository.st A Metacello-TestsMCResources.package/MetacelloTestsMCPackage.class/instance/accessing/species.st M NativeBoost-Core.package/NBExternalStructureType.class/instance/emitting code/coerceReturnPointer_.st A NativeBoost-Tests.package/NBFFIExternalStructTests.class/instance/tests/testStructWithPointerAccess.st A NativeBoost-Tests.package/NBTestStructureWithPointer1.class/README.md A NativeBoost-Tests.package/NBTestStructureWithPointer1.class/class/as yet unclassified/fieldsDesc.st A NativeBoost-Tests.package/NBTestStructureWithPointer1.class/definition.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script118.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30856.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30856 13912 backport: 13911: Metacello test packages not properly unload https://pharo.fogbugz.com/f/cases/13912 13725 NativeBoost crashes when reading null pointer field in a structure https://pharo.fogbugz.com/f/cases/13725 http://files.pharo.org/image/30/30856.zip

Aug. 29, 2014

Re: [Pharo-dev] Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by Oscar Nierstrasz

Thanks for the clarifications! Oscar On 29 Aug 2014, at 14:01 , Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 29 aoÃ»t 2014, at 13:38, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > >> >> Following up: >> >> Behavior new compile: 't ^ trueâ >> >> fails since #compile: is defined in TBehavior and depends on #basicLocalSelectors which is defined only in Class, MetaClass and TraitBehavior. >> >> It seems like #basicLocalSelectors should be abstract in TBehavior. >> Alternatively the implementation should be moved to TBehavior and the field localSelectors should be pushed up to Behavior. Am I missing something? > > You're right, it should be possible to compile methods into an instance of behavior. > IIRW, it was possible in Pharo 2 but we didn't pay enough attention to ensure that it is always possible. So if we can make it work again we should add your test somewhere for that. > About moving localSelectors to Behavior: I'm not sure that Behavior should be aware of traits. I prefer to keep Behavior minimal (it is already too messy IMO). > Also for Pharo 4 there is other issues introduced by the integration of slots (slots are now needed by Opal for compilation): > - we should move slot API to Behavior > - make sure that iv and format ivs are consistent with each other > So there is some work to be done to make it work again... > >> Oscar >> >> On 29 Aug 2014, at 12:26 , Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: >> >>> >>> Hi folks, >>> >>> I was updating my lecture on Reflection for the Software Design and Evolution course, and I see now that anonymous classes can no longer be instances of Behavior but must be instances of Class. If you try to compile a method on an instance of Behavior, it fails. (basicLocalSelectors is not understood) >>> >>> Am I missing something? >>> >>> Cheers, >>> Oscar >>> >>> testPrimitiveChangeClassTo >>> | anonClass browser | >>> >>> anonClass := Class new. âmust be Class, not Behavior" >>> anonClass superclass: Browser. >>> anonClass setFormat: Browser format. >>> >>> browser := Browser new. >>> browser primitiveChangeClassTo: anonClass new. >>> anonClass compile: 'thisIsATest ^ 2'. >>> >>> self assert: browser thisIsATest = 2. >>> self should: [Browser new thisIsATest] >>> raise: MessageNotUnderstood. >>> >>> >> >> > >

Aug. 29, 2014

Re: [Pharo-dev] UndefinedObject(Object)>>doesNotUnderstand: #wait

by David T. Lewis

On Fri, Aug 29, 2014 at 11:42:24AM +0200, Yuriy Tymchuk wrote: > Sometimes when I save image I get this error: > > > UndefinedObject(Object)>>doesNotUnderstand: #wait > [ > event wait. > processSynchronizationDelay wait. "Avoids lost signals in heavy process switching" > self changed: #childProcessStatus ] in [ > [ > event wait. > processSynchronizationDelay wait. "Avoids lost signals in heavy process switching" > self changed: #childProcessStatus ] repeat ] in UnixOSProcessAccessor>>grimReaperProcess in Block: [ ... > BlockClosure>>repeat > [ > [ > event wait. > processSynchronizationDelay wait. "Avoids lost signals in heavy process switching" > self changed: #childProcessStatus ] repeat ] in UnixOSProcessAccessor>>grimReaperProcess in Block: [ ... > [ > self value. > Processor terminateActive ] in BlockClosure>>newProcess in Block: [ ... > > > Is it a known problem? Hi Uko, I have not seen this before, but I can say that the error is coming from OSProcess. OSProcess uses a background process that wakes up when a child OS process (that was started earlier by OSProcess) has exited. I do not know the reason for the failure that you are seeing, but I am guessing that it may be somehow related to image shutdown and startup processing when you save the image. Dave

Aug. 29, 2014

Re: [Pharo-dev] Spec wiring

by Yuriy Tymchuk

Yes, thatâs the first thing that I check Uko On 29 Aug 2014, at 12:23, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Have you checked this website: http://spec.st/docs/home/ ? > > > 2014-08-29 10:51 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi guys, > > I need a little help to understand how spec works. Iâve encountered a problem, that when all children nodes of a tree are checked, the parent node remains partially checked instead of going fully checked. Iâve tried to figure out how to work with that, but failed. Any suggestions? > > Uko >

Aug. 29, 2014

Re: [Pharo-dev] about to integrate GTools, there is a command conflict who needs attention

by Yuriy Tymchuk

On 29 Aug 2014, at 13:34, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-08-29 12:26 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > On 29 Aug 2014, at 12:23, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > On 29 Aug 2014, at 12:19, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > >> I have no idea what current (cmd+o+[w|t|etc]) stands for, so for me itâs ok to trash it. > > > > ehhhh, we are not talking about trash itâ¦ just remapping if needed :P > > and those are commands for opening transcript, workspace, etc. > > oh, then this is useful :) > > > > > Esteban > > > >> > >> I think that cmd+s can make sense. > >> > >> And as we are here, Iâd like to point out that I donât like this shortcut chains. Iâd prefer to have cmd+x to remove what is currently focused rather then > >> cmd+c+x, cmd+m+x and so on. > >> > >> Uko > >> > >> On 29 Aug 2014, at 11:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >>> Hi guys, > >>> > >>> We are on our way to integrate (finally) GTools into Pharo. > >>> For now it will be the Playground and the Inspector, since the Debugger is still not ready. > >>> > >>> Now, Iâm facing a problem. The new command for playground (cmd+o) conflicts with some menyu commands: (cmd+o+[w|t|etc]). Since we cannot handle both, we need to choose one. > >>> I do not have a clear idea, so I want your opinions. > >>> So far, I think this: > >>> > >>> 1) cmd+o in playground is not so clear, maybe we could map thet to an âacceptâ (cmd+s) or an âexecureâ (cmd+e)â¦ > >>> 2) we could map cmd+o+etc. to something else. But I do not know to what. > >>> > >>> So, I hear opinions :) > >>> > >>> Esteban > >> > >> > > > > > > > > > What's the difference between cmd+o and cmd+d for the Playground? I guess that in case you want to still be able silently do something, you need a separate cmd+d. Otherwise new cmd+p should be good enough. >

Aug. 29, 2014

Re: [Pharo-dev] Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by Camille Teruel

On 29 aoÃ»t 2014, at 13:38, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > > Following up: > > Behavior new compile: 't ^ trueâ > > fails since #compile: is defined in TBehavior and depends on #basicLocalSelectors which is defined only in Class, MetaClass and TraitBehavior. > > It seems like #basicLocalSelectors should be abstract in TBehavior. > Alternatively the implementation should be moved to TBehavior and the field localSelectors should be pushed up to Behavior. Am I missing something? You're right, it should be possible to compile methods into an instance of behavior. IIRW, it was possible in Pharo 2 but we didn't pay enough attention to ensure that it is always possible. So if we can make it work again we should add your test somewhere for that. About moving localSelectors to Behavior: I'm not sure that Behavior should be aware of traits. I prefer to keep Behavior minimal (it is already too messy IMO). Also for Pharo 4 there is other issues introduced by the integration of slots (slots are now needed by Opal for compilation): - we should move slot API to Behavior - make sure that iv and format ivs are consistent with each other So there is some work to be done to make it work again... > Oscar > > On 29 Aug 2014, at 12:26 , Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > >> >> Hi folks, >> >> I was updating my lecture on Reflection for the Software Design and Evolution course, and I see now that anonymous classes can no longer be instances of Behavior but must be instances of Class. If you try to compile a method on an instance of Behavior, it fails. (basicLocalSelectors is not understood) >> >> Am I missing something? >> >> Cheers, >> Oscar >> >> testPrimitiveChangeClassTo >> | anonClass browser | >> >> anonClass := Class new. âmust be Class, not Behavior" >> anonClass superclass: Browser. >> anonClass setFormat: Browser format. >> >> browser := Browser new. >> browser primitiveChangeClassTo: anonClass new. >> anonClass compile: 'thisIsATest ^ 2'. >> >> self assert: browser thisIsATest = 2. >> self should: [Browser new thisIsATest] >> raise: MessageNotUnderstood. >> >> > >

Aug. 29, 2014

Re: [Pharo-dev] Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by Sebastian Tleye

2014-08-29 13:38 GMT+02:00 Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com>: > > Following up: > > Behavior new compile: 't ^ trueâ > > fails since #compile: is defined in TBehavior and depends on > #basicLocalSelectors which is defined only in Class, MetaClass and > TraitBehavior. > > It seems like #basicLocalSelectors should be abstract in TBehavior. > Alternatively the implementation should be moved to TBehavior and the field > localSelectors should be pushed up to Behavior. Am I missing something? > Yep, I think you are right. Last year I did a lot of modifications in Behavior, TBehavior, Class, etc. These changes were made to make classes and traits polymorphic. If I remember correctly, the instance variable localSelectors was not moved to Behavior because it was not possible to push up that instance variable (there were a lot of errors since it is one of the core classes). If you look at the traits hierarchy, localSelectors is in TraitBehavior, not in Trait. So moving the instance variable localSelectors to Behavior and then abstract basicLocalSelectors in TBehavior would be very good > Oscar > > On 29 Aug 2014, at 12:26 , Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> > wrote: > > > > > Hi folks, > > > > I was updating my lecture on Reflection for the Software Design and > Evolution course, and I see now that anonymous classes can no longer be > instances of Behavior but must be instances of Class. If you try to > compile a method on an instance of Behavior, it fails. > (basicLocalSelectors is not understood) > > > > Am I missing something? > > > > Cheers, > > Oscar > > > > testPrimitiveChangeClassTo > > | anonClass browser | > > > > anonClass := Class new. âmust be Class, not Behavior" > > anonClass superclass: Browser. > > anonClass setFormat: Browser format. > > > > browser := Browser new. > > browser primitiveChangeClassTo: anonClass new. > > anonClass compile: 'thisIsATest ^ 2'. > > > > self assert: browser thisIsATest = 2. > > self should: [Browser new thisIsATest] > > raise: MessageNotUnderstood. > > > > > > >

Aug. 29, 2014

Re: [Pharo-dev] Future of Spec

by Alexandre Bergel

+1 > Le 29-08-2014 Ã 4:17, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > I like this spirit :) > > >> On Fri, Aug 29, 2014 at 9:46 AM, stepharo <stepharo(a)free.fr> wrote: >> the future is bright and shinning :) >> >> Stef > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 29, 2014

Re: [Pharo-dev] Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by Oscar Nierstrasz

Following up: Behavior new compile: 't ^ trueâ fails since #compile: is defined in TBehavior and depends on #basicLocalSelectors which is defined only in Class, MetaClass and TraitBehavior. It seems like #basicLocalSelectors should be abstract in TBehavior. Alternatively the implementation should be moved to TBehavior and the field localSelectors should be pushed up to Behavior. Am I missing something? Oscar On 29 Aug 2014, at 12:26 , Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > > Hi folks, > > I was updating my lecture on Reflection for the Software Design and Evolution course, and I see now that anonymous classes can no longer be instances of Behavior but must be instances of Class. If you try to compile a method on an instance of Behavior, it fails. (basicLocalSelectors is not understood) > > Am I missing something? > > Cheers, > Oscar > > testPrimitiveChangeClassTo > | anonClass browser | > > anonClass := Class new. âmust be Class, not Behavior" > anonClass superclass: Browser. > anonClass setFormat: Browser format. > > browser := Browser new. > browser primitiveChangeClassTo: anonClass new. > anonClass compile: 'thisIsATest ^ 2'. > > self assert: browser thisIsATest = 2. > self should: [Browser new thisIsATest] > raise: MessageNotUnderstood. > >

Aug. 29, 2014

Re: [Pharo-dev] Board clarification around Spec

by Alexandre Bergel

Thanks Esteban. This kind of message are really important. Thanks to let us know Cheers, Alexandre > Le 29-08-2014 Ã 4:38, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > > Hi, > > Due the recent known success, the board feels some clarification is needed. > So, here it is: > > Spec is integral part of Pharo, and we will keep it as part of our distribution. > Is our intention that community continues enhancing it, since like always, there is room for improvement. > > just that :) > > Esteban

Aug. 29, 2014