- Pharo-dev - lists.pharo.org

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

by Miguel CobÃ¡

Amazing, it really appears to be that it hurts you everything about Pharo. Even as a mere mention of Pharo in some blog it can trigger a retaliation from you. I can't imagine how many spare hours you have to dedicate to build this impressive list of facts but I think that even the data is (I believe) correct, the aim isn't clear to me. Why? Why is this converting in some kind of "mine is bigger than yours"? It is because the changes you make for Squeak are meant for Squeak use only? That is something that you can't avoid, because the license is MIT. It is because even with that impressive amount of patches that Squeak receives, Squeak remains the same niche as it was 3 or 5 years before. As you can maybe sense, is needed more than technical skills to build a project. So, maybe you are right and Squeak has better bits inside it but for the +10 year it has living, Pharo has come to match and, my *personal opinion* left behind Squeak in only 2 years. That evidence that not only good, best-performance, mathematically perfect solutions are needed, but also a motivated community. But again, I don't know what is the precise reason of your disdain for Pharo. Because most Pharo people were Squeak people. We aren't coming to steal your house and kill your children, we just want other kind of Smalltalk. Is that a sin in the Squeak church? If it is, then glad Pharo forked it. But, as minimal our steps are, they are honest and with a vision. Don't take it personal. As StÃ©phane said in other mail, we would be more than happy to have your skills dedicated to Pharo, but your comments minimizing the Pharo team's work although allowed are not welcome. May the cordiality be king here and more happy collaborations begin. Cheers El miÃ©, 22-12-2010 a las 18:49 +0100, Levente Uzonyi escribiÃ³: > On Tue, 21 Dec 2010, Sven Van Caekenberghe wrote: > > > > > On 21 Dec 2010, at 19:16, Levente Uzonyi wrote: > > > >> 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 > > > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Dec. 22, 2010

[Pharo-project] How I can do SWF files playing in pharo?

by Denis Kudriashov

Hello I search way for playing swf files in morphic. Can you advise some approaches for implementing this stuff? I found flash package in squeaksource. But It support only swf format version 3. Its realy up to day. I cant read required flash files. And I dont know how I can improve current implementation for recent swf format. Maybe I wrong but I hear swf format have no open specification. I found gstreamer flash plugin. And there is gstreamer binding in squeaksource. Is somebody try playing flash by gstreamer? And is this will be different then playing video? Best regards, Denis

Dec. 22, 2010

Re: [Pharo-project] PNGReadWriter2Plugin

by StÃ©phane Ducasse

On Dec 22, 2010, at 9:32 PM, Luc Fabresse wrote: > ok, it is for speed. > so why don't we use a FFI (FFI, Alien, NB or another) to directly call external lib? Luc the primitive is just about one loop for reading and one loop for writing. So this is not calling an external library. Igor could not resist to show me the NB implementation he did about that primitive a while ago. I guess that this is terrible for igor to get a mac because he will not stop working before the vm builds from hudson (he worked last night until 3 in the morning :)). native boost works on mac and a lot more :) Now seriously for native boost this may be a problem to rely on platform assembler generation to get speed when C is a portable assembler. So probably

Dec. 22, 2010

Re: [Pharo-project] PNGReadWriter2Plugin

by StÃ©phane Ducasse

