- Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20131

by StÃ©phane Ducasse

20131 ----- - Issue 6060: New some ensure methods to FileSystem. Thanks Sean De Nigris and Mariano Martinez-Peck. http://code.google.com/p/pharo/issues/detail?id=6060.

June 14, 2012

[Pharo-project] [update 2.0] #20130

by StÃ©phane Ducasse

20130 ----- - Issue 6059: Problem with FileHandle >> open. http://code.google.com/p/pharo/issues/detail?id=6059 - Issue 6056: Typo updete in TestRunner http://code.google.com/p/pharo/issues/detail?id=6056 - Issue 6062: faster InstructionStream>>#interpret http://code.google.com/p/pharo/issues/detail?id=6062

June 14, 2012

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

by StÃ©phane Ducasse

Ok so join forces and propose something. On Jun 14, 2012, at 3:19 PM, Denis Kudriashov wrote: > 2012/6/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > If one group of guys would take the lead we could introduce XTream in 2.0 and slowly start to integrate and deprecate slowly the old streams. Who is interested in that? > > > I am very very want it:)

June 14, 2012

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

by Damien Cassou

On Thu, Jun 14, 2012 at 3:19 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I am very very want it:) I guess the question was not "who would like this?" but more "who will take the lead and make it happen?" To you or Nicolas want to take the lead and make it happen? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 14, 2012

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

by Denis Kudriashov

2012/6/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > If one group of guys would take the lead we could introduce XTream in 2.0 > and slowly start to integrate and deprecate slowly the old streams. Who is > interested in that? > > I am very very want it:)

June 14, 2012

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

by Henrik Sperre Johansen

On 13.06.2012 14:59, Igor Stasenko wrote: > 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. So, is this a one-off for Cairo, or are you planning on introducing a <var: #myStringParameter encoding: #utfXX> pragma or something to NBFFI? Because, on Windows system calls either expect the local system code page, or utf16 (depending on which version of the API you use), while the in other libraries the expected encoding may be different from the one of the system libraries. Heck, the same lib may expect different encodings, case in point: The expected encoding of the Oracle client lib (and by extension DBXTalk*) depends on either an environment variable, what you told it to expect using an API function, or one of many other fallbacks I can't remember at the moment. Cheers, Henry *<rant> OpenDBX makes an explicity choice to simply pass the data you hand it over to whatever backend you have hooked up raw. Very nice of a library that does a good job of abstracting the actual API of communicating with a database to leave it up to you to decide which encoding to use (which depends on the abstracted away backend...) if you want your data stored correctly... There is a reason those benchmarks are fast! :) </rant>

June 14, 2012

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

by petton.nicolas＠gmail.com

StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> writes: > If one group of guys would take the lead we could introduce XTream in > 2.0 and slowly start to integrate and deprecate slowly the old > streams. Who is interested in that? Me. Nico > > Stef > >>>>> Tx >>>>> >>>>> now there is a difference between adjustments and fully new API and I >>>>> would have preferred adjustments. >>>>> >>>>> Stef >>>> >>>> IMO, Xtreams design is simply superior. >>> >>> +100. >>> I gave up on trying to mold the current Streams into something a bit more >>> reasonable and still be backwards compatible quite some time ago. >>> >>> That other thread about Converters? >>> Totally related. For example, you can't do what Sven did in the Zn >>> converters without breaking backwards compatability. Nor could you do it >>> reasonably fast in the general case, since fast string -> bytearray >>> streaming works for some streams, but not for others. (which, I guess, is >>> one reason why the legacy converters do string -> string.) >>> >>> IMHO, Xtreams would be a perfect fit to go with the new FileSystem as well. >>> (using compositing on top of a "dumb" terminal) >>> >> >> Quite sure that it is highly ranked in Colin's plans. >> >>>> But i agree, we cannot throw existing streams out.. too much things >>>> tied to them, and rely >>>> on using stream protocols. :( >>> >>> Well, one*could* try to introduce something akin to the Zn HTTPClient >>> compatability protocol, strictly speaking what you can do with Xtreams is a >>> superset of what Streams currently do. >>> The problem is all the moronic quirks of the current Streams, and clients >>> potentially relying on that behaviour. >>> >>> Cheers, >>> Henry >>> >>> >>> >> > > -- Nicolas Petton http://nicolas-petton.fr

June 14, 2012

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

by StÃ©phane Ducasse

I would also really like to have a chapter based on the documentation (if any). > If one group of guys would take the lead we could introduce XTream in 2.0 and slowly start to integrate and deprecate slowly the old streams. Who is interested in that?

June 14, 2012

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

by StÃ©phane Ducasse

>> > > Indeed, with the new FS being almost ready in 2.0 the next big mess to > tackle are the streams. > > Personally I really liked the clean separation of the low level stream > features (bytes) and the high-level interfaces to it (converters, characters...) > > but the question remains on how to integrate them into a running system ;) > > after having done the FS take-over I see that it's rather easy to create > an image that works with the replaced classes. But creating a nice loadable > slice / changeset is a rather fragile and tedious task :P We can just have dedicated sprints. I think that tomorrow I would like to finish with you the FS part. Then I would not open the Xtreams work now but plan it. Stef

June 14, 2012

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

by Camillo Bruni

>>> >> +100. >> I gave up on trying to mold the current Streams into something a bit more >> reasonable and still be backwards compatible quite some time ago. >> >> That other thread about Converters? >> Totally related. For example, you can't do what Sven did in the Zn >> converters without breaking backwards compatability. Nor could you do it >> reasonably fast in the general case, since fast string -> bytearray >> streaming works for some streams, but not for others. (which, I guess, is >> one reason why the legacy converters do string -> string.) >> >> IMHO, Xtreams would be a perfect fit to go with the new FileSystem as well. >> (using compositing on top of a "dumb" terminal) >> > > Quite sure that it is highly ranked in Colin's plans. Indeed, with the new FS being almost ready in 2.0 the next big mess to tackle are the streams. Personally I really liked the clean separation of the low level stream features (bytes) and the high-level interfaces to it (converters, characters...) but the question remains on how to integrate them into a running system ;) after having done the FS take-over I see that it's rather easy to create an image that works with the replaced classes. But creating a nice loadable slice / changeset is a rather fragile and tedious task :P

June 14, 2012