- Pharo-dev - lists.pharo.org

removing a trait from a class, breaks the saving to the package?

by stepharo

Apparently I cannot remove the trait TAbleToRotate from a class If - I copy SimpleButtonMorph - remove the use: clause from the class def - I cannot commit the package anymore. there is a problem in packageSet Esteban do you copy me :) Stef

July 18, 2014

Re: [Pharo-dev] PetitParser in 3.0?

by Martin McClure

On 07/18/2014 07:37 AM, stepharo wrote: > Hi martin > > in Moose (working on 3.0) all the tools are working so I do not know the > status of the published configuration but it should work. > Have a look at Moose and the configuration repo from there. Thanks, Stef (and Phil). I'll try loading from Moose. Regards, -Martin

July 18, 2014

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

by Oscar E. A. CallaÃº

Well, I fixed the problem by modifying the Pharo.exe file with the 4GB patch program (http://ntcore.com/4gb_patch.php) As mentioned before, I think the best solution is that Pharo vms must be compiled with the flag LARGEADDRESSAWARE, so more memory space is enabled for 64bits Windows OSs. Thanks guys Oscar On Thu, Jul 17, 2014 at 11:03 PM, Andres Valloud < avalloud(a)smalltalk.comcastbiz.net> wrote: > 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).aspx >>> <http://msdn.microsoft.com/en-us/library/windows/hardware/ >>> dn613959%28v=vs.85%29.aspx>? >>> >>> >>> >> 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).aspx >> 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 Stephan Eggermont

Esteban wrote: >Pharo has a stable version, 3. >Bug fix releases are that: bug fixes, and does not break any compatibility. That is the goal, but not currently the result. >Again, not true. We released Pharo3 with no yellow/red tests. The test runner in ci behaves different from the test runner in-image. We used to have non-deterministic tests, I haven't checked if they ar wall gone. Running the test runner in all Pharo 3 builds shows failures and errors. (Mac Mavericks 10.9.3, vm356) 30852 30851 30850 30849 30848

July 18, 2014

Re: [Pharo-dev] PetitParser in 3.0?

by stepharo

Hi martin in Moose (working on 3.0) all the tools are working so I do not know the status of the published configuration but it should work. Have a look at Moose and the configuration repo from there. Stef On 18/7/14 04:15, Martin McClure wrote: > 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] [pharo-project/pharo-core] 9ebdd6: 40099

by stepharo

