- Pharo-dev - lists.pharo.org

VM Serial plugin

by Luc Fabresse

Hi all, With Santiago, we made a small fix for the serial plugin on Linux and OsX. We worked on a cloned repository of the PharoVM on github. I just sent a pull request. I guess I should also fill a bug entry somewhere. on which bugtracker, the pharo one ? Tell me and I will do it. Thanks, #Luc

Sept. 27, 2013

[update 3.0] #30426

by Marcus Denker

30426 ----- 11691 Failing test: testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits https://pharo.fogbugz.com/f/cases/11691 11693 Spec building is taking ages due to changes in PragmaCollector https://pharo.fogbugz.com/f/cases/11693 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.163.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke…

Sept. 27, 2013

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