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

[Pharo-project] PNGReadWriter2Plugin

by Denis Kudriashov

Hello Is somebody have built windows PNGReadWriter2Plugin dll? Can you share it? Best regards, Denis

Dec. 22, 2010

Re: [Pharo-project] Pharo 2010 - Thank you!

by StÃ©phane Ducasse

Sven Thanks a ***lot***. We have to do a party close to the border (well we are on the border already) and meet This should be a resolution for 2011. You see, this is because of such a kind of feeling and good energy that we find the energy to do pharo. Pharo is just like that because you are making it that too. The work around Zinc is important. And this is because there are people like you, alain, lukas, luc, mariano (all busy like hell doing something else) with a cool spirit that this is fun to do Pharo. We all want to open new space, create knowledge and support your business. The funny part of life is that we do pharo on our free time :).... at least I'm running so much to make sure that phds make progress, get money for the team, do bugdet budget, admin, admin, writing.... that people would not believe it. :) But this is cool and I can tell you that I will take time for pharo and its future. Because we want more :) Stef On Dec 22, 2010, at 8:17 PM, Sven Van Caekenberghe wrote: > Since about the middle of 2010 I have been actively following Pharo and it has been an amazing time. > > These are my highlights, there are probably many others. > > 0.x became 1.0, then came 1.1 and finally 1.1.1. There has been amazing activity on 1.2. > > Seaside became 3.0. > > I learned how to deploy Seaside and manage it in production. > > I learned how to work efficiently with Monticello and SqueakSource. > > Hudson integration servers were customized and deployed for various Smalltalk projects and for Pharo itself. > > I learned how to build my own development and deployment images. > > I learned how to do load balancing and static content serving for Seaside. > > I love the Glamorous theme and the improved DejaVuBitmapFonts loader, I like the the Pro theme. > > I am successfully using Glorp and PostresV2. > > I am using the Cog VM every day. > > I simply love developing in Pharo. > > The Pharo community is just as great, from the leadership to the core developers, the dev image developers, the application and framework developers, those doing documentation, screencasts, help systems, the testers, to the countless people answering questions on this list. > > Thank you all ! > > Sven > > PS: I can't wait for 2011. > > PPS: Of course, part of the above are results of the greater Smalltalk community. Pharo is my view into this world. > >

Dec. 22, 2010

Re: [Pharo-project] accessors vs direct access in Cog

by StÃ©phane Ducasse

>> Hi guys >> >> Ideally I would love to be able to use accessors as the abstraction layer that they can bring us: >> I mean the fact that we could avoid to have offset based bytecode means that we could reuse a lot more >> the methods (in special case - mixins and others). > > It's simply a bad idea. Be scientific, bring real arguments on the table else this is not fun and I can just not reply to your email or have other preconceived statements. > If you don't want instance variables, just change the VM's object representation, but then don't call your system Smalltalk anymore. ;) this has nothing to do with that. You can instance variable but have an execution model that use internally message sends and this way you can maximize reuse of methods for object having a different layout. This is what a good mixin implementation is doing + copy-down accessor on each mixin application. > Btw without instance variables you don't need mixins, cause you have traits. unifying behavior and state is really a way to late bound decision and increase reuse. > If you only want mixins (instead of stateful traits), then there's at least one mixin implementation for Squeak out there. > >> >> Now I have a question does the JIT or the shortcut (not sure if this is in stackVM) blurry the cost of accessors >> vs. direct accesses? > > Bytecodes are still 10-12x faster with Cog than sends. You mean bytecode representing instance variable accesses are faster than sends? > P.S.: IIRC one of V8's optimizations is to use a common representation (class) for objects that have the same slots (instance variables). And? using accessor vs direct field access has nothing to do with prototypes. So I do not understand what you are implying. Stef

Dec. 22, 2010

Re: [Pharo-project] accessors vs direct access in Cog

by StÃ©phane Ducasse

> Hi guys > > Ideally I would love to be able to use accessors as the abstraction layer that they can bring us: > I mean the fact that we could avoid to have offset based bytecode means that we could reuse a lot more > the methods (in special case - mixins and others). > > Now I have a question does the JIT or the shortcut (not sure if this is in stackVM) blurry the cost of accessors > vs. direct accesses? > > Not yet. But IMO it would be straight-forward to add. The PIC design supports inserting extra code at a send site, which is the logical place to put the access code. I would love that because it it would be a really cool step into late binding structure vs. behavior. (of course at the cost of weakening encapsulation but still). I like the design of newspeak from that perspective. > > > Does anybody run a benchmarck about > self x vs x in Cog recently > on a real app? > > Stef > > best > Eliot

