- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Dear Santa ...

by StÃ©phane Ducasse

Ralph point us to it, what is it, where is it? open a ticker with the code is the best way to make sure that something can happen. Provide tests is another steps. Stef I think that this one can be easily done. On Dec 26, 2010, at 2:21 AM, Ralph Boland wrote: > Dear Santa, if it's not too late, please add the generator code > that Andreas Raas added to Squeak to Pharo as well. > Generators are used in some of the packages that I have written > for Squeak but they don't port to Pharo without the generator code. > Oh please Santa, it's under 150 lines of code and it is so so useful! > > Merry Xmas to all, Squeaker and Pharoer alike. > > Ralph Boland >

Dec. 26, 2010

Re: [Pharo-project] Which Keymaps/Shortcuts do we want to have?

by StÃ©phane Ducasse

On Dec 25, 2010, at 6:36 PM, Mariano Martinez Peck wrote: > > > On Sat, Dec 25, 2010 at 10:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 25, 2010, at 1:18 AM, Guillermo Polito wrote: > > > Which shortcuts would you like to have, and how should they be launched? We can choose combinations such as (ctrl + a, ctrl + b) > > > It would be good to have several maps > > on mac apple-w for closing windows > > isnt this the case? cmd + b closes the windows for me yes I was just saying that this one is important to keep :) > > > I would love to have a map with > ctrle > ctrla > like in emacs > > > > > Close window - ctrl + w? > > Minimize window - ctrl + ??? > > Maximize window - ctrl + ??? > > > > Open browser - ctrl + ? > > Open Monticello browser ? > > > > Go to next window? > > > > My idea is to: > > > > - get an idea of what kind of keymaps do we want > > - build them using Keymapping, so I can test it well with a nice set of shortcuts > > - gradually replace hardcoded shortcuts with Keymappings (at least to have an extension to load to do this) > > > > Merry christmas :) (Here is 9 pm yet, hehe) > > > > Guille > > >

Dec. 26, 2010

Re: [Pharo-project] Which Keymaps/Shortcuts do we want to have?

by StÃ©phane Ducasse

> On Sat, Dec 25, 2010 at 6:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 25, 2010, at 1:18 AM, Guillermo Polito wrote: > > > Which shortcuts would you like to have, and how should they be launched? We can choose combinations such as (ctrl + a, ctrl + b) > > > It would be good to have several maps > > on mac apple-w for closing windows > > Mmm, today keymapping does not support platform specific shortcuts... Maybe I can write it down in my wishlist, but I don't think it is not critical. What do you think? this can be managed by setting different maps and merging them and using the OSPlatform class > I would love to have a map with > ctrle > ctrla > like in emacs > > Ah, thats already supported :D. rahhhhhhhh lovely (Gotlieb reference for the belgium school comics reader). > > > > > > Close window - ctrl + w? > > Minimize window - ctrl + ??? > > Maximize window - ctrl + ??? > > > > Open browser - ctrl + ? > > Open Monticello browser ? > > > > Go to next window? > > > > My idea is to: > > > > - get an idea of what kind of keymaps do we want > > - build them using Keymapping, so I can test it well with a nice set of shortcuts > > - gradually replace hardcoded shortcuts with Keymappings (at least to have an extension to load to do this) > > > > Merry christmas :) (Here is 9 pm yet, hehe) > > > > Guille > > >

Dec. 26, 2010

Re: [Pharo-project] CustomMenu was replaced by MenuMorph?

by StÃ©phane Ducasse

Ok make sense. We should use UIManager default .... and in 1.3 I think that we will integrate the idea of igor to have Smalltalk ui tools Stef On Dec 25, 2010, at 5:30 PM, Guillermo Polito wrote: > SoundMorphicUserInterface Package, in PharoNonCore, more specifically: > > 'MidiInputMorph invokeMenu' > 'PopUpChoiceMorph mouseDown:' > 'SimpleMIDIPort class inputPortNumFromUser' > 'SimpleMIDIPort class outputPortNumFromUser' > 'SpectrumAnalyzerMorph invokeMenu' > 'SpectrumAnalyzerMorph setDisplayType' > 'SpectrumAnalyzerMorph setFFTSize' > 'SpectrumAnalyzerMorph setSamplingRate' > 'WaveEditor chooseLoopStart' > 'WaveEditor invokeMenu' > > Thanks! > > On Sat, Dec 25, 2010 at 6:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 24, 2010, at 9:20 PM, Guillermo Polito wrote: > > > I was looking at Release>>testUndeclared that is failing in 1.2 dev. And of course it is failing because there are some methods pointing to some undeclared variables/globals/classes :). > > > > I found some references to CustomMenu and I'm not sure how to replace them :). > > where because normally I fixed them all. > > Stef > > >

