- Pharo-dev - lists.pharo.org

Re: [Pharo-project] * Smalltalk User Group

by Norbert Hartl

Ha ha, I was asking that myself earlier in this century. AFAIK there are not that much smalltalkers in Berlin. But Potsdam and the HPI are close. I wanted to create a Berlin user group but now I don't live there anymore (and I helped creating one in cologne instead). But I'm inclined to attend anyway even now I'm closer to Lille than Berlin :) good luck, Norbert Am 17.11.2011 um 12:53 schrieb StÃ©phane Ducasse: > > > Begin forwarded message: > >> From: Johannes Rasche <johannesrasche(a)mac.com> >> Subject: * Smalltalk User Group >> Date: November 17, 2011 12:27:15 PM GMT+01:00 >> To: pharo-project-owner(a)lists.gforge.inria.fr >> >> as Sven just announced the Belgian Smalltalk User Group (BSUG) meeting: >> >> are there Pharo people in Berlin (I didn't realize it up to now)? >> >> It would be great to have a local community with the opportunity for face-to-face exchange >> and potential cooperation >> >> Johannes >> >> -- >> Johannes Rasche Hagelberger Str. 56 10965 Berlin mail johannesrasche(a)mac.com mobile +49 1577 175 04 75 >

Nov. 17, 2011

Re: [Pharo-project] WideString performance

by Levente Uzonyi

On Thu, 17 Nov 2011, Henrik Sperre Johansen wrote: > On 17.11.2011 11:53, Levente Uzonyi wrote: >> On Thu, 17 Nov 2011, Henrik Sperre Johansen wrote: >> >>> On 17.11.2011 11:26, Levente Uzonyi wrote: >>>> On Thu, 17 Nov 2011, Henrik Sperre Johansen wrote: >>>> >>>>> On 16.11.2011 21:45, Nicolas Cellier wrote: >>>>>> I think that there are several issues: >>>>>> >>>>>> 1) Character with codePoint< 256 are unique, but Wider are not. >>>>>> The characters are not stored in the WideString (which instead stores >>>>>> the code points), but any enumeration using at: rather than wordAt: >>>>>> will create an overhead. I presume that it would be better to have a >>>>>> #codePointAt: defined as #byteAt: in ByteString and #wordAt: in >>>>>> WideString, so we could still define generic methods in String. >>>>>> 2) A lot of ByteString methods are optimized with ad hoc optional >>>>>> primitives, but very few WideString methods are. >>>>>> 3) Some of these optimized operations work with 256 element masks and >>>>>> cannot be generalized to WideString that easily >>>>>> 4) Some Stream operations that copy one Collection to the stream >>>>>> buffer or vice versa are also not optimized for mixed byte/word >>>>>> collections >>>>>> 5) UTF8 is optimized for ASCII anyway... And Squeak/Pharo converters >>>>>> also are (because they can use more primitives in this case) >>>>>> 6) Pharo ripped #squeakToUtf8 and #utf8ToSqueak which were maybe >>>>>> questionable from quality POV, but were not replaced from efficiency >>>>>> POV. >>>>>> >>>>>> I would say that a new VM with immediate Character values might help, >>>>>> but that won't be enough. >>>>>> >>>>>> Nicolas >>>>> If I may object to point 6: >>>>> (Squeak) >>>>> [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream >>>>> contents]] timeToRun 6753 >>>>> (Pharo) >>>>> [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream >>>>> contents]] timeToRun 7027 >>>>> Reading without conversion, then converting with utf8ToSqueak: >>>>> [FileStream oldFileNamed: 'C:\Users\Rydier\Dropbox\Pharo 1.4 latest >>>>> jenkins\Data.csv' >>>>> do: [:stream | stream converter: Latin1TextConverter >>>>> new. >>>>> text := stream contents >>>>> utf8ToSqueak ]] timeToRun 9752 >>>> >>>> That's not "reading without conversion", you explicitly setting >>>> Latin1TextConverter there, try StandardFileStream instead. ;) >>>> >>>> >>>> Levente >>> Latin1TextConverter does not do any conversion, no? ;) >>> >>> [StandardFileStream oldFileNamed: 'C:\Users\Rydier\Dropbox\Pharo 1.4 >>> latest jenkins\Data.csv' >>> do: [:stream | >>> text := stream contents >>> utf8ToSqueak ]] timeToRun 9221 >>> >>> Better? ;) >> >> Better, but not good enough :). I got the following in Squeak: >> >> [ FileStream readOnlyFileNamed: 'Data.csv' do: [ :file | >> file contents ] ] timeToRun. >> 2429 >> >> [ StandardFileStream readOnlyFileNamed: 'Data.csv' do: [ :file | >> file contents utf8ToSqueak ] ] timeToRun. >> 2288 >> >> Significant amount of time is spent finding the current leadingChar in both >> cases. Using 0 as leadingChar in Unicode >> #value: gives the following >> results: >> >> [ FileStream readOnlyFileNamed: 'Data.csv' do: [ :file | >> file contents ] ] timeToRun. >> 1152 >> >> [ StandardFileStream readOnlyFileNamed: 'Data.csv' do: [ :file | >> file contents utf8ToSqueak ] ] timeToRun. >> 1247 >> >> >> Levente >> >> P.S.: To avoid measuring disk latency, the file was already in memory >> during the tests. > I fail to se how even those values are significant enough to warrant using > utf8ToSqueak rather than let the converter take care of it, which was the > point I contended in the first place. It's not worth using #utf8ToSqueak in this case to get better performance. This is also true for all other cases, because of the optimizations done to text converters (in Squeak UTF8TextConverter uses the same method as #utf8ToSqueak when possible). The only thing you can save with it performance wise is the creation of the converter and the optional lookup of the converter class, which is insignificant in most cases. Levente > > Cheers, > Henry > >

