- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Tudor Girba

Hi, > On Jan 24, 2016, at 9:51 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Sun, Jan 24, 2016 at 12:42 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Eliot, > > I created a package to easily reproduce the problem: > https://dl.dropboxusercontent.com/u/18323746/Tmp/moose-6-for-GC-bug.zip > > In there you will get: > - an image, > - the MSE file to be loaded, and > - a Playground script that loads that file. > > That sounds perfect. > > On my Mac, this takes some 3 minutes, while before it took about 1 minute. > > What's the system info on your Mac? Mine is "Version 10.9.5 Processor 2.2GHz Intel Core i7 Memory 16Gb 1333 MHz DDR3â Model Name: MacBook Pro Model Identifier: MacBookPro10,1 Processor Name: Intel Core i7 Processor Speed: 2.6 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 16 GB Boot ROM Version: MBP101.00EE.B0A SMC Version (system): 2.3f36 Serial Number (system): C02JG3T5DKQ5 Hardware UUID: 1FF116A4-5040-53B2-A133-F95256DE6C94 Cheers, Doru > Let me know if you need anything else. > > Cheers, > Doru > > > > > On Jan 24, 2016, at 9:33 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Doru, > > > > On Sun, Jan 24, 2016 at 12:26 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Eliot, > > > > Thanks for looking at this. > > > > Please let us know what support you need, or what kind of experiments we can do on our side. > > > > What I want most of all is a test case that I can run on Mac. I'm assuming that I can just copy the job that Vincent mentioned in his email and use that as a test case. Do you see any issues with that? If so, how do I get a really bug MOOSE test case to run on Mac? > > > > > > Cheers, > > Doru > > > > > > > On Jan 24, 2016, at 9:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > Hi Vincent, > > > > > > I'll take a look early this week. There's clearly a bug; the Spur > > > GC is /not/ collecting those dictionaries :-( (thanks Stephan!). > > > Assuming the bug is fixed times should come down (see below). It may > > > be that the bug in Slang that I introduced in December has broken > > > things because I don't see these symptoms in my daily work (but I use > > > the most up-to-date VM version possible ;-) ). But I'm not in denial > > > and look forward to using MOOSE as a good stress case. > > > > > > I do want to say that the GC is not complete. Right now we have a > > > scavenger that works well, and a global GC that has a slow compaction > > > algorithm, and hence there are significant pauses. For example here's > > > what I see as typical in using SPur for VMMaker work: > > > > > > memory 160,432,128 bytes > > > old 153,658,624 bytes (95.8%) > > > young 4,838,224 bytes (3%) > > > used 127,009,928 bytes (79.2%) > > > free 28,126,456 bytes (17.5%) > > > GCs 7,265 (?? ms between GCs) > > > full 36 totalling 13,229 ms (0% uptime), avg 367.5 ms > > > incr 7,229 totalling 6,546 ms (0% uptime), avg 0.9 ms > > > tenures 3,589,063 (avg 0 GCs/tenure) > > > > > > (There's no uptime in the above stats because we're still > > > transitioning Squeak to the 64-bit clock and there are consequently > > > bugs in computing uptime). > > > > > > The plan is to add an incremental global GC so this work is broken up > > > into much smaller pieces. I don't want to see 700ms pauses in global > > > GC; one can't do game animation with that. So an incremental > > > mark-sweep is needed. There are two nice papers we're considering, > > > one from Lua and one for a truly concurrent collector. But time is > > > pressing, so if anyone out there knows GC and is interested in helping > > > this is a nicely self-contained project for which we'd love to have > > > volunteers. > > > > > > _,,,^..^,,,_ (phone) > > > > > >> On Jan 24, 2016, at 3:43 AM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net> wrote: > > >> > > >> Hi, > > >> > > >> I made the benchmarks with the files you provided. I have more or less the > > >> same magnitude: > > >> Version 504: 0:00:01:09.021 > > >> Version 1175: 0:00:02:37.507 > > >> > > >> However, by launching it in the time profiler (MooseModel new > > >> importFromMSEStream: (StandardFileStream readOnlyFileNamed: > > >> 'd:/ArgoUML-0-34.mse')), it takes > > >> 504: 1 min 55 > > >> 1175: 4 min 25 > > >> Well there is a delta... > > >> > > >> After investigation, the standard process has almost the same duration (120 > > >> secs for prespur and 140 secs for spur). > > >> But, there is a large difference in GC time: > > >> > > >> 504: not spur > > >> **Memory** > > >> old +144,822,000 bytes > > >> young -8,293,660 bytes > > >> used +136,528,340 bytes > > >> free -104,186,788 bytes > > >> > > >> **GCs** > > >> full 1 totalling 965ms (1.0% uptime), avg 965.0ms > > >> incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms > > >> tenures 2,497 (avg 1 GCs/tenure) > > >> root table 0 overflows > > >> > > >> 1175: spur > > >> **Memory** > > >> old +0 bytes > > >> young +340,048 bytes > > >> used +340,048 bytes > > >> free -340,048 bytes > > >> **GCs** > > >> full 7 totalling 145,003ms (66.0% uptime), avg > > >> 20715.0ms > > >> incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms > > >> tenures 7,146,505 (avg 0 GCs/tenure) > > >> root table 0 overflows > > >> > > >> Total GC time > > >> 504: 43 secs > > >> 1175: 176 secs > > >> > > >> See the performance reports attached. > > >> > > >> I let VM people take care of the issue ;) > > >> > > >> Cheers, > > >> Vincent > > >> > > >> -----Original Message----- > > >> From: moose-dev-bounces(a)list.inf.unibe.ch > > >> [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba > > >> Sent: dimanche 24 janvier 2016 09:08 > > >> To: Moose-related development > > >> Subject: [Moose-dev] Re: mse loading looks slower :( > > >> > > >> Hi, > > >> > > >> I am talking about the difference between Moose 6 images: > > >> - October 7: > > >> https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip > > >> > > >> - yesterday: > > >> https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip > > >> > > >> Multiple things did change, but not in Moose. In the end, I would like to > > >> understand where the slowness comes. Maybe it comes from Spur itself, but > > >> maybe it comes from somewhere else. > > >> > > >> Cheers, > > >> Doru > > >> > > >> > > >> > > >>>> On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> > > >>> wrote: > > >>> > > >>> Doru...just to be sure it is not a Pharo (image change), when you said > > >> before and after Spur, do you mean a Pharo 5.0 exactly (just before Spur) > > >> and a Pharo JUST after it? Otherwise, the slowness may come from the > > >> difference between the 2 Pharos you are running. > > >>> > > >>> Cheers, > > >>> > > >>> On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > >>> Hi, > > >>> > > >>> I am doing some performance testing of Moose with the Spur VM on Mac. > > >>> > > >>> I tried to load an MSE file with ArgoUML 0.34 and on my machine it loads > > >> twice as slow with Spur than before: > > >>> - PreSpur: 0:00:01:07.272 > > >>> - Spur: 0:00:02:10.508 > > >>> > > >>> Here is the reference file: > > >>> https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip > > >>> > > >>> And here is the script: > > >>> [ > > >>> MooseModel new > > >>> importFromMSEStream: (StandardFileStream > > >> readOnlyFileNamed: > > >>> (FileSystem workingDirectory / 'src' / > > >> 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName). > > >>> ] timeToRun > > >>> > > >>> Do you get the same? > > >>> > > >>> Cheers, > > >>> Doru > > >>> > > >>> > > >>> -- > > >>> www.tudorgirba.com > > >>> www.feenk.com > > >>> > > >>> "Problem solving should be focused on describing the problem in a way > > >>> that makes the solution obvious." > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Moose-dev mailing list > > >>> Moose-dev(a)list.inf.unibe.ch > > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > > >>> > > >>> > > >>> > > >>> -- > > >>> Mariano > > >>> http://marianopeck.wordpress.com > > >>> _______________________________________________ > > >>> Moose-dev mailing list > > >>> Moose-dev(a)list.inf.unibe.ch > > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > > >> > > >> -- > > >> www.tudorgirba.com > > >> www.feenk.com > > >> > > >> "What is more important: To be happy, or to make happy?" > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> Moose-dev(a)list.inf.unibe.ch > > >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > >> <report504.txt> > > >> <report1175.txt> > > > > > > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > -- > _,,,^..^,,,_ > best, Eliot > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 24, 2016

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Stephan Eggermont