Dec. 22, 2010

Re: [Pharo-project] a moment of truth and fun

by StÃ©phane Ducasse

:) > My name could also be at the end of the pdf :-) > > Alexandre > > > On 22 Dec 2010, at 14:55, StÃ©phane Ducasse wrote: > >> Hi guys >> >> I found this document of humor on my hd and I wanted to share with you. >> For me this was a real gift :) >> http://stephane.ducasse.free.fr/Web/havingFunWithStephane.pdf >> >> Thanks vincent. >> Stef >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Dec. 22, 2010

Re: [Pharo-project] [OT] Re: Why Smalltalk ? Which Smalltalk ?

by StÃ©phane Ducasse

Levente What do you want to prove? We pushed/supported squeak since 3.5 or even before. So what? We were harvesters of bug fixes long long long long time ago. We started to clean squeak years ago. Do you want me to come up with a similar timeline from our effort? I do not have that amount of time to lose. We wrote most of the books and tutorial on Squeak. We built the squeakfoundation too btw :) and we give you all that effort for free. People think that going pharo was an easy choice, this was not. May be you do not believe that this is a lot but it is. Now please please nobody has to gain anything polluting the good energy we are creating. You are free to believe what you want. We are free to do the way we want it. Levente we did pharo just to avoid arguing and get bad feelings. so keep this place nice friendly and welcoming. Stef PS: I can send you private mail to show you some evidence of the fact that our efforts to improve Squeak got attacked by 'Important' squeaker. >>> a) removing unessential code from Squeak (Squeak, having started as a children.s education project, has accumulated a fair amount of cruft over the years), >>> b) clearer licensing (MIT license), >>> c) more frequent updates (think Ubuntu versus Debian), and >>> d) being a reference implementation for the Seaside platform (perfect, exactly what I need it for)." >>> >>> b) and c) are clearly false. a) ignores the fact that you can unload quite a lot of "cruft" from Squeak making it comparable to Pharo-Core. >> >> I might be wrong, and I known that Squeak has been changing lately, but Pharo seems to have been the driver here, putting these issues on the map. > > The modularization of Squeak is an old idea (a). One such effort is Pavel's KernelImage project which dates back to 2006: http://lambda-the-ultimate.org/node/1873 > > The idea of relicensing Squeak (b) dates back to 2003 or earlier. Apple relicensed the original Squeak code in 2006 under the Apache license. AFAIK the MITification process started in 2006 or 2007: > http://c2.com/cgi-bin/wiki?SqueakRelicensePush. According to wikipedia the driving force was adding EToys to OLPC. > > I think that in case of the update frequency (c) Squeak was the driving force. Why? Let's see the timeline: > > 21 March 2008: Squeak 3.10 released > 21 May 2008: Pharo forked Squeak 3.9 (the date may not be exact) > 30 May 2008: First Pharo snapshot uploaded to gforge > 02 July 2009: Squeak's new developement process announced (aka 3.11 developement cancelled) > 31 July 2009: Pharo 1.0 Beta announced > 16 March 2010: Squeak 4.0 comes out (same as Squeak 3.10, but with MIT license) > 29 March 2010: Squeak 4.1 feature freeze announced > 16 April 2010: Pharo 1.0 released > 26 April 2010: Squeak 4.1 released (the first artifact of the new process) > 16 May 2010: Pharo 1.1 Beta announced > 26 July 2010: Pharo 1.1 released > 08 December 2010: Pharo 1.2 Beta announced > 13 December 2010: Squeak 4.2 feature freeze announced > > Pharo's developement cycle restarts after a beta. Squeak's developement cycle restarts after the release. So: > > Artifact DW RW WSPR > ------------------------------------ > Pharo 1.0 62 99 N/A > Pharo 1.1 41 47 14 > Pharo 1.2 29 >31 >21 > Squeak 4.1 38 42 5 but irrelevant > Squeak 4.2 33 >34 >34 > > DW = Developement weeks (number of weeks between cycle restart and feature freeze/beta) > RW = Release weeks (number of weeks between cycle restart and release) > WSPR = Weeks since previous release (number of weeks between releases) > > What I wanted to show is that the release of Pharo 1.0 was not urgent at all (DW and RW are both _more than a year_) until Squeak 4.1 came out. After the release of Squeak 4.1, Pharo 1.0 and 1.1 was released ASAP. > > So yes, I think you're wrong, just like Dmitri. > > > Levente > >> >> Sven >> >> >> >