the true fun part of the discussion is that igor wanted to get rid of the plugin and andreas said that BMP is really used but apparently the plugin has not been invoked for years in Squeak and Pharo. So may be it is not that used after all :) Life have beauty when you know how to look at it :) > I ask myself the same question: why do we need plugins to read/write images (PNG, BMP, ..)? > I would understand it for JPG which requires some heavy computation. > any hint? > > #Luc > > > 2010/12/22 Alexandre Bergel <alexandre(a)bergel.eu> > Why do we need a plugin for this? So far, I am quite happy with the exportAsPNG found in Morph. > > Cheers, > Alexandre > > > > On 22 Dec 2010, at 17:10, Igor Stasenko wrote: > > > On 22 December 2010 20:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello > >> > >> Is somebody have built windows PNGReadWriter2Plugin dll? > >> Can you share it? > > > > Err.. i can't find it. where you seen it? > > > >> > >> Best regards, > >> Denis > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

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, Igor Stasenko wrote: > >> 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. > > Aren't instance variables part of the syntax? Or is Self Smalltalk? > >> >>> >>> 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? >> > > You benchmark has several flaws. It uses bench which is a message send by > itself and does several other sends, block activations, whatever. Just > evaluate > [] bench. > to see the problem. > > Here is the benchmark I based my idea about 10-12x performance difference: > > 0 tinyBenchmarks. > '540940306 bytecodes/sec; 50274171 sends/sec' > > It shows 10.76x difference. You may say that it's inaccurate, so I wrote > another myself: http://leves.web.elte.hu/squeak/SendBenchmark.st > > To run it evaluate the following: > SendBenchmark run. > > My result is: > #(#(109 16) #(105 17) #(105 18) #(108 18) #(106 19)). > To get the difference (may not work in Pharo): > #(#(109 16) #(105 17) #(105 18) #(108 18) #(106 19)) sum in: [ :sum | > Â Â Â Â sum first / sum second roundTo: 0.01 ]. > 6.06 > > So it's 6x faster to use instance variables, than accessors. > so it is 6x. and takin into account that Cog code gen is "naive", this number can be improved even more. But reality is, that application will not necessary run 6x times slower, because accessing ivars is only a % of all operation types, that's why i compared two dirty loops, instead of pure ones, like you did. But of course it depends on application. > > Levente > >>> >>> 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. >> > -- Best regards, Igor Stasenko AKA sig.

Dec. 22, 2010

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

by StÃ©phane Ducasse

>> >> Why? For me smalltalk is a syntax and everything is an object. The >> rest is optional. > > Aren't instance variables part of the syntax? Or is Self Smalltalk? ? What if you use the same syntax and behind the scene the system makes sure that you get optimized message send? >From a method reuse point of view we do not have offset based bytecode 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. >>> >> 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? >> > > You benchmark has several flaws. It uses bench which is a message send by itself and does several other sends, block activations, whatever. Just evaluate > [] bench. > to see the problem. > > Here is the benchmark I based my idea about 10-12x performance difference: > > 0 tinyBenchmarks. > '540940306 bytecodes/sec; 50274171 sends/sec' > > It shows 10.76x difference. You may say that it's inaccurate, so I wrote another myself: http://leves.web.elte.hu/squeak/SendBenchmark.st > > To run it evaluate the following: > SendBenchmark run. > > My result is: > #(#(109 16) #(105 17) #(105 18) #(108 18) #(106 19)). > To get the difference (may not work in Pharo): > #(#(109 16) #(105 17) #(105 18) #(108 18) #(106 19)) sum in: [ :sum | > sum first / sum second roundTo: 0.01 ]. > 6.06 > > So it's 6x faster to use instance variables, than accessors. > > > Levente > >>> >>> 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, Igor Stasenko wrote: > 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. Aren't instance variables part of the syntax? Or is Self Smalltalk? > >> >> 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? > You benchmark has several flaws. It uses bench which is a message send by itself and does several other sends, block activations, whatever. Just evaluate [] bench. to see the problem. Here is the benchmark I based my idea about 10-12x performance difference: 0 tinyBenchmarks. '540940306 bytecodes/sec; 50274171 sends/sec' It shows 10.76x difference. You may say that it's inaccurate, so I wrote another myself: http://leves.web.elte.hu/squeak/SendBenchmark.st To run it evaluate the following: SendBenchmark run. My result is: #(#(109 16) #(105 17) #(105 18) #(108 18) #(106 19)). To get the difference (may not work in Pharo): #(#(109 16) #(105 17) #(105 18) #(108 18) #(106 19)) sum in: [ :sum | sum first / sum second roundTo: 0.01 ]. 6.06 So it's 6x faster to use instance variables, than accessors. Levente >> >> 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] [OT] Re: Why Smalltalk ? Which Smalltalk ?

