Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

[Ben Coman]

Thanks Nicolai. I tried your suggestion but running the CI tests
then crashes the VM.  I'll gather more info.
cheers -ben

On Wed, Mar 18, 2015 at 7:12 AM, Nicolai Hess  wrote:

> 2015-03-17 18:29 GMT+01:00 Ben Coman :
>
>>
>> Currently the image the monkey uses to validate issues is 9 days old -
>> which might be a problem if your bug fix today depends on or conflicts with
>> something integrated a week ago.
>>
>> I have somewhat isolated the problem to a Rubric/GTTools update, but
>> nothing looks obvious from the package level.  Its time for bed, so I
>> haven't dug into code changes yet, but could someone from the Glamorous
>> Team familiar with the changes for Issue 15018 take a look?
>>
>> https://pharo.fogbugz.com/default.asp?15018
>>
>> https://pharo.fogbugz.com/default.asp?15127
>>
>> cheers -ben
>>
>
>
> possible fix:
> GTSpotterEventRecorderSettings
> only read/write preference file if this startUp is a real  image start up
> / booting.
>
> startUp: resuming
> resuming ifFalse:[ ^ self].
> "We reset image preferences, because this is likely
> a newly downloaded image or different user
> and he/she should agree about sending data."
> self preferences exists ifFalse: [ self reset ].
> self loadPreferences.
>

Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

[Nicolai Hess]

2015-03-17 18:29 GMT+01:00 Ben Coman :

>
> Currently the image the monkey uses to validate issues is 9 days old -
> which might be a problem if your bug fix today depends on or conflicts with
> something integrated a week ago.
>
> I have somewhat isolated the problem to a Rubric/GTTools update, but
> nothing looks obvious from the package level.  Its time for bed, so I
> haven't dug into code changes yet, but could someone from the Glamorous
> Team familiar with the changes for Issue 15018 take a look?
>
> https://pharo.fogbugz.com/default.asp?15018
>
> https://pharo.fogbugz.com/default.asp?15127
>
> cheers -ben
>


possible fix:
GTSpotterEventRecorderSettings
only read/write preference file if this startUp is a real  image start up /
booting.

startUp: resuming
resuming ifFalse:[ ^ self].
"We reset image preferences, because this is likely
a newly downloaded image or different user
and he/she should agree about sending data."
self preferences exists ifFalse: [ self reset ].
self loadPreferences.

Re: [Pharo-dev] pharo vs. java

[Stephan Eggermont]

On 17/03/15 21:35, Nicolas Cellier wrote:

But wait, the file was buffered (bytes are fetched from file by packets),
but the decoder was not! All decoding is performed char by char.


In the optimized version there is still no reading of a 32/64-bit word
at a time, checking all 8th bits at the same time, isn't there?

I assume Bitmap asByteArray hack works for ByteStrings too?

Stephan

Re: [Pharo-dev] Rubric mutability issue in RubTextComposer binary search

[Stephan Eggermont]

Hi Alex,

On 17/03/15 22:19, Aliaksei Syrel wrote:

seems like there is a rather rare bug in Rubric. I opened an issue with
explanation:

https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability-issue-in-RubTextComposer-binary-search

Would be nice to fix it until release. It was caught in Spotter - as it
heavily uses multithreading. Any suggestions are welcome if it is known :)


Why is that an issue in Rubric? Sounds like you might need a monitor in 
Spotter?


Stephan

[Pharo-dev] Rubric mutability issue in RubTextComposer binary search

[Aliaksei Syrel]

Hi,

seems like there is a rather rare bug in Rubric. I opened an issue with
explanation:

https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability-issue-in-RubTextComposer-binary-search

Would be nice to fix it until release. It was caught in Spotter - as it
heavily uses multithreading. Any suggestions are welcome if it is known :)

Cheers,
Alex

Re: [Pharo-dev] pharo vs. java

[Nicolas Cellier]

2015-03-17 21:10 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:

> We can already have relatively fast UTF8 reading when the file is
> essentially composed of ascii.
> I've demonstrated this a few years ago with SqueaXtreams (
> http://www.squeaksource.com/XTream/)
>
> For example, see
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141577.html
>
> I don't want to sell SqueaXtreams, it was just an experiment, but the good
> ideas should be extracted, we don't have to wait for a new VM.
>
> Nicolas Cellier (eh, I now have to disambiguate, maybe i will sign NiCe...)
>
>
I've also found this  -
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153389.html
- only the end counts, quoted below:


But wait, the file was buffered (bytes are fetched from file by packets),
but the decoder was not! All decoding is performed char by char.
That's bad, because when only a few bytes require decoding and
majority can be translated unchanged to String, there is potentially a
major speed up by simple using a sub-array copy primitive. We know
this since #squeakToUTF8, many thanks to Andreas.
To profit by buffering for decoder too, just use a message to wrap it up:

{
[| tmp |
tmp := (MultiByteFileStream readOnlyFileNamed: (SourceFiles
at: 2) name) ascii;
wantsLineEndConversion: false; converter: UTF8TextConverter
new.
1 to: 2 do: [:i | tmp upTo: Character cr].
tmp close] timeToRun.
[| tmp |
tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles at: 2)
name)
readXtream binary buffered ~> UTF8Decoder) buffered.
1 to: 2 do: [:i | tmp upTo: Character cr].
tmp close] timeToRun.
}
   #(152 18)
   #(152 19)

Bingo, now the speed up is there too! 7.5x is not a bad score afterall.
That's not amazing, the change log is essentially made of ASCII and
does rarely require any UTF8 translation at all.
Of course, if you handle files full of chinese code points, don't
expect a speed up at all!
But for a decent proportion of latin character users, the potential
speed-up is there, right under our Streams.