Nov. 17, 2011

[Pharo-project] Fwd: * Smalltalk User Group

by StÃ©phane Ducasse

Begin forwarded message: > From: Johannes Rasche <johannesrasche(a)mac.com> > Subject: * Smalltalk User Group > Date: November 17, 2011 12:27:15 PM GMT+01:00 > To: pharo-project-owner(a)lists.gforge.inria.fr > > as Sven just announced the Belgian Smalltalk User Group (BSUG) meeting: > > are there Pharo people in Berlin (I didn't realize it up to now)? > > It would be great to have a local community with the opportunity for face-to-face exchange > and potential cooperation > > Johannes > > -- > Johannes Rasche Hagelberger Str. 56 10965 Berlin mail johannesrasche(a)mac.com mobile +49 1577 175 04 75

Nov. 17, 2011

Re: [Pharo-project] WideString performance

by Henrik Sperre Johansen

On 17.11.2011 11:53, Levente Uzonyi wrote: > On Thu, 17 Nov 2011, Henrik Sperre Johansen wrote: > >> On 17.11.2011 11:26, Levente Uzonyi wrote: >>> On Thu, 17 Nov 2011, Henrik Sperre Johansen wrote: >>> >>>> On 16.11.2011 21:45, Nicolas Cellier wrote: >>>>> I think that there are several issues: >>>>> >>>>> 1) Character with codePoint< 256 are unique, but Wider are not. >>>>> The characters are not stored in the WideString (which instead stores >>>>> the code points), but any enumeration using at: rather than wordAt: >>>>> will create an overhead. I presume that it would be better to have a >>>>> #codePointAt: defined as #byteAt: in ByteString and #wordAt: in >>>>> WideString, so we could still define generic methods in String. >>>>> 2) A lot of ByteString methods are optimized with ad hoc optional >>>>> primitives, but very few WideString methods are. >>>>> 3) Some of these optimized operations work with 256 element masks and >>>>> cannot be generalized to WideString that easily >>>>> 4) Some Stream operations that copy one Collection to the stream >>>>> buffer or vice versa are also not optimized for mixed byte/word >>>>> collections >>>>> 5) UTF8 is optimized for ASCII anyway... And Squeak/Pharo converters >>>>> also are (because they can use more primitives in this case) >>>>> 6) Pharo ripped #squeakToUtf8 and #utf8ToSqueak which were maybe >>>>> questionable from quality POV, but were not replaced from efficiency >>>>> POV. >>>>> >>>>> I would say that a new VM with immediate Character values might help, >>>>> but that won't be enough. >>>>> >>>>> Nicolas >>>> If I may object to point 6: >>>> (Squeak) >>>> [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream >>>> contents]] timeToRun 6753 >>>> (Pharo) >>>> [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream >>>> contents]] timeToRun 7027 >>>> Reading without conversion, then converting with utf8ToSqueak: >>>> [FileStream oldFileNamed: 'C:\Users\Rydier\Dropbox\Pharo 1.4 latest >>>> jenkins\Data.csv' >>>> do: [:stream | stream converter: >>>> Latin1TextConverter new. >>>> text := stream contents >>>> utf8ToSqueak ]] timeToRun 9752 >>> >>> That's not "reading without conversion", you explicitly setting >>> Latin1TextConverter there, try StandardFileStream instead. ;) >>> >>> >>> Levente >> Latin1TextConverter does not do any conversion, no? ;) >> >> [StandardFileStream oldFileNamed: 'C:\Users\Rydier\Dropbox\Pharo 1.4 >> latest jenkins\Data.csv' >> do: [:stream | >> text := stream contents >> utf8ToSqueak ]] timeToRun 9221 >> >> Better? ;) > > Better, but not good enough :). I got the following in Squeak: > > [ FileStream readOnlyFileNamed: 'Data.csv' do: [ :file | > file contents ] ] timeToRun. > 2429 > > [ StandardFileStream readOnlyFileNamed: 'Data.csv' do: [ :file | > file contents utf8ToSqueak ] ] timeToRun. > 2288 > > Significant amount of time is spent finding the current leadingChar in > both cases. Using 0 as leadingChar in Unicode >> #value: gives the > following results: > > [ FileStream readOnlyFileNamed: 'Data.csv' do: [ :file | > file contents ] ] timeToRun. > 1152 > > [ StandardFileStream readOnlyFileNamed: 'Data.csv' do: [ :file | > file contents utf8ToSqueak ] ] timeToRun. > 1247 > > > Levente > > P.S.: To avoid measuring disk latency, the file was already in memory > during the tests. I fail to se how even those values are significant enough to warrant using utf8ToSqueak rather than let the converter take care of it, which was the point I contended in the first place. Cheers, Henry

