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

[Pharo-project] in 13101 it looks like I broke the toolbar. I need help

by StÃ©phane Ducasse

hi guys can you have a look. Apparently the tool bar does not receive event. Stef

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Toon Verwaest

Grmbl. Seems broken indeed. I reinstalled it. Still some work to be done on coloring :) If you are interesting in the translation part from Smalltalk to Schemetalk, it can be found at: https://www.iam.unibe.ch/scg/svn_repos/Sources/SchemeTalk/smalltalk The parser is basically a petit-parser like PEG parser written in Schemetalk. The translator compiles the pharo filed-out sources to schemetalk code and/or loads the generated code. Then there's some stuff that avoids "bad" definitions that only serve to make pharo run fast on the pharo VM, such as "fixtemps" and whileFalse:, whileTrue: which don't convey their proper semantics but rather just recursively end up in the same method hoping that the bytecode evaluation will do the proper thing. Unfortunately I didn't write about the squeak->schemetalk conversion; since I just considered it a silly exercise ... I guess I could if someone's interested. cheers, Toon On 03/22/2011 05:23 PM, Alexandre Bergel wrote: > I tried to have a look at SchemeTalk. Apparently the website is not up to date. I reached http://www.iam.unibe.ch/~verwaest/blog/?p=6 from http://scg.unibe.ch/research/schemetalk > > Alexandre > > > On 22 Mar 2011, at 11:16, Toon Verwaest wrote: > >> On 03/22/2011 05:10 PM, Alexandre Bergel wrote: >>> I see your point and I suspected you spoke according to your experience. I am just trying to make people innovate, in my own way. >>> >>> Another thing. Keeping the VM small will definitely help when moving to a different executing platform. It would be amazing to have the Pharo running on Javascript VM. >> That's not even that hard. I even had Pharo running on top of my own SchemeTalk already, after 2 days of hacking. I only stopped where I bumped into traits, since I didn't find any bootstrapping script for traits. >> >> I would basically compile all the smalltalk code to equivalent schemetalk code (very easy since the models are very similar), and compile all the natives to function-calls that perform what the native should perform. These functions had names that wouldn't clash with the Smalltalk names so you couldn't refer to it directly. >> >> Obviously in the end you would have all the smalltalk code running with SchemeTalk syntax, but all the code was virgin Pharo code. Very fun stuff :) >> And if you do it this way, it doesn't really depend on your VM anyway, since I was executing Smalltalk code as Scheme code, not as Smalltalk bytecodes interpreted by schemecode. That's a lot faster. >> >> cheers, >> Toon >>> Alexandre >>> >>> >>>> Ok, I very much understand this point of view. That's exactly why I started Pinocchio. >>>> >>>> I'm currently building my 4rd iteration. I started building a Smalltalk by having AST evaluation (actually I started out with self-evaluating AST objects that got evaluated by sending message... :D) . Then moved on to stack-based bytecodes. Then moved on to registered-based bytecodes (where I am now). All of my progress has been made by careful scrutinizing of the problems at hand. I did reevaluate and question all steps; and I'm a bit sad that I ended up doing it this way... But then I guess there is some inevitability in it. >>>> >>>> For example the register-based bytecodes, I had no idea that what I was doing were register-based bytecodes until I read the Lua VM description and noticed that it was exactly the same. >>>> >>>> However I do think that I learned a lot by doing it. I made the trade-offs myself and understand them a lot better than I did before. What I'm defending in this discussion isn't based on estimates but experience from building it from the ground up. >>>> >>>> And this is where I welcome everyone to do the same! It took me 2 years to get to where I am now, but maybe it goes faster for you ;) It is definitely a very worthwhile exercise. And I think because of it I'm finally at the point where I can contribute something... >>>> >>>> cheers, >>>> Toon >>>> >>

March 22, 2011

Re: [Pharo-project] Issue 3843 in pharo: isHealthy for HasedCollection

by pharo＠googlecode.com

Updates: Status: FixToInclude Labels: Milestone-1.3 Comment #1 on issue 3843 by stephane...(a)gmail.com: isHealthy for HasedCollection http://code.google.com/p/pharo/issues/detail?id=3843 (No comment was entered for this change.)

March 22, 2011

[Pharo-project] Issue 3843 in pharo: isHealthy for HasedCollection

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com New issue 3843 by stephane...(a)gmail.com: isHealthy for HasedCollection http://code.google.com/p/pharo/issues/detail?id=3843 Some integrity checks for Dictionary and friends Attachments: HashedCollection-IntegrityCheck.2.cs 10.0 KB

March 22, 2011

Re: [Pharo-project] Issue 2190 in pharo: at:put: return the argument

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #5 on issue 2190 by marcus.d...(a)gmail.com: at:put: return the argument http://code.google.com/p/pharo/issues/detail?id=2190 (No comment was entered for this change.)

