October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] WebBrowser

by Marcus Denker

On Oct 8, 2010, at 3:36 AM, Levente Uzonyi wrote: > On Thu, 7 Oct 2010, Alexander LazareviÄ wrote: > >> 2010/10/7 Torsten Bergmann <astares(a)gmx.de>: >>> 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. >> >> It got nuked with >> >> Name: System-Applications-StephaneDucasse.18 >> Author: StephaneDucasse >> Time: 11 July 2010, 6:52:54 pm >> UUID: 7eb6ce52-4ac4-4523-b44f-eaf822506c76 >> Ancestors: System-Applications-StephaneDucasse.14 >> >> - Issue 2664: empty classes: WebBrowser, SketchMorph, >> PasteUpMorphTest, NameOfSubclass, MethodTempsNode > > Why did you remove NameOfSubclass? > It was part of the compiler tests, but there are no users (at least I am too dumb to find them). -> empty class -> no References -> Not even in the source -> In a tests package -> Running the tests does not seem to re-create the class (else in addition, tearDown code would be needed) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by StÃ©phane Ducasse

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

Oct. 8, 2010

Re: [Pharo-project] XMLRPC Project - Progress Report

by Lawson English

On 10/4/10 6:24 AM, Sven Van Caekenberghe wrote: > [...] > There is still some technical work to do, but the most important thing is that we need as much users as possible to shake out the bugs. The code has to prove itself for others (with different encodings/languages/networks). > here's a challenge: http://www.morphle.org:8502/pier/samplepage That's genuine Second Life login xmlrpc with invalid password. Lawson

Oct. 8, 2010

Re: [Pharo-project] WebBrowser

by Levente Uzonyi

On Thu, 7 Oct 2010, Alexander LazareviÄ wrote: > 2010/10/7 Torsten Bergmann <astares(a)gmx.de>: >> 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. > > It got nuked with > > Name: System-Applications-StephaneDucasse.18 > Author: StephaneDucasse > Time: 11 July 2010, 6:52:54 pm > UUID: 7eb6ce52-4ac4-4523-b44f-eaf822506c76 > Ancestors: System-Applications-StephaneDucasse.14 > > - Issue 2664: empty classes: WebBrowser, SketchMorph, > PasteUpMorphTest, NameOfSubclass, MethodTempsNode Why did you remove NameOfSubclass? Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

2010/10/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/10/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2010/10/8 Igor Stasenko <siguctua(a)gmail.com>: > snip... >> >> Buffering could be automated at FSReadXtream creation. >> The utf8 decoder should also be buffered, but it's just a matter of >> creating a nice shortCut for composition, maybe simply >> >> 'aaa.txt' asFile readXtream gunzip utf8. >> > > Oops I forgot the .gz extension: > > 'aaa.txt.gz' asFile readXtream gunzip utf8. > > Nicolas > Oh, and VW features are more rich than reach... Time to sleep. Bye

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

2010/10/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/10/8 Igor Stasenko <siguctua(a)gmail.com>: snip... > > Buffering could be automated at FSReadXtream creation. > The utf8 decoder should also be buffered, but it's just a matter of > creating a nice shortCut for composition, maybe simply > > 'aaa.txt' asFile readXtream gunzip utf8. > Oops I forgot the .gz extension: 'aaa.txt.gz' asFile readXtream gunzip utf8. Nicolas

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

