- Pharo-dev - lists.pharo.org

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

by Alexandre Bergel

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. 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 22, 2011

Re: [Pharo-project] Inspector in 1.2

by Esteban Lorenzano

yes... that's because NewInspector has it's own tool set. I worked around by making NewInspectorToolSet inherits from DEVToolSet. best, Esteban El 22/03/2011, a las 12:59p.m., AxiNat escribiÃ³: > Is it possible that installing the NewInspector has broken the autocompleter and some other stuff? > > 2011/3/22 AxiNat <tibabenfortlapalanca(a)gmail.com> > 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] Inspector in 1.2

by AxiNat

Is it possible that installing the NewInspector has broken the autocompleter and some other stuff? 2011/3/22 AxiNat <tibabenfortlapalanca(a)gmail.com> > 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 Alexandre Bergel

>> I am not saying that this is feasible with the current VM. But I am doubtful that the bytecode verification can only be done in the VM. If something get wrong, why not to raise a primitiveFailed, as 1/0 will do? >> > Because checking all these things at runtime will make interpretation slow. But could not it be at compile time? I am not expert in VM. But something that I learnt from all over these years, is that if we copy what other people do, then we will just have a pale copy. Innovation begins by doing what other think it is impossible to do. Smalltalk has classes as object, whereas Java and C++ took a different stance. Smalltalk has the debugger and the profiler in the image; again, java people have a different opinion. Now, if someone say that bytecode verification can only be done in the VM, I am skeptic. >> You could have the necessary guards in the VM. > > Slow. I do not know. There are guards for arrays, message sent, primitive calls, ... And it is not that slow. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 22, 2011

[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