- Pharo-dev - lists.pharo.org

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

by kilon

found a bug in NBOpengl this function definition is incorrect getShaderiv_shader: "in" shader pname: "in" pname params: "out" params <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: primErrorCode> ^ self glApiCall: #( void glGetShaderiv ( GLuint shader , GLenum pname , long* params ) ) index: 793 attributes: #( #category #VERSION_2_0 #version #'2.0' ) while the function definition is void glGetShaderiv(GLuint shader, GLenum pname, GLint * params); so there is no long* in there for params as is confirmed from opengl 2.1 reference pages -> http://www.opengl.org/sdk/docs/man2/ <http://www.opengl.org/sdk/docs/man2/> dont know if this bug has any effect , or maybe not a bug ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695962.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 28, 2013

[update 3.0] #30229

by Marcus Denker

30229 ----- 11067 World Menu is broken https://pharo.fogbugz.com/f/cases/11067 10984 Remove NameOfSubclass class https://pharo.fogbugz.com/f/cases/10984 11057 Random order in classes when debugger windows is shown https://pharo.fogbugz.com/f/cases/11057 11061 Remove test for old ClassBuilder https://pharo.fogbugz.com/f/cases/11061 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1156.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.27.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-MarcusDenker.522.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.42… http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-MarcusDenker.173.diff

June 28, 2013

[update 3.0] #30228

by Marcus Denker

30228 ----- 11059 OpenToolTest failing https://pharo.fogbugz.com/f/cases/11059 10887 Compound Extension Methods Unpackaged https://pharo.fogbugz.com/f/cases/10887 10910 Window Menu Registration (like World Menu) https://pharo.fogbugz.com/f/cases/10910 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/ToolsTest-MarcusDenker.denker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Tests-MarcusDenker.1… http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Core-MarcusDenker.23… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.25.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/MenuRegistration-MarcusDenker…

June 28, 2013

Re: [Pharo-dev] Sprint tomorrow

by Stephan Eggermont

Is 10569 on the list for today? Cheers, Stephan

June 28, 2013

Re: [Pharo-dev] [update 3.0] #30228

by Marcus Denker

Again, undo. Something makes the VM crash on windowsâ¦ in #evaluate. Now there was a change of that method in Isuue 1143. A change that should not crash the VM, but... On Jun 28, 2013, at 10:19 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30228 > ----- > > 11048 Dont display a StringMorph if the string is nil > https://pharo.fogbugz.com/f/cases/11048 > > 11011 Using anonymousSubclassOf: for creating anonymous subclasses > https://pharo.fogbugz.com/f/cases/11011 > > 11043 Update Opal to newest version > https://pharo.fogbugz.com/f/cases/11043 > > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Core-MarcusDenker… >

June 28, 2013

[update 3.0] #30228

by Marcus Denker

30228 ----- 11048 Dont display a StringMorph if the string is nil https://pharo.fogbugz.com/f/cases/11048 11011 Using anonymousSubclassOf: for creating anonymous subclasses https://pharo.fogbugz.com/f/cases/11011 11043 Update Opal to newest version https://pharo.fogbugz.com/f/cases/11043 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Core-MarcusDenker…

June 28, 2013

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

by kilon

Care to explain whats the difference between one from the other ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695864.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 28, 2013

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

by Esteban Lorenzano

On Jun 28, 2013, at 1:40 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Kilon wrote: >> 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. > > Why? It takes me less than 20 minutes to run out of available ram now, even though my machine has 8 times more. > On current hardware, 512GB is a more reasonable maximum size for a single app. Pharo apps have needed more than 4GB for as long as Pharo exists, nearly all Moose applications are strongly limited by it. > > Philippe wrote: >> Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to >me. > > Not to me. They force me to spend time thinking about partitioning at the moment I don't want to. Current machines > support more than 4G/core, so 64 bits flat is needed anyhow. Later binding, I want later binding! And Objects > Spaces too. They seem like a good idea. But later :) > > The java GC situation is ridiculous, and only exists because Oracle wants to sell databases. not sure, it is not so easy to produce an efficient large memory manager/garbage collector. but anyway, I agree that we need to be able to handle much larger spaces than we can now. Esteban > > Stephan > >

June 28, 2013

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

by Esteban Lorenzano

yeah, that sounds bizarre :) On Jun 28, 2013, at 7:53 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 27.06.2013 um 22:33 schrieb "phil(a)highoctane.be" <phil(a)highoctane.be>: > >> Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to me. >> > Can you explain what you mean? I cannot see how object spaces can solve the problem. The thing you describe sounds for me is just like starting a second image which is one way to use more than 4GB of RAM. > > Norbert >> Le 27 juin 2013 21:43, "ClÃ©ment Bera" <bera.clement(a)gmail.com> a Ã©crit : >> 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 28, 2013

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

by Esteban Lorenzano

honestly, the unique advantage of having a 64bits vm/image is that we will stop to have the 32bits as a limit to talk with outside world libraries (not a minor thing, IMO). you may think this is not important, since with some work you can still make everything work, but it is: nowadays more and more systems come just in 64bits, and stay in 32bits will doom us in the medium term. also, we will need a better memory manager, who can manage more than 512m efficiently (in fact, it is possible to manage more now, but it system become... well, clumsy :) it is not just the GC, is all the memory manager who we need to take care about, but this is another problem. Esteban On Jun 27, 2013, at 9:32 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > 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 28, 2013