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

Re: [Pharo-dev] Possible PharoVM bug (wrong object on stack top)

by phil＠highoctane.be

I do have that issue often when loading my devstack configuration on Pharo 2.0 (as in http://www.smalltalkhub.com/#!/~philippeback/HOWebStack) Doing everything again fixes the problem but fingers crossed are required. It is a really annoying bug indeed. Phil --- 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 Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Thu, Jun 27, 2013 at 3:22 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 June 2013 14:13, Max Leske <maxleske(a)gmail.com> wrote: > > Hi > > > > I've been seeing a particular bug that I can only see when using the > PharoVM and I was wondering if anybody else has been having the same issue. > > > > Under certain condition, a debugger will open displaying "SmallInteger > does not understand <some message>". The stack top contains an integer > (something of the form 138402, not sure how many digits), which explains > the message. However, the situation actually looks like this: > > > > htmil anchor > > id: 'foo'; > > â¦ > > > > In this example, the error would be "SmallInteger does not understand > #id:". So the stack top contains an integer instead of the receiver. > > Restarting the execution of the method and proceeding fixes the problem. > I think I've seen that (using seaside), a new session will trigger the bug > again. > > > > Apart from Seaside, I've also seen the same problem when loading Roberto > Minelli's DevFlow into a Pharo 2.0 image. The debugger will open on a > Metacello method. > > > > VM: latest PharoVM > > image: latest 2.0 > > try this config: http://smalltalkhub.com/#!/~RobertoMinelli/DevFlowwith "ConfigurationOfDevFlow loadDevelopment" > > > > > > Has anybody else encountered this? > > > yes, couple months ago we had this issue. > It looks like it doesn't likes some bytecode sequence (which causing > this).. > and this sequence is not appears that often. > > If i remember Esteban said that changing compiler optimizations flags > fixed it.. > but perhaps not on platform , you running on? > > > Cheers, > > Max > > > > -- > Best regards, > Igor Stasenko. > >

June 27, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Igor Stasenko

On 27 June 2013 18:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jun 2 >> >> Yes, you right. >> (NBFFICallout new resolveType: 'byte*') valueSize => 1 >> (NBFFICallout new resolveType: 'byte*') storageSize => 4 >> >> apparently, if one wants array with 'byte*' element type (or any other) >> it should use a pointer size (4), not byte size (1) for it. >> >>> Or is a disclaimer not to use the class for, say, 'char*' elements more >>> appropriate? >>> >> no , it should be fine. >> The difference between valueSize and storageSize is a bit confusing, >> and easy to confuse which to use.. >> Perhaps they need different naming. > +1 consider that people will use that during 10 years so good comments + names is KEY > yes, i always in such mode. But sometimes a right term/word/concept comes after number of interations (until you, as developer finally really understand what you just did or what you actually wanted to do ;) >> There also stackSize, which means "how many bytes a value of given type >> will take, if pushed on stack , and aligned accordingly" >> >> ... after some more investigation, i found that actually >> storageSize should not be used. There is typeSize instead. >> >> So, the final expression should be: >> >> elementType := aTypeName. >> elementSize := (NBFFICallout new requestor: self; resolveType: >> elementType) typeSize. >> >> >> and #sizeOf: method should also use typeSize apparently. >> >> >>> Cheers, >>> Henry >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

June 27, 2013

Sprint tomorrow

by phil＠highoctane.be

Hello, Is the sprint occuring in Lille tomorrow? I'd be glad to join but want to be sure it happens. Regards, Phil

June 27, 2013

Re: [Pharo-dev] Metacello doubt

by Igor Stasenko

On 27 June 2013 15:43, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > ----- Original Message ----- > | From: "Igor Stasenko" <siguctua(a)gmail.com> > | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > | Sent: Thursday, June 27, 2013 4:26:14 AM > | Subject: Re: [Pharo-dev] Metacello doubt > | > | Just adding some comments: > | - i avoid using loading bleeding edge > | because it has problems which only humans can solve: > | - if there are two different branches, not yet merged it may load > | not one that you want > | - even if dependencies is ok, it doesn't means that if you load two > | latest versions of two packages, > | they will work > | > | so, what i do, is loading a known working config, and then go to > | monticello and manually picking and loading updated packages. > | > > But once the human has solved the problem, the solution should be encoded in a script that can be used by others to solve the same problem ... > > It's the manual bits that I'm trying to address with the Scripting API ... if you know you want to deviate from the standard load directives, you should be able to construct a load expression that allows you to specify your deviations so you can do your next build without requiring manual intervention... > Well, the "bleeding edge" called this way exactly for reasons that it is unsafe/unpredictable and hardly formalizeable. I don't see what can be done there: trying to predict a developer's next move is not something you can do with software :) As i said, if there at least two persons working on project , each in his own branch, a term "bleeding edge" will mean something different for each of them. Only when one person takes an effort to merge and update config, you'll have new development version, but before that, if they will commit often without merging, the bleeding edge will jump between one branch and another, and i do not see how that can be useful to anyone. > Dale -- Best regards, Igor Stasenko.

June 27, 2013

Re: [Pharo-dev] Metacello doubt

by Dale K. Henrichs

Allright ... I'll add a test case covering #bleedingEdge loads (perhaps not today...) and let you know if it's already functional or not ... if not I'll plan on getting it supported ... Dale ----- Original Message ----- | From: "Guido Chari" <charig(a)gmail.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Thursday, June 27, 2013 10:23:33 AM | Subject: Re: [Pharo-dev] Metacello doubt | I'm in. | 2013/6/26 Dale K. Henrichs < dale.henrichs(a)gemtalksystems.com > | | | From: "Guido Chari" < charig(a)gmail.com > | | | | | | To: "Pharo Development List" < pharo-dev(a)lists.pharo.org > | | | | | | Sent: Wednesday, June 26, 2013 2:49:09 PM | | | | | | Subject: Re: [Pharo-dev] Metacello doubt | | | | | | I understood. Thanks for the answer Dale. The drawback in this | | | case | | | is to specify a particular dependency to AsmJit in my | | | configuration. | | | Also, perhaps is the right way since i realized i have a | | | particular | | | dependency on it. | | | | | | But this discussion makes me thing a little and so i have a new | | | question. | | | | | | Form what I (mis) undestand from Metacello, when asking for a | | | bleedingEdge version it loads only the baseline that specifies | | | packages and then last version of every package specified there. | | | | | | As in the projects referenced on the baseline there is no need | | | for | | | specifying a version, and that's the case of nativeBoost | | | configuration, wouldn't it be interesting to have some behavior | | | (i | | | mean i new method for loading like loadDeepSymbolic:) that not | | | only | | | load the symbolicVersion of the package asked, but also propagate | | | that symbolicVersion (bleedingEdge in this case) to all the | | | dependencies that don't specify a concrete version? | | | | | | Guido. | | | | | Guido, | | | With the Metacello Scripting API[1] I've taken a slightly different | | tack, but I think that it gets you to the same place. | | | I am a big fan of deterministic loads, but I know that from a | | practical point of view developers need to have a certain amount of | | control over exactly what gets loaded into their DEVELOPMENT | | environments and they need to be able to exert this control without | | having to resort to editing configurations to match their specific | | requirements. | | | I have accomplished this by arranging for a Notification to be | | signalled whenever a project is referenced during a load. The | | developer can use one or more of the onUpgrade:, onDowngrade: and | | onConflict: clauses in their load scripts to exert fine control | | over | | what happens on a project by project basis ... | | | For your specific use case, I would think that you would want to | | use | | the `lock` command[2] and specify that you want to `lock` the | | projects (NativeBoost and AsmJit) to the #bleedingEdge version. I | | don't recall if I've got test cases for symbolic versions, but if | | you are seriously interested in taking the Scripting API for a | | spin, | | I'd be willing to write some additional tests using the | | #bleedingEdge symbolic version (if not already covered) and | | validate | | this use case... | | | I am entering a phase where I will be doing some work on getting | | FileTree and Metacello up to snuff for Pharo3.0 so this would be a | | good time for me to add some test cases in anticipation of having | | some interested users ... | | | I haven't released the Scripting API, because I need to have real | | users with real use cases take the API for a spin and validate the | | API. The Scripting API can be loaded into any version of | | Pharo/Squeak/GemStone and I think the Scripting API is (or will be) | | available in Pharo3.0. | | | I'm looking forward to getting feedback as to how the API stands up | | to real use ... | | | So let me know if you are interested in being another Scripting API | | guinea pig:) | | | Dale | | | [1] | | https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… | | | [2] | | https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… |

June 27, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. Tests.Release.ReleaseTest.testObsoleteClasses

June 27, 2013

Re: [Pharo-dev] Metacello doubt

by Guido Chari

I'm in. 2013/6/26 Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> > > > ------------------------------ > > *From: *"Guido Chari" <charig(a)gmail.com> > *To: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> > *Sent: *Wednesday, June 26, 2013 2:49:09 PM > > *Subject: *Re: [Pharo-dev] Metacello doubt > > I understood. Thanks for the answer Dale. The drawback in this case is to > specify a particular dependency to AsmJit in my configuration. Also, > perhaps is the right way since i realized i have a particular dependency on > it. > > But this discussion makes me thing a little and so i have a new question. > > Form what I (mis) undestand from Metacello, when asking for a bleedingEdge > version it loads only the baseline that specifies packages and then last > version of every package specified there. > > As in the projects referenced on the baseline there is no need for > specifying a version, and that's the case of nativeBoost configuration, > wouldn't it be interesting to have some behavior (i mean i new method for > loading like loadDeepSymbolic:) that not only load the symbolicVersion of > the package asked, but also propagate that symbolicVersion (bleedingEdge in > this case) to all the dependencies that don't specify a concrete version? > > Guido. > > Guido, > > With the Metacello Scripting API[1] I've taken a slightly different tack, > but I think that it gets you to the same place. > > I am a big fan of deterministic loads, but I know that from a practical > point of view developers need to have a certain amount of control over > exactly what gets loaded into their DEVELOPMENT environments and they need > to be able to exert this control without having to resort to editing > configurations to match their specific requirements. > > I have accomplished this by arranging for a Notification to be signalled > whenever a project is referenced during a load. The developer can use one > or more of the onUpgrade:, onDowngrade: and onConflict: clauses in their > load scripts to exert fine control over what happens on a project by > project basis ... > > For your specific use case, I would think that you would want to use the > `lock` command[2] and specify that you want to `lock` the projects > (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if > I've got test cases for symbolic versions, but if you are seriously > interested in taking the Scripting API for a spin, I'd be willing to write > some additional tests using the #bleedingEdge symbolic version (if not > already covered) and validate this use case... > > I am entering a phase where I will be doing some work on getting FileTree > and Metacello up to snuff for Pharo3.0 so this would be a good time for me > to add some test cases in anticipation of having some interested users ... > > I haven't released the Scripting API, because I need to have real users > with real use cases take the API for a spin and validate the API. The > Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I > think the Scripting API is (or will be) available in Pharo3.0. > > I'm looking forward to getting feedback as to how the API stands up to > real use ... > > So let me know if you are interested in being another Scripting API guinea > pig:) > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [2] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > >

June 27, 2013

Re: [Pharo-dev] Metacello doubt

by Guido Chari

The problem is that my use case is a jenkins job. I want to have something that is the more automatically as possible. On the other hand, i like tools that support the user to be as free as possible. More if we are taking about tools for developers. In this case, i guess its not bad to have metacello allowing for developers to automatically load last version of every package. I think i have a clear use case here where i have a need that could be perhaps tackled with Metacello and is hard to tackle other way. 2013/6/27 Igor Stasenko <siguctua(a)gmail.com> > Just adding some comments: > - i avoid using loading bleeding edge > because it has problems which only humans can solve: > - if there are two different branches, not yet merged it may load > not one that you want > - even if dependencies is ok, it doesn't means that if you load two > latest versions of two packages, > they will work > > so, what i do, is loading a known working config, and then go to > monticello and manually picking and loading updated packages. > > On 27 June 2013 01:27, Dale K. Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: > > > > > > ________________________________ > > > > From: "Guido Chari" <charig(a)gmail.com> > > > > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > Sent: Wednesday, June 26, 2013 2:49:09 PM > > Subject: Re: [Pharo-dev] Metacello doubt > > > > I understood. Thanks for the answer Dale. The drawback in this case is to > > specify a particular dependency to AsmJit in my configuration. Also, > perhaps > > is the right way since i realized i have a particular dependency on it. > > > > But this discussion makes me thing a little and so i have a new question. > > > > Form what I (mis) undestand from Metacello, when asking for a > bleedingEdge > > version it loads only the baseline that specifies packages and then last > > version of every package specified there. > > > > As in the projects referenced on the baseline there is no need for > > specifying a version, and that's the case of nativeBoost configuration, > > wouldn't it be interesting to have some behavior (i mean i new method for > > loading like loadDeepSymbolic:) that not only load the symbolicVersion of > > the package asked, but also propagate that symbolicVersion (bleedingEdge > in > > this case) to all the dependencies that don't specify a concrete version? > > > > Guido. > > > > Guido, > > > > With the Metacello Scripting API[1] I've taken a slightly different tack, > > but I think that it gets you to the same place. > > > > I am a big fan of deterministic loads, but I know that from a practical > > point of view developers need to have a certain amount of control over > > exactly what gets loaded into their DEVELOPMENT environments and they > need > > to be able to exert this control without having to resort to editing > > configurations to match their specific requirements. > > > > I have accomplished this by arranging for a Notification to be signalled > > whenever a project is referenced during a load. The developer can use > one or > > more of the onUpgrade:, onDowngrade: and onConflict: clauses in their > load > > scripts to exert fine control over what happens on a project by project > > basis ... > > > > For your specific use case, I would think that you would want to use the > > `lock` command[2] and specify that you want to `lock` the projects > > (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if > > I've got test cases for symbolic versions, but if you are seriously > > interested in taking the Scripting API for a spin, I'd be willing to > write > > some additional tests using the #bleedingEdge symbolic version (if not > > already covered) and validate this use case... > > > > I am entering a phase where I will be doing some work on getting FileTree > > and Metacello up to snuff for Pharo3.0 so this would be a good time for > me > > to add some test cases in anticipation of having some interested users > ... > > > > I haven't released the Scripting API, because I need to have real users > with > > real use cases take the API for a spin and validate the API. The > Scripting > > API can be loaded into any version of Pharo/Squeak/GemStone and I think > the > > Scripting API is (or will be) available in Pharo3.0. > > > > I'm looking forward to getting feedback as to how the API stands up to > real > > use ... > > > > So let me know if you are interested in being another Scripting API > guinea > > pig:) > > > > Dale > > > > [1] > > > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > > [2] > > > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > > > > -- > Best regards, > Igor Stasenko. > >

June 27, 2013

Re: [Pharo-dev] cleaning pasteUpMorph

by StÃ©phane Ducasse

We should also remove ActiveWorld since there is already World as global! Stef On Jun 27, 2013, at 6:53 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > We will have also to clarify the invariant between > > hands first and currentHand (pointing to the global ActiveHand). > > Stef > On Jun 27, 2013, at 6:45 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> there is currentHand, primaryHandâ¦.. >> and lovely code like that >> >> primaryHand >> >> | outer | >> outer := self outermostWorldMorph ifNil: [^ nil]. >> ^ outer activeHand ifNil: [outer firstHand] > >

June 27, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 1 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods

June 27, 2013