>
> 2015-03-17 19:58 GMT+01:00 p...@highoctane.be :
>
>>
>> Le 17 mars 2015 18:59, "Stephan Eggermont"  a écrit :
>> >
>> > On 17/03/15 17:59, Stephan Eggermont wrote:
>> >
>> >> I tried the code with the latest pharo-spur image and vm:
>> >> from 17 seconds down to 10.5
>> >
>> >
>> > And I tried it again with cogspurlinux 3268 and the
>> > trunk46-spur. That needed switching to
>> >
>> > MultiByteFileStream readOnlyFileNamed:
>> >
>> > and ran in 8.8 sec (average of three runs). Interestingly, on Pharo
>> > that is significantly slower, about 15 sec.
>> >
>> > replacing that by StandardFileStream (and no decoding) reduced it to
>> > <120 ms.
>>
>> Maybe using FFI to read the file in the correct format would be a nice
>> option to have available.
>>
>> The code in the MultibyteFileStream looks quite convoluted when reading.
>>
>> There is reason we need a 64 it VM to read a UTF8 file fast. (8secs
>> really does not qualify)
>>
>> Opinions?
>>
>> Phil
>>
>> >
>> > Stephan
>> >
>> >
>> > [1 to: 10 do: [:j | |a length|
>> >   length := 0.
>> >   a :=
>> > (MultiByteFileStream readOnlyFileNamed:
>> '/home/stephan/Downloads/jfreechart.mse') readStream contents]]
>> timeToRunWithoutGC
>> >
>> >
>> >
>> >
>>
>
>

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

[Nicolas Cellier]

2015-03-17 19:07 GMT+01:00 Sven Van Caekenberghe :

> Yes indeed, first external, then internal.
> Behaviour is way more important than structure.
>
>
Both are important.
Don't forget that we shall be able to understand the smallest part of the
system :)



> > On 17 Mar 2015, at 18:23, stepharo  wrote:
> >
> > Did you check it?
> > It is nice now.
> >
> > Not a stupid template with just something that goes against any book on
> OOP: violation of encapsulation.
> > Let us not talk about instance variables.
> >
> > Stef
> >
> >
> > Le 17/3/15 15:59, Sven Van Caekenberghe a écrit :
> >> All class comments seem to have been modified ?
> >> Was that intentional ?
> >>
> >>> On 17 Mar 2015, at 15:48, GitHub  wrote:
> >>>
> >>> 15147 change class comment template
> >>> https://pharo.fogbugz.com/f/cases/15147
> >>
> >>
> >
> >
>
>
>

Re: [Pharo-dev] pharo vs. java

[Stephan Eggermont]

On 17/03/15 19:58, p...@highoctane.be wrote:

Maybe using FFI to read the file in the correct format would be a nice
option to have available.


File reading seems fast enough: faster than my SSD can deliver data
(>1GB/s)


The code in the MultibyteFileStream looks quite convoluted when reading.


Yes.


There is reason we need a 64 it VM to read a UTF8 file fast. (8secs
really does not qualify)


40MB/s (on a 4GHz i7 4790K). As far as I understand it the inner loop of 
this is exactly what Sista can improve.


Stephan

Re: [Pharo-dev] SpecTableLayout not in Pahro 4

[stepharo]

We can add a configurationOfSpec but somebody should find the old and 
resurrect it.

I remember that I started to remove bad dependencies


Le 17/3/15 18:04, Peter Uhnák a écrit :
I am assuming requiring SpecTableLayout after it is incorporated into 
Spec?
There is currently no configuration for spec since it is inside the 
image, so the only way would be to specify version of Pharo (i.e. it's 
incorporated in version X, so the user needs at least Pharo X) or 
testing whether the class already exists.


As for overriding behavior - loading a package would rewrite existing 
code.


There may be some issues if you were to concurrently update both Spec 
and your package, and then the latest would win; but there may be 
better solution.


Peter

On Tue, Mar 17, 2015 at 5:24 PM, webwarrior > wrote:


Created issue in fogbugz.

Also, if I decide to distribute a library that requires
SpecTableLayout, how
to do it properly? Basically most of changes are new classes (so
may be
shipped in any package), but there is also a modification to
existing method
in SpecInterpreter.



--
View this message in context:
http://forum.world.st/SpecTableLayout-not-in-Pahro-4-tp4812428p4812633.html
Sent from the Pharo Smalltalk Developers mailing list archive at
Nabble.com.

[Pharo-dev] Need more success stories

[stepharo]

Hi guys

we need more success stories:
You should get one in 15 min.

One paragraph:
Context/solution
One screenshot
One comment on the techno

This is important. But if you do not do it I cannot do it for you and we 
all lose.


Stef

Re: [Pharo-dev] pharo vs. java

[p...@highoctane.be]

Le 17 mars 2015 18:59, "Stephan Eggermont"  a écrit :
>
> On 17/03/15 17:59, Stephan Eggermont wrote:
>
>> I tried the code with the latest pharo-spur image and vm:
>> from 17 seconds down to 10.5
>
>
> And I tried it again with cogspurlinux 3268 and the
> trunk46-spur. That needed switching to
>
> MultiByteFileStream readOnlyFileNamed:
>
> and ran in 8.8 sec (average of three runs). Interestingly, on Pharo
> that is significantly slower, about 15 sec.
>
> replacing that by StandardFileStream (and no decoding) reduced it to
> <120 ms.

Maybe using FFI to read the file in the correct format would be a nice
option to have available.

The code in the MultibyteFileStream looks quite convoluted when reading.

There is reason we need a 64 it VM to read a UTF8 file fast. (8secs really
does not qualify)

Opinions?

Phil

>
> Stephan
>
>
> [1 to: 10 do: [:j | |a length|
>   length := 0.
>   a :=
> (MultiByteFileStream readOnlyFileNamed:
'/home/stephan/Downloads/jfreechart.mse') readStream contents]]
timeToRunWithoutGC
>
>
>
>

