- Pharo-dev - lists.pharo.org

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)
by StÃ©phane Ducasse Oct. 8, 2010

Oct. 8, 2010

I do not know. ;) I need time and concentration to give aware feedback Stef On Oct 7, 2010, at 11:29 PM, Schwab,Wilhelm K wrote: > Stef, > > Do you have any interest in my alternate protocol idea? In short, #next is misleading even on VW. When I learned that, I pretty much gave up on a robust implementation and did the logical thing: made the alternate selectors and started writing all of my new code in terms of them. It is a lot quicker to type a few extra characters than to spend a lot of time chasing down side effects rather than original errors. By simply making new code work better, the backward compatibility problem largely evaporates. It's a shame that perfectly good selectors #next and #next: are usurped, but that's how it is unless we want to break a lot of old code. > > One interesting observation (not mine) is that many #next and #next: senders in the image are vulnerable to defects if they get other than expected results. Robust semantics would break some things, but call attention to lurking bugs elsewhere. > > I will happily make the alternate selector code available if you want it; in fact, an old version is in the in box. In the past, you expressed concerns about getting exhaustion errors when you don't want them. My answer is that #nextAvailable: exists for that purpose - it "authorizes" truncation. You can also add a #nextOrNil if you must (I might even have it for benefit of some of my older code). In Pharo, #nextOrNil is trivial: just delegate to #next. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Thursday, October 07, 2010 4:25 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!) > > Thanks nicolas > Indeed we would love to have a clean covered with test composable stream hierarchy > the idea behind nile was to make it compatible, integrate it and then clean but may be we should have done > otherwise. > > It would be good to have a path to get streams cleaned, but my time is counted. > > Stef > On Oct 7, 2010, at 9:41 PM, Nicolas Cellier wrote: > >> Yes, every time I must warn and apologize because I'm guilty of >> hijacking the name. >> The goals are more or less the same, because I also hijacked some >> ideas (though not all invented at VW): >> - separate read/write stream >> - use stream wrappers >> - implement main sequenceable collection API >> (more to be found at http://www.squeaksource.com/XTream.html wiki page) >> >> There are also Squeak specific goals: >> - clean the mess by first principles (just an excerpt >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141786… >> ) >> - accelerate MultiByteFileStream >> >> At time Squeak Xtream started, there was no license for VW Xtream, so >> it's a full rewrite from scratch. >> Thus implementation differs. Mainly I did not reify the Buffer (the >> master piece of original VW Xtream). >> Due to this, I've got a BufferedReadWriteStream, which is >> contradictory to goal 1). >> It might change in future. >> I also do not want to depend too much on Exception handling, which >> current VW Buffer implementation does. >> >> Also, I did not replace the whole protocol, but rather reused existing one. >> That's because further goal is to provide a replacement for Squeak >> Streams (could apply to Pharo too, but there's a possible overlap with >> Nile* See note below). >> However, I currently made no plan to reach this goal. I just have some >> toy images that I break regularly due to lack of compatibility... >> Either I implement all the messy protocol that flourished in Squeak, >> or I try to stay a bit cleaner but with uncompatibilities... >> Maybe a separate compatibility package with a deprecation policy might help... >> >> Be aware that recent Squeak and Pharo acceleration thanks to buffering >> was first experimented in Squeak Xtream, and then ported by talents of >> Levente, that's already a little reward. >> Some big acceleration could be gained other UTF8 streams when a >> majority of characters are ASCII (the case of source code management >> and most latin characters texts), both in cog and traditional vm. >> My current tests (cog) are: >> >> { >> [| tmp | tmp := (MultiByteFileStream readOnlyFileNamed: (SourceFiles >> at: 2) name) ascii; wantsLineEndConversion: false; converter: >> UTF8TextConverter new. >> 1 to: 20000 do: [:i | tmp upTo: Character cr]. tmp close] timeToRun. >> [| tmp | tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles >> at: 2) name) readXtream binary buffered ~> UTF8Decoder) buffered. >> 1 to: 20000 do: [:i | tmp upTo: Character cr]. tmp close] timeToRun. >> } >> #(163 21) >> >> So, Xtream is around 8x faster at reading first 20000 lines of change >> log... No surprise it's more than 99% pure ASCII. >> >> Last, concerning the errors, it's more a matter of fixing the tests >> themselves... >> They use #squeakToUtf8 as a reference, and some tests are for other >> unloaded XTream packages. >> I started to change the test last night but did not publish all... >> >> See also: >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15357… >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141539… >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141647… >> and more mails in november/december 2009 >> >> more dated material http://bugs.squeak.org/view.php?id=6755 >> and various attempts like LazyStream/LazyCollections... >> >> Nicolas >> >> * Note about Nile: >> Nile has a different approach: do not eliminate ReadWriteStreams, but >> compose with traits. >> Nile also has high test coverage level, which is good. >> Nile was designed as a Stream replacement for Squeak Stream... >> As such, it carries some cruft (same dilemna as Squeak Xtream). >> Pharo goal is to perform major clean-up. As a mean to reach this goal, >> it shall not encumber with backward compatibility. This means that >> once Nile adopted (with historical compatibility cruft), it should be >> cleaned up again... >> >> 2010/10/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> pay attention that there are two xtreams package frameworks from what I understand >>> >>> one presented at esug and one developed by nicolas >>> >>> Stef >>> >>> On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote: >>> >>>> >>>> On 06 Oct 2010, at 08:48, Nicolas Cellier wrote: >>>> >>>>> See also hijacked http://www.squeaksource.com/XTream.html borrowing >>>>> some of the ideas, but somehow less extreme. >>>>> Most packages should now load in Pharo. >>>> >>>> Hi Nicolas, >>>> >>>> I have been looking at the ESUG 2010 slides & google code project pages of xstreams and I must say that I like this very much. >>>> >>>> Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with errors that I think are probably fixable. I am browsing it now. >>>> >>>> Now my question is, first, do you have some write up somewhere explaining what you did and why, and second, what is the current state of your project and what are your future plans/goals ? >>>> >>>> Thx, >>>> >>>> Sven >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] XMLRPC Project - Progress Report
by StÃ©phane Ducasse Oct. 8, 2010

