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

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

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