Dec. 22, 2010

[Pharo-project] Pharo 2010 - Thank you!

by Sven Van Caekenberghe

Since about the middle of 2010 I have been actively following Pharo and it has been an amazing time. These are my highlights, there are probably many others. 0.x became 1.0, then came 1.1 and finally 1.1.1. There has been amazing activity on 1.2. Seaside became 3.0. I learned how to deploy Seaside and manage it in production. I learned how to work efficiently with Monticello and SqueakSource. Hudson integration servers were customized and deployed for various Smalltalk projects and for Pharo itself. I learned how to build my own development and deployment images. I learned how to do load balancing and static content serving for Seaside. I love the Glamorous theme and the improved DejaVuBitmapFonts loader, I like the the Pro theme. I am successfully using Glorp and PostresV2. I am using the Cog VM every day. I simply love developing in Pharo. The Pharo community is just as great, from the leadership to the core developers, the dev image developers, the application and framework developers, those doing documentation, screencasts, help systems, the testers, to the countless people answering questions on this list. Thank you all ! Sven PS: I can't wait for 2011. PPS: Of course, part of the above are results of the greater Smalltalk community. Pharo is my view into this world.

Dec. 22, 2010

Re: [Pharo-project] accessors vs direct access in Cog

by Igor Stasenko

2010/12/22 Levente Uzonyi <leves(a)elte.hu>: > On Wed, 22 Dec 2010, StÃ©phane Ducasse wrote: > >> Hi guys >> >> Ideally I would love to be able to use accessors as the abstraction layer >> that they can bring us: >> I mean the fact that we could avoid to have offset based bytecode means >> that we could reuse a lot more >> the methods (in special case - mixins and others). > > It's simply a bad idea. If you don't want instance variables, just change > the VM's object representation, but then don't call your system Smalltalk > anymore. ;) Why? For me smalltalk is a syntax and everything is an object. The rest is optional. > > Btw without instance variables you don't need mixins, cause you have traits. > > If you only want mixins (instead of stateful traits), then there's at least > one mixin implementation for Squeak out there. > >> >> Now I have a question does the JIT or the shortcut (not sure if this is in >> stackVM) blurry the cost of accessors >> vs. direct accesses? > > Bytecodes are still 10-12x faster with Cog than sends. > even those, which are optimized by jit? i mean, could | pt | pt := 1@2. [ pt x ] bench '2.789668866226755e6 per second.' | pt | pt := 1@2. [ pt xx ] bench '2.642108378324335e6 per second.' where Point>>xx is: xx ^ self x so, what are you mean by 10-12 times faster? > > Levente > > P.S.: IIRC one of V8's optimizations is to use a common representation > (class) for objects that have the same slots (instance variables). > > >> >> Does anybody run a benchmarck about >> Â Â Â Â self x vs x in Cog recently >> on a real app? >> >> Stef > -- Best regards, Igor Stasenko AKA sig.

Dec. 22, 2010

Re: [Pharo-project] accessors vs direct access in Cog

by Levente Uzonyi

On Wed, 22 Dec 2010, StÃ©phane Ducasse wrote: > Hi guys > > Ideally I would love to be able to use accessors as the abstraction layer that they can bring us: > I mean the fact that we could avoid to have offset based bytecode means that we could reuse a lot more > the methods (in special case - mixins and others). It's simply a bad idea. If you don't want instance variables, just change the VM's object representation, but then don't call your system Smalltalk anymore. ;) Btw without instance variables you don't need mixins, cause you have traits. If you only want mixins (instead of stateful traits), then there's at least one mixin implementation for Squeak out there. > > Now I have a question does the JIT or the shortcut (not sure if this is in stackVM) blurry the cost of accessors > vs. direct accesses? Bytecodes are still 10-12x faster with Cog than sends. Levente P.S.: IIRC one of V8's optimizations is to use a common representation (class) for objects that have the same slots (instance variables). > > Does anybody run a benchmarck about > self x vs x in Cog recently > on a real app? > > Stef >

Dec. 22, 2010

Re: [Pharo-project] a moment of truth and fun

by Alexandre Bergel

My name could also be at the end of the pdf :-) Alexandre On 22 Dec 2010, at 14:55, StÃ©phane Ducasse wrote: > Hi guys > > I found this document of humor on my hd and I wanted to share with you. > For me this was a real gift :) > http://stephane.ducasse.free.fr/Web/havingFunWithStephane.pdf > > Thanks vincent. > Stef > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 22, 2010