June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] WriteStream, nextPutAll:, OrderedCollections

by Guillermo Polito

soo, what do I do? :D On 6/13/12, Camillo Bruni <camillobruni(a)gmail.com> wrote: > yup I know that :D > And I provided a fix on e year ago, that got lost in a big refactoring... > - I added an explicit #streamSpecies on the Collection classes. > - By default it returns the same class > - on Set / OrderedCollection / Symbol it returns the mutable types > (LinkedList as well I think) > - overwrote #streamContents: to convert from the #streamSpecies type back to > the original class > > > > On 2012-06-13, at 14:56, Guillermo Polito wrote: > >> Hi guys! >> >> I'm chasing a bug that appeared in glorp under pharo 1.4. Now, the >> bug is due to some behavior changed in OrderedCollection I think. Look >> at this piece of code: >> >> >> oc := OrderedCollection new. >> ws := oc writeStream. >> >> "this explodes" >> ws nextPutAll: (OrderedCollection with: 1 with: 2 with: 3). >> >> "this works" >> ws nextPutAll: {1.2.3} >> >> >> And I'm puzzled, why should one work and the other not from the pov of the >> user? >> And how should I replace that behavior if it's my bug? >> >> putting an asArray for each nextPutAll: does not look good for me... :S >> >> Tx, >> Guille >> > > >

June 13, 2012

Re: [Pharo-project] Look and font competition

by Igor Stasenko

On 13 June 2012 14:51, camille teruel <camille.teruel(a)gmail.com> wrote: > EFL stands for Enlightenment Foundation Librairies > It is a set of C librairies that are used for the E17 window manager (a > famous vaporware). > E17 is still in alpha (since a very long time but it is usable, give it a > try if you have a linux distro somewhere), because they're currently working > on EFLs stabilisation.Â These libraries have a pretty good reputation. > That's the main website:Â http://www.enlightenment.org/ > The canva library is called Evas. > ahh.. Enlightenment.. it was vaporware since the first time i saw it, back in 98 (i think) :) > > > 2012/6/13 Igor Stasenko <siguctua(a)gmail.com> >> >> On 13 June 2012 10:52, camille teruel <camille.teruel(a)gmail.com> wrote: >> > 2012/6/12 Igor Stasenko <siguctua(a)gmail.com> >> >> >> >> On 12 June 2012 23:28, Helene Bilbo >> >> <thereluctantprogrammer(a)fastmail.fm> >> >> wrote: >> >> > The subtle texture is more like overlaying the existing elements with >> >> > white >> >> > noise. >> >> > >> >> > While one can make an IconicButton of course, one can not make a >> >> > Window >> >> > Title Bar this way. There must be a way to make it directly in code? >> >> > With >> >> > more and more high resolution displays it will get interesting some >> >> > day. >> >> > Look at the OS X Lion - Pharo comparison screenshot: >> >> > >> >> > http://forum.world.st/file/n4634551/SubtleTexture.jpg >> >> > >> >> >> >> oh .. it is indeed subtle.. i didn't get what you mean first time. >> >> yes, of course, that's possible.. just not sure if it worth to waste >> >> CPU cycles on this, as you said,Â subtle stuff. >> > >> > >> > EFLs use bitmaps to render everything, it runs fast, you don't need >> > antialiasing, and you can customize the appearance however you like. >> > Couldn't it be an inspiration? >> >> EFL? what is it.. got a link? >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

June 13, 2012

Re: [Pharo-project] WriteStream, nextPutAll:, OrderedCollections

by Camillo Bruni

yup I know that :D And I provided a fix on e year ago, that got lost in a big refactoring... - I added an explicit #streamSpecies on the Collection classes. - By default it returns the same class - on Set / OrderedCollection / Symbol it returns the mutable types (LinkedList as well I think) - overwrote #streamContents: to convert from the #streamSpecies type back to the original class On 2012-06-13, at 14:56, Guillermo Polito wrote: > Hi guys! > > I'm chasing a bug that appeared in glorp under pharo 1.4. Now, the > bug is due to some behavior changed in OrderedCollection I think. Look > at this piece of code: > > > oc := OrderedCollection new. > ws := oc writeStream. > > "this explodes" > ws nextPutAll: (OrderedCollection with: 1 with: 2 with: 3). > > "this works" > ws nextPutAll: {1.2.3} > > > And I'm puzzled, why should one work and the other not from the pov of the user? > And how should I replace that behavior if it's my bug? > > putting an asArray for each nextPutAll: does not look good for me... :S > > Tx, > Guille >