2010/10/8 Igor Stasenko <siguctua(a)gmail.com>: > Nicolas, > the design of your version lacks composability. > Also, i seriously think that read and write streams should not be > married under same class. > This could be a paradigm shift for many people, but not for me, since > i dealt with real-time > network communications in the past and can say that network > communication based on bidirectional data flow > really sucks, because it doesn't scale.. and don't works for more than > 2 peers :) > I don't see what is not composable. Squeak Xtream is made exclusively of Xtream wrappers, except some terminal CollectionReadXtream and future IOHandleReadXtream (not yet existing see below). Track how the source/destination ivar are defined/used : most exclusively of other Xtreams. Also check the messages ~> and <~ for composition. I started using Stream wrappers in the 90s for my own applications, that's not a new idea. > By its nature, data flow is unidirectional. Trying to unify things and > present it as a bidirectional > leads to bad code, bad usage patterns (see RemoteString) and > endless discussions around 'do we need a multiple inheritance or not'. > Agree. I have mostly separated ReadXtream and WriteXtream with one exception, the so called BufferedReadWriteXtream. This class was a quick hack and is not satisfying me. In Squeak, there is one major user of ReadWriteStream: the change log, so I needed this quick hack. We can for sure decompose it in two streams, one for read, one for write, code will be a lot cleaner. But beware, the two streams will have to share a common state, and implementation is not straightforward. If you look at VW implementation, you will see this kind of object is a (shared) Buffer and the implementation is quite involved... But if you want to help with this one, you're welcome. > If i want to read from stream, i can do it like following: > > file := 'foo.txt' asFile. > > reader := file readXStream. > reader next > > if i want to write something, i do > > writer := file writeXStream. > writer nextPut: $x. > > and if i need to read & write both, then i probably should tell writer > and reader > to share same state, like file handle, cache, buffers etc, but not to > be the same object. > so, if i need to write, i should use writer, and if i need to read - i > should use reader.. > > Concerning composability, this is a cornerstone of VW XTreams implementation. > And after watching their presentation at ESUG, i can say that your > implementation completely miss the point (sorry). > Seeing how simple i can build complex parser(s) by composing multiple > low-level parsers > in PetitParser, nobody can convince me, that its a bad idea for streams. > > Why i can't simply do: > > reader := 'aaa.txt' asFile readXStream. > utf8Reader := UTF8Reader on: reader. > ? > 1) asFile does not exist yet because I thought it would be much better to conect to FileSystem http://www.wiresong.ca/downloads/Filesystem-1.0.0.sar rather than doing yet another one... 2) in the meantime, use an old StandardFileStream (yes I know, not sexy) 3) compose with message <~ for write and ~> for read By now your example shall be translated as (StandardFileStream readOnlyFileNamed: 'aaa.txt') readXtream buffered ~> UTF8Decoder. Buffering could be automated at FSReadXtream creation. The utf8 decoder should also be buffered, but it's just a matter of creating a nice shortCut for composition, maybe simply 'aaa.txt' asFile readXtream gunzip utf8. Instead of #on:, I implemented #onStream: for readXtream wrappers and #toStream: for writeXtream wrappers. I concede current implementation is weak because those two messages are duplicated... But it's just a matter of gathering the transformers under a generic subclass as you proposed in Xtream-Wrappers Hope it helps, or maybe there are really neat things I missed ? VW Xtream is really a master piece, reach features, certainly many hours of development. Squeak Xtream is a few hours proof of concept. I invite you and every one interested to complete the work. Beside, VW Xtream is now MIT, so it's easy to pick any code and unify if there's a will in this community. Nicolas > > On 8 October 2010 00:51, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 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 >>> >> >> Now, I wonder if I should not rename it SqueaXtream or something - >> apologize for not being Pharo-tically correct ;) >> >> Nicolas >> >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Igor Stasenko

Nicolas, the design of your version lacks composability. Also, i seriously think that read and write streams should not be married under same class. This could be a paradigm shift for many people, but not for me, since i dealt with real-time network communications in the past and can say that network communication based on bidirectional data flow really sucks, because it doesn't scale.. and don't works for more than 2 peers :) By its nature, data flow is unidirectional. Trying to unify things and present it as a bidirectional leads to bad code, bad usage patterns (see RemoteString) and endless discussions around 'do we need a multiple inheritance or not'. If i want to read from stream, i can do it like following: file := 'foo.txt' asFile. reader := file readXStream. reader next if i want to write something, i do writer := file writeXStream. writer nextPut: $x. and if i need to read & write both, then i probably should tell writer and reader to share same state, like file handle, cache, buffers etc, but not to be the same object. so, if i need to write, i should use writer, and if i need to read - i should use reader.. Concerning composability, this is a cornerstone of VW XTreams implementation. And after watching their presentation at ESUG, i can say that your implementation completely miss the point (sorry). Seeing how simple i can build complex parser(s) by composing multiple low-level parsers in PetitParser, nobody can convince me, that its a bad idea for streams. Why i can't simply do: reader := 'aaa.txt' asFile readXStream. utf8Reader := UTF8Reader on: reader. ? On 8 October 2010 00:51, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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 >> > > Now, I wonder if I should not rename it SqueaXtream or something - > apologize for not being Pharo-tically correct ;) > > Nicolas > >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 7, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

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 > Now, I wonder if I should not rename it SqueaXtream or something - apologize for not being Pharo-tically correct ;) Nicolas > 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 >

