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

Re: [Pharo-dev] [pharo-project/pharo-core] c2785a: 40562

by Thierry Goubier

2015-03-17 16:26 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 17 Mar 2015, at 16:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 17 Mar 2015, at 16:19, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > 2015-03-17 16:07 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > All class comments seem to have been modified ? >> > Was that intentional ? >> > >> >> I think that is an overside of the GIT commit: it commits the comment it >> gets, and this is the template when there is none. >> > > This also means that those classes appear as having been commented, even > if they weren't. > > > not really... they are still marked as "uncommented" in the image. > I really don't know why the export showed as commented, thought... I suppose > a bug in the exporter. > > > > bad implementation (no, interesting design decision): > > comment > "Answer the receiver's comment. (If missing, supply a template) " > | aString | > aString := self instanceSide organization classComment. > aString isEmpty ifFalse: [^ aString]. > ^self classCommentBlank > And Monticello taps directly into classComment, so that it can avoids that 'template fill' effect. Nautilus as well, Critics, ProfStef (Why?), Polymorph, Changes, Ring, etc... > > > I would return nil there and let the tools handle the template. > And clean everybody looking inside the organisation to avoid that effect. > > (ah, and that the comment is stored on the organisation is of course > strange too...) > Oh well... It has to be somewhere. Where would you put it? In the class itself? Thierry

March 17, 2015

Update Nautilus layout after setting plugin's height?

by Yuriy Tymchuk

Hi, Iâm playing with nautilus plugins, and sometimes I want to have a lot of space for my plugin, but there are also periods of time when I want to shrink unneeded space and use it for the rest of widgets. Iâve never worked with morphs, so can someone suggest me how to do it? Should I change the height of my plugin morph with #height: and how do I update Nautilus window? (if this is possible) Uko

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by phil＠highoctane.be

Ah, you beat me :-) Still, your implementation isn't loading the whole contents as the Java version does. The key issue is the conversion indeed. Phil On Tue, Mar 17, 2015 at 4:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 17 Mar 2015, at 15:45, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> I tried it myself, java seems to be 7 times faster on a 35 MB jfreechart.mse file I found on github. Moose 5.1 managed about >> 30 MB/s. >> >> UTF8 is rather suboptimal for source code. Nearly all of it is >> ASCII which can be processed a machine word at a time, instead of byte. There were earlier discussions about that >> http://forum.world.st/Fastest-utf-8-encoder-contest-td4634566.html >> >> Stephan > > Thanks for the pointer to the file (finally !). > > Using this file: https://raw.githubusercontent.com/mircealungu/experiments-polymorphism/mast… which is indeed 35Mb we can do better. > > Since > > (FileLocator desktop / 'jfreechart.mse') binaryReadStreamDo: [ :in | > in contents allSatisfy: [ :each | each < 127 ]. > > is true, we can skip decoding. > > For me, it is pretty fast now > > [ > | count | > count := 0. > (FileLocator desktop / 'jfreechart.mse') binaryReadStreamDo: [ :in | > in contents do: [ :each | count := count + 1 ] ]. > count > ] timeToRun. > > "0:00:00:00.637" > > Adding UTF8 decoding (implemented in Pharo) makes it 10x slower > > [ > | count | > count := 0. > (FileLocator desktop / 'jfreechart.mse') binaryReadStreamDo: [ :in | > in contents utf8Decoded do: [ :each | count := count + 1 ] ]. > count > ] timeToRun. "0:00:00:07.45" > > HTH, > > Sven > > >

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by phil＠highoctane.be

Ok, I've tried this out. First version ---------------- [ |length a| length := 0. 1 to: 10 do: [ :index | ('Loop {1}' format: { index }) logCr. a := (FileLocator imageDirectory / 'javacomp' / 'jfreechart-0_9_0.mse') readStream contents. (ReadStream on: a) do: [ :c | length := length + 1. ]. length asString logCr. ]] timeToRun 0:00:00:22.33 Takes a lot of time. Second version (streaming, less memory intensive) --------------------------------------------------------------------- [ |length c| length := 0. 1 to: 10 do: [ :index | ('Loop {1}' format: { index }) logCr. (FileLocator imageDirectory / 'javacomp' / 'jfreechart-0_9_0.mse') readStreamDo: [ :s | [ s atEnd ] whileFalse: [ c := s next. length := length + 1. ] ]. length asString logCr. ]] timeToRun 0:00:00:03.683 Already better. But profiling version 1 showed the issue. We dealing with a multibyte stream there. So, switching to a StandardFileStream gives Version 3 ------------- [ |length a| length := 0. 1 to: 10 do: [ :index | ('Loop {1}' format: { index }) logCr. a := (StandardFileStream fileNamed: (FileLocator imageDirectory / 'javacomp' / 'jfreechart-0_9_0.mse') pathString) readStream contents. a do: [ :c | length := length + 1. ]. length asString logCr. ]] timeToRun 0:00:00:03.18 I see that Java does Files.readAllBytes(Paths.get(filename)), "UTF8") readAllBytes sees suspect to me, even with UTF8. Looks like a standard file stream with no conversion. Pharo isn't so slow after all. HTH Phil On Tue, Mar 17, 2015 at 1:21 PM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > the file is 10M. > > it seems to me the content does not change anything since we are just > reading it character by character without doing anything else. > > anyway, you can find it at: > https://dl.dropboxusercontent.com/u/12861461/jfreechart-0_9_0.mse > > nicolas > > On 17/03/2015 11:04, phil(a)highoctane.be wrote: >> >> 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

