- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] a31a27: 40097

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: a31a276f780b15bfbd294c214a9f317ebb7ad35a https://github.com/pharo-project/pharo-core/commit/a31a276f780b15bfbd294c21… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-07-18 (Fri, 18 Jul 2014) Changed paths: M OpalCompiler-Core.package/OCLiteralVariable.class/instance/emitting/emitStore_.st M OpalCompiler-Core.package/OCLiteralVariable.class/instance/emitting/emitValue_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script97.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40097.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Slot.package/ClassVariable.class/instance/as yet unclassified/link_.st A Slot.package/ClassVariable.class/instance/meta-object-protocol/link_.st R Slot.package/GlobalVariable.class/instance/as yet unclassified/link_.st M Slot.package/GlobalVariable.class/instance/code generation/emitValue_.st A Slot.package/GlobalVariable.class/instance/meta-object-protocol/link_.st M Slot.package/LiteralVariable.class/README.md R Slot.package/LiteralVariable.class/instance/converting/asGlobalVariable.st M Slot.package/SlotClassBuilder.class/instance/accessing/sharedVariablesFromString_.st R Slot.package/TestGlobalVariable.class/README.md R Slot.package/TestGlobalVariable.class/definition.st R Slot.package/extension/ByteString/instance/asGlobalVariable.st R Slot.package/extension/Symbol/instance/asGlobalVariable.st M Traits.package/TClass.class/instance/class variables/addClassVarNamed_.st M Traits.package/TClass.class/instance/class variables/classVariableDefinitionString.st Log Message: ----------- 40097 13584 Forward code generation for Globals and Class Vars to meta object https://pharo.fogbugz.com/f/cases/13584 13586 Class Variables should be ClassVariables, not Globals https://pharo.fogbugz.com/f/cases/13586 http://files.pharo.org/image/40/40097.zip

July 18, 2014

Re: [Pharo-dev] PetitParser in 3.0?

by Tudor Girba

In the case of Moose, #development and #bleedingEdge are the same. Doru On Fri, Jul 18, 2014 at 9:18 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I think what is loaded by CI is dependent on the workflow of the project. > IMHO for most projects loading #bleedingEdge is the best thing to do. > > Norbert > > Am 18.07.2014 um 05:21 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > It loads #development as any CI job should do. > > Doru > > > On Fri, Jul 18, 2014 at 1:40 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Stephan Eggermont wrote >> > And there is a image build at >> > https://ci.inria.fr/pharo-contribution/job/PetitParser/ >> >> Interesting. I wonder what the ci is loading, because if I try to load the >> default group in Pharo 3.0, I get an error (hence I load 'Core' and have >> no >> problems) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/PetitParser-in-3-0-tp4768398p4768407.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > -- www.tudorgirba.com "Every thing has its own flow"

July 18, 2014

Re: [Pharo-dev] PetitParser in 3.0?

by Norbert Hartl

I think what is loaded by CI is dependent on the workflow of the project. IMHO for most projects loading #bleedingEdge is the best thing to do. Norbert > Am 18.07.2014 um 05:21 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > It loads #development as any CI job should do. > > Doru > > >> On Fri, Jul 18, 2014 at 1:40 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Stephan Eggermont wrote >> > And there is a image build at >> > https://ci.inria.fr/pharo-contribution/job/PetitParser/ >> >> Interesting. I wonder what the ci is loading, because if I try to load the >> default group in Pharo 3.0, I get an error (hence I load 'Core' and have no >> problems) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/PetitParser-in-3-0-tp4768398p4768407.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

July 18, 2014

Re: [Pharo-dev] SmalltalkHub and public write access

by Marcus Denker

On 18 Jul 2014, at 01:29, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Nicolas Petton wrote >> It should be working fine now. > > Thanks! That's important for contributions :) > Yes! Thanks a lot! Marcus

July 18, 2014

Re: [Pharo-dev] [Pharo4] First Class Global Variables

by Marcus Denker

