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

Re: [Pharo-project] [Pharo-users] TWM: Multiple World integration

by StÃ©phane Ducasse

this is good that you use MultipleWorld. I forgot to integrate it. On Jun 7, 2011, at 10:33 PM, laurent laffont wrote: > With the help of my local developper group, I've integrated Sean DeNigris work and now Tiling Window Manager supports Multiple Worlds. > > Here's a screencast that shows the progress. (My English seems a little less catastrophic than the previous screencast :) > > http://magaloma.blogspot.com/2011/06/multiple-worlds-for-twm.html > > > Cheers, > > Laurent Laffont - @lolgzs > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st >

June 8, 2011

Re: [Pharo-project] [Pharo-users] TWM: Multiple World integration

by StÃ©phane Ducasse

the snapshotting looks really cool! In nautilus benjmain added groups. Stef On Jun 7, 2011, at 10:33 PM, laurent laffont wrote: > With the help of my local developper group, I've integrated Sean DeNigris work and now Tiling Window Manager supports Multiple Worlds. > > Here's a screencast that shows the progress. (My English seems a little less catastrophic than the previous screencast :) > > http://magaloma.blogspot.com/2011/06/multiple-worlds-for-twm.html > > > Cheers, > > Laurent Laffont - @lolgzs > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st >

June 8, 2011

Re: [Pharo-project] TWM: Multiple World integration

by Serge Stinckwich

On Wed, Jun 8, 2011 at 3:33 AM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > With the help of myÂ local developper group, I've integratedÂ Sean DeNigris > workÂ and now Tiling Window Manager supports Multiple Worlds. > Here's a screencast that shows the progress. (My English seems a little less > catastrophic than the previous screencast :) Beer might help here :-) > http://magaloma.blogspot.com/2011/06/multiple-worlds-for-twm.html Great ! I was not able to join you this time, because Skype seems completly down. See you next week ! -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

June 8, 2011

Re: [Pharo-project] Spaktacualr Class Forest of Pharo

by HwaJong Oh

Actually, the cow will vary in size. Packages with classes those don't share superclass will be represented with big big big cow. That cow will be hiding most of other 3d objects with its huge back. And some cows will be small like an ant. Besides, cow will genreate lots of polygons. I have no idea presenting both hierarchy and package membership in one 3d space. All I can think of is filtering in classes with user selected package. Best Regards HwaJong Oh -- View this message in context: http://forum.world.st/Spaktacualr-Class-Forest-of-Pharo-tp3578542p3581237.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 8, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by Craig Latta

Hi Damien-- > Do we want to keep traits in the system? Maybe not. Do we want to > delete them and forget them forever? I certainly don't want that > because I see real potential in traits. So, either we keep them in the > system or we make it possible to load them. I'm not sure solution #2 > is doable and nobody showed interest yet. For what it's worth, I'm interested and I plan to make traits a loadable module in Spoon. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

June 7, 2011

[Pharo-project] [PBE-Spanish] Status udpate 2011-06-07

by NicolÃ¡s Paez

Hello everyone, Here is the status update of the Spanish translation of Pharo By Example book. During this I will try to get in contact with the French translators in order to know about the they organized the revision process. Chapter 01: 28% Chapter 02: 60% *Chapter 03: 100%, already publish* *Chapter 04: 100%, already publish* Chapter 05: 66% Chapter 06: 7% Chapter 07: 46% *Chapter 08: just started* *Chapter 09: 100%, not published yet* *Chapter 11: 100%, already published* Chapter 12: 19% *Chapter 13: 100%, not published yet* *Chapter 14: 100%, not published yet* Regards, Nico. blog: nicopaez.wordpress.com

June 7, 2011

Re: [Pharo-project] What screencast tool you recommend for pharocast building ?

by Markus Fritsche

Before recording your first two hour Screencast at once keep in mind that CamStudio can't work with files bigger than two gigabytes... Kind regards, Mar"learned it the hard way"kus Am 05.06.2011 12:30 schrieb "Denis Kudriashov" <dionisiydk(a)gmail.com>: > Thanks for answer. > I am on Windows. So I found CamStudio. It's maybe not suitable but free > > 2011/6/5 laurent laffont <laurent.laffont(a)gmail.com> > >> On Mac I use Screenflow which is great. >> >> On Linux see: >> http://www.pharocasts.com/2010/02/how-i-record-screencasts-for-pharocasts.h… >> >> Laurent >> >> >> >> >> On Sun, Jun 5, 2011 at 11:50 AM, Denis Kudriashov <dionisiydk(a)gmail.com >wrote: >> >>> Hello >>> >>> I want to build few screencasts for my pharo framework. What tool you can >>> recomment me? >>> >>> Best regards, >>> Denis >>> >> >>

