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

Re: [Pharo-dev] Pharo (cog) Vm on Windows with 2GB virtual mem

by Guillermo Polito

I think latest Pharo VM supports to change the memory limit by only changing an ini file. Igor did that not long ago. Cheers, Guille On Fri, Sep 27, 2013 at 2:09 PM, Oscar E. A. CallaÃº <oalvarez(a)dcc.uchile.cl>wrote: > Hi Guys, > > I read in this thread > > http://forum.world.st/out-of-memory-cog-on-windows-td3465621.html > > that 512 mb limit can be avoided in windows, but a re-compilation is > needed. I was wondering if the situation changed, and now we can pass a > parameter. Otherwise, I would be interested if any of you has a > pre-compiled vm with more mem. > > I need to run some experiments and I need 2GB (or 1.5 GB at least ) on a > cog VM for Windows. > > Thanks in advance. > > Oscar >

Sept. 27, 2013

Pharo (cog) Vm on Windows with 2GB virtual mem

by Oscar E. A. CallaÃº

Hi Guys, I read in this thread http://forum.world.st/out-of-memory-cog-on-windows-td3465621.html that 512 mb limit can be avoided in windows, but a re-compilation is needed. I was wondering if the situation changed, and now we can pass a parameter. Otherwise, I would be interested if any of you has a pre-compiled vm with more mem. I need to run some experiments and I need 2GB (or 1.5 GB at least ) on a cog VM for Windows. Thanks in advance. Oscar

Sept. 27, 2013

Re: [Pharo-dev] SmalltalkHub use of LESS stylesheets

by nicolas petton

Yes, it would speedup the load of the page. I kept everything on purpose including the Smalltalk source code in Amber, its IDE, etc. So that people can see how it is online and inspect everything. Now it's true that since we have an automated build for it, I could put it in deployment mode :) Nico 2013/9/27 Sebastian Sastre <sebastian(a)flowingconcept.com> > I'm curions on how this develops. > > Looking forward for hear about every tactic to make amber apps loading > snappishly :D > > > > > On Sep 26, 2013, at 11:27 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > Hi all, > > > > The SmalltalkHub website seems to be using LESS stylesheets, which are > > downloaded in a sequential order, and it takes ~20sec to download the > > styles. > > > > Wouldn't it be better to compile the LESS stylesheets to regular CSS > > files (combined and minified in a single file would be great). LESS > > stylesheets are not meant to be used in production environments. > > > > I thinks that only with that the speedup will be significant. > > > > Regards, > > > > Esteban A. Maringolo > > > > >

Sept. 27, 2013

[update 3.0] #30425

by Marcus Denker

30425 ----- 11688 Pharo Kernel shrinking update for 30424 https://pharo.fogbugz.com/f/cases/11688 11689 Spec Inspectors still let update process in some circumstances https://pharo.fogbugz.com/f/cases/11689 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.9… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.251… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.9… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.12… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.161.di…

Sept. 27, 2013

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

by Pavel Krivanek

It was me. I tried to change the config to use the latest VM to see if it is a vm related problem. Sorry. -- Pavel 2013/9/27 Marcus Denker <marcus.denker(a)inria.fr>: > > On Sep 27, 2013, at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Sep 27, 2013, at 10:29 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>>> >>> >>> Result: it still fails, even after reverting. >>> >>> Are we sure that the VM did not change in the middle? It looks *really* strange! >>> >>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=li… >>> >> >> It seems someone changed the config to load the latest VM which has problems right now. >> >> I will revert that. >> > > Ok, now we can build the image again. > > Marcus >

Sept. 27, 2013

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

by Marcus Denker

On Sep 27, 2013, at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Sep 27, 2013, at 10:29 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >>> >> >> Result: it still fails, even after reverting. >> >> Are we sure that the VM did not change in the middle? It looks *really* strange! >> >> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=li… >> > > It seems someone changed the config to load the latest VM which has problems right now. > > I will revert that. > Ok, now we can build the image again. Marcus

Sept. 27, 2013

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

by Marcus Denker

