- Pharo-dev - lists.pharo.org

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

by Norbert Hartl

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] How do can we set up a crowdsourcing for pharo

by Stephan Eggermont

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

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 11:19:03 AM | Subject: Re: [Pharo-dev] Metacello doubt | | On 27 June 2013 15:43, Dale K. Henrichs | <dale.henrichs(a)gemtalksystems.com> wrote: | > | > ----- 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... | > | | Well, the "bleeding edge" called this way exactly for reasons that it | is unsafe/unpredictable | and hardly formalizeable. You are putting too much emphasis of the "what" at the expense of "why"... In Metacello #bleedingEdge is a version like any other version. The statement "if you know you want to deviate from the standard load directives" applies to whether you want to "deviate" by loading the #bleedingEdge version of a project or to "deviate" by loading the #stable version of a project, the mechanism in the Scripting API is exactly the same. | I don't see what can be done there: trying to predict a developer's | next move is not something you can do | with software :) The point is not to predict the developers needs ... the point is to allow the developer to express how he wants to deviate, without forcing him into manual operations... and this is something you can do in software:) | As i said, if there at least two persons working on project , each in | his own branch, a term "bleeding edge" will mean | something different for each of them. Only when one person takes an | effort to merge and update config, you'll have new development | version, but before that, if they will commit often without merging, | the bleeding edge will jump between one branch and another, and i do | not see how that can be useful to anyone. Your comments are specific to the #bleedingEdge version ... as I said earlier, the mechanism that I have described does not apply to only the #bleedingEdge case, but to all versions ... When I said that I would "add test cases for the #bleedingEdge use case," I was actually thinking that I wasn't sure that symbolic versions would work as _I_ expected, since I don't recall adding any tests involving _symbolic versions ... I generally don't want to add features to Metacello that are specifically tied to support a narrow range of use cases, unless I can generalize the feature to cover a wide range. I also don't want to forbid certain use cases just because I don't think they are useful. The Scripting API was invented to give developers explicit control over what gets loaded by Metacello, because the vanilla load of a project and it's dependents is not always what a developers needs ... Dale

June 27, 2013

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

by phil＠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. 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 27, 2013

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