Re: [Pharo-dev] Jenkins build trigger

[Stephan Eggermont]

On 17/03/15 16:08, Christophe Demarey wrote:


Le 17 mars 2015 à 15:28, Stephan Eggermont a écrit :

That results in scheduled. The first time, it resulted in two builds being 
scheduled. After trying again, one build was scheduled.
After committing again, no build was scheduled.


then, the problem should be investigated on the Smalltalkhub side.
It would be good to have a test button there and be able to get the feedback.
Without that, difficult to say what is wrong


I find it interesting that the missing build gets triggered after 
triggering a build with a web browser, and especially that a normal

curl/wget does not work. Which projects actually use this build trigger?
Versionner still uses both url trigger and this one.

Stephan

Re: [Pharo-dev] [Pharo-users] [Pharo4] Please test Pharo4 *now*

[stepharo]

cool!

Le 16/3/15 21:45, jannik laval a écrit :

Hi guys,

phratch is already built on pharo 4.
30 students will use it. I will give you feedback.

Cheers,
Jannik

2015-03-16 18:14 GMT+01:00 Sven Van Caekenberghe >:



> On 16 Mar 2015, at 17:39, Marcus Denker mailto:marcus.den...@inria.fr>> wrote:
>
> Hello,
>
> As every year: We can only fix what we know.
>
> And this means that no, just because *you* think that X and Y
obviously needs to be fixed,
> it will only be fixed if
>   a) there is an issue on the issue tracker
>   b) someone fixes it.
>
> I should repeat: *Nothing*, even the most obvious or trivial,
happens by itself.
>
>   Marcus

Maybe it is also important to add that we are talking about bugs,
not features.

This is not the time for free wheeling discussions about anything,
we need help in QA, to finalize the 4.0 release.

Please load your code and give it a spin.

Sven





--

~~Jannik Laval~~
École des Mines de Douai
Enseignant-chercheur
http://www.jannik-laval.eu
http://www.phratch.com
http://www.approchealpes.info
http://car.mines-douai.fr/

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

[Sven Van Caekenberghe]

Yes indeed, first external, then internal.
Behaviour is way more important than structure.

> On 17 Mar 2015, at 18:23, stepharo  wrote:
> 
> Did you check it?
> It is nice now.
> 
> Not a stupid template with just something that goes against any book on OOP: 
> violation of encapsulation.
> Let us not talk about instance variables.
> 
> Stef
> 
> 
> Le 17/3/15 15:59, Sven Van Caekenberghe a écrit :
>> All class comments seem to have been modified ?
>> Was that intentional ?
>> 
>>> On 17 Mar 2015, at 15:48, GitHub  wrote:
>>> 
>>> 15147 change class comment template
>>> https://pharo.fogbugz.com/f/cases/15147
>> 
>> 
> 
> 

Re: [Pharo-dev] pharo vs. java

[Stephan Eggermont]

On 17/03/15 17:59, Stephan Eggermont wrote:


I tried the code with the latest pharo-spur image and vm:
from 17 seconds down to 10.5


And I tried it again with cogspurlinux 3268 and the
trunk46-spur. That needed switching to

MultiByteFileStream readOnlyFileNamed:

and ran in 8.8 sec (average of three runs). Interestingly, on Pharo
that is significantly slower, about 15 sec.

replacing that by StandardFileStream (and no decoding) reduced it to
<120 ms.

Stephan

[1 to: 10 do: [:j | |a length|
  length := 0.
  a :=
(MultiByteFileStream readOnlyFileNamed: 
'/home/stephan/Downloads/jfreechart.mse') readStream contents]] 
timeToRunWithoutGC

[Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

[Ben Coman]

Currently the image the monkey uses to validate issues is 9 days old -
which might be a problem if your bug fix today depends on or conflicts with
something integrated a week ago.

I have somewhat isolated the problem to a Rubric/GTTools update, but
nothing looks obvious from the package level.  Its time for bed, so I
haven't dug into code changes yet, but could someone from the Glamorous
Team familiar with the changes for Issue 15018 take a look?

https://pharo.fogbugz.com/default.asp?15018

https://pharo.fogbugz.com/default.asp?15127

cheers -ben

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

[stepharo]

Did you check it?
It is nice now.

Not a stupid template with just something that goes against any book on 
OOP: violation of encapsulation.

Let us not talk about instance variables.

Stef


Le 17/3/15 15:59, Sven Van Caekenberghe a écrit :

All class comments seem to have been modified ?
Was that intentional ?


On 17 Mar 2015, at 15:48, GitHub  wrote:

15147 change class comment template
https://pharo.fogbugz.com/f/cases/15147

Re: [Pharo-dev] trying a hot update un smalltalkhub

[stepharo]

Ooops I was talking about the catalog of metacello coming soon :)

Le 17/3/15 18:12, stepharo a écrit :
Another catalog has been developed. So pay attention not to build too 
much on it.

Now the configuration browser could use this information
The other catalog should be able to produce the same and more in fact

Le 17/3/15 12:15, kilon alios a écrit :
Great work Esteban that JSON may come handy for building a front end 
of STHub inside Pharo , so the users wont have to open an internet 
browser to browser and download sthub projects.


On Tue, Mar 17, 2015 at 12:50 PM, Esteban Lorenzano 
mailto:esteba...@gmail.com>> wrote:


ok, thank went more or less fine :)

now you have:

http://smalltalkhub.com/list

and

http://smalltalkhub.com/list/json

enjoy :)

Esteban




On 17 Mar 2015, at 11:15, Esteban Lorenzano mailto:esteba...@gmail.com>> wrote:

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

Re: [Pharo-dev] software update again

[Esteban Lorenzano]