Re: [Pharo-dev] [pharo-project/pharo-core] c2785a: 40562

by Marcus Denker

> On 17 Mar 2015, at 16:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 17 Mar 2015, at 16:19, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> >> >> 2015-03-17 16:07 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: >> >> > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> > >> > All class comments seem to have been modified ? >> > Was that intentional ? >> > >> >> I think that is an overside of the GIT commit: it commits the comment it gets, and this is the template when there is none. >> >> This also means that those classes appear as having been commented, even if they werenât. > > not reallyâ¦ they are still marked as âuncommentedâ in the image. > I really donât know why the export showed as commented, thoughtâ¦ I suppose a bug in the exporter. bad implementation (no, interesting design decision): comment "Answer the receiver's comment. (If missing, supply a template) " | aString | aString := self instanceSide organization classComment. aString isEmpty ifFalse: [^ aString]. ^self classCommentBlank I would return nil there and let the tools handle the template. (ah, and that the comment is stored on the organisation is of course strange tooâ¦) Marcus

March 17, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] c2785a: 40562

by Marcus Denker

> On 17 Mar 2015, at 16:19, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-03-17 16:07 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > All class comments seem to have been modified ? > > Was that intentional ? > > > > I think that is an overside of the GIT commit: it commits the comment it gets, and this is the template when there is none. > > This also means that those classes appear as having been commented, even if they weren't. > > Luckily, that git format is write-only, isn't it? I hope Monticello hasn't that bug. > No, it has not. This is just bug in the code that commits class comments. It does not check if there is noneâ¦ (we should change the design and just return nil is there is no comment. The tools than can display something) Marcus

March 17, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] c2785a: 40562

by Esteban Lorenzano

> On 17 Mar 2015, at 16:19, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-03-17 16:07 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > All class comments seem to have been modified ? > > Was that intentional ? > > > > I think that is an overside of the GIT commit: it commits the comment it gets, and this is the template when there is none. > > This also means that those classes appear as having been commented, even if they werenât. not reallyâ¦ they are still marked as âuncommentedâ in the image. I really donât know why the export showed as commented, thoughtâ¦ I suppose a bug in the exporter. > > Luckily, that git format is write-only, isn't it? I hope Monticello hasn't that bug. > > Thierry

March 17, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] c2785a: 40562

by Thierry Goubier

2015-03-17 16:07 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > All class comments seem to have been modified ? > > Was that intentional ? > > > > I think that is an overside of the GIT commit: it commits the comment it > gets, and this is the template when there is none. > This also means that those classes appear as having been commented, even if they weren't. Luckily, that git format is write-only, isn't it? I hope Monticello hasn't that bug. Thierry

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Sven Van Caekenberghe

> On 17 Mar 2015, at 15:45, Stephan Eggermont <stephan(a)stack.nl> wrote: > > I tried it myself, java seems to be 7 times faster on a 35 MB jfreechart.mse file I found on github. Moose 5.1 managed about > 30 MB/s. > > UTF8 is rather suboptimal for source code. Nearly all of it is > ASCII which can be processed a machine word at a time, instead of byte. There were earlier discussions about that > http://forum.world.st/Fastest-utf-8-encoder-contest-td4634566.html > > Stephan Thanks for the pointer to the file (finally !). Using this file: https://raw.githubusercontent.com/mircealungu/experiments-polymorphism/mast… which is indeed 35Mb we can do better. Since (FileLocator desktop / 'jfreechart.mse') binaryReadStreamDo: [ :in | in contents allSatisfy: [ :each | each < 127 ]. is true, we can skip decoding. For me, it is pretty fast now [ | count | count := 0. (FileLocator desktop / 'jfreechart.mse') binaryReadStreamDo: [ :in | in contents do: [ :each | count := count + 1 ] ]. count ] timeToRun. "0:00:00:00.637" Adding UTF8 decoding (implemented in Pharo) makes it 10x slower [ | count | count := 0. (FileLocator desktop / 'jfreechart.mse') binaryReadStreamDo: [ :in | in contents utf8Decoded do: [ :each | count := count + 1 ] ]. count ] timeToRun. "0:00:00:07.45" HTH, Sven

March 17, 2015

Re: [Pharo-dev] software update again

by Marcus Denker

> On 17 Mar 2015, at 11:57, Norbert Hartl <norbert(a)hartl.name> wrote: > > I'm trying to have an actual pharo4 image to work on. So I like to do "software update". Sometimes it doesn't work and that is ok. But the last weeks I didn't manage to update once. Everytime there was a GT-* package that could not be found. To be clear here I'm talking about a 404 from smalltalkhub. > > I've tried to update a 40557 image and the error I get is that > > ZnHttpUnsuccessful: 404 Not found > > for > > /mc/Pharo/Pharo40/main/GT-Spotter-StefanReichhart.190.mcz > > Don't know how these errors are introduced. > -> GT is loaded via a Configuration. -> this load from the GT repo, *not* Pharo40. So this means that it looks in the wrong place I wonder why. Maybe we should copy the mcz files? This would be good anyway: all code of Pharo40 is in the Pharo40 repo. Marcus

March 17, 2015