June 13, 2012

Re: [Pharo-project] Fastest utf-8 encoder contest

by Igor Stasenko

On 13 June 2012 10:31, Philippe Marschall <philippe.marschall(a)netcetera.ch> wrote: > On 06/13/2012 04:44 AM, Igor Stasenko wrote: >> Hi, hardcore hackers. >> please take a look at the code and tell if it can be improved. >> >> The AsmJit snippet below transforms an unicode integer value >> to 1..4-byte sequence of utf-8 >> >> then the outer piece of code (which is not yet written) will >> accumulate the results of this snippet >> to do a memory-aligned (4byte) writes.. >> like that, if 4 unicode characters can be encoded into 4 utf-8 bytes >> (which mostly the case for latin-1 char range), then there will be >> 4 memory reads (to read four 32-bit unicode values) but only single >> memory write (to write four 8-bit utf-8 encoded values). >> >> The idea is to make utf-8 encoding speed close to memory copying speed :) > > In Seaside we use an other trick that Andreas Raab come up with. The > assumption is that most of the strings are ASCII [1]. We use a CharSet / > bitmap to quickly scan the string for the index of the first non-ASCII > character. If we find none we just answer the argument. No copying at all. > Well, in my case i will need copying because i need to null-terminate it, to represent it as null-terminated string. This is what cairo library expects as input for rendering text. And this also means that i can use a single buffer for conversions to avoid generating garbage, i.e. i take input string, convert it to utf8 in private buffer, then pass that buffer as input to external call, on next call an input can be any other string, but output will be the same private buffer. I will be needing to allocate new buffer if incoming string does not fits into it. > In Seaside 3.1 we go one step further. Imagine you have a long > ByteString and only few non-ASCII characters. We do not want to have to > copy the whole string just to utf-8 encode a few characters, so we > combine the above approach with #next:putAll:startingAt: so that we only > have to encode and copy the non-ASCII characters, everything else is not > copied. > > I have become quite paranoid about allocation in Pharo. If I can remove > about two or three #streamContents: I can get about 100 to 200 req/s more. > > Â [1] This seems to be true for the rendering code in Seaside since it > renders many small snippets. Even if you have several non-ASCII strings > on a page since each string is rendered individually all the rest will > still be ASCII. > > Cheers > Philippe > > -- Best regards, Igor Stasenko.

June 13, 2012

[Pharo-project] WriteStream, nextPutAll:, OrderedCollections

by Guillermo Polito

Hi guys! I'm chasing a bug that appeared in glorp under pharo 1.4. Now, the bug is due to some behavior changed in OrderedCollection I think. Look at this piece of code: oc := OrderedCollection new. ws := oc writeStream. "this explodes" ws nextPutAll: (OrderedCollection with: 1 with: 2 with: 3). "this works" ws nextPutAll: {1.2.3} And I'm puzzled, why should one work and the other not from the pov of the user? And how should I replace that behavior if it's my bug? putting an asArray for each nextPutAll: does not look good for me... :S Tx, Guille

June 13, 2012

Re: [Pharo-project] Look and font competition

by camille teruel

EFL stands for Enlightenment Foundation Librairies It is a set of C librairies that are used for the E17 window manager (a famous vaporware). E17 is still in alpha (since a very long time but it is usable, give it a try if you have a linux distro somewhere), because they're currently working on EFLs stabilisation. These libraries have a pretty good reputation. That's the main website: http://www.enlightenment.org/ The canva library is called Evas. 2012/6/13 Igor Stasenko <siguctua(a)gmail.com> > On 13 June 2012 10:52, camille teruel <camille.teruel(a)gmail.com> wrote: > > 2012/6/12 Igor Stasenko <siguctua(a)gmail.com> > >> > >> On 12 June 2012 23:28, Helene Bilbo <thereluctantprogrammer(a)fastmail.fm > > > >> wrote: > >> > The subtle texture is more like overlaying the existing elements with > >> > white > >> > noise. > >> > > >> > While one can make an IconicButton of course, one can not make a > Window > >> > Title Bar this way. There must be a way to make it directly in code? > >> > With > >> > more and more high resolution displays it will get interesting some > day. > >> > Look at the OS X Lion - Pharo comparison screenshot: > >> > > >> > http://forum.world.st/file/n4634551/SubtleTexture.jpg > >> > > >> > >> oh .. it is indeed subtle.. i didn't get what you mean first time. > >> yes, of course, that's possible.. just not sure if it worth to waste > >> CPU cycles on this, as you said, subtle stuff. > > > > > > EFLs use bitmaps to render everything, it runs fast, you don't need > > antialiasing, and you can customize the appearance however you like. > > Couldn't it be an inspiration? > > EFL? what is it.. got a link? > > > -- > Best regards, > Igor Stasenko. > >