March 22, 2011

[Pharo-project] Issue 3842 in pharo: 1.2 Config needs to load latest code from OB Repository

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3842 by marcus.d...(a)gmail.com: 1.2 Config needs to load latest code from OB Repository http://code.google.com/p/pharo/issues/detail?id=3842 There is code in the repository that is not loaded by the current config of OB used when building the 1.2 Full image. Next action: - merge the code - change ConfigurationOfOB to load the latest code

March 22, 2011

Re: [Pharo-project] Inspector in 1.2

by AxiNat

Thanks a lot, I do value them :) 2011/3/22 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On Mar 22, 2011, at 3:45 28PM, AxiNat wrote: > > > Hi list, > > > > First of all, I'd like to apologise just in case this is already a known > issue; I checked and couldn't find it around. > > > > I've started working with 1.2 RC a couple days ago, and I noticed the > inspector went back to (IIRC) several releases ago. In 1.1 we had tree > navigation and were able to run code in context, now you must open a new > inspector for each node and the code is always executed from the scope of > the root object. I've also noticed you can't remove items from a collection > straight from the UI anymore. > > > > Thanks! > > > > Bernat Romagosa. > > > The reason it's not included by standard any more I believe has mostly to > do with its performance when handling large collections. > If you value its features over its faults like some other here, it is still > loadable as an external tool, see: > ConfigurationOfNewInspector in the MetacelloRepository. > > Cheers, > Henry > > > >

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Toon Verwaest

On 03/22/2011 05:10 PM, Alexandre Bergel wrote: > I see your point and I suspected you spoke according to your experience. I am just trying to make people innovate, in my own way. > > Another thing. Keeping the VM small will definitely help when moving to a different executing platform. It would be amazing to have the Pharo running on Javascript VM. That's not even that hard. I even had Pharo running on top of my own SchemeTalk already, after 2 days of hacking. I only stopped where I bumped into traits, since I didn't find any bootstrapping script for traits. I would basically compile all the smalltalk code to equivalent schemetalk code (very easy since the models are very similar), and compile all the natives to function-calls that perform what the native should perform. These functions had names that wouldn't clash with the Smalltalk names so you couldn't refer to it directly. Obviously in the end you would have all the smalltalk code running with SchemeTalk syntax, but all the code was virgin Pharo code. Very fun stuff :) And if you do it this way, it doesn't really depend on your VM anyway, since I was executing Smalltalk code as Scheme code, not as Smalltalk bytecodes interpreted by schemecode. That's a lot faster. cheers, Toon > Alexandre > > >> Ok, I very much understand this point of view. That's exactly why I started Pinocchio. >> >> I'm currently building my 4rd iteration. I started building a Smalltalk by having AST evaluation (actually I started out with self-evaluating AST objects that got evaluated by sending message... :D) . Then moved on to stack-based bytecodes. Then moved on to registered-based bytecodes (where I am now). All of my progress has been made by careful scrutinizing of the problems at hand. I did reevaluate and question all steps; and I'm a bit sad that I ended up doing it this way... But then I guess there is some inevitability in it. >> >> For example the register-based bytecodes, I had no idea that what I was doing were register-based bytecodes until I read the Lua VM description and noticed that it was exactly the same. >> >> However I do think that I learned a lot by doing it. I made the trade-offs myself and understand them a lot better than I did before. What I'm defending in this discussion isn't based on estimates but experience from building it from the ground up. >> >> And this is where I welcome everyone to do the same! It took me 2 years to get to where I am now, but maybe it goes faster for you ;) It is definitely a very worthwhile exercise. And I think because of it I'm finally at the point where I can contribute something... >> >> cheers, >> Toon >>

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Marcus Denker

On Mar 22, 2011, at 4:10 PM, Alexandre Bergel wrote: > I see your point and I suspected you spoke according to your experience. I am just trying to make people innovate, in my own way. > But talking is easy. Doing is hard. > Another thing. Keeping the VM small will definitely help when moving to a different executing platform. It would be amazing to have the Pharo running on Javascript VM. > I don't know... Gilad sounds really depressed: http://gbracha.blogspot.com/2011/03/truthiness-is-out-there.html I did not waste the last years fighting about not doing research in Java to now do it on top of another crap. And the things I wan to do are, I think, not possible on top of JavaScript anyway. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 22, 2011

Re: [Pharo-project] Issue 3821 in pharo: makeStrong/makeWeak contains a bug

by pharo＠googlecode.com

Updates: Status: FixToInclude Comment #1 on issue 3821 by stephane...(a)gmail.com: makeStrong/makeWeak contains a bug http://code.google.com/p/pharo/issues/detail?id=3821 (No comment was entered for this change.) Attachments: Announcer-fix.2.cs 1.4 KB

March 22, 2011