Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Hilaire]

I meant the problem occurs when you migrate the base application to one
version of Pharo to another one, the fuel file need to be upgraded.

Now in the situation of Dimitris this should not be a problem as its
application build script could initialize the newer fuel bitmap file. As
long as there is not user defined fuel files it should be ok.

Hilaire

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Denis Kudriashov]

Interesting what is faster: reading Form from fuel file or reading it from
simple BMP file?

2016-01-19 10:31 GMT+01:00 Hilaire :

> I meant the problem occurs when you migrate the base application to one
> version of Pharo to another one, the fuel file need to be upgraded.
>
> Now in the situation of Dimitris this should not be a problem as its
> application build script could initialize the newer fuel bitmap file. As
> long as there is not user defined fuel files it should be ok.
>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Dimitris Chloupis]

most likely fuel, since it stores your live object as is.

I like fuel but the fact that I may be limited by incompatible versions is
a game stopper for me. I am ok with new version between incompatible with
old one but there must be some backward compatibility to any format I use.
Or else I end up worrying about things I should not be worrying about.

On Tue, Jan 19, 2016 at 12:23 PM Denis Kudriashov 
wrote:

> Interesting what is faster: reading Form from fuel file or reading it from
> simple BMP file?
>
> 2016-01-19 10:31 GMT+01:00 Hilaire :
>
>> I meant the problem occurs when you migrate the base application to one
>> version of Pharo to another one, the fuel file need to be upgraded.
>>
>> Now in the situation of Dimitris this should not be a problem as its
>> application build script could initialize the newer fuel bitmap file. As
>> long as there is not user defined fuel files it should be ok.
>>
>> Hilaire
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Denis Kudriashov]

2016-01-19 11:34 GMT+01:00 Dimitris Chloupis :

> most likely fuel, since it stores your live object as is.
>
> I like fuel but the fact that I may be limited by incompatible versions is
> a game stopper for me. I am ok with new version between incompatible with
> old one but there must be some backward compatibility to any format I use.
> Or else I end up worrying about things I should not be worrying about.


You are right. I perform little experiment. Fuel reading is 60% faster than
BMP:

Smalltalk garbageCollect; garbageCollect.
r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
s binary.
fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.

Smalltalk garbageCollect; garbageCollect.
r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
s binary.
fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] benchFor:
2 seconds.

{ r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2
milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2
seconds 3 milliseconds. 2,860 per second))"

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[PBKResearch]

Denis

 

Very interesting. It would be more interesting if you could save your test 
image as a .png file, and then include reading with PNGReadWriter in your 
comparison. This would help to confirm or refute the original point made by 
Dimitris, that reading from .png is particularly slow.

 

Peter Kenny

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Denis Kudriashov
Sent: 19 January 2016 10:59
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 
5

 

 

2016-01-19 11:34 GMT+01:00 Dimitris Chloupis mailto:kilon.al...@gmail.com> >:

most likely fuel, since it stores your live object as is. 

I like fuel but the fact that I may be limited by incompatible versions is a 
game stopper for me. I am ok with new version between incompatible with old one 
but there must be some backward compatibility to any format I use. Or else I 
end up worrying about things I should not be worrying about.


You are right. I perform little experiment. Fuel reading is 60% faster than BMP:

 

Smalltalk garbageCollect; garbageCollect.

r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s | 

s binary.

fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.

 

Smalltalk garbageCollect; garbageCollect.

r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |

s binary.

fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] benchFor: 2 
seconds.

 

{ r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2 
milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2 seconds 
3 milliseconds. 2,860 per second))"

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Sven Van Caekenberghe]

> On 19 Jan 2016, at 12:29, PBKResearch  wrote:
> 
> Denis
>  
> Very interesting. It would be more interesting if you could save your test 
> image as a .png file, and then include reading with PNGReadWriter in your 
> comparison. This would help to confirm or refute the original point made by 
> Dimitris, that reading from .png is particularly slow.

Check the original thread/case, it is slow. Not *very* slow, but slower than 
the plugin based JPEG reader. That is what we eventually need, a plugin base 
PNG reader.