no, copying should not be the solution. 
but… being able to reconstruct an update is a good reason to not use generic 
versions (like #development) and instead provide a real fixed version :P

we will need to review this… but not now… for Pharo 5. 

Esteban

> On 17 Mar 2015, at 18:10, stepharo  wrote:
> 
> -> 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
> Yes!
> 
> 

Re: [Pharo-dev] trying a hot update un smalltalkhub

[stepharo]

Another catalog has been developed. So pay attention not to build too 
much on it.

Now the configuration browser could use this information
The other catalog should be able to produce the same and more in fact

Le 17/3/15 12:15, kilon alios a écrit :
Great work Esteban that JSON may come handy for building a front end 
of STHub inside Pharo , so the users wont have to open an internet 
browser to browser and download sthub projects.


On Tue, Mar 17, 2015 at 12:50 PM, Esteban Lorenzano 
mailto:esteba...@gmail.com>> wrote:


ok, thank went more or less fine :)

now you have:

http://smalltalkhub.com/list

and

http://smalltalkhub.com/list/json

enjoy :)

Esteban




On 17 Mar 2015, at 11:15, Esteban Lorenzano mailto:esteba...@gmail.com>> wrote:

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

Re: [Pharo-dev] software update again

[stepharo]

-> 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

Yes!

Re: [Pharo-dev] pharo vs. java

[Nicolas Anquetil]

On 17/03/2015 17:59, Stephan Eggermont wrote:

On 17/03/15 17:13, Eliot Miranda wrote:

Hi Nicolas,
Indeed it is.  But remember that Java VMs are typically extremely
efficient, employing aggressive optimization.  What Java VM are you 
using?


I was using an OpenSDK-7 on latest Ubuntu


same here: java-7-openjdk-amd64


But do not despair!  We are working on it.  Let me boil down your
benchmark and measure it in Cog (the current standard VM) and Spur (the
in-development improvement that should become the standard Pharo VM by
Pharo 5).  Clément and I are also working on Sista, which is an adaptive
optimizer for Cog/Spur that should further increase performance.



I am not despairing :-)
I will look into the suggestion of Sven and Phil with Binary Stream

nicolas

I tried the code with the latest pharo-spur image and vm:
from 17 seconds down to 10.5

Stephan

Re: [Pharo-dev] SpecTableLayout not in Pahro 4

[stepharo]

Could you
Create an issue on the Pharo bugtracker
Publish your changes in a slice in the inbox of Pharo
so that we check if we can integrate them or not in Pharo 40?

I'm sorry about what happened around Spec. We did not want to have a 
look a the github com

because we did not want to fuel the nastiness of Ben.

We are still insulted on the web page but I asked the lawyers not to 
react and let the story die.


Stef

Le 16/3/15 22:50, webwarrior a écrit :

I made several commits to Spec
(https://github.com/spec-framework/spec/pull/15) shortly before the license
change.
I thought these changes would be merged into Pharo. However, they are not in
Pahro 4 as for now. Are there any problems?



--
View this message in context: 
http://forum.world.st/SpecTableLayout-not-in-Pahro-4-tp4812428.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] SpecTableLayout not in Pahro 4

[Peter Uhnák]

I am assuming requiring SpecTableLayout after it is incorporated into Spec?
There is currently no configuration for spec since it is inside the image,
so the only way would be to specify version of Pharo (i.e. it's
incorporated in version X, so the user needs at least Pharo X) or testing
whether the class already exists.

As for overriding behavior - loading a package would rewrite existing code.

There may be some issues if you were to concurrently update both Spec and
your package, and then the latest would win; but there may be better
solution.

Peter

On Tue, Mar 17, 2015 at 5:24 PM, webwarrior  wrote:

> Created issue in fogbugz.
>
> Also, if I decide to distribute a library that requires SpecTableLayout,
> how
> to do it properly? Basically most of changes are new classes (so may be
> shipped in any package), but there is also a modification to existing
> method
> in SpecInterpreter.
>
>
>
> --
> View this message in context:
> http://forum.world.st/SpecTableLayout-not-in-Pahro-4-tp4812428p4812633.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] pharo vs. java

[Stephan Eggermont]

On 17/03/15 17:13, Eliot Miranda wrote:

Hi Nicolas,
Indeed it is.  But remember that Java VMs are typically extremely
efficient, employing aggressive optimization.  What Java VM are you using?


I was using an OpenSDK-7 on latest Ubuntu



But do not despair!  We are working on it.  Let me boil down your
benchmark and measure it in Cog (the current standard VM) and Spur (the
in-development improvement that should become the standard Pharo VM by
Pharo 5).  Clément and I are also working on Sista, which is an adaptive
optimizer for Cog/Spur that should further increase performance.


I tried the code with the latest pharo-spur image and vm:
from 17 seconds down to 10.5

Stephan

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

[Marcus Denker]

> 
> 
> (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?
> 


Maybe in some source code manager… that has the responsibility to hide the whole
sources/changes stuff (and those direct reference to SourceFiles).

But simple is often the best. why not just in the class?

What is clear is that the whole organziation is not needed anymore since we have
Protocol. We can simplify a lot...

Marcus

Re: [Pharo-dev] SpecTableLayout not in Pahro 4

[webwarrior]

Created issue in fogbugz.

Also, if I decide to distribute a library that requires SpecTableLayout, how
to do it properly? Basically most of changes are new classes (so may be
shipped in any package), but there is also a modification to existing method
in SpecInterpreter.



--
View this message in context: 
http://forum.world.st/SpecTableLayout-not-in-Pahro-4-tp4812428p4812633.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] pharo vs. java

[Eliot Miranda]

Hi Nicolas,

On Tue, Mar 17, 2015 at 2:19 AM, Nicolas Anquetil  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)


Indeed it is.  But remember that Java VMs are typically extremely
efficient, employing aggressive optimization.  What Java VM are you using?

But do not despair!  We are working on it.  Let me boil down your benchmark
and measure it in Cog (the current standard VM) and Spur (the
in-development improvement that should become the standard Pharo VM by
Pharo 5).  Clément and I are also working on Sista, which is an adaptive
optimizer for Cog/Spur that should further increase performance.


[| a n |
a := String new: 10 * 1024 * 1024.
n := 0.
1 to: a size do: [:i| | c | c := a at: i. n := n + 1]] bench
Cog: '1.99 per second. 502 milliseconds per run.'
Spur: '12.2 per second. 82.1 milliseconds per run.'


[| a n |
a := String new: 10 * 1024 * 1024.
n := 0.
1 to: a size do: [:i| n := n + 1]] bench
Cog: '2.93 per second. 341 milliseconds per run.'
Spur: '23.8 per second. 42.1 milliseconds per run.'

Now the Java VM's optimizer is probably able to eliminate the at:, so we
would expect it to run "| c | c := a at: i. n := n + 1" at the same speed
as it runs "n := n + 1".  We expect Sista will be able to perform the same
optimization.


P.S.

Of course, a programmer is able to realise that the above computation is
equivalent to

a := String new: 10 * 1024 * 1024.
a size + 1 * (a size / 2)

;-)