On 24-01-16 21:20, Eliot Miranda wrote: > Hi Vincent, > > I'll take a look early this week. There's clearly a bug; the Spur > GC is /not/ collecting those dictionaries :-( (thanks Stephan!). I'm afraid the dictionaries are part of the model and should not be garbage collected. They do make things slow though, so we need a better model. Garbage collection cycle takes a few seconds now on my 4 GHz 4790K 32GB. Stephan

Jan. 24, 2016

Re: [Pharo-dev] [Moose-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Eliot Miranda

On Sun, Jan 24, 2016 at 12:42 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Eliot, > > I created a package to easily reproduce the problem: > https://dl.dropboxusercontent.com/u/18323746/Tmp/moose-6-for-GC-bug.zip > > In there you will get: > - an image, > - the MSE file to be loaded, and > - a Playground script that loads that file. > That sounds perfect. On my Mac, this takes some 3 minutes, while before it took about 1 minute. > What's the system info on your Mac? Mine is "*Version* 10.9.5 *Processor* 2.2GHz Intel Core i7 *Memory* 16Gb 1333 MHz DDR3" > Let me know if you need anything else. > > Cheers, > Doru > > > > > On Jan 24, 2016, at 9:33 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > Hi Doru, > > > > On Sun, Jan 24, 2016 at 12:26 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > Hi Eliot, > > > > Thanks for looking at this. > > > > Please let us know what support you need, or what kind of experiments we > can do on our side. > > > > What I want most of all is a test case that I can run on Mac. I'm > assuming that I can just copy the job that Vincent mentioned in his email > and use that as a test case. Do you see any issues with that? If so, how > do I get a really bug MOOSE test case to run on Mac? > > > > > > Cheers, > > Doru > > > > > > > On Jan 24, 2016, at 9:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > Hi Vincent, > > > > > > I'll take a look early this week. There's clearly a bug; the Spur > > > GC is /not/ collecting those dictionaries :-( (thanks Stephan!). > > > Assuming the bug is fixed times should come down (see below). It may > > > be that the bug in Slang that I introduced in December has broken > > > things because I don't see these symptoms in my daily work (but I use > > > the most up-to-date VM version possible ;-) ). But I'm not in denial > > > and look forward to using MOOSE as a good stress case. > > > > > > I do want to say that the GC is not complete. Right now we have a > > > scavenger that works well, and a global GC that has a slow compaction > > > algorithm, and hence there are significant pauses. For example here's > > > what I see as typical in using SPur for VMMaker work: > > > > > > memory 160,432,128 bytes > > > old 153,658,624 bytes (95.8%) > > > young 4,838,224 bytes (3%) > > > used 127,009,928 bytes (79.2%) > > > free 28,126,456 bytes (17.5%) > > > GCs 7,265 (?? ms between GCs) > > > full 36 totalling 13,229 ms (0% uptime), avg 367.5 ms > > > incr 7,229 totalling 6,546 ms (0% uptime), avg 0.9 ms > > > tenures 3,589,063 (avg 0 GCs/tenure) > > > > > > (There's no uptime in the above stats because we're still > > > transitioning Squeak to the 64-bit clock and there are consequently > > > bugs in computing uptime). > > > > > > The plan is to add an incremental global GC so this work is broken up > > > into much smaller pieces. I don't want to see 700ms pauses in global > > > GC; one can't do game animation with that. So an incremental > > > mark-sweep is needed. There are two nice papers we're considering, > > > one from Lua and one for a truly concurrent collector. But time is > > > pressing, so if anyone out there knows GC and is interested in helping > > > this is a nicely self-contained project for which we'd love to have > > > volunteers. > > > > > > _,,,^..^,,,_ (phone) > > > > > >> On Jan 24, 2016, at 3:43 AM, Vincent BLONDEAU < > vincent.blondeau(a)polytech-lille.net> wrote: > > >> > > >> Hi, > > >> > > >> I made the benchmarks with the files you provided. I have more or > less the > > >> same magnitude: > > >> Version 504: 0:00:01:09.021 > > >> Version 1175: 0:00:02:37.507 > > >> > > >> However, by launching it in the time profiler (MooseModel new > > >> importFromMSEStream: (StandardFileStream readOnlyFileNamed: > > >> 'd:/ArgoUML-0-34.mse')), it takes > > >> 504: 1 min 55 > > >> 1175: 4 min 25 > > >> Well there is a delta... > > >> > > >> After investigation, the standard process has almost the same > duration (120 > > >> secs for prespur and 140 secs for spur). > > >> But, there is a large difference in GC time: > > >> > > >> 504: not spur > > >> **Memory** > > >> old +144,822,000 bytes > > >> young -8,293,660 bytes > > >> used +136,528,340 bytes > > >> free -104,186,788 bytes > > >> > > >> **GCs** > > >> full 1 totalling 965ms (1.0% uptime), avg 965.0ms > > >> incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms > > >> tenures 2,497 (avg 1 GCs/tenure) > > >> root table 0 overflows > > >> > > >> 1175: spur > > >> **Memory** > > >> old +0 bytes > > >> young +340,048 bytes > > >> used +340,048 bytes > > >> free -340,048 bytes > > >> **GCs** > > >> full 7 totalling 145,003ms (66.0% uptime), avg > > >> 20715.0ms > > >> incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms > > >> tenures 7,146,505 (avg 0 GCs/tenure) > > >> root table 0 overflows > > >> > > >> Total GC time > > >> 504: 43 secs > > >> 1175: 176 secs > > >> > > >> See the performance reports attached. > > >> > > >> I let VM people take care of the issue ;) > > >> > > >> Cheers, > > >> Vincent > > >> > > >> -----Original Message----- > > >> From: moose-dev-bounces(a)list.inf.unibe.ch > > >> [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba > > >> Sent: dimanche 24 janvier 2016 09:08 > > >> To: Moose-related development > > >> Subject: [Moose-dev] Re: mse loading looks slower :( > > >> > > >> Hi, > > >> > > >> I am talking about the difference between Moose 6 images: > > >> - October 7: > > >> https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip > > >> > > >> - yesterday: > > >> https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip > > >> > > >> Multiple things did change, but not in Moose. In the end, I would > like to > > >> understand where the slowness comes. Maybe it comes from Spur itself, > but > > >> maybe it comes from somewhere else. > > >> > > >> Cheers, > > >> Doru > > >> > > >> > > >> > > >>>> On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> > > >>> wrote: > > >>> > > >>> Doru...just to be sure it is not a Pharo (image change), when you > said > > >> before and after Spur, do you mean a Pharo 5.0 exactly (just before > Spur) > > >> and a Pharo JUST after it? Otherwise, the slowness may come from the > > >> difference between the 2 Pharos you are running. > > >>> > > >>> Cheers, > > >>> > > >>> On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > >>> Hi, > > >>> > > >>> I am doing some performance testing of Moose with the Spur VM on Mac. > > >>> > > >>> I tried to load an MSE file with ArgoUML 0.34 and on my machine it > loads > > >> twice as slow with Spur than before: > > >>> - PreSpur: 0:00:01:07.272 > > >>> - Spur: 0:00:02:10.508 > > >>> > > >>> Here is the reference file: > > >>> > https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip > > >>> > > >>> And here is the script: > > >>> [ > > >>> MooseModel new > > >>> importFromMSEStream: (StandardFileStream > > >> readOnlyFileNamed: > > >>> (FileSystem workingDirectory / 'src' / > > >> 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName). > > >>> ] timeToRun > > >>> > > >>> Do you get the same? > > >>> > > >>> Cheers, > > >>> Doru > > >>> > > >>> > > >>> -- > > >>> www.tudorgirba.com > > >>> www.feenk.com > > >>> > > >>> "Problem solving should be focused on describing the problem in a way > > >>> that makes the solution obvious." > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Moose-dev mailing list > > >>> Moose-dev(a)list.inf.unibe.ch > > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > > >>> > > >>> > > >>> > > >>> -- > > >>> Mariano > > >>> http://marianopeck.wordpress.com > > >>> _______________________________________________ > > >>> Moose-dev mailing list > > >>> Moose-dev(a)list.inf.unibe.ch > > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > > >> > > >> -- > > >> www.tudorgirba.com > > >> www.feenk.com > > >> > > >> "What is more important: To be happy, or to make happy?" > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> Moose-dev(a)list.inf.unibe.ch > > >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > >> <report504.txt> > > >> <report1175.txt> > > > > > > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > -- _,,,^..^,,,_ best, Eliot

Jan. 24, 2016

Re: [Pharo-dev] Why pharo is going over squeaksource when saving code?

by stepharo

I know. What I meant is why do we have still all the repositories hanging around. They slow us down. Stef Le 9/1/16 14:42, Thierry Goubier a Ã©crit : > > > Le 9 janv. 2016 2:06 PM, "Dimitris Chloupis" <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> a Ã©crit : > > > > why it has to check for version conflicts ? once I tell pharo to > install a package thats what I want it to do. Is this practice really > necessary ? > > This is because Monticello needs to check all repositories to choose a > version number higher by one to all version numbers of that package in > all repositories. > > Of course, this could fail if you don't check all mc repositories in > the whole world... > > Of course, this has no meaning for gitfiletree repositories... > > Thierry > > > On Sat, Jan 9, 2016 at 2:58 PM Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > >> > >> it is a combination of 2 things: the repo must 1st be defined and > used by a package, then there is this odd behaviour of checking all > repos for version conflicts. > >> > >> so it depends on what you have loaded. > >> > >> > On 09 Jan 2016, at 12:34, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > >> > > >> > eeeehhh that was happening forever at least the last 2 years I am > around. How come you guys just noticed ? > >> > > >> > On Sat, Jan 9, 2016 at 1:01 PM Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > >> > I saw that too, I choked in my coffee ;-) > >> > > >> > > On 09 Jan 2016, at 10:07, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > >> > > > >> > > may be I'm dreaming this morning but when I saved code in the > inbox I saw a query to www.squeaksource.com <http://www.squeaksource.com>? > >> > > > >> > > Stef > >> > > > >> > > >> > > >> > >> >

Jan. 24, 2016

Re: [Pharo-dev] Morphic Migrations gotchas, was Re: Better class comment version2

by stepharo

> I wonder whether it would be worth reversing this change, to > remove an unnecessary incompatibility with other dialects. > > But maybe there is no development activity outside of Pharo, that > would justify making any effort to maintain compatibility. I do > not know. > > Practicality beats purity, if cleaning up existing APIs means > cutting out Pharo from a wider ecosystem, and introducing painful > bitrot, it might not be worth the cost. > > > Hum. > > That change induced a lot of pain because touching Rectangle is very > invasive (tend to crash the GUI), but I can't avoid thinking that > places creating those strange rectangles were in fact bugs. They were bugs. This API is plain crap. It produces intermediate objects for nothing. Now we have margin. > > For LayoutFrame, a simple refactoring when importing Morphic code > would do the trick. > > In practice, a significant amount of code in Pharo 5 still creates > wrong rectangles. Less and less. We spent a lot of time chasing them. We used the trick of nicolas to spot them based on exception. and I would be curious to see if some degenerated rectangles are left. Then it is important to clean it because we end up having from clipping and the code just worked because primitives werer robust. > A specific package even added an API to Rectangle to be able to do so. Bad idea. > > Thierry > > > >> On 11 Jan 2016, at 22:25, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com >> <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >> >> And it probably won't be integrated in Squeak, because it's not >> worth the pain. >> >> The change was conducted without analyzing all the impacts, >> because it was probably not possible to analyze the huge code base. >> (though it would have been possible to instrument code and >> collect the sender stacks producing degenerated rectangles) >> >> The only motto was to make code more "pure". >> Generally, I tend to be wary... >> >> On the other hand, storing the offsets in a rectangle just >> because there are 4 edges is sort of hackish usage, so while at >> cleaning... >> >> 2016-01-11 9:42 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl >> <mailto:stephan@stack.nl>>: >> >> On 10-01-16 23:16, Thierry Goubier wrote: >> >> Hi David, >> >> this is the bug with LayoutFrame>>#fractions:offsets: we >> were talking >> about relative to that class comment. >> >> In Pharo, Rectangles are constrained to have the smallest >> vertical value >> as the top, smallest horizontal value as the left, >> largest vertical >> value as bottom and largest horizontal value as right. >> >> >> Indeed. And there is no Morphic documentation at all that is >> aware of that, as nearly all of it was written before we >> changed the behavior of Rectangle in Pharo, and it is a >> change that is not done in Squeak. The result is that nearly >> no old Morphic code will run unmodified in Pharo. >> >> I would like to collect a list of these gotchas, preferably >> with solutions, to make it easier for people to >> update/migrate old morphic code. Post them here, or mail them >> to me. >> >> Stephan >> >> >> >> >> > >

Jan. 24, 2016

Re: [Pharo-dev] [Moose-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Tudor Girba

Hi Eliot, I created a package to easily reproduce the problem: https://dl.dropboxusercontent.com/u/18323746/Tmp/moose-6-for-GC-bug.zip In there you will get: - an image, - the MSE file to be loaded, and - a Playground script that loads that file. On my Mac, this takes some 3 minutes, while before it took about 1 minute. Let me know if you need anything else. Cheers, Doru > On Jan 24, 2016, at 9:33 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Doru, > > On Sun, Jan 24, 2016 at 12:26 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Eliot, > > Thanks for looking at this. > > Please let us know what support you need, or what kind of experiments we can do on our side. > > What I want most of all is a test case that I can run on Mac. I'm assuming that I can just copy the job that Vincent mentioned in his email and use that as a test case. Do you see any issues with that? If so, how do I get a really bug MOOSE test case to run on Mac? > > > Cheers, > Doru > > > > On Jan 24, 2016, at 9:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Vincent, > > > > I'll take a look early this week. There's clearly a bug; the Spur > > GC is /not/ collecting those dictionaries :-( (thanks Stephan!). > > Assuming the bug is fixed times should come down (see below). It may > > be that the bug in Slang that I introduced in December has broken > > things because I don't see these symptoms in my daily work (but I use > > the most up-to-date VM version possible ;-) ). But I'm not in denial > > and look forward to using MOOSE as a good stress case. > > > > I do want to say that the GC is not complete. Right now we have a > > scavenger that works well, and a global GC that has a slow compaction > > algorithm, and hence there are significant pauses. For example here's > > what I see as typical in using SPur for VMMaker work: > > > > memory 160,432,128 bytes > > old 153,658,624 bytes (95.8%) > > young 4,838,224 bytes (3%) > > used 127,009,928 bytes (79.2%) > > free 28,126,456 bytes (17.5%) > > GCs 7,265 (?? ms between GCs) > > full 36 totalling 13,229 ms (0% uptime), avg 367.5 ms > > incr 7,229 totalling 6,546 ms (0% uptime), avg 0.9 ms > > tenures 3,589,063 (avg 0 GCs/tenure) > > > > (There's no uptime in the above stats because we're still > > transitioning Squeak to the 64-bit clock and there are consequently > > bugs in computing uptime). > > > > The plan is to add an incremental global GC so this work is broken up > > into much smaller pieces. I don't want to see 700ms pauses in global > > GC; one can't do game animation with that. So an incremental > > mark-sweep is needed. There are two nice papers we're considering, > > one from Lua and one for a truly concurrent collector. But time is > > pressing, so if anyone out there knows GC and is interested in helping > > this is a nicely self-contained project for which we'd love to have > > volunteers. > > > > _,,,^..^,,,_ (phone) > > > >> On Jan 24, 2016, at 3:43 AM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net> wrote: > >> > >> Hi, > >> > >> I made the benchmarks with the files you provided. I have more or less the > >> same magnitude: > >> Version 504: 0:00:01:09.021 > >> Version 1175: 0:00:02:37.507 > >> > >> However, by launching it in the time profiler (MooseModel new > >> importFromMSEStream: (StandardFileStream readOnlyFileNamed: > >> 'd:/ArgoUML-0-34.mse')), it takes > >> 504: 1 min 55 > >> 1175: 4 min 25 > >> Well there is a delta... > >> > >> After investigation, the standard process has almost the same duration (120 > >> secs for prespur and 140 secs for spur). > >> But, there is a large difference in GC time: > >> > >> 504: not spur > >> **Memory** > >> old +144,822,000 bytes > >> young -8,293,660 bytes > >> used +136,528,340 bytes > >> free -104,186,788 bytes > >> > >> **GCs** > >> full 1 totalling 965ms (1.0% uptime), avg 965.0ms > >> incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms > >> tenures 2,497 (avg 1 GCs/tenure) > >> root table 0 overflows > >> > >> 1175: spur > >> **Memory** > >> old +0 bytes > >> young +340,048 bytes > >> used +340,048 bytes > >> free -340,048 bytes > >> **GCs** > >> full 7 totalling 145,003ms (66.0% uptime), avg > >> 20715.0ms > >> incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms > >> tenures 7,146,505 (avg 0 GCs/tenure) > >> root table 0 overflows > >> > >> Total GC time > >> 504: 43 secs > >> 1175: 176 secs > >> > >> See the performance reports attached. > >> > >> I let VM people take care of the issue ;) > >> > >> Cheers, > >> Vincent > >> > >> -----Original Message----- > >> From: moose-dev-bounces(a)list.inf.unibe.ch > >> [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba > >> Sent: dimanche 24 janvier 2016 09:08 > >> To: Moose-related development > >> Subject: [Moose-dev] Re: mse loading looks slower :( > >> > >> Hi, > >> > >> I am talking about the difference between Moose 6 images: > >> - October 7: > >> https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip > >> > >> - yesterday: > >> https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip > >> > >> Multiple things did change, but not in Moose. In the end, I would like to > >> understand where the slowness comes. Maybe it comes from Spur itself, but > >> maybe it comes from somewhere else. > >> > >> Cheers, > >> Doru > >> > >> > >> > >>>> On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> > >>> wrote: > >>> > >>> Doru...just to be sure it is not a Pharo (image change), when you said > >> before and after Spur, do you mean a Pharo 5.0 exactly (just before Spur) > >> and a Pharo JUST after it? Otherwise, the slowness may come from the > >> difference between the 2 Pharos you are running. > >>> > >>> Cheers, > >>> > >>> On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>> Hi, > >>> > >>> I am doing some performance testing of Moose with the Spur VM on Mac. > >>> > >>> I tried to load an MSE file with ArgoUML 0.34 and on my machine it loads > >> twice as slow with Spur than before: > >>> - PreSpur: 0:00:01:07.272 > >>> - Spur: 0:00:02:10.508 > >>> > >>> Here is the reference file: > >>> https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip > >>> > >>> And here is the script: > >>> [ > >>> MooseModel new > >>> importFromMSEStream: (StandardFileStream > >> readOnlyFileNamed: > >>> (FileSystem workingDirectory / 'src' / > >> 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName). > >>> ] timeToRun > >>> > >>> Do you get the same? > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Problem solving should be focused on describing the problem in a way > >>> that makes the solution obvious." > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)list.inf.unibe.ch > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >>> > >>> > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)list.inf.unibe.ch > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "What is more important: To be happy, or to make happy?" > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev(a)list.inf.unibe.ch > >> https://www.list.inf.unibe.ch/listinfo/moose-dev > >> <report504.txt> > >> <report1175.txt> > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 24, 2016

Re: [Pharo-dev] Color yzw

by stepharo

I did not forget just running against time and busy Le 16/1/16 22:17, Nicolai Hess a Ã©crit : > > see attached changesets. > > load with: > > DangerousClassNotifier disableDuring:[ > String subclass: #Symbol > instanceVariableNames: '' > classVariableNames: 'NewSymbols OneCharacterSymbols SymbolTable > SelectorTable' > package: 'Collections-Strings' > ]. > > DangerousClassNotifier disableDuring:[ > 'selectortable.1.cs' > asFileReference fileIn. > ]. > Symbol initSelectorTable. > 'use_selector_table.cs' asFileReference fileIn. > > what do you think ? > > (selectortable.cs defines SelectorTable and some methods in Symbol and > String) > (use_selector_table adds selectors as internedSelectorSymbol if this > selector is set as a selector on CompiledMethod > and uses findInternedSelector .... in RubStyler visitMessageNode)

Jan. 24, 2016

Re: [Pharo-dev] Moving large classes in Pharo5 between packages makes me sad

by stepharo

Tell us more because right now we cannot help. What is the problem? How to reproduce it? Setf Le 24/1/16 20:08, Aliaksei Syrel a Ã©crit : > Inline image 1 > > Cheers, > Alex >

Jan. 24, 2016

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Eliot Miranda

Hi Doru, On Sun, Jan 24, 2016 at 12:26 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Eliot, > > Thanks for looking at this. > > Please let us know what support you need, or what kind of experiments we > can do on our side. > What I want most of all is a test case that I can run on Mac. I'm assuming that I can just copy the job that Vincent mentioned in his email and use that as a test case. Do you see any issues with that? If so, how do I get a really bug MOOSE test case to run on Mac? > > Cheers, > Doru > > > > On Jan 24, 2016, at 9:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > Hi Vincent, > > > > I'll take a look early this week. There's clearly a bug; the Spur > > GC is /not/ collecting those dictionaries :-( (thanks Stephan!). > > Assuming the bug is fixed times should come down (see below). It may > > be that the bug in Slang that I introduced in December has broken > > things because I don't see these symptoms in my daily work (but I use > > the most up-to-date VM version possible ;-) ). But I'm not in denial > > and look forward to using MOOSE as a good stress case. > > > > I do want to say that the GC is not complete. Right now we have a > > scavenger that works well, and a global GC that has a slow compaction > > algorithm, and hence there are significant pauses. For example here's > > what I see as typical in using SPur for VMMaker work: > > > > memory 160,432,128 bytes > > old 153,658,624 bytes (95.8%) > > young 4,838,224 bytes (3%) > > used 127,009,928 bytes (79.2%) > > free 28,126,456 bytes (17.5%) > > GCs 7,265 (?? ms between GCs) > > full 36 totalling 13,229 ms (0% uptime), avg 367.5 ms > > incr 7,229 totalling 6,546 ms (0% uptime), avg 0.9 ms > > tenures 3,589,063 (avg 0 GCs/tenure) > > > > (There's no uptime in the above stats because we're still > > transitioning Squeak to the 64-bit clock and there are consequently > > bugs in computing uptime). > > > > The plan is to add an incremental global GC so this work is broken up > > into much smaller pieces. I don't want to see 700ms pauses in global > > GC; one can't do game animation with that. So an incremental > > mark-sweep is needed. There are two nice papers we're considering, > > one from Lua and one for a truly concurrent collector. But time is > > pressing, so if anyone out there knows GC and is interested in helping > > this is a nicely self-contained project for which we'd love to have > > volunteers. > > > > _,,,^..^,,,_ (phone) > > > >> On Jan 24, 2016, at 3:43 AM, Vincent BLONDEAU < > vincent.blondeau(a)polytech-lille.net> wrote: > >> > >> Hi, > >> > >> I made the benchmarks with the files you provided. I have more or less > the > >> same magnitude: > >> Version 504: 0:00:01:09.021 > >> Version 1175: 0:00:02:37.507 > >> > >> However, by launching it in the time profiler (MooseModel new > >> importFromMSEStream: (StandardFileStream readOnlyFileNamed: > >> 'd:/ArgoUML-0-34.mse')), it takes > >> 504: 1 min 55 > >> 1175: 4 min 25 > >> Well there is a delta... > >> > >> After investigation, the standard process has almost the same duration > (120 > >> secs for prespur and 140 secs for spur). > >> But, there is a large difference in GC time: > >> > >> 504: not spur > >> **Memory** > >> old +144,822,000 bytes > >> young -8,293,660 bytes > >> used +136,528,340 bytes > >> free -104,186,788 bytes > >> > >> **GCs** > >> full 1 totalling 965ms (1.0% uptime), avg 965.0ms > >> incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms > >> tenures 2,497 (avg 1 GCs/tenure) > >> root table 0 overflows > >> > >> 1175: spur > >> **Memory** > >> old +0 bytes > >> young +340,048 bytes > >> used +340,048 bytes > >> free -340,048 bytes > >> **GCs** > >> full 7 totalling 145,003ms (66.0% uptime), avg > >> 20715.0ms > >> incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms > >> tenures 7,146,505 (avg 0 GCs/tenure) > >> root table 0 overflows > >> > >> Total GC time > >> 504: 43 secs > >> 1175: 176 secs > >> > >> See the performance reports attached. > >> > >> I let VM people take care of the issue ;) > >> > >> Cheers, > >> Vincent > >> > >> -----Original Message----- > >> From: moose-dev-bounces(a)list.inf.unibe.ch > >> [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba > >> Sent: dimanche 24 janvier 2016 09:08 > >> To: Moose-related development > >> Subject: [Moose-dev] Re: mse loading looks slower :( > >> > >> Hi, > >> > >> I am talking about the difference between Moose 6 images: > >> - October 7: > >> https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip > >> > >> - yesterday: > >> https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip > >> > >> Multiple things did change, but not in Moose. In the end, I would like > to > >> understand where the slowness comes. Maybe it comes from Spur itself, > but > >> maybe it comes from somewhere else. > >> > >> Cheers, > >> Doru > >> > >> > >> > >>>> On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> > >>> wrote: > >>> > >>> Doru...just to be sure it is not a Pharo (image change), when you said > >> before and after Spur, do you mean a Pharo 5.0 exactly (just before > Spur) > >> and a Pharo JUST after it? Otherwise, the slowness may come from the > >> difference between the 2 Pharos you are running. > >>> > >>> Cheers, > >>> > >>> On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>> Hi, > >>> > >>> I am doing some performance testing of Moose with the Spur VM on Mac. > >>> > >>> I tried to load an MSE file with ArgoUML 0.34 and on my machine it > loads > >> twice as slow with Spur than before: > >>> - PreSpur: 0:00:01:07.272 > >>> - Spur: 0:00:02:10.508 > >>> > >>> Here is the reference file: > >>> https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip > >>> > >>> And here is the script: > >>> [ > >>> MooseModel new > >>> importFromMSEStream: (StandardFileStream > >> readOnlyFileNamed: > >>> (FileSystem workingDirectory / 'src' / > >> 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName). > >>> ] timeToRun > >>> > >>> Do you get the same? > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Problem solving should be focused on describing the problem in a way > >>> that makes the solution obvious." > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)list.inf.unibe.ch > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >>> > >>> > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)list.inf.unibe.ch > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "What is more important: To be happy, or to make happy?" > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev(a)list.inf.unibe.ch > >> https://www.list.inf.unibe.ch/listinfo/moose-dev > >> <report504.txt> > >> <report1175.txt> > > > > > -- _,,,^..^,,,_ best, Eliot

Jan. 24, 2016

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Tudor Girba

Hi Eliot, Thanks for looking at this. Please let us know what support you need, or what kind of experiments we can do on our side. Cheers, Doru > On Jan 24, 2016, at 9:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Vincent, > > I'll take a look early this week. There's clearly a bug; the Spur > GC is /not/ collecting those dictionaries :-( (thanks Stephan!). > Assuming the bug is fixed times should come down (see below). It may > be that the bug in Slang that I introduced in December has broken > things because I don't see these symptoms in my daily work (but I use > the most up-to-date VM version possible ;-) ). But I'm not in denial > and look forward to using MOOSE as a good stress case. > > I do want to say that the GC is not complete. Right now we have a > scavenger that works well, and a global GC that has a slow compaction > algorithm, and hence there are significant pauses. For example here's > what I see as typical in using SPur for VMMaker work: > > memory 160,432,128 bytes > old 153,658,624 bytes (95.8%) > young 4,838,224 bytes (3%) > used 127,009,928 bytes (79.2%) > free 28,126,456 bytes (17.5%) > GCs 7,265 (?? ms between GCs) > full 36 totalling 13,229 ms (0% uptime), avg 367.5 ms > incr 7,229 totalling 6,546 ms (0% uptime), avg 0.9 ms > tenures 3,589,063 (avg 0 GCs/tenure) > > (There's no uptime in the above stats because we're still > transitioning Squeak to the 64-bit clock and there are consequently > bugs in computing uptime). > > The plan is to add an incremental global GC so this work is broken up > into much smaller pieces. I don't want to see 700ms pauses in global > GC; one can't do game animation with that. So an incremental > mark-sweep is needed. There are two nice papers we're considering, > one from Lua and one for a truly concurrent collector. But time is > pressing, so if anyone out there knows GC and is interested in helping > this is a nicely self-contained project for which we'd love to have > volunteers. > > _,,,^..^,,,_ (phone) > >> On Jan 24, 2016, at 3:43 AM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net> wrote: >> >> Hi, >> >> I made the benchmarks with the files you provided. I have more or less the >> same magnitude: >> Version 504: 0:00:01:09.021 >> Version 1175: 0:00:02:37.507 >> >> However, by launching it in the time profiler (MooseModel new >> importFromMSEStream: (StandardFileStream readOnlyFileNamed: >> 'd:/ArgoUML-0-34.mse')), it takes >> 504: 1 min 55 >> 1175: 4 min 25 >> Well there is a delta... >> >> After investigation, the standard process has almost the same duration (120 >> secs for prespur and 140 secs for spur). >> But, there is a large difference in GC time: >> >> 504: not spur >> **Memory** >> old +144,822,000 bytes >> young -8,293,660 bytes >> used +136,528,340 bytes >> free -104,186,788 bytes >> >> **GCs** >> full 1 totalling 965ms (1.0% uptime), avg 965.0ms >> incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms >> tenures 2,497 (avg 1 GCs/tenure) >> root table 0 overflows >> >> 1175: spur >> **Memory** >> old +0 bytes >> young +340,048 bytes >> used +340,048 bytes >> free -340,048 bytes >> **GCs** >> full 7 totalling 145,003ms (66.0% uptime), avg >> 20715.0ms >> incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms >> tenures 7,146,505 (avg 0 GCs/tenure) >> root table 0 overflows >> >> Total GC time >> 504: 43 secs >> 1175: 176 secs >> >> See the performance reports attached. >> >> I let VM people take care of the issue ;) >> >> Cheers, >> Vincent >> >> -----Original Message----- >> From: moose-dev-bounces(a)list.inf.unibe.ch >> [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba >> Sent: dimanche 24 janvier 2016 09:08 >> To: Moose-related development >> Subject: [Moose-dev] Re: mse loading looks slower :( >> >> Hi, >> >> I am talking about the difference between Moose 6 images: >> - October 7: >> https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip >> >> - yesterday: >> https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip >> >> Multiple things did change, but not in Moose. In the end, I would like to >> understand where the slowness comes. Maybe it comes from Spur itself, but >> maybe it comes from somewhere else. >> >> Cheers, >> Doru >> >> >> >>>> On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>> Doru...just to be sure it is not a Pharo (image change), when you said >> before and after Spur, do you mean a Pharo 5.0 exactly (just before Spur) >> and a Pharo JUST after it? Otherwise, the slowness may come from the >> difference between the 2 Pharos you are running. >>> >>> Cheers, >>> >>> On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hi, >>> >>> I am doing some performance testing of Moose with the Spur VM on Mac. >>> >>> I tried to load an MSE file with ArgoUML 0.34 and on my machine it loads >> twice as slow with Spur than before: >>> - PreSpur: 0:00:01:07.272 >>> - Spur: 0:00:02:10.508 >>> >>> Here is the reference file: >>> https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip >>> >>> And here is the script: >>> [ >>> MooseModel new >>> importFromMSEStream: (StandardFileStream >> readOnlyFileNamed: >>> (FileSystem workingDirectory / 'src' / >> 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName). >>> ] timeToRun >>> >>> Do you get the same? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Problem solving should be focused on describing the problem in a way >>> that makes the solution obvious." >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "What is more important: To be happy, or to make happy?" >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> <report504.txt> >> <report1175.txt> >

Jan. 24, 2016