> Peter Kenny
>  
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> Denis Kudriashov
> Sent: 19 January 2016 10:59
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 
> and 5
>  
>  
> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis :
>> most likely fuel, since it stores your live object as is. 
>> 
>> I like fuel but the fact that I may be limited by incompatible versions is a 
>> game stopper for me. I am ok with new version between incompatible with old 
>> one but there must be some backward compatibility to any format I use. Or 
>> else I end up worrying about things I should not be worrying about.
> 
> You are right. I perform little experiment. Fuel reading is 60% faster than 
> BMP:
>  
> Smalltalk garbageCollect; garbageCollect.
> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s | 
> s binary.
> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.
>  
> Smalltalk garbageCollect; garbageCollect.
> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
> s binary.
> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] benchFor: 2 
> seconds.
>  
> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2 
> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2 
> seconds 3 milliseconds. 2,860 per second))"

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Esteban Lorenzano]

Yesterday I tested creating PNGs from disk using Athens: 

[(AthensCairoSurface 
createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png' 
ifFailed: [ ]) 
asForm] bench.

That gave me 46k/s … (455k image) which IMO is pretty reasonable :)

Esteban

> On 19 Jan 2016, at 12:34, Sven Van Caekenberghe  wrote:
> 
> 
>> On 19 Jan 2016, at 12:29, PBKResearch  wrote:
>> 
>> Denis
>> 
>> Very interesting. It would be more interesting if you could save your test 
>> image as a .png file, and then include reading with PNGReadWriter in your 
>> comparison. This would help to confirm or refute the original point made by 
>> Dimitris, that reading from .png is particularly slow.
> 
> Check the original thread/case, it is slow. Not *very* slow, but slower than 
> the plugin based JPEG reader. That is what we eventually need, a plugin base 
> PNG reader.
> 
>> Peter Kenny
>> 
>> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
>> Denis Kudriashov
>> Sent: 19 January 2016 10:59
>> To: Any question about pharo is welcome 
>> Subject: Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 
>> and 5
>> 
>> 
>> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis :
>>> most likely fuel, since it stores your live object as is. 
>>> 
>>> I like fuel but the fact that I may be limited by incompatible versions is 
>>> a game stopper for me. I am ok with new version between incompatible with 
>>> old one but there must be some backward compatibility to any format I use. 
>>> Or else I end up worrying about things I should not be worrying about.
>> 
>> You are right. I perform little experiment. Fuel reading is 60% faster than 
>> BMP:
>> 
>> Smalltalk garbageCollect; garbageCollect.
>> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s | 
>>s binary.
>> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.
>> 
>> Smalltalk garbageCollect; garbageCollect.
>> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
>>s binary.
>> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] benchFor: 
>> 2 seconds.
>> 
>> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2 
>> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2 
>> seconds 3 milliseconds. 2,860 per second))"
> 
> 

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Denis Kudriashov]

And more extended test:

Smalltalk garbageCollect; garbageCollect.
r1:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
s binary.
fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] benchFor:
2 seconds.

Smalltalk garbageCollect; garbageCollect.
r2 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
s binary.
fromBMP := BMPReadWriter new on: s; nextImage]] benchFor: 2 seconds.

Smalltalk garbageCollect; garbageCollect.
r3 := [FileLocator imageDirectory / 'test.png' readStreamDo: [ :s |
s binary.
fromPNG := PNGReadWriter new on: s; nextImage]] benchFor: 2 seconds.

Smalltalk garbageCollect; garbageCollect.
r4:= [
fromAthens := (AthensCairoSurface
createFromFile: (FileLocator imageDirectory / 'test.png') pathString
ifFailed: []) asForm.
] benchFor: 2 seconds.


{ r1. r2. r3. r4 }.
 "an Array(a BenchmarkResult(5,537 iterations in 2 seconds 2 milliseconds.
2,766 per second) a BenchmarkResult(2,193 iterations in 2 seconds 2
milliseconds. 1,095 per second) a BenchmarkResult(443 iterations in 2
seconds 5 milliseconds. 220.948 per second) a BenchmarkResult(1,033
iterations in 2 seconds 3 milliseconds. 515.726 per second))"


2016-01-19 13:21 GMT+01:00 Esteban Lorenzano :