>
> 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: 1 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 < 1; 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
>>
>>
>
>


-- 
best,
Eliot

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

[Thierry Goubier]

2015-03-17 17:07 GMT+01:00 Marcus Denker :

>
>
>
>> (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?
>
>
> Maybe in some source code manager... that has the responsibility to hide the
> whole
> sources/changes stuff (and those direct reference to SourceFiles).
>

Good idea. With an indirection to make use of packages as well.


>
> But simple is often the best. why not just in the class?
>

I'd be ok with that solution too.


>
> What is clear is that the whole organziation is not needed anymore since
> we have
> Protocol. We can simplify a lot...
>

And clean all users of that stuff :)

Thierry

Re: [Pharo-dev] pharo vs. java

[Sven Van Caekenberghe]

> On 17 Mar 2015, at 16:29, p...@highoctane.be wrote:
> 
> Still, your implementation isn't loading the whole contents as the Java 
> version does.

Well, your third piece of code, which uses StandardFileStream, does not do any 
UTF-8 decoding either. It uses FileStream>>#contents, like my binary stream 
(ByteArray and ByteString are interchangeable at this level).

Anyway, our conclusion is the same.

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

[Thierry Goubier]

2015-03-17 16:26 GMT+01:00 Marcus Denker :

>
> On 17 Mar 2015, at 16:22, Esteban Lorenzano  wrote:
>
>
> On 17 Mar 2015, at 16:19, Thierry Goubier 
> wrote:
>
>
>
> 2015-03-17 16:07 GMT+01:00 Marcus Denker :
>
>>
>> > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe  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

Re: [Pharo-dev] pharo vs. java