Nov. 17, 2011

Re: [Pharo-project] WideString performance

by Levente Uzonyi

On Thu, 17 Nov 2011, Henrik Sperre Johansen wrote: > On 17.11.2011 11:26, Levente Uzonyi wrote: >> On Thu, 17 Nov 2011, Henrik Sperre Johansen wrote: >> >>> On 16.11.2011 21:45, Nicolas Cellier wrote: >>>> I think that there are several issues: >>>> >>>> 1) Character with codePoint< 256 are unique, but Wider are not. >>>> The characters are not stored in the WideString (which instead stores >>>> the code points), but any enumeration using at: rather than wordAt: >>>> will create an overhead. I presume that it would be better to have a >>>> #codePointAt: defined as #byteAt: in ByteString and #wordAt: in >>>> WideString, so we could still define generic methods in String. >>>> 2) A lot of ByteString methods are optimized with ad hoc optional >>>> primitives, but very few WideString methods are. >>>> 3) Some of these optimized operations work with 256 element masks and >>>> cannot be generalized to WideString that easily >>>> 4) Some Stream operations that copy one Collection to the stream >>>> buffer or vice versa are also not optimized for mixed byte/word >>>> collections >>>> 5) UTF8 is optimized for ASCII anyway... And Squeak/Pharo converters >>>> also are (because they can use more primitives in this case) >>>> 6) Pharo ripped #squeakToUtf8 and #utf8ToSqueak which were maybe >>>> questionable from quality POV, but were not replaced from efficiency >>>> POV. >>>> >>>> I would say that a new VM with immediate Character values might help, >>>> but that won't be enough. >>>> >>>> Nicolas >>> If I may object to point 6: >>> (Squeak) >>> [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream >>> contents]] timeToRun 6753 >>> (Pharo) >>> [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream >>> contents]] timeToRun 7027 >>> Reading without conversion, then converting with utf8ToSqueak: >>> [FileStream oldFileNamed: 'C:\Users\Rydier\Dropbox\Pharo 1.4 latest >>> jenkins\Data.csv' >>> do: [:stream | stream converter: Latin1TextConverter >>> new. >>> text := stream contents >>> utf8ToSqueak ]] timeToRun 9752 >> >> That's not "reading without conversion", you explicitly setting >> Latin1TextConverter there, try StandardFileStream instead. ;) >> >> >> Levente > Latin1TextConverter does not do any conversion, no? ;) > > [StandardFileStream oldFileNamed: 'C:\Users\Rydier\Dropbox\Pharo 1.4 latest > jenkins\Data.csv' > do: [:stream | > text := stream contents > utf8ToSqueak ]] timeToRun 9221 > > Better? ;) Better, but not good enough :). I got the following in Squeak: [ FileStream readOnlyFileNamed: 'Data.csv' do: [ :file | file contents ] ] timeToRun. 2429 [ StandardFileStream readOnlyFileNamed: 'Data.csv' do: [ :file | file contents utf8ToSqueak ] ] timeToRun. 2288 Significant amount of time is spent finding the current leadingChar in both cases. Using 0 as leadingChar in Unicode >> #value: gives the following results: [ FileStream readOnlyFileNamed: 'Data.csv' do: [ :file | file contents ] ] timeToRun. 1152 [ StandardFileStream readOnlyFileNamed: 'Data.csv' do: [ :file | file contents utf8ToSqueak ] ] timeToRun. 1247 Levente P.S.: To avoid measuring disk latency, the file was already in memory during the tests. > > Cheers, > Henry > >