> Yesterday I tested creating PNGs from disk using Athens:
>
> [(AthensCairoSurface
> createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png'
> ifFailed: [ ])
> asForm] bench.
>
> That gave me 46k/s … (455k image) which IMO is pretty reasonable :)
>
> Esteban
>
> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe  wrote:
> >
> >
> >> On 19 Jan 2016, at 12:29, PBKResearch  wrote:
> >>
> >> Denis
> >>
> >> Very interesting. It would be more interesting if you could save your
> test image as a .png file, and then include reading with PNGReadWriter in
> your comparison. This would help to confirm or refute the original point
> made by Dimitris, that reading from .png is particularly slow.
> >
> > Check the original thread/case, it is slow. Not *very* slow, but slower
> than the plugin based JPEG reader. That is what we eventually need, a
> plugin base PNG reader.
> >
> >> Peter Kenny
> >>
> >> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On
> Behalf Of Denis Kudriashov
> >> Sent: 19 January 2016 10:59
> >> To: Any question about pharo is welcome 
> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on
> Pharo 4 and 5
> >>
> >>
> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis :
> >>> most likely fuel, since it stores your live object as is.
> >>>
> >>> I like fuel but the fact that I may be limited by incompatible
> versions is a game stopper for me. I am ok with new version between
> incompatible with old one but there must be some backward compatibility to
> any format I use. Or else I end up worrying about things I should not be
> worrying about.
> >>
> >> You are right. I perform little experiment. Fuel reading is 60% faster
> than BMP:
> >>
> >> Smalltalk garbageCollect; garbageCollect.
> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
> >>s binary.
> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.
> >>
> >> Smalltalk garbageCollect; garbageCollect.
> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
> >>s binary.
> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]]
> benchFor: 2 seconds.
> >>
> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2
> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2
> seconds 3 milliseconds. 2,860 per second))"
> >
> >
>
>
>

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Dimitris Chloupis]

does not work for me on ubuntu it keeps saying that "cannot locate cairo
library" even though its installed via

sudo apt-get install libcairo2-dev

By the way just for the fun, I will make a benchmark comparison betweem PNG
loader in pharo and SDL in C to see what is the speed difference and dust
off my C skills.

On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano 
wrote:

> Yesterday I tested creating PNGs from disk using Athens:
>
> [(AthensCairoSurface
> createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png'
> ifFailed: [ ])
> asForm] bench.
>
> That gave me 46k/s … (455k image) which IMO is pretty reasonable :)
>
> Esteban
>
> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe  wrote:
> >
> >
> >> On 19 Jan 2016, at 12:29, PBKResearch  wrote:
> >>
> >> Denis
> >>
> >> Very interesting. It would be more interesting if you could save your
> test image as a .png file, and then include reading with PNGReadWriter in
> your comparison. This would help to confirm or refute the original point
> made by Dimitris, that reading from .png is particularly slow.
> >
> > Check the original thread/case, it is slow. Not *very* slow, but slower
> than the plugin based JPEG reader. That is what we eventually need, a
> plugin base PNG reader.
> >
> >> Peter Kenny
> >>
> >> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On
> Behalf Of Denis Kudriashov
> >> Sent: 19 January 2016 10:59
> >> To: Any question about pharo is welcome 
> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on
> Pharo 4 and 5
> >>
> >>
> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis :
> >>> most likely fuel, since it stores your live object as is.
> >>>
> >>> I like fuel but the fact that I may be limited by incompatible
> versions is a game stopper for me. I am ok with new version between
> incompatible with old one but there must be some backward compatibility to
> any format I use. Or else I end up worrying about things I should not be
> worrying about.
> >>
> >> You are right. I perform little experiment. Fuel reading is 60% faster
> than BMP:
> >>
> >> Smalltalk garbageCollect; garbageCollect.
> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
> >>s binary.
> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.
> >>
> >> Smalltalk garbageCollect; garbageCollect.
> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
> >>s binary.
> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]]
> benchFor: 2 seconds.
> >>
> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2
> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2
> seconds 3 milliseconds. 2,860 per second))"
> >
> >
>
>
>

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Dimitris Chloupis]

