- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by btc＠openInWorld.com

Esteban Lorenzano wrote: > Hi, > > I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). > I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click: > > - pre-load OmniBrowser. > Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). > Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. > Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser. > > +1 for newcomer consideration. Nautilus is obviously well liked by the more experienced users who can deal better with the odd issue and modification that pops up, but an older code base might be better for new users for now. Thanks for the advance notice. I've just got to the point in the 1.4 review of Pharo By Example that I am taking snapshots of the browser and tossing up which browser to include. I was leaning towards using only the basic 1.4-built-in browser to try to make each chapter independent of previous ones - but much happier to snapshot OB. So unless any objections arise, I will do PBE with OB. These will need redoing for the 2.0 look and feel anyway, and PBE can be changed to Nautilus then. > - pre-load Spotlight > Yeah, another small tool who can make your life easy. > Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. > That would be me. I'm not familiar with Spotlight but it sounds like I'll like it. > If you still prefer those ways, is up to you ;) > > So far, this and the bugfixes we already made (and some more)... > > What do you think? > > Esteban > >

June 13, 2012

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

by Mark Smith

Thanks Sven. That's working now :). On 13 Jun 2012, at 11:22, Sven Van Caekenberghe wrote: > Mark, > > On 13 Jun 2012, at 12:09, 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 > > Good question. > > Try > > server isRunning & server isListening > > as is done by most unit tests using #withServerDo: > > HTH, > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

June 13, 2012

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

by Philippe Marschall

On 06/13/2012 11:40 AM, Henrik Sperre Johansen 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: Yes, it's the name approach apart from that our converters also support #next:putAll:startingAt:. We use the same approach for quick HTML and URL encoding so these converters feed into the utf-8 converter. Cheers Philippe

June 13, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by phil＠highoctane.be

Esteban, Definitely worth doing!!! Install all the stuff I need on new images etc just to the have to discard them for some reason doesn't makes me reinstall anything afterwards. Tried to work the way of Mariano with the "ConfigurationOfXXXX" but frankly, let it fall by the wayside. Just too many problems with loading packages that do work well together etc. And no refactoring out of the box in 1.4 is really lame indeed. As for Nautilus in 2.0, the regular yellow crosses on red background are getting on my nerves, especially since I don't know why they do appear.$ So, yeah: +100000000 Philippe 2012/6/13 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). > I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click: > > - pre-load OmniBrowser. > Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). > Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. > Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser. > > - pre-load Spotlight > Yeah, another small tool who can make your life easy. > Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. > If you still prefer those ways, is up to you ;) > > So far, this and the bugfixes we already made (and some more)... > > What do you think? > > Esteban -- Philippe Back Dramatic Performance Improvments Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 13, 2012

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

by Sven Van Caekenberghe

Mark, On 13 Jun 2012, at 12:09, 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 Good question. Try server isRunning & server isListening as is done by most unit tests using #withServerDo: HTH, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

June 13, 2012