March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SetTest>>#testAllSetsAreHealthy error

by Max Leske

> On 17 Mar 2015, at 10:40, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > I'm getting weird SetTest>>#testAllSetsAreHealthy error > https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/27236//artifact/val… <https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/27236//artifact/val…> > > My changes are completely unrelated to Sets, also when i tried the test, it passes on my machine. > > Any ideas? > > Thanks, > Peter Iâve seen that on my machine. Itâs a single set WeakSet containing only MCMethodDefinition objects. I didnât see where it was referenced from though.

March 17, 2015

trying a hot update un smalltalkhub

by Esteban Lorenzano

Hi, Iâm trying to use the power of pharo and do a hot update in smalltalkhub. Of course, it can failâ¦ in that case I will need to turn it off and do it in the old wayâ¦ :) Esteban

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by phil＠highoctane.be

Yeah, put the file on a dropbox somewhere and share the link. I'd like to see why this is "slow". I am reading tons of data from a MongoDb and it is superfast. Phil On Tue, Mar 17, 2015 at 10:24 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Can you post/share your file (jfreechart-0_9_0.mse) somewhere so we can run the same test ? > > Also, in your Java code I do not see a loop doing the benchmark 10 times ... > >> On 17 Mar 2015, at 10:19, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: >> >> >> Eliot, Sven, Stephan, >> >> thank you for your answers. >> >> As you noticed I am not an expert in profiling :-) >> >> it seems now I might have goofed up and the time taken by pharo in my initial program (compared to java) is due to some other extra compilation I was doing. >> >> So the "macro benchmark" might be wrong >> >> Still the "micro benchmark" still holds >> I tested the code proposed by Elliot and the result is .... >> >> --- >> [1 to: 10 do: [:j || a length | >> length:=0. >> a := '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' asFileReference readStream contents. >> 1 to: a size do: [ :i| | c | c:= a at: i. length:= length+1]]] timeToRunWithoutGC >> --- >> >> 12.723 sec. >> >> [reminder] For java it is: 1.482 sec. >> >> so it is still a factor 8 or 9 >> it seems a lot for such a simple thing, no? >> (or maybe not, I don't know) >> >> nicolas >> >> On 16/03/2015 09:49, Nicolas Anquetil wrote: >>> I have been doing some file intensive activities and found my program to be VERY slow (see at the end). >>> Just to be sure I ran them in Java and found it was much faster >>> >>> So I did a small test: >>> --- >>> [10 timesRepeat: [i := 0. >>> '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' asFileReference readStream contents do: [ :c | i:= i+1]. >>> ] ] timeToRunWithoutGC. >>> --- >>> >>> result = 12.932 sec >>> >>> similar thing (as far as I can tell) 10 times in java: 1.482 sec. >>> --- >>> public static void main(String[] args) { >>> int length =0; >>> try { >>> String filename = "/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse"; >>> String content = new String(Files.readAllBytes(Paths.get(filename)), "UTF8"); >>> for (int i=0; i < content.length(); i++) { >>> content.charAt(i); >>> length = length+1; >>> } >>> } catch (IOException e) { >>> e.printStackTrace(); >>> } >>> System.out.println(length); >>> } >>> --- >>> >>> Because my program is MUCH slower (see at the end) in Smalltalk than in Java, I did another experiment: >>> >>> --- >>> [1 to: 10 do: [:i| 1 to: 100000000 do: [:j | String new] ] ] timeToRunWithoutGC. >>> --- >>> >>> result = 33.063 sec >>> >>> and in java: 4.382 sec. >>> ---[10 runs of] >>> public static void main(String[] args) { >>> for (int i=0; i < 100000000; i++) { >>> new String(); >>> } >>> } >>> --- >>> >>> >>> >>> >>> Concretly, my need was: >>> Take 2600 methods in a Moose model, take their source code (therefore reading files), for methods longer than 100 lines (there are 29 of them), go through there code to find the blocks (matching {}). >>> In smalltalk it ran > 12hours and I had processed 5 methods of the 29 long ones >>> I reimplemented in Java (basically, just changing from pharo to java syntax) and it took 1 minutes to compute everything ... >>> >>> :-( >>> >>> On the good side, it was much easier to program it in smalltalk (about half a day to think about the algorithm, experiement, implement, test) than in Java (another 1/2 day, just to recode the algorithm that already worked). >>> >>> nicolas >>> >> >> > >

March 17, 2015

SetTest>>#testAllSetsAreHealthy error

by Peter UhnÃ¡k

Hi, I'm getting weird SetTest>>#testAllSetsAreHealthy error https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/27236//artifact/val… My changes are completely unrelated to Sets, also when i tried the test, it passes on my machine. Any ideas? Thanks, Peter

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Sven Van Caekenberghe

Can you post/share your file (jfreechart-0_9_0.mse) somewhere so we can run the same test ? Also, in your Java code I do not see a loop doing the benchmark 10 times ... > On 17 Mar 2015, at 10:19, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > > Eliot, Sven, Stephan, > > thank you for your answers. > > As you noticed I am not an expert in profiling :-) > > it seems now I might have goofed up and the time taken by pharo in my initial program (compared to java) is due to some other extra compilation I was doing. > > So the "macro benchmark" might be wrong > > Still the "micro benchmark" still holds > I tested the code proposed by Elliot and the result is .... > > --- > [1 to: 10 do: [:j || a length | > length:=0. > a := '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' asFileReference readStream contents. > 1 to: a size do: [ :i| | c | c:= a at: i. length:= length+1]]] timeToRunWithoutGC > --- > > 12.723 sec. > > [reminder] For java it is: 1.482 sec. > > so it is still a factor 8 or 9 > it seems a lot for such a simple thing, no? > (or maybe not, I don't know) > > nicolas > > On 16/03/2015 09:49, Nicolas Anquetil wrote: >> I have been doing some file intensive activities and found my program to be VERY slow (see at the end). >> Just to be sure I ran them in Java and found it was much faster >> >> So I did a small test: >> --- >> [10 timesRepeat: [i := 0. >> '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' asFileReference readStream contents do: [ :c | i:= i+1]. >> ] ] timeToRunWithoutGC. >> --- >> >> result = 12.932 sec >> >> similar thing (as far as I can tell) 10 times in java: 1.482 sec. >> --- >> public static void main(String[] args) { >> int length =0; >> try { >> String filename = "/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse"; >> String content = new String(Files.readAllBytes(Paths.get(filename)), "UTF8"); >> for (int i=0; i < content.length(); i++) { >> content.charAt(i); >> length = length+1; >> } >> } catch (IOException e) { >> e.printStackTrace(); >> } >> System.out.println(length); >> } >> --- >> >> Because my program is MUCH slower (see at the end) in Smalltalk than in Java, I did another experiment: >> >> --- >> [1 to: 10 do: [:i| 1 to: 100000000 do: [:j | String new] ] ] timeToRunWithoutGC. >> --- >> >> result = 33.063 sec >> >> and in java: 4.382 sec. >> ---[10 runs of] >> public static void main(String[] args) { >> for (int i=0; i < 100000000; i++) { >> new String(); >> } >> } >> --- >> >> >> >> >> Concretly, my need was: >> Take 2600 methods in a Moose model, take their source code (therefore reading files), for methods longer than 100 lines (there are 29 of them), go through there code to find the blocks (matching {}). >> In smalltalk it ran > 12hours and I had processed 5 methods of the 29 long ones >> I reimplemented in Java (basically, just changing from pharo to java syntax) and it took 1 minutes to compute everything ... >> >> :-( >> >> On the good side, it was much easier to program it in smalltalk (about half a day to think about the algorithm, experiement, implement, test) than in Java (another 1/2 day, just to recode the algorithm that already worked). >> >> nicolas >> > >

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Nicolas Anquetil

Eliot, Sven, Stephan, thank you for your answers. As you noticed I am not an expert in profiling :-) it seems now I might have goofed up and the time taken by pharo in my initial program (compared to java) is due to some other extra compilation I was doing. So the "macro benchmark" might be wrong Still the "micro benchmark" still holds I tested the code proposed by Elliot and the result is .... --- [1 to: 10 do: [:j || a length | length:=0. a := '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' asFileReference readStream contents. 1 to: a size do: [ :i| | c | c:= a at: i. length:= length+1]]] timeToRunWithoutGC --- 12.723 sec. [reminder] For java it is: 1.482 sec. so it is still a factor 8 or 9 it seems a lot for such a simple thing, no? (or maybe not, I don't know) nicolas On 16/03/2015 09:49, Nicolas Anquetil wrote: > I have been doing some file intensive activities and found my program > to be VERY slow (see at the end). > Just to be sure I ran them in Java and found it was much faster > > So I did a small test: > --- > [10 timesRepeat: [i := 0. > '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' > asFileReference readStream contents do: [ :c | i:= i+1]. > ] ] timeToRunWithoutGC. > --- > > result = 12.932 sec > > similar thing (as far as I can tell) 10 times in java: 1.482 sec. > --- > public static void main(String[] args) { > int length =0; > try { > String filename = > "/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse"; > String content = new > String(Files.readAllBytes(Paths.get(filename)), "UTF8"); > for (int i=0; i < content.length(); i++) { > content.charAt(i); > length = length+1; > } > } catch (IOException e) { > e.printStackTrace(); > } > System.out.println(length); > } > --- > > Because my program is MUCH slower (see at the end) in Smalltalk than > in Java, I did another experiment: > > --- > [1 to: 10 do: [:i| 1 to: 100000000 do: [:j | String new] ] ] > timeToRunWithoutGC. > --- > > result = 33.063 sec > > and in java: 4.382 sec. > ---[10 runs of] > public static void main(String[] args) { > for (int i=0; i < 100000000; i++) { > new String(); > } > } > --- > > > > > Concretly, my need was: > Take 2600 methods in a Moose model, take their source code (therefore > reading files), for methods longer than 100 lines (there are 29 of > them), go through there code to find the blocks (matching {}). > In smalltalk it ran > 12hours and I had processed 5 methods of the 29 > long ones > I reimplemented in Java (basically, just changing from pharo to java > syntax) and it took 1 minutes to compute everything ... > > :-( > > On the good side, it was much easier to program it in smalltalk (about > half a day to think about the algorithm, experiement, implement, test) > than in Java (another 1/2 day, just to recode the algorithm that > already worked). > > nicolas >

March 17, 2015

Re: [Pharo-dev] Jenkins build trigger

by Stephan Eggermont

On 11/03/15 14:55, Christophe Demarey wrote: > Here is the way to go: > > * go to your job configuration on Jenkins > o In the *build triggers* section, > + enable *Trigger builds remotely (e.g., from scripts)* and > choose an*authentication token*. > + disable [*URLTrigger] - Poll with a URL* > * go to smalltalkhub, on your project settings page > o Fill in the *commit hook url *field with > https://ci.inria.fr/pharo-contribution/buildByToken/build?job=*JOBNAME*&tok… > by replacing JOBNAME and TOKEN by the Jenkins job name and the > token chosen. I tried that with a new project XPath. Did I do something wrong/is there a delay? It hasn't start building yet. Stephan

March 17, 2015

[pharo-project/pharo-core] 35a636: 40561

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 35a636587698c185e2194a666beee0b95d3ce7b9 https://github.com/pharo-project/pharo-core/commit/35a636587698c185e2194a66… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-17 (Tue, 17 Mar 2015) Changed paths: M Morphic-Core.package/Morph.class/instance/drawing/boundingBoxOfSubmorphs.st A MorphicTests.package/MorphTest.class/instance/testing - geometry/testBoundingBoxOfSubmorphs.st M NativeBoost-Core.package/NBExternalEnumeration.class/class/class initialization/initialize.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script560.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script561.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40560.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40561.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40561 15126 NBExternalEnumeration needs to respect slots https://pharo.fogbugz.com/f/cases/15126 14873 Morph>>#boundingBoxOfSubmorphs is sometimes too large https://pharo.fogbugz.com/f/cases/14873 http://files.pharo.org/image/40/40561.zip

March 17, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40561 Home: https://github.com/pharo-project/pharo-core

March 17, 2015

Re: [Pharo-dev] [Pharo4] 203 issues tagged tagged for Pharo4

by Marcus Denker

Wow! Great! Now: 125 On Mon, Mar 16, 2015 at 7:10 PM, Ben Coman <btc(a)openinworld.com> wrote: > Pharo 4: 135 > > On Mon, Mar 16, 2015 at 9:08 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

March 17, 2015