June 7, 2011

[Pharo-project] [COTDC] 71 - InflateStream

by laurent laffont

Today: InflateStream Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

June 7, 2011

Re: [Pharo-project] [COTDC] 70 - DeflateStream

by laurent laffont

I'm the base class for "stream compressor". For example, my subclass GZipWriteStream can compress a stream contents using gzip algorithm. Try: gzData := String streamContents: [:aStream| (GZipWriteStream on: aStream) nextPutAll: 'Some data to be gzipped'; close. ]. Transcript show: gzData; cr; show: (GZipReadStream on: gzData) upToEnd; cr. Laurent On Mon, Jun 6, 2011 at 10:50 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: DeflateStream > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent > > >

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by Mariano Martinez Peck

Ok....since Martin is a shy guy I will speak in his name ;) Not sure if it is worth it for the thread, but just want to make clear why we used Traits. A couple of reasons: 1) Martin didn't have time to play with Traits before, and since he is a hacky guy he wanted to learn and try. Fuel has a particular problem, and he tried with Traits 2) In a couple of places we found Traits were easier than subclassifaction. So, we went ahead. 3) We were not aware of some problems of traits, and we discover them after. I cannot really reproduce or numerate them but some tools like OB, RB and Monticello are not fully working with them. 4) Martin was taught (mostly by Hernan Wilkinson I guess jajajaja) not to duplicate code at all. Maybe even too much ;) 5) I also liked when Martin put traits. 90% are used in tests. The little part of the core can be easily removed as Eliot suggested. Now, I am not saying whether Traits are useful or not. I just want to say why we used them. Now, if we re-think about them, as said, we may be able to refactor them and not used them and avoid code duplication. Cheers On Tue, Jun 7, 2011 at 10:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi eliot > > we are nearly in sync :). > > > and e.g. if it looses traits then at least provides tools for importing > packages with traits, eliminating the trait usage on the way in, and in > general provides tools for cleaning-up packages (i.e. refactoring with > clean-ups) so that old packages continue to function, and so that users can > continue to use Pharo in their daily work. > > We always pay attention to that. We are working on tools to support change > and evolution. Now we do not have enough man power. Torch is the example of > the best tools for understanding changes > I have seen but this is > > > But you also need Pharo the Phuture, which is a system moving towards > your vision. By maintaining the two side-by-side you get to work on > migration tools and you keep the existing user base happy while helping > people to dip their toes in the Phuture water. I know its expensive, > yes we know that and this is what we are doing > > > but if you just provide Phuture you'll alienate the existing user base > and you won't provide a well-tooled migration path to bring that user base > into the future. This is an agile, incremental approach to getting the > entire community into the future, > > oh yes that we know and this is for the reason that classboxes were not > adequate for real usage that we never push them. > > > instead of an isolated incremental approach, where only the developers at > the core of Pharo can keep up with the incremental progress towards the > vision. Anyway, that's how I would go about it. > > Yes this is our vision and process too. > > eliot what I want to say is that we did pharo to open space and reinvent > Smalltalk. > I have no problem to perform a real analysis and decide that we made a > mistake and learn from it with traits (see the beginning of the other > mails). > > I have a problem with cries and backward compatibility for the sake of it. > If one of the smalltalk adds a good feature then we should copy it and we > should add what we think > is important. Smalltalk is not carved in stone. This is what we did for > pragma (they are cool). We have the initialize invoked automatically (like > CLOS since 90). > Now if we do not give intellectual space for inventing on the pretext of > backward compatibility then frankly better do something else. I think that > pharo is doing a good job and we will continue and we will add/change the > language for the better. We want slots for example because this is really > good. And some people will do not like it and be against and use the "non > compatible" flag. > > The feedback we got from some venture oriented people is that: it is old. > Sure they are probably idiot but with money and power in our case. So if I > would sell the java, javascript it would be much simpler (even if the java > hype i over and people are open to dynamic language): clojure, scala... > xxxx. > So my point is at least we should be imaginative and show that we are smart > and that we can learn from others and be open to change. > > This is my main point. I do not care about traits: I care about innovation > and the place we give it. > > For example we got a really nice presentation from tom van cutsem about the > new scheme for proxy in Javascript and this is good and they will have a > nice way to secure some part of Javascript. > So mariano is working on Ghost and we want a really good proxy > implementation and we will have it. > This is the same for Fuel: we liked the idea of the pickle format and we > will have a nice object-serializers. These two examples are not about the > languages but for me this is the same. > Ghost is based on a VM hook that does not exist in other Smalltalk. so too > bad ;) > > Stef > > > > > > -- Mariano http://marianopeck.wordpress.com

June 7, 2011