[p...@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  wrote:
>
>> On 17 Mar 2015, at 15:45, Stephan Eggermont  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/master/fileouts/jfreechart.mse
>  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
>
>
>

Re: [Pharo-dev] pharo vs. java

[p...@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
 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, p...@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 
>> 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 
 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: 1 do: [:j | Str

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

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: c2785aa6da1b2fefa3b7e063bb12c226533c5bee
  
https://github.com/pharo-project/pharo-core/commit/c2785aa6da1b2fefa3b7e063bb12c226533c5bee
  Author: Jenkins Build Server 
  Date:   2015-03-17 (Tue, 17 Mar 2015)

  Changed paths:
M AST-Core.package/RBLiteralArrayToken.class/README.md
M AST-Core.package/RBMultiKeywordLiteralToken.class/README.md
M AST-Core.package/RBNumberLiteralToken.class/README.md
M AST-Core.package/RBPatternPragmaNode.class/README.md
M AST-Core.package/RBShortAssignmentToken.class/README.md
R 
Collections-Strings.package/String.class/instance/accessing/lastIndexOfPKSignature_.st
M CollectionsTests.package/NullStreamTest.class/README.md
M CollectionsTests.package/OrderedIdentityDictionaryTest.class/README.md
M CollectionsTests.package/StreamBugsTest.class/README.md
A Compression.package/extension/String/instance/lastIndexOfPKSignature_.st
M CompressionTests.package/ZipCrcTests.class/README.md
M CompressionTests.package/ZipWriteStreamTests.class/README.md
M 
ConfigurationOfFileSystemST.package/ConfigurationOfFileSystemST.class/README.md
M ConfigurationOfOSWindow.package/ConfigurationOfOSWindow.class/README.md
M Deprecated40.package/NBWin32ShellTest.class/README.md
M FileSystem-Smalltalk.package/CompiledMethodMemoryHandle.class/README.md
M FileSystem-Smalltalk.package/FSSTFileNameEncoder.class/README.md
M FileSystem-Smalltalk.package/MethodFileNameEncoder.class/README.md
M 
FileSystem-Tests-Relative.package/RelativeFileSystemStoreTest.class/README.md
M FileSystem-Tests-Relative.package/RelativeFileSystemTest.class/README.md
M FuelTests.package/FLCompiledMethodSerializationTest.class/README.md
M FuelTests.package/FLDelayedSerializationMock.class/README.md
M FuelTests.package/FLDelayedSerializerMock.class/README.md
M FuelTests.package/FLProcessSerializationTest.class/README.md
M FuelTests.package/FLReplacementClassMock.class/README.md
M FuelTests.package/FLReplacementMock.class/README.md
M FuelTests.package/FLSimpleStackTest.class/README.md
M GT-Spotter.package/GTFilter.class/README.md
M GT-Spotter.package/GTFilterAlike.class/README.md
M GT-Spotter.package/GTFilterBlock.class/README.md
M GT-Spotter.package/GTFilterRegex.class/README.md
M GT-Spotter.package/GTFilterStringMatch.class/README.md
M GT-Spotter.package/GTFilterSubstring.class/README.md
M GT-Spotter.package/GTFilterSubstrings.class/README.md
M GT-Spotter.package/GTOrderedFilter.class/README.md
M GT-Spotter.package/GTSpotterActOn.class/README.md
M GT-Spotter.package/GTSpotterAllCandidatesAdded.class/README.md
M GT-Spotter.package/GTSpotterAllCandidatesRemoved.class/README.md
M GT-Spotter.package/GTSpotterBreadcrumbSeparatorRenderer.class/README.md
M GT-Spotter.package/GTSpotterBreadcrumbVisibilityChanged.class/README.md
M GT-Spotter.package/GTSpotterBrickDarkThemer.class/README.md
M GT-Spotter.package/GTSpotterBrickThemer.class/README.md
M GT-Spotter.package/GTSpotterCandidateAdded.class/README.md
M GT-Spotter.package/GTSpotterCandidateLink.class/README.md
M GT-Spotter.package/GTSpotterCandidateSelected.class/README.md
M GT-Spotter.package/GTSpotterCandidateSelectedMoved.class/README.md
M GT-Spotter.package/GTSpotterCandidatesAmountChanged.class/README.md
M GT-Spotter.package/GTSpotterCategoryBrick.class/README.md
M GT-Spotter.package/GTSpotterCategorySelected.class/README.md
M GT-Spotter.package/GTSpotterCategoryTitleBrick.class/README.md
M GT-Spotter.package/GTSpotterContentsBrick.class/README.md
M GT-Spotter.package/GTSpotterContext.class/README.md
M GT-Spotter.package/GTSpotterContextChanged.class/README.md
M GT-Spotter.package/GTSpotterCurrentStepChanged.class/README.md
M GT-Spotter.package/GTSpotterDiveInCategory.class/README.md
M GT-Spotter.package/GTSpotterDiveInElement.class/README.md
M GT-Spotter.package/GTSpotterDiveOut.class/README.md
M GT-Spotter.package/GTSpotterDoubleLinkedList.class/README.md
M GT-Spotter.package/GTSpotterDropDownMorph.class/README.md
M GT-Spotter.package/GTSpotterExitAnnouncement.class/README.md
M GT-Spotter.package/GTSpotterHeaderBrick.class/README.md
M GT-Spotter.package/GTSpotterHideHints.class/README.md
M GT-Spotter.package/GTSpotterHidePreview.class/README.md
M GT-Spotter.package/GTSpotterItemActionbarBrick.class/README.md
M GT-Spotter.package/GTSpotterItemBrick.class/README.md
M GT-Spotter.package/GTSpotterMorph.class/README.md
M GT-Spotter.package/GTSpotterPaneBrick.class/README.md
M GT-Spotter.package/GTSpotterPreviewArrowBrick.class/README.md
M GT-Spotter.package/GTSpotterPreviewBrick.class/README.md
M GT-Spotter.package/GTSpotterProcessorLink.class/README.md
M GT-Spotter.package/GTSpotterProcessorsForExamplesTest.class/READM

Re: [Pharo-dev] pharo vs. java

[Nicolas Anquetil]

in the bash:
---
$ for i in 1 2 3 4 5 6 7 8 9 10; do time java PharoJava; done
---

then I did the sum manually :-)

nicolas

On 17/03/2015 13:47, Sven Van Caekenberghe wrote:

On 17 Mar 2015, at 10:24, Sven Van Caekenberghe  wrote:

Also, in your Java code I do not see a loop doing the benchmark 10 times ...

Just to make sure: where is your 10x loop in Java ?

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);
}
---

[Pharo-dev] Update Nautilus layout after setting plugin's height?

