- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] Look and font competition

by camille teruel

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?

June 13, 2012

Re: [Pharo-project] recompiling class

by Marcus Denker

> On 11 June 2012 09:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> The whole point about improving the system is to then use the improvements. >> Else what's the point in improving anything? >> > > Hi, from Capt. Obvious :) > The sad fact is that this is not obvious... far from it. Marcus -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

June 13, 2012

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

by Philippe Marschall

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. 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

June 13, 2012

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

by Marcus Denker

On Jun 13, 2012, at 10:07 AM, Sven Van Caekenberghe wrote: > Hi Igor, > > It is very good that someone tries to optimize this, it is a weak point currently, performance wise. > > I am not a low-level guy, so I can't really help with the assembler code. But utf-8 encoding/decoding is an area that interests me. > > I can point to the 2 currently available utf-8 encoders/decoders that I know of, as this might be instructive for your quest (provided you did not already know of them): > > UTF8TextConverter > ZnUTF8Encoder > > In Seaside, there is some optimization code in > > GRPharoUtf8CodecStream>>#encodeFast: > We shoud standardize on *one* converter... what is the use of everyone doing it again? Marcus -- Marcus Denker -- http://marcusdenker.de

June 13, 2012

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by Mariano Martinez Peck

- Added #deleteIfAbsent: , #ensureDeleted and #ensureClosed. - Added #testDeleteIfAbsent, #testEnsureClosed, #testEnsureDeleted and #testExists. - Make FileSystemHandleTest >> tearDown more robust by using ensure* methods. I have know much about FileSystem so if someone can check please. I don't know if the classes where I place the unit tests are the correct place. http://code.google.com/p/pharo/issues/detail?id=6060 thanks On Tue, Jun 12, 2012 at 10:57 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Mariano Martinez Peck wrote > > > > Hi sean. It's time you update your image ;) > > ...does not work with > > Pharo2.0a > > Latest update: #20129 > > > > Ah yes. Now it's broken... I feel much better :) > > -- > View this message in context: > http://forum.world.st/FileReference-should-throw-error-when-deleting-unexis… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

June 13, 2012