Dec. 26, 2010

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

by Levente Uzonyi

On Wed, 22 Dec 2010, StÃ©phane Ducasse wrote: >>> >>> 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? That's possible with VM hacking, but I doubt you'd get the same performance. > From a method reuse point of view we do not have offset based bytecode anymore. Some primitives also rely on instance variable indexes. Levente > > >>>> 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. 26, 2010

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

by Levente Uzonyi

On Wed, 22 Dec 2010, StÃ©phane Ducasse wrote: > 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. Let me respond to only those parts that weren't answered already: I don't like the idea what some Pharo users and developers (yes, that's including you too) are suggesting about Squeak. A few examples: - Squeak has no vision - Squeak should be a multimedia platform - the purpose of Squeak is to support EToys - Squeak should only be used for educational purposes - Squeak is a mess (while Pharo is clean) - Squeak is dead etc. IMHO Squeak is and should be "a modern, open source, full-featured implementation of the powerful Smalltalk programming language and environment". This implies that it should be good for everything what Pharo is good for. Since I use it for software developement and I'm making a living with it - just like many other people in the past (including some of you) and present - it should be developer friendly too. Why "I got stuck in Squeak"? That's a long story, so let me tell you what I like better in Squeak than Pharo instead: - Squeak's update mechanism is a lot more stable. If you update your image you have ~99% chance that it will work with your already loaded packages. I can always use the bleeding edge version, because it's like a beta or rc. We have some deployed images which were updated from 3.10.2 to the current 4.2 (with Seaside and lot of other packages). - When it's possible to do something in a backwards compatible way, then it's usually done that way. - The contribution process is simpler. - The code changes appear on the mailing list. - Colorful windows make it easy to find the one you're looking for. Most windows are grey in Pharo even if you use a "Squeak theme". - The UI feels faster. - I use the toolbar with it's search tool all the time. The taskbar in Pharo doesn't seem to be useful, but that's probably because I used to find windows by colors. The list is not complete, but I guess the most important ones are here from a user's POV. Levente > > Stef >

Dec. 26, 2010

Re: [Pharo-project] does anybody ported neopus to squeak/pharo?

by Chip Nowacek

When I try to load BT-ggf.30.mcz (squeaksource.com/BackTalk) I get what's below. I wish I was clever enough to figure out how to get past this: This package depends on the following classes: View You must resolve these dependencies before you will be able to load these definitions: AbstractBoardView AbstractBoardView>>changeNbSquares AbstractBoardView>>changeNbSquaresSquared AbstractBoardView>>changeSquareSize AbstractBoardView>>defaultControllerClass AbstractBoardView>>displayOn: AbstractBoardView>>displaySquare:on: AbstractBoardView>>initSquareBounds AbstractBoardView>>initialize AbstractBoardView>>model: AbstractBoardView>>redisplaySquare: AbstractBoardView>>redisplaySquares: AbstractBoardView>>squareAtPosition: AbstractBoardView>>squareSize AbstractBoardView>>squareSize: BTSolutionView BTSolutionView classSide>>initialize BTSolutionView classSide>>openOn: BTSolutionView>>displayOn: BTSolutionView>>update Select Proceed to continue, or close this window to cancel the operation. -- View this message in context: http://forum.world.st/does-anybody-ported-neopus-to-squeak-pharo-tp3031913p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 26, 2010

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

by Levente Uzonyi

On Wed, 22 Dec 2010, StÃ©phane Ducasse wrote: > 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. Since others already wrote the answer to this part, I won't duplicate it here. > > 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. I guess you already sent that to me in March this year. Levente > >>>> 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. 26, 2010

Re: [Pharo-project] Dear Santa ...

by Ralph Boland

Dear Santa, if it's not too late, please add the generator code that Andreas Raas added to Squeak to Pharo as well. Generators are used in some of the packages that I have written for Squeak but they don't port to Pharo without the generator code. Oh please Santa, it's under 150 lines of code and it is so so useful! Merry Xmas to all, Squeaker and Pharoer alike. Ralph Boland

Dec. 26, 2010

Re: [Pharo-project] does anybody ported neopus to squeak/pharo?

by Chip Nowacek

What inference engine is behind the code critic facility? I'm not smart enough yet to figure it out myself. I tried. -- View this message in context: http://forum.world.st/does-anybody-ported-neopus-to-squeak-pharo-tp3031913p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 26, 2010