ah yes it needs the 32 bit libs of cairo, yeah good luck with that, cant
wait till we finally support 64 bit, but far my most needed feature of
pharo. No idea how to find 32 bit lib of cairo, google returns nothing
meaningful, download page of cairo website mentions nothing.

On Tue, Jan 19, 2016 at 2:52 PM Dimitris Chloupis 
wrote:

> does not work for me on ubuntu it keeps saying that "cannot locate cairo
> library" even though its installed via
>
> sudo apt-get install libcairo2-dev
>
> By the way just for the fun, I will make a benchmark comparison betweem
> PNG loader in pharo and SDL in C to see what is the speed difference and
> dust off my C skills.
>
> On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano 
> wrote:
>
>> Yesterday I tested creating PNGs from disk using Athens:
>>
>> [(AthensCairoSurface
>> createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png'
>> ifFailed: [ ])
>> asForm] bench.
>>
>> That gave me 46k/s … (455k image) which IMO is pretty reasonable :)
>>
>> Esteban
>>
>> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe  wrote:
>> >
>> >
>> >> On 19 Jan 2016, at 12:29, PBKResearch  wrote:
>> >>
>> >> Denis
>> >>
>> >> Very interesting. It would be more interesting if you could save your
>> test image as a .png file, and then include reading with PNGReadWriter in
>> your comparison. This would help to confirm or refute the original point
>> made by Dimitris, that reading from .png is particularly slow.
>> >
>> > Check the original thread/case, it is slow. Not *very* slow, but slower
>> than the plugin based JPEG reader. That is what we eventually need, a
>> plugin base PNG reader.
>> >
>> >> Peter Kenny
>> >>
>> >> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On
>> Behalf Of Denis Kudriashov
>> >> Sent: 19 January 2016 10:59
>> >> To: Any question about pharo is welcome 
>> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on
>> Pharo 4 and 5
>> >>
>> >>
>> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis :
>> >>> most likely fuel, since it stores your live object as is.
>> >>>
>> >>> I like fuel but the fact that I may be limited by incompatible
>> versions is a game stopper for me. I am ok with new version between
>> incompatible with old one but there must be some backward compatibility to
>> any format I use. Or else I end up worrying about things I should not be
>> worrying about.
>> >>
>> >> You are right. I perform little experiment. Fuel reading is 60% faster
>> than BMP:
>> >>
>> >> Smalltalk garbageCollect; garbageCollect.
>> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
>> >>s binary.
>> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.
>> >>
>> >> Smalltalk garbageCollect; garbageCollect.
>> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
>> >>s binary.
>> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]]
>> benchFor: 2 seconds.
>> >>
>> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2
>> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2
>> seconds 3 milliseconds. 2,860 per second))"
>> >
>> >
>>
>>
>>

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Ben Coman]

$ apt-cache search cairo | grep cairo | less
shows... libcairo2 - Cairo 2D vector graphics library

so following the pattern for Debian here...
http://pharo.org/gnu-linux-installation

I presume...
$ sudo dpkg --add-architecture i386
$ sudo apt-get update
$ sudo apt-get install  libcairo2:i386

...but haven't tried this since I'm using 32-bit Debian.

cheers -ben

On Tue, Jan 19, 2016 at 9:02 PM, Dimitris Chloupis
 wrote:
> ah yes it needs the 32 bit libs of cairo, yeah good luck with that, cant
> wait till we finally support 64 bit, but far my most needed feature of
> pharo. No idea how to find 32 bit lib of cairo, google returns nothing
> meaningful, download page of cairo website mentions nothing.
>
> On Tue, Jan 19, 2016 at 2:52 PM Dimitris Chloupis 
> wrote:
>>
>> does not work for me on ubuntu it keeps saying that "cannot locate cairo
>> library" even though its installed via
>>
>> sudo apt-get install libcairo2-dev
>>
>> By the way just for the fun, I will make a benchmark comparison betweem
>> PNG loader in pharo and SDL in C to see what is the speed difference and
>> dust off my C skills.
>>
>> On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano 
>> wrote:
>>>
>>> Yesterday I tested creating PNGs from disk using Athens:
>>>
>>> [(AthensCairoSurface
>>> createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png'
>>> ifFailed: [ ])
>>> asForm] bench.
>>>
>>> That gave me 46k/s … (455k image) which IMO is pretty reasonable :)
>>>
>>> Esteban
>>>
>>> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe  wrote:
>>> >
>>> >
>>> >> On 19 Jan 2016, at 12:29, PBKResearch  wrote:
>>> >>
>>> >> Denis
>>> >>
>>> >> Very interesting. It would be more interesting if you could save your
>>> >> test image as a .png file, and then include reading with PNGReadWriter in
>>> >> your comparison. This would help to confirm or refute the original point
>>> >> made by Dimitris, that reading from .png is particularly slow.
>>> >
>>> > Check the original thread/case, it is slow. Not *very* slow, but slower
>>> > than the plugin based JPEG reader. That is what we eventually need, a 
>>> > plugin
>>> > base PNG reader.
>>> >
>>> >> Peter Kenny
>>> >>
>>> >> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On
>>> >> Behalf Of Denis Kudriashov
>>> >> Sent: 19 January 2016 10:59
>>> >> To: Any question about pharo is welcome 
>>> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on
>>> >> Pharo 4 and 5
>>> >>
>>> >>
>>> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis :
>>> >>> most likely fuel, since it stores your live object as is.
>>> >>>
>>> >>> I like fuel but the fact that I may be limited by incompatible
>>> >>> versions is a game stopper for me. I am ok with new version between
>>> >>> incompatible with old one but there must be some backward compatibility 
>>> >>> to
>>> >>> any format I use. Or else I end up worrying about things I should not be
>>> >>> worrying about.
>>> >>
>>> >> You are right. I perform little experiment. Fuel reading is 60% faster
>>> >> than BMP:
>>> >>
>>> >> Smalltalk garbageCollect; garbageCollect.
>>> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
>>> >>s binary.
>>> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.
>>> >>
>>> >> Smalltalk garbageCollect; garbageCollect.
>>> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
>>> >>s binary.
>>> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]]
>>> >> benchFor: 2 seconds.
>>> >>
>>> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2
>>> >> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2
>>> >> seconds 3 milliseconds. 2,860 per second))"
>>> >
>>> >
>>>
>>>
>

[Pharo-users] spotter: top search for senders and references

[Tudor Girba]

Hi,

With the latest GT integration, we also integrated the search for senders and 
references from the first step.

Here is a detailed explanation about it, including what we still want to do, 
how it’s done, and how to discover what else is around:
http://www.humane-assessment.com/blog/spotting-senders-references-with-gtspotter/



Please let us know what you think.

Cheers,
Doru


--
www.tudorgirba.com
www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem 
understanding."

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

[Dimitris Chloupis]

thanks ben that indeed get the cairo 32 bit version but there must be a
version mismatch because now pharo complains
"Error:Could not  find accessor for variable named "aCairoSurfaceHandle" "

On Tue, Jan 19, 2016 at 3:30 PM Ben Coman  wrote:

> $ apt-cache search cairo | grep cairo | less
> shows... libcairo2 - Cairo 2D vector graphics library
>
> so following the pattern for Debian here...
> http://pharo.org/gnu-linux-installation
>
> I presume...
> $ sudo dpkg --add-architecture i386
> $ sudo apt-get update
> $ sudo apt-get install  libcairo2:i386
>
> ...but haven't tried this since I'm using 32-bit Debian.
>
> cheers -ben
>
> On Tue, Jan 19, 2016 at 9:02 PM, Dimitris Chloupis
>  wrote:
> > ah yes it needs the 32 bit libs of cairo, yeah good luck with that, cant
> > wait till we finally support 64 bit, but far my most needed feature of
> > pharo. No idea how to find 32 bit lib of cairo, google returns nothing
> > meaningful, download page of cairo website mentions nothing.
> >
> > On Tue, Jan 19, 2016 at 2:52 PM Dimitris Chloupis  >
> > wrote:
> >>
> >> does not work for me on ubuntu it keeps saying that "cannot locate cairo
> >> library" even though its installed via
> >>
> >> sudo apt-get install libcairo2-dev
> >>
> >> By the way just for the fun, I will make a benchmark comparison betweem
> >> PNG loader in pharo and SDL in C to see what is the speed difference and
> >> dust off my C skills.
> >>
> >> On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano 
> >> wrote:
> >>>
> >>> Yesterday I tested creating PNGs from disk using Athens:
> >>>
> >>> [(AthensCairoSurface
> >>> createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png'
> >>> ifFailed: [ ])
> >>> asForm] bench.
> >>>
> >>> That gave me 46k/s … (455k image) which IMO is pretty reasonable :)
> >>>
> >>> Esteban
> >>>
> >>> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe 
> wrote:
> >>> >
> >>> >
> >>> >> On 19 Jan 2016, at 12:29, PBKResearch 
> wrote:
> >>> >>
> >>> >> Denis
> >>> >>
> >>> >> Very interesting. It would be more interesting if you could save
> your
> >>> >> test image as a .png file, and then include reading with
> PNGReadWriter in
> >>> >> your comparison. This would help to confirm or refute the original
> point
> >>> >> made by Dimitris, that reading from .png is particularly slow.
> >>> >
> >>> > Check the original thread/case, it is slow. Not *very* slow, but
> slower
> >>> > than the plugin based JPEG reader. That is what we eventually need,
> a plugin
> >>> > base PNG reader.
> >>> >
> >>> >> Peter Kenny
> >>> >>
> >>> >> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On
> >>> >> Behalf Of Denis Kudriashov
> >>> >> Sent: 19 January 2016 10:59
> >>> >> To: Any question about pharo is welcome <
> pharo-users@lists.pharo.org>
> >>> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on
> >>> >> Pharo 4 and 5
> >>> >>
> >>> >>
> >>> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis  >:
> >>> >>> most likely fuel, since it stores your live object as is.
> >>> >>>
> >>> >>> I like fuel but the fact that I may be limited by incompatible
> >>> >>> versions is a game stopper for me. I am ok with new version between
> >>> >>> incompatible with old one but there must be some backward
> compatibility to
> >>> >>> any format I use. Or else I end up worrying about things I should
> not be
> >>> >>> worrying about.
> >>> >>
> >>> >> You are right. I perform little experiment. Fuel reading is 60%
> faster
> >>> >> than BMP:
> >>> >>
> >>> >> Smalltalk garbageCollect; garbageCollect.
> >>> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
> >>> >>s binary.
> >>> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.
> >>> >>
> >>> >> Smalltalk garbageCollect; garbageCollect.
> >>> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
> >>> >>s binary.
> >>> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]]
> >>> >> benchFor: 2 seconds.
> >>> >>
> >>> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2
> seconds 2
> >>> >> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations
> in 2
> >>> >> seconds 3 milliseconds. 2,860 per second))"
> >>> >
> >>> >
> >>>
> >>>
> >
>
>

[Pharo-users] 1st Call for Contributions for SPLASH'16: OOPSLA, Onward!, Workshops, DLS, SLE, GPCE

[Tijs van der Storm]