Nov. 17, 2011

Re: [Pharo-project] ProcessWrapper crashes image on startup

by Levente Uzonyi

On Thu, 17 Nov 2011, HernÃ¡n Morales Durand wrote: > Anyone working with ProcessWrapper.dll plugin in Pharo 1.3? I've > tested a bit and saved the image after a full GC. Now my developement > image became unusable crashing on opening under all updated VM's > (Croquet, CogVM and Stack). Moving out the .dll from image directory > makes the image unresponsive. > Any idea? Seems like the finalization registry was not cleaned up before shutdown. Levente > crash.dmp attached. > > Cheers, > > HernÃ¡n >

Nov. 17, 2011

Re: [Pharo-project] OpenGL in Pharo?

by Igor Stasenko

On 17 November 2011 11:22, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Igor is working on it i've heard. I am also waiting for it > NativeBoost bindings for OpenGL working fine under Windows. On Macs and Linux there still missing platform-specific glue code to initialize context. I started Mac implementation recently, but i didn't finished it. Since there are increasing interest, i will try to finish it in nearest days. > Alexandre > > > On 17 Nov 2011, at 04:52, Michele Lanza <michele.lanza(a)usi.ch> wrote: > >> Dear all, >> I wanted to ask whether there are some news I missed with respect to having a decent OpenGL framework in Pharo. I checked the following page: >> >> http://book.pharo-project.org/book/LanguageAndLibraries/3DGraphicsAndOpenGL/ >> >> ..but it sounds all a bit outdated and not something I can rely on in the long run. Ideally there should be something like the Jun framework (available for VisualWorks), but when I met the Jun maker at ICSE and I asked him whether there were any plans of porting Jun to Pharo he told me that it was not in their plans. Long talk, short sense: Is anyone working on OpenGL for Pharo? >> >> Cheers >> >> Michele > > -- Best regards, Igor Stasenko.

Nov. 17, 2011

Re: [Pharo-project] WideString performance

by Henrik Sperre Johansen