Oct. 7, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

2010/10/7 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > 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 > Alternatively, the Squeak Xtream solution is to set appropriate endOfStreamAction: at creation time for example. For example, you could have a different factory SequenceableCollection>>#pedanticReadXtream ^self readXtream endOfStreamAction: [self error: 'no more data in this stream']; yourself Nicolas > > > ________________________________________ > 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 >

Oct. 7, 2010

[Pharo-project] copying formatted text into a Pages (or any)

by Esteban Lorenzano

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

Oct. 7, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Schwab,Wilhelm K

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

Oct. 7, 2010

Re: [Pharo-project] WebBrowser

by Alexander LazareviÄ

2010/10/7 Torsten Bergmann <astares(a)gmx.de>: > 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. It got nuked with Name: System-Applications-StephaneDucasse.18 Author: StephaneDucasse Time: 11 July 2010, 6:52:54 pm UUID: 7eb6ce52-4ac4-4523-b44f-eaf822506c76 Ancestors: System-Applications-StephaneDucasse.14 - Issue 2664: empty classes: WebBrowser, SketchMorph, PasteUpMorphTest, NameOfSubclass, MethodTempsNode

Oct. 7, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by StÃ©phane Ducasse

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

Oct. 7, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

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 >

Oct. 7, 2010

Re: [Pharo-project] MicroSqueak [was System Tracer]

by StÃ©phane Ducasse

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

Oct. 7, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by StÃ©phane Ducasse

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

Oct. 7, 2010

Re: [Pharo-project] WebBrowser

by StÃ©phane Ducasse

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

Oct. 7, 2010

Re: [Pharo-project] MicroSqueak [was System Tracer]

by Eliot Miranda

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

Oct. 7, 2010

Re: [Pharo-project] MicroSqueak [was System Tracer]

by Eliot Miranda

On Thu, Oct 7, 2010 at 2:38 AM, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Thanks Eliot! > > I just downloaded Squeak 2.0 and start loading the MicroSqueak files. > But, I encountered a strange problem. In the fileList, the > MSqueak-Collections-Unordered.st file content isn't displayed and I can't > load it. > I get only this message in the fileList: > > For some reason, this file cannot be read > > Any hint? > No clue. So instead I've put all the files, including a development image that has all the code filed in on http://www.mirandabanda.org/files/MicroSqueak. Check the !README<http://www.mirandabanda.org/files/MicroSqueak/!README> . HTH Eliot Noury > On 7 oct. 2010, at 01:22, Eliot Miranda 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 > > > > <MicroSqueak.tgz>_______________________________________________ > > 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 >

Oct. 7, 2010

Re: [Pharo-project] Pointer types

by Schwab,Wilhelm K