//
ACM Conference on Systems, Programming, Languages, and Applications:
Software for Humanity (SPLASH'16)

Amsterdam, The Netherlands
Sun 30th October - Fri 4th November , 2016

http://2016.splashcon.org

Sponsored by ACM SIGPLAN

//

FIRST COMBINED CALL FOR CONTRIBUTIONS:
OOPSLA
Onward!
Workshops
Doctoral Symposium
Posters
Dynamic Languages Symposium (DLS)
Software Language Engineering (SLE)
Generative Programming: Concepts & Experiences (GPCE)

//


# SPLASH 2016

The ACM SIGPLAN conference on Systems, Programming, Languages and
Applications: Software for Humanity (SPLASH) embraces all aspects of
software construction, to make it the premier conference at the
intersection of programming, languages, systems, and software engineering.
We invite high quality submissions describing original and unpublished work.


## OOPSLA Research Papers

Papers that address any aspect of software development are welcome,
including requirements, modeling, prototyping, design, implementation,
generation, analysis, verification, testing, evaluation, maintenance,
reuse, replacement, and retirement of software systems. Papers may address
these topics in a variety of ways, including new tools (such as languages,
program analyses, and runtime systems), new techniques (such as
methodologies, design processes, code organization approaches, and
management techniques), and new evaluations (such as formalisms and proofs,
corpora analyses, user studies, and surveys).

Submissions due: Wed 23 March, 2016
http://2016.splashcon.org/track/splash-2016-oopsla


## Onward! Research Papers

Onward! is a premier multidisciplinary conference focused on everything to
do with programming and software: including processes, methods, languages,
communities, and applications. Onward! is more radical, more visionary, and
more open than other conferences to ideas that are well-argued but not yet
proven. We welcome different ways of thinking about, approaching, and
reporting on programming language and software engineering research.

Submissions due: Fri 1 April, 2016
http://2016.splashcon.org/track/onward2016/onward-2016-papers


## Onward! Essays

Onward! Essays is looking for clear and compelling pieces of writing about
topics important to the software community. An essay can be an exploration
of a topic, its impact, or the circumstances of its creation; it can
present a personal view of what is, explore a terrain, or lead the reader
in an act of discovery; it can be a philosophical digression or a deep
analysis. It can describe a personal journey, perhaps by which the author
reached an understanding of such a topic. The subject area should be
interpreted broadly and can include the relationship of software to human
endeavors, or its philosophical, sociological, psychological, historical,
or anthropological underpinnings.

Submissions due: Fri 1 April, 2016
http://2016.splashcon.org/track/onward2016/onward2016-essays

## Workshops

The SPLASH Workshops track will host a variety of high-quality workshops,
allowing their participants to meet and discuss research questions with
peers, to mature new and exciting ideas, and to build up communities and
start new collaborations. SPLASH workshops complement the main tracks of
the conference and provide meetings in a smaller and more specialized
setting. Workshops cultivate new ideas and concepts for the future,
optionally recorded in formal proceedings.

Late Phase Submissions of Workshop Proposals due: Fri 4 Mar, 2016
http://2016.splashcon.org/track/splash2016-workshops


## Doctoral Symposium

The SPLASH Doctoral Symposium provides students with useful guidance for
completing their dissertation research and beginning their research
careers. The Symposium will provide an interactive forum for doctoral
students who have progressed far enough in their research to have a
structured proposal, but will not be defending their dissertation in the
next 12 months.

Submissions due: Thu 30 Jun, 2016
http://2016.splashcon.org/track/splash-2016-ds


## Posters

The SPLASH Poster track provides an excellent forum for authors to present
their recent or ongoing projects in an interactive setting, and receive
feedback from the community. We invite submissions covering any aspect of
programming, systems, languages and applications. The goal of the poster
session is to encourage and facilitate small groups of individuals
interested in a technical area to gather and interact.

Poster submissions due: Fri 8 Jul, 2016
http://2016.splashcon.org/track/splash-2016-posters

## Dynamic Languages Symposium (DLS)

DLS is the premier forum for researchers and practitioners to share
knowledge and research on dynamic languages, their implementation, and
applications. The influence of dynami

Re: [Pharo-users] Generating a binary package like PharoLauncher

[Damien Cassou]

Serge Stinckwich  writes:

> Dear all,
>
> I would like to distribute Kendrick like PharoLauncher, i.e as a
> binary package for mac and windows. Are the script of CI for
> generating PharoLauncher available somewhere ?

https://github.com/pharo-project/pharo-ci/blob/master/ci-jobs/pharo/Launcher/build.sh
https://github.com/pharo-project/pharo-ci/blob/master/ci-jobs/pharo/Launcher-Mac/build.sh
https://github.com/pharo-project/pharo-ci/blob/master/ci-jobs/pharo/Launcher-Win/build.sh

these 3 scripts control the 3 jobs at https://ci.inria.fr/pharo/view/Launcher/

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

[Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[Sven Van Caekenberghe]

Not that we didn't already know this or that we don't feel like this (else you 
wouldn't be here), but it is nice to see a concise description and some fact 
based reasoning around this subject:

> http://games.greggman.com/game/dynamic-typing-static-typing/ 
> 

In summary:

In a dynamically typed language you write (a lot) less code for a shorter 
program that is easier and faster to write and debug, which gives you more time 
to think about what you are doing, resulting in more reliable programs.

Static typing catches only a (very) small amount of typing errors, that are 
just as easy to handle as dynamic typing exceptions, but they are a bit faster.

Sven

[Pharo-users] [ANN] OSSubprocess v0.2.0 release

[Mariano Martinez Peck]

Hi guys,

I am happy to announce OSSubprocess v0.2.0. You can see the changelog here:
https://github.com/marianopeck/OSSubprocess/releases/tag/v0.2.0
Such version becomes the #stable, so the installation instructions remain
the same.
Note that I have improved and added more info in the documentation.

I took into account most of the feedback I received in the first release
plus some other stuff from the survey.

If you have more feedback, just let me know!

Hope you enjoy.

Best,

-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[Martin Bähr]

Excerpts from Sven Van Caekenberghe's message of 2016-01-19 22:09:44 +0100:
> > http://games.greggman.com/game/dynamic-typing-static-typing/ 
> > 
> In a dynamically typed language you write (a lot) less code for a shorter 
> program that is easier and faster to write and debug, which gives you more 
> time to think about what you are doing, resulting in more reliable programs.
> 
> Static typing catches only a (very) small amount of typing errors, that are 
> just as easy to handle as dynamic typing exceptions, but they are a bit 
> faster.

if that is the case, then why are people working on typescript, why are both
python and ruby getting optional types?

i think this is a comparison of apples with oranges.
even without typing languages like java, c and c++ are significantly different
from dynamic languages like python, ruby, smalltalk and others.

adding typing to javascript, python and ruby means that we can have our cake
and eat it too. 

so i'll wait for this study to be redone in the next decade, to compare typed
with untyped javascript, python and ruby. and only that will show us the real
truth. does adding types, with everything else being equal, really make a
difference, or not?

btw: the guys at rubyrogues make an interesting argument why lack of typing
works better in smalltalk than it does in ruby:
http://devchat.cachefly.net/rubyrogues/transcript-155-rr-why-ruby-sucks-ruby-rogues.pdf
read page 8 of that transcript.

basically they are saying that because java and c/c++ are compiled they can be
analyzed statically and you can build great refactoring tools for them because
the tools can predict which methods are the same.
and in difference to that smalltalk and lisp only know the code at runtime and
so they can't make those predictions. but they make up for that because they
are always running. there is no such thing as not runtime. you can simply ask
the system about its state, like find out which object in the whole system
would respond to a particular message. and in ruby you can't do either of those.

disclaimer: for the last 20 years, my main programming language has been pike,
a dynamic language like smalltalk, but with declarative typing. (it's optional,
in the sense that you can declare a type as "mixed" which can be anything, so
just like typescript, and how python and ruby will be once they have optional
types)

greetings, martin.

-- 
eKita   -   the online platform for your entire academic life
-- 
chief engineer   eKita.co
pike programmer  pike.lysator.liu.secaudium.net societyserver.org
secretary  beijinglug.org
mentor   fossasia.org
foresight developer  foresightlinux.orgrealss.com
unix sysadmin
Martin Bähr  working in chinahttp://societyserver.org/mbaehr/

[Pharo-users] Updated Pharo Chapter 2 ready for review

[stepharo]

Hi

yes it is long and tedious.
Now the second chapter is ready for review. Should work with Playground, 
new debugger and spotter.

Thanks in advance.

Stef


https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample/234/artifact/book-result/PharoTour/PharoTour.pdf 

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[stepharo]

What is funny is that in general people do not believe us :).
So I decided that I do not want to talk with type freaks.

Stef

Le 19/1/16 22:09, Sven Van Caekenberghe a écrit :

Not that we didn't already know this or that we don't feel like this (else you 
wouldn't be here), but it is nice to see a concise description and some fact 
based reasoning around this subject:


http://games.greggman.com/game/dynamic-typing-static-typing/ 


In summary:

In a dynamically typed language you write (a lot) less code for a shorter 
program that is easier and faster to write and debug, which gives you more time 
to think about what you are doing, resulting in more reliable programs.

Static typing catches only a (very) small amount of typing errors, that are 
just as easy to handle as dynamic typing exceptions, but they are a bit faster.

Sven