June 13, 2012

[Pharo-project] New journal paper about Fuel serializer

by Mariano Martinez Peck

Hi guys. If you are interested in learning about Fuel's internals, its differences with other serializers, etc, I invite you to read our journal paper that has just been accepted. This paper is *much* better than the version of the ESUG workshop (in case you have read that one). You can find the pdf here: http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf Fuel website: http://rmod.lille.inria.fr/web/pier/software/Fuel Cheers, -- Mariano http://marianopeck.wordpress.com

June 13, 2012

Re: [Pharo-project] Fastest utf-8 encoder contest

by Igor Stasenko

On 13 June 2012 11:40, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 13.06.2012 10:31, Philippe Marschall wrote: >> >> On 06/13/2012 04:44 AM, Igor Stasenko wrote: >>> >>> Hi, hardcore hackers. >>> please take a look at the code and tell if it can be improved. >>> >>> The AsmJit snippet below transforms an unicode integer value >>> to 1..4-byte sequence of utf-8 >>> >>> then the outer piece of code (which is not yet written) will >>> accumulate the results of this snippet >>> to do a memory-aligned (4byte) writes.. >>> like that, if 4 unicode characters can be encoded into 4 utf-8 bytes >>> (which mostly the case for latin-1 char range), then there will be >>> 4 memory reads (to read four 32-bit unicode values) but only single >>> memory write (to write four 8-bit utf-8 encoded values). >>> >>> The idea is to make utf-8 encoding speed close to memory copying speed :) >> >> >> In Seaside 3.1 we go one step further. Imagine you have a long >> ByteString and only few non-ASCII characters. We do not want to have to >> copy the whole string just to utf-8 encode a few characters, so we >> combine the above approach with #next:putAll:startingAt: so that we only >> have to encode and copy the non-ASCII characters, everything else is not >> copied. >> >> >> Cheers >> Philippe >> >> > Both Pharo and Squeak default TextConverters have done something similar for > the last 1 1/2 years, see (in Pharo) nextPutByteString:toSteam: > What Igor describes seems aimed at encoding WideString -> utf8 though, which > is still slow with the default converters. > > As to the assembly, is leadingChar gone entirely? Otherwise the branching > may fail miserably. > yes. In Pharo, leadingchar == 0 is unicode. of course i can add another branch to check if unicode value is greater than 16r10FFFF and just fail primitive if it is. > > Cheers, > Henry -- Best regards, Igor Stasenko.

June 13, 2012

Re: [Pharo-project] Zinc: Detect failed binds

by Ben Coman

Mark Smith wrote: > Hi :), > > Does anyone know if there's a way to detect if a Zinc Server doesn't bind to a port, (probably because there's already a server listening on that port), and signal an error? > > Thanks a lot, > > Mark > > As a backup plan... why not from one code path (perhaps requiring a fork) 1. start Zinc Server 2. generate random magic number 3. connect to server as a client requesting magic number. 4. check returned magic number matches the one from (2)

June 13, 2012

Re: [Pharo-project] Look and font competition

by Igor Stasenko

On 13 June 2012 10:52, camille teruel <camille.teruel(a)gmail.com> wrote: > 2012/6/12 Igor Stasenko <siguctua(a)gmail.com> >> >> On 12 June 2012 23:28, Helene Bilbo <thereluctantprogrammer(a)fastmail.fm> >> wrote: >> > The subtle texture is more like overlaying the existing elements with >> > white >> > noise. >> > >> > While one can make an IconicButton of course, one can not make a Window >> > Title Bar this way. There must be a way to make it directly in code? >> > With >> > more and more high resolution displays it will get interesting some day. >> > Look at the OS X Lion - Pharo comparison screenshot: >> > >> > http://forum.world.st/file/n4634551/SubtleTexture.jpg >> > >> >> oh .. it is indeed subtle.. i didn't get what you mean first time. >> yes, of course, that's possible.. just not sure if it worth to waste >> CPU cycles on this, as you said,Â subtle stuff. > > > EFLs use bitmaps to render everything, it runs fast, you don't need > antialiasing, and you can customize the appearance however you like. > Couldn't it be an inspiration? EFL? what is it.. got a link? -- Best regards, Igor Stasenko.

June 13, 2012