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

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

[Pharo-project] Zinc: Detect failed binds

by Mark Smith

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

June 13, 2012

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

by Henrik Sperre Johansen

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. Cheers, Henry

June 13, 2012

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

by Sven Van Caekenberghe

On 13 Jun 2012, at 11:08, 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 > - 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 ;) + 1 > So far, this and the bugfixes we already made (and some more)... > > What do you think? > > Esteban Would it be hard to also preload Nautilus, as a preview ? Many people, including myself, really like Nautilus a lot. And it deserves it. The counter indication would be if this would make life harder on Benjamin. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

June 13, 2012

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

by Sven Van Caekenberghe

On 13 Jun 2012, at 10:29, Marcus Denker wrote: > We shoud standardize on *one* converter... what is the use of everyone doing it again? Ultimately, yes, there should be one. However, it does not hurt that multiple people are working on the same subject even if that sometimes means multiple implementations coexist in one image. It is one of the ways that open source software advances. As for my rationale for ZnUTF8Encoder: http://zn.stfx.eu/zn/zinc-http-components-paper.html#characterencoding << ZnCharacterEncoding is an extension and reimplementation of regular TextConverter. It only works on binary input and generated binary output. It adds the ability to compute the encoded length of a source character, a crucial operation for HTTP. It is more correct and will throw proper exceptions when things go wrong. >> Throwing out and replacing fundamental system classes is hard. New designs often are not 100% API compatible or change the semantics, on purpose. Look at the #isBinary test in UTF8TextConverter>>nextFromStream and nextPut:toStream, it is so broken. Can it be fixed ? I don't know. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

June 13, 2012

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

by Esteban Lorenzano

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

June 13, 2012