Thanks pavel. We should continue to repackage and clean. Tools for example. I'm currently working on Polymorph. Stef > Great, now the shrinking to the basic image does not have any > overrides nor ugly hacks. > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-1… > > -- Pavel > > > 2014-07-18 10:32 GMT+02:00 GitHub <noreply(a)github.com > <mailto:noreply@github.com>>: > > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 9ebdd640712f23c1c3055d066972c2034e3ca45e > https://github.com/pharo-project/pharo-core/commit/9ebdd640712f23c1c3055d06… > Author: Jenkins Build Server <board(a)pharo-project.org > <mailto:board@pharo-project.org>> > Date: 2014-07-18 (Fri, 18 Jul 2014) > > Changed paths: > R Graphics-Primitives.package/Color.class/class/as yet > unclassified/aaFontsColormapDepth.st > R Graphics-Primitives.package/Color.class/class/as yet > unclassified/cachedColormapFrom_to_.st > A > Graphics-Primitives.package/Color.class/class/colormaps/aaFontsColormapDepth.st > A > Graphics-Primitives.package/Color.class/class/colormaps/cachedColormapFrom_to_.st > M > Graphics-Primitives.package/Color.class/instance/printing/shortPrintString.st > M > Graphics-Primitives.package/EllipseMidpointTracer.class/definition.st > <http://definition.st> > M > Graphics-Primitives.package/EllipseMidpointTracer.class/instance/initialize/on_.st > A NativeBoost-Unix.package/UnixEnvironment.class/README.md > A > NativeBoost-Unix.package/UnixEnvironment.class/class/testing/isDefaultFor_.st > A NativeBoost-Unix.package/UnixEnvironment.class/definition.st > <http://definition.st> > A > NativeBoost-Unix.package/UnixEnvironment.class/instance/accessing/environ.st > <http://environ.st> > A > NativeBoost-Unix.package/UnixEnvironment.class/instance/enumeration/keysAndValuesDo_.st > A > NativeBoost-Unix.package/UnixEnvironment.class/instance/private/environAt_.st > A > NativeBoost-Unix.package/UnixEnvironment.class/instance/private/setEnv_value_.st > A NativeBoost-Win32.package/Win32Environment.class/README.md > A > NativeBoost-Win32.package/Win32Environment.class/class/testing/isDefaultFor_.st > A > NativeBoost-Win32.package/Win32Environment.class/definition.st > <http://definition.st> > A > NativeBoost-Win32.package/Win32Environment.class/instance/accessing/environmentStrings.st > A > NativeBoost-Win32.package/Win32Environment.class/instance/enumeration/keysAndValuesDo_.st > A > NativeBoost-Win32.package/Win32Environment.class/instance/private/getEnvSize_.st > A > NativeBoost-Win32.package/Win32Environment.class/instance/private/getEnv_.st > A > NativeBoost-Win32.package/Win32Environment.class/instance/private/getEnv_buffer_size_.st > A > NativeBoost-Win32.package/Win32Environment.class/instance/private/setEnv_value_.st > A > NativeBoost-Win32.package/Win32Environment.class/instance/private/unsetEnv_.st > A > ReleaseTests.package/ReleaseTest.class/instance/testing/testAllClassPoolBindingAreClassVariables.st > A > ReleaseTests.package/ReleaseTest.class/instance/testing/testAllGlobalBindingAreGlobalVariables.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - > scripts/script99.st <http://script99.st> > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - > updates/update40099.st <http://update40099.st> > M > ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > M Slot.package/ClassVariable.class/README.md > M > Slot.package/ClassVariable.class/instance/meta-object-protocol/link_.st > A > Slot.package/ClassVariable.class/instance/testing/isClassVariable.st > M Slot.package/GlobalVariable.class/README.md > A Slot.package/GlobalVariable.class/instance/as yet > unclassified/definingClass.st > M > Slot.package/GlobalVariable.class/instance/meta-object-protocol/link_.st > A > Slot.package/GlobalVariable.class/instance/testing/isGlobalVariable.st > R > Slot.package/LiteralVariable.class/instance/meta-object-protocol/link_.st > A > Slot.package/LiteralVariable.class/instance/testing/isClassVariable.st > A > Slot.package/LiteralVariable.class/instance/testing/isGlobalVariable.st > R System-Platforms.package/UnixEnvironment.class/README.md > R > System-Platforms.package/UnixEnvironment.class/class/testing/isDefaultFor_.st > R System-Platforms.package/UnixEnvironment.class/definition.st > <http://definition.st> > R > System-Platforms.package/UnixEnvironment.class/instance/accessing/environ.st > <http://environ.st> > R > System-Platforms.package/UnixEnvironment.class/instance/enumeration/keysAndValuesDo_.st > R > System-Platforms.package/UnixEnvironment.class/instance/private/environAt_.st > R > System-Platforms.package/UnixEnvironment.class/instance/private/setEnv_value_.st > R System-Platforms.package/Win32Environment.class/README.md > R > System-Platforms.package/Win32Environment.class/class/testing/isDefaultFor_.st > R > System-Platforms.package/Win32Environment.class/definition.st > <http://definition.st> > R > System-Platforms.package/Win32Environment.class/instance/accessing/environmentStrings.st > R > System-Platforms.package/Win32Environment.class/instance/enumeration/keysAndValuesDo_.st > R > System-Platforms.package/Win32Environment.class/instance/private/getEnvSize_.st > R > System-Platforms.package/Win32Environment.class/instance/private/getEnv_.st > R > System-Platforms.package/Win32Environment.class/instance/private/getEnv_buffer_size_.st > R > System-Platforms.package/Win32Environment.class/instance/private/setEnv_value_.st > R > System-Platforms.package/Win32Environment.class/instance/private/unsetEnv_.st > M > Tests.package/OSEnvironmentTest.class/instance/tests/testEnvironmentFor.st > > Log Message: > ----------- > 40099 > 13576 Small code critique cleanup Graphics-Primitives > https://pharo.fogbugz.com/f/cases/13576 > > 13587 add tests to make sure globals and class vars use the right > bindings > https://pharo.fogbugz.com/f/cases/13587 > > 13580 move UnixEnvironment and Win32Environment to NativeBoost > https://pharo.fogbugz.com/f/cases/13580 > > http://files.pharo.org/image/40/40099.zip > > >

