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] [ANN]: Pharo x.5

by Sean P. DeNigris

> It nw fails with Could not load RPackage-Core-SeanDeNigris.215.mcz: > ZnHttpUnsuccessful: 404 Not Found' Okay I'll take a better look at what's missing... > However I did go back to an earlier ConfigurationOfPharoSpd and that > worked. Good! > is this because not all Monitcello packages get > published? It's because until now the project was just for my own use, so those packages are probably all in my local package cache and it works so I didn't realize I hadn't uploaded them. I should probably set up a Jenkins job so a pre-loaded image can be downloaded... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-ANN-Pharo-x-5-tp4693932p4695673.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 27, 2013

Re: [Pharo-dev] NBGLFrameBuffer>>checkStatus

by Alexandre Bergel

Thanks Igor, I will ask our local OpenGL expert Cheers, Alexandre On Jun 27, 2013, at 7:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 June 2013 21:06, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> Apparently, it happens that we get an error "Frame buffer status: Unknown error". The error comes from the method checkStatus: >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> NBGLFrameBuffer>>checkStatus >> | status | >> self bind. >> status := gl checkFramebufferStatusEXT: GL_FRAMEBUFFER. >> >> status = GL_FRAMEBUFFER_COMPLETE ifFalse: [ >> #( >> #GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT >> #GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT >> #GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER >> #GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER >> #GL_FRAMEBUFFER_UNSUPPORTED >> #GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE >> #GL_FRAMEBUFFER_UNDEFINED >> ) do: [:sym | >> (self class bindingOf: sym) ifNotNil: [:b | >> status = b value ifTrue: [ ^ self error: 'Frame buffer is incomplete: ', b key ] ]. >> ]. >> ^ self error: 'Frame buffer status: Unknown error'. >> ]. >> ^ true "ok" >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> Any idea what's going on? >> >> We took a Pharo 2.0, loaded Athens, NBOpenGL, SourceCity, and roassal3d. Running the test of roassal3d shows this. >> I suspect this error comes from some interaction between the tests. Closing an opengl window is enough to desallocate the opengl resources? >> > > If i remember , you should close and force GC. > But of course, it would be preferable , if on window close event you > explicitly deallocate things immediately, > then you don't have to wait for GC to clean it for you. > > The problem, i think, is interference between two different opengl contexts. > OpenGL is built so, that you need to actiave different context > (glMakeCurrent) between using any functions for it > (otherwise you would need to pass extra argument - a context handle, > to each function).. > Now i think the code that allocates/deallocates things in opengl > assumes that a valid context is currently selected (or only single > context ).. > because apparently, if current context is different than where you did > allocated the resources , you will get an error. > >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > > > -- > Best regards, > Igor Stasenko. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 27, 2013

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

by Max Leske

OK. I'll collect some cases and post them on the FogBugz issue. On 27.06.2013, at 16:06, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > 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/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

[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… 3 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods CollectionsTests.Strings.StringTest.testAt Tests.Release.ReleaseTest.testObsoleteClasses

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

June 27, 2013

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