Oct. 8, 2010

Tell us when pharo core can be a user. Because we want to clean the mess. Stef On Oct 3, 2010, at 6:52 PM, Sven Van Caekenberghe wrote: > GermÃ¡n, > > On 03 Oct 2010, at 17:41, GermÃ¡n Arduino wrote: > >> As usual, any comment, suggestion or criticism is more than welcome. > > Well, you could consider using the Zinc HTTP Components framework. > > XMLRPCProxy>>#sendXmlRpc: is using the ugly HTTPSocket interface. > > Using any of the clients in Zn will give you a semantically much richer interface to headers and content (entities), both for requests and for responses. And you get many features on top. > > I haven't looked at the server side, but there too you can get HTTP functionality for free. > > It will add a dependency though, but I would guess you have one for the server side already, no ? > > Anyway, we're looking for users... > > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

[Pharo-project] WebBrowser
by Torsten Bergmann Oct. 8, 2010

Oct. 8, 2010

There once was a subclass of AppRegistry called WebBrowser. This is now gone in "PharoCore 1.2a 12172" compared to Pharo 1.1 Dont know why this specific subclass was removed since other subclasses of AppRegistry are still in the image (like MailSender, SoundService, ...) Was it by accident or if not what is the idea here. However - since this class is missing the package "ExternalWebBrowser" will fail to load in Pharo 1.2 since it would like to register itself as a webbrowser in a class side #initialize. Two possibilities: - we change ExternalWebBrowser - we reintroduce the missing class (either internal or in a compatibility package) Any comments? Thx Torsten -- GRATIS! Movie-FLAT mit Ã¼ber 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

4 3

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)
by StÃ©phane Ducasse Oct. 7, 2010

Oct. 7, 2010

