- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] How do can we set up a crowdsourcing for pharo

by Sven Van Caekenberghe

On 27 Jun 2013, at 20:41, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 June 2013 18:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> I told you: 2 man/month >> (not taking NB-FFI into account) >> > That is a bit optimistic :) > But reasonable. Just to be clear: the goal is to make the current Cog & Stack VMs decent 64-bit apps that can operate on a 64-bit OS without needing special/extra 32-bit libs, while keeping intact the current 32-bit internal memory/pointer model, right ? And that on all 3 platforms ? Make that at least 3 months ;-) >> On Jun 27, 2013, at 6:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> so much? >>> how many men/months? >>> >>> Stef >>> >>> On Jun 27, 2013, at 3:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 27 June 2013 14:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> Hi >>>>> >>>>> we got this discussion about the VM on 64 bits so do we try to take the opportunity >>>>> to get a crowdsource donate button for it? >>>>> >>>>> Esteban/igor what is your estimate for such task? >>>>> >>>> >>>> depends what you put into it: >>>> - interpreter + plugins >>>> - new object/image format (64bit) >>>> - 64-bit jit >>>> >>>>> Stef >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

June 27, 2013

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

by Igor Stasenko

What i find fun with this bug, that it is one that is just annoying (you just get a DNU, then you restart and it works). Comparing to hard VM crash we experienced before... :) On 27 June 2013 20:23, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > 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/DevFlow with >> > "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. >> > -- Best regards, Igor Stasenko.

June 27, 2013

Re: [Pharo-dev] [Pharo-users] How do can we set up a crowdsourcing for pharo

by Igor Stasenko

On 27 June 2013 18:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I told you: 2 man/month > (not taking NB-FFI into account) > That is a bit optimistic :) But reasonable. > On Jun 27, 2013, at 6:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> so much? >> how many men/months? >> >> Stef >> >> On Jun 27, 2013, at 3:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 27 June 2013 14:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Hi >>>> >>>> we got this discussion about the VM on 64 bits so do we try to take the opportunity >>>> to get a crowdsource donate button for it? >>>> >>>> Esteban/igor what is your estimate for such task? >>>> >>> >>> depends what you put into it: >>> - interpreter + plugins >>> - new object/image format (64bit) >>> - 64-bit jit >>> >>>> Stef >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > -- Best regards, Igor Stasenko.

June 27, 2013

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

by Igor Stasenko

On 27 June 2013 18:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor we should document such mistakes > This is important can you add such comments in class comment? > Well, it is a general rule to never operate with pointers to moveable objects, because objects may change their locations at any moment and you don't control that. A pointer to object can be considered non-moving only if: - there is no allocation(s) of new objects between obtaining the pointer value and using it (like passing to external function) - you not running any smalltalk code/function you call will NOT call back and enter smalltalk code - you cannot be interrupted by something, which would allow the above. in short, anything which may cause GC between point where you got the pointer and point where you going to use it is a recipe for disaster. -- Best regards, Igor Stasenko.

June 27, 2013

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