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

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

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

by Esteban Lorenzano

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] [Pharo-project] Understanding NBOpenGL

by Henrik Johansen

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? Or is a disclaimer not to use the class for, say, 'char*' elements more appropriate? Cheers, Henry

June 27, 2013

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

by Dale K. Henrichs

Cami, Agreed ... the monticello meta data is only necessary for backward compatibility (being able to move packages back and forth between mcz repos and git repos) .... there's an almost infinite number of ways that the Monticello definitions can be "cast in directory structure" and I'm not sure that there is an optimal format:) as different formats yield different tradeoffs ... Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Thursday, June 27, 2013 12:32:13 AM | Subject: Re: [Pharo-dev] Versions Browser over gitfiletree:// | | >> without Monticello file back-end no? | > | > No, in fact it's very much dependent on Monticello filetree back | > end. This backend has the granularity which allow a use of git | > querying / fetching facilities to the level associated with | > changesets. | > | > I could implement a use of a gitfiletree:// repo as a complete | > replacement of a live changeset + monticello repository in one, if | > needed. | > | > Still wondering if this is the way to go. | | I think it is a very good start :), | eventually we have to come up with second version of the filetree | format as | the current one has a major limitiation: categories are stored in the | method source | | Impact: | - md5 hashes of the pure ST method sources do not correspond the md5 | hashes in the | git repository | - each file-in requires another strip-the-category-path | | of course there are workarounds for that. Additionally I would love | to have a | filetree version that doesn't store all this MC metadata. The changes | in these | files generate so much noise that is it hard to see the actual | changes. | | Anyway, most of it is future talk, I guess the current approach will | work :) | | Though I wonder what we will do once we have custom slots :/. I guess | we need | some hacks to make that run on top of Monticello. |

June 27, 2013

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

by Dale K. Henrichs

June 27, 2013