Sig, Thanks for the insights. Your use of the Smalltalk types as parameters should not surprise me (I've been using StructClass* for a long time), but it does a little. Part of what I am trying to sort out is how all of this will look in the things I have going from meta data to calls. You might have just made that easier. The ease with which you drop into assembly language is impressive. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Thursday, October 07, 2010 7:58 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pointer types On 7 October 2010 14:24, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 7 October 2010 14:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> I have to start watching the clock here, so I will just throw this out for your consideration. Yes a pointer is a pointer, but there are layers of specificity. If a function expects a double*, ideally passing a FloatArray would "take some work," perhaps in the form of wrapping the argument in a "cast"/adpater of some type and passing that to the function. If I describe an argument to the function as void*, then I do not expect much help. In fact, this is a growing source of trouble for me, because my DOUBLEArray leads me to describe parameters as void* when they should/could be double*. The current FFI *appears* to be helping in other situations by complaining when type A does not fit in slot B. >> >> Clearly if the function is mapped as the wrong type in the code I give you, then the seg fault is on me. But it would be nice if when given a correct (double*, long) argument sequence, you could raise an error if those are reversed. Am I missing something? I gotta go =:0 > > You could even specify that a double* argument expects an argument to > be an instance of DoubleArray, which then will be coerced to pointer. > There's many other things possible, but before you start using it, > you'll never know :) > or , as i said before, just write a function specification as following: foo (DoubleArray array, long dummy) then, in DoubleArray class>>asNBExternalType: answer an instance of your own DoubleArrayType which will be responsible for argument type-checking its coercion to double * and pushing to stack. As an example of implementing custom external type, you can take a look at SqS/NBOpenGL repository a package NBOpelGL-Core For example: NBOpenGL>>color3f_red: "in" red green: "in" green blue: "in" blue "This method was automatically generated from OpenGL specs" "See http://squeaksource.com/OpenGLSpecs for details" <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self glApiCall: #( void glColor3f ( GLfloat red , GLfloat green , GLfloat blue ) ) index: 141 attributes: #( #category #'VERSION_1_0_DEPRECATED' #deprecated #'3.1' #version #'1.0' ) GLfloat is defined in NBOpenGLTypes pool as: GLfloat := #NBGLFloat. And NBGLFloat is a external type subclass: NBFloat32 subclass: #NBGLFloat instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'NBOpenGL-Core' which overrides #pushAsValue: pushAsValue: gen | proxy asm oop EAX | proxy := gen proxy. asm := gen asm. EAX := asm EAX. oop := loader emitLoad: gen. asm mov: oop to: EAX. proxy oop: EAX ifSmallInt: [ asm sar: EAX with: 1; push: EAX; fild: asm ESP ptr32; fstp: asm ESP ptr32 ] ifNotSmallInt: [ proxy pushFloatOopAsFloat32: EAX. ]. So, in contrast to its superclas (NBFloat32), it accepting a smallints as valid argument, not only instances of Float. >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Thursday, October 07, 2010 6:49 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Pointer types >> >> On 7 October 2010 13:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Sig, >>> >>> Ultimately, I will have to simply try this, but it reminds me of something that I can't place. Have you considered using a dictionary or other type of collection to store the types? A new handler would then be created and finally hooked into the system by sending a message to connect it; opposite on removal. It might turn out to be very much one-to-one so that what I am wondering about does not apply. >>> >> >> Sure, you can use dictionaries in alias lookup implementation: >> >> MyClass>>externalTypeAlias: aTypeName >> ^ myAliasesDict at: aTypeName ifAbsent: [ nil ] >> >>> Anything that can be double* can also be used with void*. How does that work? >>> >> >> Pointer is a pointer. If function expects a pointer argument, you can >> pass any pointer to it. >> Code generator just checks that an argument you passes can be >> converted to C pointer (bytearray, wordarray, external pointer), >> but sure thing it can't check if you passed char* or double* or void*. >> Such kind of type checking belongs to C compiler :) >> >> So, a pointer types in FFI callout declarations is more like a hint, >> what function expects, rather than something ,which >> influence the generated callout code. >> >> >>> Bill >>> >>> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >>> Sent: Thursday, October 07, 2010 12:41 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Pointer types >>> >>> On 7 October 2010 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>> Sig, >>>> >>>> Am I correct in taking this as a description of how to solve it with NB, not Squeak/Pharo FFI? That's ok, just want to know if there is an applicable lesson on FFI to be extracted. >>>> >>>> You say the NB callout generator knows nothing about types. Is that how it should be? The scenario I have in mind is a bogus type and whether that can/should be flagged at compile time vs. runtime. Maybe all it takes is a scan for a suitable handler before or after the method is compiled. I ask because I hit a related snag with FFI runtime errors being reported as coercion errors when in fact I had used errant types in the callout definitions. IIRC, Andreas patched the compiler to report the bogus types. >>>> >>>> >>>> "Or, if you want make double* type to use it as a DoubleArray, then you can add an alias: >>>> >>>> MyClass>>externalTypeAlias: aTypeName >>>> aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. >>>> ^ nil >>>> >>>> Then, any method which contains an FFI callout in MyClass, will use that alias." >>>> >>>> What is MyClass in the above? Is it the class holding the callout method, or it elsewhere in the chain? I ask because it could be a sore spot for maintenance/pluggability. I'm wondering how you and I would independently add such instructions. If it goes in the external type subclass, then it is probably fine; if it goes in a class that makes the call, we might stomp on each other. Make sense? My hunch is that you have it handled. >>>> >>> >>> Its in an any class, which using FFI callouts. We can stomp on each >>> other if you define aliases in Object class :) >>> But this won't be a good idea, isnt? >>> NBExternalType subclasses defining coercions between ST oops and >>> concrete C type, they are not for defining aliases. >>> >>>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >>>> Sent: Monday, October 04, 2010 7:36 AM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] Pointer types >>>> >>>> On 4 October 2010 06:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>> 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? >>>>> >>>> >>>> In NB, there is a type system, which implements C<->Smalltalk coercions. >>>> The responsibility of type coercions taken by a subclasses of NBExternalType, >>>> so NB callout code generator actually knows nothing about types and >>>> how to coerce them. >>>> >>>> To create own custom type, you need to subclass from NBExternalType >>>> and override methods which responsible for coercions. >>>> There you can define any kind of operations , what needs to be done in >>>> order to push value on stack, or >>>> convert it to some smalltalk object. >>>> >>>> Then, in your DoubleArray class, simply implement a message on a class side: >>>> >>>> asNBExternalType: gen >>>> >>>> ^ MyDoubleArrayExternalType new >>>> >>>> >>>> And then, in FFI callouts you can use a class name directly: >>>> >>>> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) >>>> >>>> etc. >>>> >>>> Or, if you want make double* type to use it as a DoubleArray, then you >>>> can add an alias: >>>> >>>> MyClass>>externalTypeAlias: aTypeName >>>> aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. >>>> ^ nil >>>> >>>> Then, any method which contains an FFI callout in MyClass, >>>> will use that alias. So, you can write callout as: >>>> >>>> double* foo (double *arr, double ** arrPtrPtr) >>>> >>>> but it will be understood as: >>>> >>>> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) >>>> >>>> >>>> About handling pointers.. well for smalltalk there is no pointers, just objects. >>>> So, in NB NBExternalType keeps two things: >>>> - a value type >>>> - a pointer arity >>>> >>>> >>>> So, for example, when you specifying type, like: >>>> char *** >>>> >>>> a value type will be char >>>> and pointer arity will be 3. >>>> >>>> It is up to NBExternalType subclass how to push values whose pointer arity > 0. >>>> By default, if pointerArity > 0, then it is treated as a pointer, >>>> which can be either: - nil, ByteArray, or NBExternalAddress >>>> >>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 7, 2010

[Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Sven Van Caekenberghe

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

Oct. 7, 2010

Re: [Pharo-project] WebBrowser

by Mariano Martinez Peck

On Thu, Oct 7, 2010 at 12:56 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > 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) > > I would change ExternalWebBrowser, add the missing class there, and create a new version in ConfigurationOf that works in 1.2 > 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

Oct. 7, 2010

Re: [Pharo-project] [Pharo-users] Pharo Talk ESUG 2010

by Alexandre Bergel

>> You will come to Smalltalks 2010 ? > > Yes, Mariano, Luc and me. Cool! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 7, 2010

Re: [Pharo-project] Learning by download all the mcz files from a repository

by Alexandre Bergel

Hi! Romain Robbes has been working on exactly this: http://www.squeaksource.com/Ecco.html I also provide a way to profile each version of a given package in the Spy repository. Cheers, Alexandre On 7 Oct 2010, at 03:23, HwaJong Oh wrote: > > I plan to study history of Metacello. > For that I came up with an idea, what if i download all the mcz in the > metacello repository on squeaksource. > Then sort them by commit time stamp. > > installing very first version of Metacello to last version of > Metacello-Help. Every moment of installation, see the difference by clicking > "Changes" button of monticello browser. > > By doing it, i can grasp the idea, the indents of version and understand how > the design has been changed and know the direction of change. > > What do you think of this idea? > > -HwaJong Oh- > -- > View this message in context: http://forum.world.st/Learning-by-download-all-the-mcz-files-from-a-reposit… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 7, 2010