On 17.11.2011 11:26, Levente Uzonyi wrote: > On Thu, 17 Nov 2011, Henrik Sperre Johansen wrote: > >> On 16.11.2011 21:45, Nicolas Cellier wrote: >>> I think that there are several issues: >>> >>> 1) Character with codePoint< 256 are unique, but Wider are not. >>> The characters are not stored in the WideString (which instead stores >>> the code points), but any enumeration using at: rather than wordAt: >>> will create an overhead. I presume that it would be better to have a >>> #codePointAt: defined as #byteAt: in ByteString and #wordAt: in >>> WideString, so we could still define generic methods in String. >>> 2) A lot of ByteString methods are optimized with ad hoc optional >>> primitives, but very few WideString methods are. >>> 3) Some of these optimized operations work with 256 element masks and >>> cannot be generalized to WideString that easily >>> 4) Some Stream operations that copy one Collection to the stream >>> buffer or vice versa are also not optimized for mixed byte/word >>> collections >>> 5) UTF8 is optimized for ASCII anyway... And Squeak/Pharo converters >>> also are (because they can use more primitives in this case) >>> 6) Pharo ripped #squeakToUtf8 and #utf8ToSqueak which were maybe >>> questionable from quality POV, but were not replaced from efficiency >>> POV. >>> >>> I would say that a new VM with immediate Character values might help, >>> but that won't be enough. >>> >>> Nicolas >> If I may object to point 6: >> (Squeak) >> [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream >> contents]] timeToRun 6753 >> (Pharo) >> [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream >> contents]] timeToRun 7027 >> Reading without conversion, then converting with utf8ToSqueak: >> [FileStream oldFileNamed: 'C:\Users\Rydier\Dropbox\Pharo 1.4 latest >> jenkins\Data.csv' >> do: [:stream | stream converter: >> Latin1TextConverter new. >> text := stream contents >> utf8ToSqueak ]] timeToRun 9752 > > That's not "reading without conversion", you explicitly setting > Latin1TextConverter there, try StandardFileStream instead. ;) > > > Levente Latin1TextConverter does not do any conversion, no? ;) [StandardFileStream oldFileNamed: 'C:\Users\Rydier\Dropbox\Pharo 1.4 latest jenkins\Data.csv' do: [:stream | text := stream contents utf8ToSqueak ]] timeToRun 9221 Better? ;) Cheers, Henry

Nov. 17, 2011

Re: [Pharo-project] WideString performance

by Levente Uzonyi

On Thu, 17 Nov 2011, Henrik Sperre Johansen wrote: > On 16.11.2011 21:45, Nicolas Cellier wrote: >> I think that there are several issues: >> >> 1) Character with codePoint< 256 are unique, but Wider are not. >> The characters are not stored in the WideString (which instead stores >> the code points), but any enumeration using at: rather than wordAt: >> will create an overhead. I presume that it would be better to have a >> #codePointAt: defined as #byteAt: in ByteString and #wordAt: in >> WideString, so we could still define generic methods in String. >> 2) A lot of ByteString methods are optimized with ad hoc optional >> primitives, but very few WideString methods are. >> 3) Some of these optimized operations work with 256 element masks and >> cannot be generalized to WideString that easily >> 4) Some Stream operations that copy one Collection to the stream >> buffer or vice versa are also not optimized for mixed byte/word >> collections >> 5) UTF8 is optimized for ASCII anyway... And Squeak/Pharo converters >> also are (because they can use more primitives in this case) >> 6) Pharo ripped #squeakToUtf8 and #utf8ToSqueak which were maybe >> questionable from quality POV, but were not replaced from efficiency >> POV. >> >> I would say that a new VM with immediate Character values might help, >> but that won't be enough. >> >> Nicolas > If I may object to point 6: > (Squeak) > [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream contents]] > timeToRun 6753 > (Pharo) > [FileStream oldFileNamed: 'Data.csv' do: [:stream | text := stream contents]] > timeToRun 7027 > Reading without conversion, then converting with utf8ToSqueak: > [FileStream oldFileNamed: 'C:\Users\Rydier\Dropbox\Pharo 1.4 latest > jenkins\Data.csv' > do: [:stream | stream converter: Latin1TextConverter new. > text := stream contents > utf8ToSqueak ]] timeToRun 9752 That's not "reading without conversion", you explicitly setting Latin1TextConverter there, try StandardFileStream instead. ;) Levente > > The efficiency drain in this example is, as Dennis points out, CSVParser > adding scanned characters 1 by 1 to the WideString representing current > value. > > Cheers, > Henry > > > >

Nov. 17, 2011

Re: [Pharo-project] OpenGL in Pharo?

by Alexandre Bergel

Igor is working on it i've heard. I am also waiting for it Alexandre On 17 Nov 2011, at 04:52, Michele Lanza <michele.lanza(a)usi.ch> wrote: > Dear all, > I wanted to ask whether there are some news I missed with respect to having a decent OpenGL framework in Pharo. I checked the following page: > > http://book.pharo-project.org/book/LanguageAndLibraries/3DGraphicsAndOpenGL/ > > ..but it sounds all a bit outdated and not something I can rely on in the long run. Ideally there should be something like the Jun framework (available for VisualWorks), but when I met the Jun maker at ICSE and I asked him whether there were any plans of porting Jun to Pharo he told me that it was not in their plans. Long talk, short sense: Is anyone working on OpenGL for Pharo? > > Cheers > > Michele

Nov. 17, 2011