Thanks nicolas Indeed we would love to have a clean covered with test composable stream hierarchy the idea behind nile was to make it compatible, integrate it and then clean but may be we should have done otherwise. It would be good to have a path to get streams cleaned, but my time is counted. Stef On Oct 7, 2010, at 9:41 PM, Nicolas Cellier wrote: > Yes, every time I must warn and apologize because I'm guilty of > hijacking the name. > The goals are more or less the same, because I also hijacked some > ideas (though not all invented at VW): > - separate read/write stream > - use stream wrappers > - implement main sequenceable collection API > (more to be found at http://www.squeaksource.com/XTream.html wiki page) > > There are also Squeak specific goals: > - clean the mess by first principles (just an excerpt > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141786… > ) > - accelerate MultiByteFileStream > > At time Squeak Xtream started, there was no license for VW Xtream, so > it's a full rewrite from scratch. > Thus implementation differs. Mainly I did not reify the Buffer (the > master piece of original VW Xtream). > Due to this, I've got a BufferedReadWriteStream, which is > contradictory to goal 1). > It might change in future. > I also do not want to depend too much on Exception handling, which > current VW Buffer implementation does. > > Also, I did not replace the whole protocol, but rather reused existing one. > That's because further goal is to provide a replacement for Squeak > Streams (could apply to Pharo too, but there's a possible overlap with > Nile* See note below). > However, I currently made no plan to reach this goal. I just have some > toy images that I break regularly due to lack of compatibility... > Either I implement all the messy protocol that flourished in Squeak, > or I try to stay a bit cleaner but with uncompatibilities... > Maybe a separate compatibility package with a deprecation policy might help... > > Be aware that recent Squeak and Pharo acceleration thanks to buffering > was first experimented in Squeak Xtream, and then ported by talents of > Levente, that's already a little reward. > Some big acceleration could be gained other UTF8 streams when a > majority of characters are ASCII (the case of source code management > and most latin characters texts), both in cog and traditional vm. > My current tests (cog) are: > > { > [| tmp | tmp := (MultiByteFileStream readOnlyFileNamed: (SourceFiles > at: 2) name) ascii; wantsLineEndConversion: false; converter: > UTF8TextConverter new. > 1 to: 20000 do: [:i | tmp upTo: Character cr]. tmp close] timeToRun. > [| tmp | tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles > at: 2) name) readXtream binary buffered ~> UTF8Decoder) buffered. > 1 to: 20000 do: [:i | tmp upTo: Character cr]. tmp close] timeToRun. > } > #(163 21) > > So, Xtream is around 8x faster at reading first 20000 lines of change > log... No surprise it's more than 99% pure ASCII. > > Last, concerning the errors, it's more a matter of fixing the tests > themselves... > They use #squeakToUtf8 as a reference, and some tests are for other > unloaded XTream packages. > I started to change the test last night but did not publish all... > > See also: > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15357… > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141539… > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/141647… > and more mails in november/december 2009 > > more dated material http://bugs.squeak.org/view.php?id=6755 > and various attempts like LazyStream/LazyCollections... > > Nicolas > > * Note about Nile: > Nile has a different approach: do not eliminate ReadWriteStreams, but > compose with traits. > Nile also has high test coverage level, which is good. > Nile was designed as a Stream replacement for Squeak Stream... > As such, it carries some cruft (same dilemna as Squeak Xtream). > Pharo goal is to perform major clean-up. As a mean to reach this goal, > it shall not encumber with backward compatibility. This means that > once Nile adopted (with historical compatibility cruft), it should be > cleaned up again... > > 2010/10/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> pay attention that there are two xtreams package frameworks from what I understand >> >> one presented at esug and one developed by nicolas >> >> Stef >> >> On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote: >> >>> >>> On 06 Oct 2010, at 08:48, Nicolas Cellier wrote: >>> >>>> See also hijacked http://www.squeaksource.com/XTream.html borrowing >>>> some of the ideas, but somehow less extreme. >>>> Most packages should now load in Pharo. >>> >>> Hi Nicolas, >>> >>> I have been looking at the ESUG 2010 slides & google code project pages of xstreams and I must say that I like this very much. >>> >>> Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with errors that I think are probably fixable. I am browsing it now. >>> >>> Now my question is, first, do you have some write up somewhere explaining what you did and why, and second, what is the current state of your project and what are your future plans/goals ? >>> >>> Thx, >>> >>> Sven >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

[Pharo-project] copying formatted text into a Pages (or any)
by Esteban Lorenzano Oct. 7, 2010

Oct. 7, 2010

Hi, Is there a way to copy formated text inside a Pages document (or any other external writer) ? Cheers, Esteban

1 0

Re: [Pharo-project] MicroSqueak [was System Tracer]
by StÃ©phane Ducasse Oct. 7, 2010

Oct. 7, 2010