>> >> I have added a first GlobalVar hierarchyâ¦ it has already the code generation methods but Opal is not yet forwarding >> code generation (and the compiler does not yet compile bindings with the subclass). >> > > update 40 095 contains changes to deeper integrate first class variables (Slots and first class Globals) int the system. > > 1) Both the binding in "Smalltalk globals" as well as all Class Variables are now instances of GlobalVariable. > (I want to have both GlobalVariable and ClassVariable, but that is for later) > > e.g. > > Object binding class > (SmalltalkImage classVariableNamed: 'ShutDownList') class > > all the Slots and Globals understand > > #definingClass -> returns the class defining the variable or "nil" for true globals > #usingMethods -> all methods reading or writing the variable > > > e.g. try (Point slotNamed: #x) usingMethods > > Next: > > -> Hook Opal to forward code generation for globals to the meta object Done (not yet integrated): https://pharo.fogbugz.com/f/cases/13584/Forward-code-generation-for-Globals… > -> use ClassVariable for class variables Done (not yet integrated): https://pharo.fogbugz.com/f/cases/13586/Class-Variables-should-be-ClassVari… Marcus

July 18, 2014

Re: [Pharo-dev] PetitParser in 3.0?

by Tudor Girba

It loads #development as any CI job should do. Doru On Fri, Jul 18, 2014 at 1:40 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephan Eggermont wrote > > And there is a image build at > > https://ci.inria.fr/pharo-contribution/job/PetitParser/ > > Interesting. I wonder what the ci is loading, because if I try to load the > default group in Pharo 3.0, I get an error (hence I load 'Core' and have no > problems) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/PetitParser-in-3-0-tp4768398p4768407.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

July 18, 2014

Re: [Pharo-dev] Memory limit problems on Windows VM

by Andres Valloud

I worked on that switch before, and IIRC it's just a linker switch that marks executables a certain way. So, if you have imagecfg.exe handy... http://support.microsoft.com/kb/297812 On 7/17/14 19:25 , Oscar E. A. CallaÃº wrote: > Well. It seems that Pharo vms must be compiled with that option :/ > > Cheers > > > On Wed, Jul 16, 2014 at 8:44 PM, <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > __ > Eliot Miranda wrote: >> >> >> >> On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. CallaÃº >> <oscar.apollo(a)gmail.com <mailto:oscar.apollo@gmail.com>> wrote: >> >> Hi, >> >> I'm using Windows 8.1 (update1) 64bits with 4GB of physical >> RAM. I only need 1.5GB of RAM, so I think I don't need to >> configure my OS to take /3GB of RAM. >> >> >> Well my experience (and others) is that one can't grow the heap >> much above 1.1 Gb without using the /3Gb switch on Windows XP. I >> can't talk for 8.1. But if 8.x also limits memory to 2Gb/process >> unless the /3Gb switch is in effect then yes, you'll need to use >> the /3Gb switch. >> >> HTH >> Eliot >> >> >> Cheers >> >> On Wednesday, July 16, 2014, Eliot Miranda wrote: >> >> Hi Oscar, >> >> >> On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. A. CallaÃº >> <oscar.apollo(a)gmail.com> wrote: >> >> Hi guys, >> >> I'm running some experiments in Pharo. My data >> is aprox. 1.3GB. When I load my image on Mac, >> everything works perfectly. But, when I try to load >> the same image on Windows, I get this error: >> >> Unable to commit memory (1326649344 bytes requested) >> >> I tried the Pharo VM, cogMT and NBcog with and >> without the option >> >> AddressSpaceLimit = 2048 >> >> in the ini file >> >> Please help. >> >> What OS are you using? Have you read e.g. >> http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959(v=vs.85).… >> <http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959%28v=vs.85…>? >> >> > > Here are some additional links... > > /LARGEADDRESSAWARE (Handle Large Addresses) > http://msdn.microsoft.com/en-us/library/wz223b1z.aspx > > Memory Limits for Windows and Windows Server Releases > http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).a… > I learnt something new reading this article. For Win 8.1 64-bit, the > /3GB switch is not applicable or required. However the > /LARGEADDRESSAWARE linker option is critical for both 32-bit and > 64-bit VMs. Its only the default setting that changes between > compiling 32-bit or 64-bit applications. Some extracts... > > Limits on memory and address space depend on whether the > IMAGE_FILE_LARGE_ADDRESS_AWARE value of the LOADED_IMAGE structure > and 4-gigabyte tuning (4GT) are in use. > IMAGE_FILE_LARGE_ADDRESS_AWARE is set or cleared by using the > /LARGEADDRESSAWARE linker option. 4-gigabyte tuning (4GT), also > known as application memory tuning, or the /3GB switch, is a > technology (**only applicable to 32 bit systems**) that alters the > amount of virtual address space available to user mode applications. > > On x64-bit MS Windows, User-Mode virtual address space for each > 32-bit process > 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set > 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default) > > On x64-bit MS Windows, User-Mode virtual address space for each > 64-bit process > 8 TB With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): > 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared > > cheers -ben > >> >> -- >> best, >> Eliot >> >> >> >> >> -- >> best, >> Eliot > >

