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

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

by Igor Stasenko

On 27 June 2013 21:25, kilon <thekilon(a)yahoo.co.uk> wrote: > Ok we solved that problem lest move to the next one. > > I have this line of code > > Glint status; > > to be used in this > > glGetShaderiv(shader, GL_COMPILE_STATUS, &status); > > Now my first thought was to do this > > statusAdress := NativeBoost allocate: NBOpenGLTypes GLint. > > but of course NBOpenGLTypes GLint is not really a message so that fails. > > My problem here is that allocate , allocates a specific amount of bytes and > then returns the address. The problem is that there is no gurantee how many > bytes a GLint is. Is there a method somewhere in NBOpengl that can return > me that amount of bytes of a GLint in the platform that NBOpengl executes ? > > Remember I cant use here a constant number cause there is no guarantees that > GLint will be the same size for every user of NBOpengl. > > This is really fun by the way learning so low level stuff :) > > Well, on 32-bit system GLInt is alias for int, int32 To check its size you can do something like following: (NBFFICallout new requestor: <put a class which has access to GLInt>; resolveType: 'GLInt') typeSize Try NBExternalType sizeOf: 'GLInt' > > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695790.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

June 27, 2013

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

by ClÃ©ment Bera

2013/6/27 kilon <thekilon(a)yahoo.co.uk> > Just for the notice, because I stirred up the whole discussion about 64 bit > pharo. > > To my knowledge the whole point of having a 64 bit app is that so that app > can access more than 4 GBs of Ram. Is that the case or I have no clue what > I > am talking about ? > Yeah actually the goal is to allow the user to work on Pharo without installing 32bits lib and to be able to call 64 bits external libraries instead of 32 bits ones. > > I have read that already Pharo VM has some restrictions on how much ram an > image can use. Obviously even for todays standard 4GBs for a single app is > a > bit excessive but if pharo apps continue to grow in complexity and we start > to venture in areas of demanding ram needs , then it wont be hard to brake > that 4GB barrier. > You are right, we don't care about the RAM size, even language as Java does not have a VM with a GC supporting more that much of RAM. > > In any case maybe before you invest so much effort you must clear up what > the real benefits would be for us the users of pharo if pharo goes 64 bit. > > > > -- > View this message in context: > http://forum.world.st/Pharo-dev-How-do-can-we-set-up-a-crowdsourcing-for-ph… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

June 27, 2013

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

by kilon

Just for the notice, because I stirred up the whole discussion about 64 bit pharo. To my knowledge the whole point of having a 64 bit app is that so that app can access more than 4 GBs of Ram. Is that the case or I have no clue what I am talking about ? I have read that already Pharo VM has some restrictions on how much ram an image can use. Obviously even for todays standard 4GBs for a single app is a bit excessive but if pharo apps continue to grow in complexity and we start to venture in areas of demanding ram needs , then it wont be hard to brake that 4GB barrier. In any case maybe before you invest so much effort you must clear up what the real benefits would be for us the users of pharo if pharo goes 64 bit. -- View this message in context: http://forum.world.st/Pharo-dev-How-do-can-we-set-up-a-crowdsourcing-for-ph… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 27, 2013

Re: [Pharo-dev] Sprint tomorrow

by ClÃ©ment Bera

I confirm.The sprint will happen tomorrow in Lille. 2013/6/27 phil(a)highoctane.be <phil(a)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 > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

June 27, 2013

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

by kilon

Ok we solved that problem lest move to the next one. I have this line of code Glint status; to be used in this glGetShaderiv(shader, GL_COMPILE_STATUS, &status); Now my first thought was to do this statusAdress := NativeBoost allocate: NBOpenGLTypes GLint. but of course NBOpenGLTypes GLint is not really a message so that fails. My problem here is that allocate , allocates a specific amount of bytes and then returns the address. The problem is that there is no gurantee how many bytes a GLint is. Is there a method somewhere in NBOpengl that can return me that amount of bytes of a GLint in the platform that NBOpengl executes ? Remember I cant use here a constant number cause there is no guarantees that GLint will be the same size for every user of NBOpengl. This is really fun by the way learning so low level stuff :) -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695790.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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 20:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 ;-) > Be careful with using 'decent'. Because to my opinion, i cannot call even our today's 32-bit VMs decent. They are OK as to me. But i want more/better etc before i can call them decent. :) -- Best regards, Igor Stasenko.

June 27, 2013

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