how sad. I thought that science was making progress by exchange. Should I erase my memory since I read the code? > Hi All, > > > turns out John does not want this code released, so please can you destroy any and all copies? Also, who do I have to talk to to get the archive message, with attachments, destroyed? > > Apologies to all, I've f***ed up badly here. > > Eliot > > On Wed, Oct 6, 2010 at 4:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > FInd attached. You want MicroSqueak-colonequal.st and the various MSqueak-.st files. This produces a 57k image. John's also given me a 2.0 development image which will run on a 3.8 VM. Let me know if you want that. For me this is a proof of concept. What's needed is to define a headless core that contains the compiler, good error reporting to standard out, the core collection and numeric libraries and file support. Then we try and load packages into it and build up a headful image. > > On Wed, Oct 6, 2010 at 3:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 6, 2010, at 7:18 PM, Eliot Miranda wrote: > > > > > > > On Wed, Oct 6, 2010 at 7:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > generate a new image. > > > > But that's not what it does. > > Yes I know gnerates = clone in my mail. > > > t merely clones an image, which is a long way form building an image form source. *That*'s a useful project. John Maloney's lovely MicroSqueak is a good starting point for ideas (basically have a copy of a kernel subset of the system in a namespace and generate a fresh image from that). > > Do you have a pointer on the code of john. We are looking at bootstrap code right now. > > > > > On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > > > > > Hi! > > > > > > What do you want to achieve? > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > > > > > >> Hi > > >> > > >> Does anyone know where I can find the system tracer that is currently > > >> in use in Pharo? > > >> > > >> Bests > > >> Gabriel > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] WebBrowser
by StÃ©phane Ducasse Oct. 7, 2010

Oct. 7, 2010

if this is used we can reintroduce it. Stef > There once was a subclass of AppRegistry called > WebBrowser. This is now gone in "PharoCore 1.2a 12172" > compared to Pharo 1.1 > > Dont know why this specific subclass was removed since > other subclasses of AppRegistry are still in the image > (like MailSender, SoundService, ...) > > Was it by accident or if not what is the idea here. > > However - since this class is missing the package > "ExternalWebBrowser" will fail to load in Pharo 1.2 > since it would like to register itself as a webbrowser in > a class side #initialize. > > Two possibilities: > - we change ExternalWebBrowser > - we reintroduce the missing class (either internal > or in a compatibility package) > > Any comments? > > Thx > Torsten > -- > GRATIS! Movie-FLAT mit Ã¼ber 300 Videos. > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Pointer types
by Schwab,Wilhelm K Oct. 7, 2010

Oct. 7, 2010

Sig, You mentioned something that might be useful, depending on where it lives. Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess. Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to<g>) expressing them as void pointers to allow me to pass byte arrays into them. Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call? If not FFI, how does NB handle it? Bill

2 9

Re: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm))
by StÃ©phane Ducasse Oct. 7, 2010

Oct. 7, 2010

>>> >>>> Noury, >>>> >>>> One of the other aspects that I find important is elementary efficiency. >>>> >>>> A lot of stream related code in Smalltalk is not efficient, the actual data is copied around like crazy, turning it from a stream to a collection and then back into a stream multiple times. For Zinc HTTP Components I made a lot of effort to make it possible to read data from a socket stream in true streaming fashion (instead of just returning a byte array). Now, the idea was then that for example JPEGReadWriter>>#nextImage would work transparaently on that raw stream. Sadly, the code in JPEGReadWriter and friends just reads everything into an array before it starts to work ! >>>> >>>> Doing a #nextPutAll: <some byte array> should really try never to copy the array. Similary, a #next: <count> into: <some byte array> should similary write directly into the given array. What I see in the current SocketStream is <censored/> ;-) >>> >>> This is why we implemented our own SocketStream in PostgresV3. >> >> what is the license? > > It's MIT, but it's not a general purpose SocketStream. sniff

4 4

[Pharo-project] Pharo Talk ESUG 2010
by Marcus Denker Oct. 7, 2010

Oct. 7, 2010

Hi, Now online: Slides Slideshare: http://www.slideshare.net/esug/pharo Slides Download: http://www.marcusdenker.de/talks/10ESUG/2010PharoESUG.pdf Video Web: http://esug2010.objectfusion.fr/tuesday.html (part of all the Tuesday Videos) Video for Download: flv: http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.flv mp4: http://www.marcusdenker.de/talks/10ESUG/esug2010_0914_denker.mp4 Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

4 5