July 18, 2014

Re: [Pharo-dev] PetitParser in 3.0?

by Tudor Girba

Hi Esteban, Moose 5 is still under development. We will likely reach a stable version within one or two months. In the meantime, it is true that there are some subcomponents that are stable (such as PetitParser), but we do not have yet the capacity and the organization to be able to release it individually easily. Perhaps once we will streamline the use of tooling around Metacello it will get easier. But, if people want to create a release of PetitParser, they are of course welcome to do it. Cheers, Doru On Fri, Jul 18, 2014 at 3:13 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 18 Jul 2014, at 14:12, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > Esteban wrote > >> This is a question for the moosers :) > >> Why there is no copy (with stable version) in metarepo of ll > configurations that are under the moose umbrella? > > > > That's a question of effort vs results. Moose builds on top of Pharo, > which has no stable. > > Pharo has a stable version, 3. > Bug fix releases are that: bug fixes, and does not break any compatibility. > > > There are newer builds of Pharo 3 containing bug-fixes. Moose has no > Metacello way to identify > > which build it is running on so no way to create a stable. Moose is a > large framework exercising > > large parts of the Pharo code base so almost all bug-fix releases impact > Moose. > > Thatâs not true. Bug fixes do not break Pharo and shouldnât break Moose. > The fact that you do not declare stable versions of Moose is the reason > why you cannot provide a loadable version in Pharo3. > You just continued working and breaking backward compatibility. Iâm > perfectly ok with that (in fact, I really like all the work around moose), > but you should provide a stable version for Pharo 3, like you should > provide a development version for Pharo 4. > > > The test suite of Pharo contains non-green tests so there is no easy way > to track issues. > > Again, not true. We released Pharo3 with no yellow/red tests. > > Esteban > > > > In addition there are of course the issues in Moose development itself. > > > > Stephan > > > -- www.tudorgirba.com "Every thing has its own flow"

July 18, 2014

[RMOD interviews] Clara's interview online!

by Nicolas Petton

Hi guys, I just published the interview of Clara Allende here: http://nicolas-petton.fr/blog/interview-clara.html As this is my last day in the team, I won't have time to interview any other member of the team (with the exception of Camille, as the interview is done, I just have to publish it). I was hoping to interview everyone of you, but time flies. :/ Anyway, I hope you like the interview! Cheers, Nico

July 18, 2014

Re: [Pharo-dev] PetitParser in 3.0?

by Esteban Lorenzano

On 18 Jul 2014, at 14:12, Stephan Eggermont <stephan(a)stack.nl> wrote: > Esteban wrote >> This is a question for the moosers :) >> Why there is no copy (with stable version) in metarepo of ll configurations that are under the moose umbrella? > > That's a question of effort vs results. Moose builds on top of Pharo, which has no stable. Pharo has a stable version, 3. Bug fix releases are that: bug fixes, and does not break any compatibility. > There are newer builds of Pharo 3 containing bug-fixes. Moose has no Metacello way to identify > which build it is running on so no way to create a stable. Moose is a large framework exercising > large parts of the Pharo code base so almost all bug-fix releases impact Moose. Thatâs not true. Bug fixes do not break Pharo and shouldnât break Moose. The fact that you do not declare stable versions of Moose is the reason why you cannot provide a loadable version in Pharo3. You just continued working and breaking backward compatibility. Iâm perfectly ok with that (in fact, I really like all the work around moose), but you should provide a stable version for Pharo 3, like you should provide a development version for Pharo 4. > The test suite of Pharo contains non-green tests so there is no easy way to track issues. Again, not true. We released Pharo3 with no yellow/red tests. Esteban > In addition there are of course the issues in Moose development itself. > > Stephan

July 18, 2014

Silently changing classes/methods

by Yuriy Tymchuk

Hi, I need to manipulate classes/methods in my tests. E.g. create class, test something, remove it. Can I do this silently? Because otherwise I get dirty packages, Epicea log and so on. Cheers Uko

July 18, 2014