July 18, 2014

Re: [Pharo-dev] Memory limit problems on Windows VM

by Oscar E. A. CallaÃº

Well. It seems that Pharo vms must be compiled with that option :/ Cheers On Wed, Jul 16, 2014 at 8:44 PM, <btc(a)openinworld.com> wrote: > Eliot Miranda wrote: > > > > > On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. CallaÃº < > oscar.apollo(a)gmail.com> wrote: > >> Hi, >> >> I'm using Windows 8.1 (update1) 64bits with 4GB of physical RAM. I only >> need 1.5GB of RAM, so I think I don't need to configure my OS to take /3GB >> of RAM. >> > > Well my experience (and others) is that one can't grow the heap much > above 1.1 Gb without using the /3Gb switch on Windows XP. I can't talk for > 8.1. But if 8.x also limits memory to 2Gb/process unless the /3Gb switch > is in effect then yes, you'll need to use the /3Gb switch. > > > HTH > Eliot > > >> Cheers >> >> On Wednesday, July 16, 2014, Eliot Miranda wrote: >> >>> Hi Oscar, >>> >>> >>> On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. A. CallaÃº < >>> oscar.apollo(a)gmail.com> wrote: >>> >>>> Hi guys, >>>> >>>> I'm running some experiments in Pharo. My data is aprox. >>>> 1.3GB. When I load my image on Mac, everything works perfectly. But, when I >>>> try to load the same image on Windows, I get this error: >>>> >>>> Unable to commit memory (1326649344 bytes requested) >>>> >>>> I tried the Pharo VM, cogMT and NBcog with and without the option >>>> >>>> AddressSpaceLimit = 2048 >>>> >>>> in the ini file >>>> >>>> Please help. >>>> >>> >>> What OS are you using? Have you read e.g. >>> http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959(v=vs.85).… >>> >>> >> > Here are some additional links... > > /LARGEADDRESSAWARE (Handle Large Addresses) > http://msdn.microsoft.com/en-us/library/wz223b1z.aspx > > Memory Limits for Windows and Windows Server Releases > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).a… > I learnt something new reading this article. For Win 8.1 64-bit, the /3GB > switch is not applicable or required. However the /LARGEADDRESSAWARE > linker option is critical for both 32-bit and 64-bit VMs. Its only the > default setting that changes between compiling 32-bit or 64-bit > applications. Some extracts... > > Limits on memory and address space depend on whether the > IMAGE_FILE_LARGE_ADDRESS_AWARE value of the LOADED_IMAGE structure and > 4-gigabyte tuning (4GT) are in use. IMAGE_FILE_LARGE_ADDRESS_AWARE is set > or cleared by using the /LARGEADDRESSAWARE linker option. 4-gigabyte > tuning (4GT), also known as application memory tuning, or the /3GB switch, > is a technology (**only applicable to 32 bit systems**) that alters the > amount of virtual address space available to user mode applications. > > On x64-bit MS Windows, User-Mode virtual address space for each 32-bit > process > 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set > 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default) > > On x64-bit MS Windows, User-Mode virtual address space for each 64-bit > process > 8 TB With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): > 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared > > cheers -ben > > >>> -- >>> best, >>> Eliot >>> >> > > > -- > best, > Eliot > > >

July 18, 2014

Re: [Pharo-dev] PetitParser in 3.0?

by Martin McClure

On 07/17/2014 04:37 PM, Sean P. DeNigris wrote: > Martin McClure-2 wrote >> Anyone using PetitParser in Pharo 3.0? > > Yes! > > 1. Open the Config Browser from the World menu > 2. Right click in the list pane and switch to the ss3 meta repo > 3. Load the PP config > 4. ConfigurationOfPetitParser project stableVersion load: 'Core' > > HTH Thanks a bunch, Sean! That loads in the latest 3.0 image, and the test pass. I gather that the GUI tools have not been ported forward? Regards, -Martin

July 18, 2014

Re: [Pharo-dev] PetitParser in 3.0?

by Stephan Eggermont

MetaRepoForPharo20 does not necessarily contain versions that work for Pharo 3 (or 4). You might want to compare versions. Can't do it from here, as smalltalkhub crashes safari on iOS devices. Stephan

July 18, 2014