On Sep 27, 2013, at 10:29 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Sep 27, 2013, at 10:08 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Sep 27, 2013, at 9:25 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >>> And it's interesting that during the first pass on a dirty image it >>> works well even on the slave too. >>> >> >> I will revert the compiler merge for now >> >> (it did even run the regression testsâ¦ but showing some strange - I think - trait-recompiling >> related bug..) >> >> So what we will do >> >> -> revert this update (it is already auto-reverted due to the crash) >> -> save Opal as it is in the image before this to to the Opal repo >> -> get the Opal regression green (traits bug) >> -> get image green (we do have some failing tests) >> -> *then* on the Opal repo, merge step-by-the intermediate 5 small commits >> (Abstract compiler class, some trivial cleanups, clean block analysis that is not called) >> I do not see how these changes could lead to the problem, but it could be that there is some >> bug in the compiler that shows itself when recompiling certain methods. >> >> One interesting observation: we did not check the Opal-Regression tester for 4 weeks, and >> we are in the mess. This just shows how important continous integration + automatic regression >> testing *after every commit* is for compiler developmentâ¦ (or being more intelligent would maybe >> another solution ;-) >> > > Result: it still fails, even after reverting. > > Are we sure that the VM did not change in the middle? It looks *really* strange! > > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=li… > It seems someone changed the config to load the latest VM which has problems right now. I will revert that. Marcus

Sept. 27, 2013

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

by Marcus Denker

On Sep 27, 2013, at 10:08 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Sep 27, 2013, at 9:25 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> And it's interesting that during the first pass on a dirty image it >> works well even on the slave too. >> > > I will revert the compiler merge for now > > (it did even run the regression testsâ¦ but showing some strange - I think - trait-recompiling > related bug..) > > So what we will do > > -> revert this update (it is already auto-reverted due to the crash) > -> save Opal as it is in the image before this to to the Opal repo > -> get the Opal regression green (traits bug) > -> get image green (we do have some failing tests) > -> *then* on the Opal repo, merge step-by-the intermediate 5 small commits > (Abstract compiler class, some trivial cleanups, clean block analysis that is not called) > I do not see how these changes could lead to the problem, but it could be that there is some > bug in the compiler that shows itself when recompiling certain methods. > > One interesting observation: we did not check the Opal-Regression tester for 4 weeks, and > we are in the mess. This just shows how important continous integration + automatic regression > testing *after every commit* is for compiler developmentâ¦ (or being more intelligent would maybe > another solution ;-) > Result: it still fails, even after reverting. Are we sure that the VM did not change in the middle? It looks *really* strange! https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=li… Marcus

Sept. 27, 2013

Re: [Pharo-dev] Strange FileDoesNotExistException when loading code from Seaside...

by Marcus Denker

On Sep 26, 2013, at 8:28 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys, > > I have a link in a Seaside app that allow us to trigger a Metacello load to update the source code. It has a weird error....I get a FileDoesNotExistException with the .changes file, which indeed exists. The error is in #readOnlyFileNamed:. I attach an screenshot of the stack. > > What is funny is that the compiled method that has the problem is always (or at least most of the times) either WAAttribute>>#accept: or WAAttribute>>#isAdvanced ... > > More funny...if I open a debugger in the problem, and I re-execute readOnlyFileNamed: it works! (of course, because the .changes file does exists). > > Does anyone had a similar problem? This could be related to this bug: Plugins Primitives no longer work after a while https://pharo.fogbugz.com/f/cases/7559/ In 3 I think this does not happen anymore, and I though this was fixed in 2, tooâ¦ but someone recently mentioned that it happened sometimes. Marcus

Sept. 27, 2013

Re: [Pharo-dev] UI Mess

by Goubier Thierry

Le 26/09/2013 21:54, Sean P. DeNigris a Ã©crit : > Goubier Thierry wrote >> answer := UIManager default >> chooseFileReference: 'Select a file' >> path: aFileReference >> pattern: '*.png' >> name: nil > > I can't tell if that captures the full options of fileDialogWindow without a > bit more investigation, but that would be a great improvement over the > current mess. I feel that whatever we do should be coupled with moving the > open/answer logic into that single entry point and out of UITheme. UITheme > should only provide the morph. I'd do a change for a single entry point in UIManager, the theme also providing a single entry point for creating the dialog. Sounds doable without many changes to the dialog code itself. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 27, 2013