- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 27 June 2013 15:34, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Jun 27, 2013, at 2:22 , Igor Stasenko wrote: > > i think it fails because you passing strange (NBExternalObject null) > as length parameter. > i guess you meant NBExternalAddress null instead. > > > Speaking of weird external stuffâ¦ > > NBExternalArray class >> #initElementType: aTypeName > "Initialize the element type and size. > If you want to use a public subclass of me, then make sure you call this > method > in your class #initialize method. > " > > elementType := aTypeName. > elementSize := (NBFFICallout new requestor: self; resolveType: elementType) > valueSize . > self installAccessors. > > Shouldn't that be storageSize? 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. 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.

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=li… 2 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods CollectionsTests.Strings.StringTest.testAt

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Goubier Thierry

Done, Thierry Le 27/06/2013 15:25, Dale K. Henrichs a Ã©crit : > Yes, please. > > Dale > > ----- Original Message ----- > | From: "Goubier Thierry" <thierry.goubier(a)cea.fr> > | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > | Sent: Thursday, June 27, 2013 12:13:40 AM > | Subject: Re: [Pharo-dev] Versions Browser over gitfiletree:// > | > | Hi Dale, > | > | should I merge this work into the last pull request (#85) I made? > | I've > | corrected a few bugs and solved some performance issues, in addition > | to > | adding the API for querying and loading parts of a package. It's > | currently on a separate branch. > | > | Thierry > | > | > | Le 27/06/2013 01:26, Dale K. Henrichs a Ã©crit : > | > Cool! I plan to integrate your work soon and I expect to merge your > | > work on the Pharo3.0 branch as well... > | > > | > Dale > | > > | > ----- Original Message ----- > | > | From: "GOUBIER Thierry" <thierry.goubier(a)cea.fr> > | > | To: "Pharo Development List â[pharo-dev@lists.pharo.org]â" > | > | <pharo-dev(a)lists.pharo.org> > | > | Sent: Wednesday, June 26, 2013 2:28:55 PM > | > | Subject: [Pharo-dev] Versions Browser over gitfiletree:// > | > | > | > | Or ... A first step towards Pharo without a changeset. > | > | > | > | 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 > | > | > > > -- 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

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Dale K. Henrichs

Excellent! ----- Original Message ----- | From: "Goubier Thierry" <thierry.goubier(a)cea.fr> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Thursday, June 27, 2013 7:08:40 AM | Subject: Re: [Pharo-dev] Versions Browser over gitfiletree:// | | Done, | | Thierry | | Le 27/06/2013 15:25, Dale K. Henrichs a Ã©crit : | > Yes, please. | > | > Dale | > | > ----- Original Message ----- | > | From: "Goubier Thierry" <thierry.goubier(a)cea.fr> | > | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | > | Sent: Thursday, June 27, 2013 12:13:40 AM | > | Subject: Re: [Pharo-dev] Versions Browser over gitfiletree:// | > | | > | Hi Dale, | > | | > | should I merge this work into the last pull request (#85) I made? | > | I've | > | corrected a few bugs and solved some performance issues, in | > | addition | > | to | > | adding the API for querying and loading parts of a package. It's | > | currently on a separate branch. | > | | > | Thierry | > | | > | | > | Le 27/06/2013 01:26, Dale K. Henrichs a Ã©crit : | > | > Cool! I plan to integrate your work soon and I expect to merge | > | > your | > | > work on the Pharo3.0 branch as well... | > | > | > | > Dale | > | > | > | > ----- Original Message ----- | > | > | From: "GOUBIER Thierry" <thierry.goubier(a)cea.fr> | > | > | To: "Pharo Development List â[pharo-dev@lists.pharo.org]â" | > | > | <pharo-dev(a)lists.pharo.org> | > | > | Sent: Wednesday, June 26, 2013 2:28:55 PM | > | > | Subject: [Pharo-dev] Versions Browser over gitfiletree:// | > | > | | > | > | Or ... A first step towards Pharo without a changeset. | > | > | | > | > | 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 | > | | > | | > | > | > | | -- | 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 | |

June 27, 2013

Re: [Pharo-dev] SqueakSource3 with new server name

by Dale K. Henrichs

June 27, 2013

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

by Guillermo Polito

It would be good to have a simple way to reproduce it and make a test for it. I tried that last week but I wasn't able to reproduce it :(. In any case, the problem is with the JIT. On a StackVM we don't have the problem. On Thu, Jun 27, 2013 at 4:00 PM, Max Leske <maxleske(a)gmail.com> wrote: > Thanks guys. > > So Esteban, do you need more cases? I can provide some if you want me to. > > Cheers, > Max > > > On 27.06.2013, at 15:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > On 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? > > > > no, I didn't said that :) > > > > I still don't know how to fix this... I can workaround the problem, but > the real problem is still there. > > > > see: https://pharo.fogbugz.com/f/cases/10395 > > > > for an explanation on how to workaround the issue. > > > > cheers, > > Esteban > > > >> > >>> Cheers, > >>> Max > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > >

June 27, 2013

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

by Max Leske

Thanks guys. So Esteban, do you need more cases? I can provide some if you want me to. Cheers, Max On 27.06.2013, at 15:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 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? > > no, I didn't said that :) > > I still don't know how to fix this... I can workaround the problem, but the real problem is still there. > > see: https://pharo.fogbugz.com/f/cases/10395 > > for an explanation on how to workaround the issue. > > cheers, > Esteban > >> >>> Cheers, >>> Max >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

June 27, 2013

Re: [Pharo-dev] SqueakSource3 with new server name

by Martin Dias

Since yesterday I have problems to save and to copy a version in a ss3.gemstone.com repo*: but when I change the url to ss3.gemtalksystems.com, then the operation success. Won't Squeaksource3 support saving and copying using the old url? *: http://ss3.gemtalksystems.com/ss/PharoTaskForces Cheers, MartÃn On Wed, Jun 26, 2013 at 11:39 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > https://pharo.fogbugz.com/f/cases/11023/Backport-2-0-Change-gemstone-refere… > > Thierry > > Le 26/06/2013 11:18, Torsten Bergmann a Ã©crit : > >> Dale wrote: >> "When the servers come back online you should start using the new domain >> names: >> >> ss3.gemstone.com -> ss3.gemtalksystems.com >> ... >> >> All of the old domains will continue to be usable for about a year, but I >> recommend that you start switching to the new domain names as soon as you >> can. >> " > > > -- > 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 >

June 27, 2013

Re: [Pharo-dev] [ANN]: Pharo x.5

by news{＠bestley.co.uk

Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Mark Bestley-2 wrote > > 'Could not load RPackage-Tests-SeanDeNigris.110.mcz: ZnHttpUnsuccessful: > > 404 Not Found' > > ... > > How do I get the later version? > > I've uploaded it. Please try again. > > It nw fails with Could not load RPackage-Core-SeanDeNigris.215.mcz: ZnHttpUnsuccessful: 404 Not Found' However I did go back to an earlier ConfigurationOfPharoSpd and that worked. Being new at Pharo is this because not all Monitcello packages get published? -- Mark

June 27, 2013

Re: [Pharo-dev] Metacello doubt

by Dale K. Henrichs

----- 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... Dale

June 27, 2013