by StÃ©phane Ducasse

Hi levente, after your mails some people sent me private mails because they did not feel well. They wondered why people were sending mails against pharo in this mailing-list while they do not send aggressive mails in squeak. I can understand them. Now I think that this is ok that you send the mails you want, you can send your feelings here, even if this is not that positive :). Kicks in the ass is always a feedback and we can make progress. I always appreciated your benchmarks and precise remarks. I liked (and I told you publicly) that you always replied to my mails about your changes in squeak. I can understand your frustration (I have been there for years trying to move squeak - again we did not do pharo for an ego problem - I cannot tell the number of students that looked at me like I was an idiot to use a system with all the colors and messy menus). We do pharo to build an ecosystem where people can expand, create cool ideas and make money to live from them. What is wrong with that? Now do not play pharo against squeak, it will not work on the mid term and this is not fun for everybody. I would love that Squeak builds its own real vision: for example been a real multimedia platform. We could have a lot of fun. Now I think that except a miracle this will not happen: after 10 years, squeak failed to go to the next level - I wanted everything and more Cairo, Zoomable interface, crazy ideas and all the rest - I was a big fan of Sophie (I can tell you that I was a bit fucked by some bulgarian people on that level trying to support Squeak and sophie there) and other impara tools. Now impara failed to make squeak sexy and them the center of the universe - They could have but may be they did not have the vision to be something else than building tools for alan. Anyway this is life. Now I wonder why you get stuck in Squeak you are welcome in Pharo. May be Squeak fits your vision and spirit but I do not understand what we are doing wrong so that you are mad against us. Stef

Dec. 22, 2010

Re: [Pharo-project] PNGReadWriter2Plugin

by Alexandre Bergel

Ah ok, it makes sense Alexandre On 22 Dec 2010, at 17:25, Denis Kudriashov wrote: > I just search more faster way to read png files. > > I read discussion about bmp plugin. And primitive supported reading is 10 times faster then smalltalk implementation. > > And I start to search png analogous. And I found PNGReadWriter2 plugin. > > 2010/12/22 Alexandre Bergel <alexandre(a)bergel.eu> > Why do we need a plugin for this? So far, I am quite happy with the exportAsPNG found in Morph. > > Cheers, > Alexandre > > > > On 22 Dec 2010, at 17:10, Igor Stasenko wrote: > > > On 22 December 2010 20:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello > >> > >> Is somebody have built windows PNGReadWriter2Plugin dll? > >> Can you share it? > > > > Err.. i can't find it. where you seen it? > > > >> > >> Best regards, > >> Denis > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 22, 2010

Re: [Pharo-project] PNGReadWriter2Plugin

by Luc Fabresse

ok, it is for speed. so why don't we use a FFI (FFI, Alien, NB or another) to directly call external lib? #Luc 2010/12/22 Denis Kudriashov <dionisiydk(a)gmail.com> > I just search more faster way to read png files. > > I read discussion about bmp plugin. And primitive supported reading is 10 > times faster then smalltalk implementation. > > And I start to search png analogous. And I found PNGReadWriter2 plugin. > > 2010/12/22 Alexandre Bergel <alexandre(a)bergel.eu> > > Why do we need a plugin for this? So far, I am quite happy with the >> exportAsPNG found in Morph. >> >> Cheers, >> Alexandre >> >> >> >> On 22 Dec 2010, at 17:10, Igor Stasenko wrote: >> >> > On 22 December 2010 20:45, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >> Hello >> >> >> >> Is somebody have built windows PNGReadWriter2Plugin dll? >> >> Can you share it? >> > >> > Err.. i can't find it. where you seen it? >> > >> >> >> >> Best regards, >> >> Denis >> >> >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko AKA sig. >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >

Dec. 22, 2010