[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

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

[Marcus Denker]

> On 17 Mar 2015, at 16:19, Thierry Goubier  wrote:
> 
> 
> 
> 2015-03-17 16:07 GMT+01:00 Marcus Denker  >:
> 
> > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe  > > 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

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

[Marcus Denker]

> On 17 Mar 2015, at 16:22, Esteban Lorenzano  wrote:
> 
> 
>> On 17 Mar 2015, at 16:19, Thierry Goubier > > wrote:
>> 
>> 
>> 
>> 2015-03-17 16:07 GMT+01:00 Marcus Denker > >:
>> 
>> > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe > > > 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

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

[Esteban Lorenzano]

> On 17 Mar 2015, at 16:19, Thierry Goubier  wrote:
> 
> 
> 
> 2015-03-17 16:07 GMT+01:00 Marcus Denker  >:
> 
> > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe  > > 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

Re: [Pharo-dev] pharo vs. java

[Sven Van Caekenberghe]

> On 17 Mar 2015, at 15:45, Stephan Eggermont  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/master/fileouts/jfreechart.mse
 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

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

[Thierry Goubier]

2015-03-17 16:07 GMT+01:00 Marcus Denker :

>
> > On 17 Mar 2015, at 15:59, Sven Van Caekenberghe  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

Re: [Pharo-dev] software update again

[Marcus Denker]

> On 17 Mar 2015, at 11:57, Norbert Hartl  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

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

[Marcus Denker]

> On 17 Mar 2015, at 15:59, Sven Van Caekenberghe  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.

Marcus

Re: [Pharo-dev] Jenkins build trigger

[Christophe Demarey]

Le 17 mars 2015 à 15:28, Stephan Eggermont a écrit :

> On 17/03/15 14:52, Christophe Demarey wrote:
>> There is no delay.
>> The first thing to try if it does not work is to open the URL given on 
>> smalltalkhub from a web browser (strangely, does not work with curl/wget).
>> ex: curl 
>> https://ci.inria.fr/pharo-contribution/buildByToken/build?job=*JOBNAME*&token=*TOKEN*
>> 
>> You should see the message 'scheduled!'. If it does not  work, check the URL 
>> used and fix it.
> 
> That results in scheduled. The first time, it resulted in two builds being 
> scheduled. After trying again, one build was scheduled.
> After committing again, no build was scheduled.

then, the problem should be investigated on the Smalltalkhub side.
It would be good to have a test button there and be able to get the feedback.
Without that, difficult to say what is wrong

smime.p7s
Description: S/MIME cryptographic signature

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

[Sven Van Caekenberghe]

All class comments seem to have been modified ?
Was that intentional ?

> On 17 Mar 2015, at 15:48, GitHub  wrote:
> 
> 15147 change class comment template
>   https://pharo.fogbugz.com/f/cases/15147

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

Re: [Pharo-dev] pharo vs. java

[Stephan Eggermont]

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

Re: [Pharo-dev] Jenkins build trigger

[Stephan Eggermont]

On 17/03/15 14:52, Christophe Demarey wrote:

There is no delay.
The first thing to try if it does not work is to open the URL given on 
smalltalkhub from a web browser (strangely, does not work with curl/wget).
ex: curl 
https://ci.inria.fr/pharo-contribution/buildByToken/build?job=*JOBNAME*&token=*TOKEN*

You should see the message 'scheduled!'. If it does not  work, check the URL 
used and fix it.


That results in scheduled. The first time, it resulted in two builds 
being scheduled. After trying again, one build was scheduled.

After committing again, no build was scheduled.

Stephan

Re: [Pharo-dev] Jenkins build trigger

[Christophe Demarey]

Le 17 mars 2015 à 10:18, Stephan Eggermont a écrit :

> 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*&token=*TOKEN*
>>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.

There is no delay.
The first thing to try if it does not work is to open the URL given on 
smalltalkhub from a web browser (strangely, does not work with curl/wget).
ex: curl 
https://ci.inria.fr/pharo-contribution/buildByToken/build?job=*JOBNAME*&token=*TOKEN*

You should see the message 'scheduled!'. If it does not  work, check the URL 
used and fix it.

Hope this helps.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] pharo vs. java

[Sven Van Caekenberghe]

> On 17 Mar 2015, at 10:24, Sven Van Caekenberghe  wrote:
> 
> Also, in your Java code I do not see a loop doing the benchmark 10 times ...

Just to make sure: where is your 10x loop in Java ?

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);
   }
---

Re: [Pharo-dev] trying a hot update un smalltalkhub

[Esteban Lorenzano]

yes, that’s because info is cached (and refreshed each 6h) so, each 6h someone 
will have a slow request :)

Esteban 

> On 17 Mar 2015, at 13:16, Sven Van Caekenberghe  wrote:
> 
> 
>> On 17 Mar 2015, at 12:52, Sean P. DeNigris  wrote:
>> 
>> Sven Van Caekenberghe-2 wrote
>>> And it is fast as well: 0.33 seconds for me.
>> 
>> Yes! For me 26ms for the GET and 43ms to parse.
> 
> Actually the parsing is way faster:
> 
> json := ZnClient new get: 'http://smalltalkhub.com/list/json'.
> 
> [ NeoJSONReader fromString: json ] bench. 
> 
> => '21.895 per second'
> 
> So, 0.05 seconds to parse ;-)
> 

Re: [Pharo-dev] pharo vs. java

[Nicolas Anquetil]

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, p...@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  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  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: 1 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 < 1; 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

Re: [Pharo-dev] trying a hot update un smalltalkhub

[Sven Van Caekenberghe]

> On 17 Mar 2015, at 12:52, Sean P. DeNigris  wrote:
> 
> Sven Van Caekenberghe-2 wrote
>> And it is fast as well: 0.33 seconds for me.
> 
> Yes! For me 26ms for the GET and 43ms to parse.

Actually the parsing is way faster:

json := ZnClient new get: 'http://smalltalkhub.com/list/json'.

[ NeoJSONReader fromString: json ] bench. 

=> '21.895 per second'

So, 0.05 seconds to parse ;-)

Re: [Pharo-dev] trying a hot update un smalltalkhub

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> And it is fast as well: 0.33 seconds for me.

Yes! For me 26ms for the GET and 43ms to parse.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/trying-a-hot-update-un-smalltalkhub-tp4812535p4812552.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] trying a hot update un smalltalkhub

[Sven Van Caekenberghe]

Very nice.

For those who want to parse the result:

ZnClient new
  contentReader: [ :entity | NeoJSONReader fromString: entity contents ]; 
  get: 'http://smalltalkhub.com/list/json'.

Or even:

ZnClient new
  contentReader: [ :entity | STON fromString: entity contents ]; 
  get: 'http://smalltalkhub.com/list/json'

And it is fast as well: 0.33 seconds for me.

> On 17 Mar 2015, at 11:50, Esteban Lorenzano  wrote:
> 
> ok, thank went more or less fine :)
> 
> now you have: 
> 
> http://smalltalkhub.com/list
> 
> and 
> 
> http://smalltalkhub.com/list/json
> 
> enjoy :)
> 
> Esteban
> 
> 
> 
>> On 17 Mar 2015, at 11:15, Esteban Lorenzano  wrote:
>> 
>> 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
> 

Re: [Pharo-dev] trying a hot update un smalltalkhub

[kilon alios]

Great work Esteban that JSON may come handy for building a front end of
STHub inside Pharo , so the users wont have to open an internet browser to
browser and download sthub projects.

On Tue, Mar 17, 2015 at 12:50 PM, Esteban Lorenzano 
wrote:

> ok, thank went more or less fine :)
>
> now you have:
>
> http://smalltalkhub.com/list
>
> and
>
> http://smalltalkhub.com/list/json
>
> enjoy :)
>
> Esteban
>
>
>
> On 17 Mar 2015, at 11:15, Esteban Lorenzano  wrote:
>
> 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
>
>
>

Re: [Pharo-dev] trying a hot update un smalltalkhub

[p...@highoctane.be]

On Tue, Mar 17, 2015 at 11:50 AM, Esteban Lorenzano  wrote:
> ok, thank went more or less fine :)
>
> now you have:
>
> http://smalltalkhub.com/list
>
> and
>
> http://smalltalkhub.com/list/json



Niiice!!! (now, a description in Json... :-p )

Phil

>
> enjoy :)
>
> Esteban
>
>
>
> On 17 Mar 2015, at 11:15, Esteban Lorenzano  wrote:
>
> 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
>
>

[Pharo-dev] software update again

[Norbert Hartl]

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.

Norbert

Re: [Pharo-dev] trying a hot update un smalltalkhub

[Esteban Lorenzano]

ok, thank went more or less fine :)

now you have: 

http://smalltalkhub.com/list 

and 

http://smalltalkhub.com/list/json 

enjoy :)

Esteban



> On 17 Mar 2015, at 11:15, Esteban Lorenzano  wrote:
> 
> 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

Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V1.0

[Blondeau Vincent]

Hi Juampi,

I know that the libraries are difficult to configure. We will improve that.
I don’t have a Mac, but as far as I know, you need to put the R libraries where 
are the Pharo ones like “libAsynchFilePlugin.dylib”.

If you didn’t do it, you need to restart the Pharo image at each time you 
change the library location and you need to install R (to copy the libraries 
seems not enough).

If it works, inspect “self nbGetSymbolAddress: 'Rf_initEmbeddedR' module: #R” 
should show you a NBExternalAddress instead of nil.

Furthermore, you need to use the 32 bits R libraries, Pharo doesn’t not support 
yet the 64 bit libs.

I hope that will be helpful,

Regards,

Vincent

De : Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] De la part de 
Juan Pablo Sandoval Alcocer
Envoyé : vendredi 13 mars 2015 23:20
À : Any question about pharo is welcome
Cc : Pharo Development List
Objet : Re: [Pharo-users] [ANN] RProjectConnector V1.0

Hi,

I was trying to use RProjectConnector in my Mac (1.9.1) and i have some issues 
:(.

I have copied the dynamic libraries of R to /usr/lib directory (.i.e. 
libR.dylib). But PharoVM does not find the libraries. For instance, this line 
of code returns always nil.

  self nbGetSymbolAddress: 'Rf_initEmbeddedR' module: #R
  "copied from the project"

I also tried copying the libraries to folder Pharo.app/Contents/MacOS/Plugins. 
or passing the library name as parameter like:

  self nbGetSymbolAddress: 'Rf_initEmbeddedR' module: 'libR.dylib'
or

  self nbGetSymbolAddress: 'Rf_initEmbeddedR' module: 
'/usr/lib/libR.dylib'

But i had not success. Could someone help me? I am doing something wrong?

Thanks,
Juampi






2014-12-08 11:10 GMT-03:00 Blondeau Vincent 
mailto:vincent.blond...@worldline.com>>:
Hello everyone,

I am glad to announce the first version of the RProjectConnector, a binding 
between Pharo and R using NativeBoost.

You can now call directly your R methods from Pharo:
data := (1 to: 1000) collect: #yourself.
res := (#acf asRFunctionWith: {data}) eval

To use it, you should copy the R libraries near the Pharo VM (see the 
documentation on SmalltalkHub to see how to proceed) and

Gofer it

smalltalkhubUser: 'VincentBlondeau' project: 'RProjectConnector';

configuration;

loadStable
Don’t forget to relaunch Pharo after the installation to be able to use the 
connector.

The sources are available on Smalltalkhub:
http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector

if you want to participate, just ask me!

Cheers,

Vincent BLONDEAU



Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.



--
Saludos,
Juan Pablo



Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender 

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

[Max Leske]

> On 17 Mar 2015, at 10:40, Peter Uhnák  wrote:
> 
> Hi,
> 
> I'm getting weird SetTest>>#testAllSetsAreHealthy error
> https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/27236//artifact/validationReport.html
>  
> 
> 
> 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.

[Pharo-dev] trying a hot update un smalltalkhub

[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

Re: [Pharo-dev] pharo vs. java

[p...@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  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  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: 1 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 < 1; 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
>>>
>>
>>
>
>

[Pharo-dev] SetTest>>#testAllSetsAreHealthy error

[Peter Uhnák]

Hi,

I'm getting weird SetTest>>#testAllSetsAreHealthy error
https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/27236//artifact/validationReport.html

My changes are completely unrelated to Sets, also when i tried the test, it
passes on my machine.

Any ideas?

Thanks,
Peter

Re: [Pharo-dev] pharo vs. java

[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  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: 1 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 < 1; 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
>> 
> 
> 

Re: [Pharo-dev] pharo vs. java

[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: 1 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 < 1; 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

Re: [Pharo-dev] Jenkins build trigger

[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*&token=*TOKEN*
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

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

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 35a636587698c185e2194a666beee0b95d3ce7b9
  
https://github.com/pharo-project/pharo-core/commit/35a636587698c185e2194a666beee0b95d3ce7b9
  Author: Jenkins Build Server 
  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

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

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

[Marcus Denker]

Wow! Great!

Now: 125

On Mon, Mar 16, 2015 at 7:10 PM, Ben Coman  wrote:

> Pharo 4: 135
>
> On Mon, Mar 16, 2015 at 9:08 PM, Marcus Denker 
> wrote:
>
>>
>>
--
Marcus Denker  --  den...@acm.org
http://www.marcusdenker.de