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

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

by Marcus Denker

On Mar 22, 2011, at 3:53 PM, Alexandre Bergel wrote: >>> 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? > Yes. That is called a "bytecode verifier". Now if that would be in the image, you would not gain anything as what you verify is changable. (and the verifier itself, too). > 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. > It can only be done in the VM if what you have is a standard smalltalk system. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 22, 2011

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

by Toon Verwaest

On 03/22/2011 04:52 PM, Alexandre Bergel wrote: >>> 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. 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] We are preparing to this year Google Summer of Code (GSoC)

by Craig Latta

If ESUG is planning another try for 2012, I'd like to help. -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

March 22, 2011

Re: [Pharo-project] Inspector in 1.2

by Henrik Johansen

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

[Pharo-project] Inspector in 1.2

by AxiNat

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.

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? I have the impression that you give a particular status to the bytecodes. I have the feeling that we should not. I can realize a division, and time to time it get wrong (/0). But the VM does not crash. So, why if I evaluate the wrong bytecodes, the VM should crash? You could have the necessary guards in the VM. But the full algorithm for verification could be in the VM. I am not expert on this and I may perfectly be wrong. Most of virtual machine maker will say that a good debugger and profiler can only be done in the VM. Do you agree with this? Cheers, Alexandre On 22 Mar 2011, at 09:24, Toon Verwaest wrote: > Construct me any scenario just based on the image, and I can show you how I can avoid it and segfault your system anyway. > > Construct me any piece of code that can segfault my approach. I doubt that you'll find any. > > I can't really say more, since I don't know what you are unconvinced about :) > > cheers, > Toon > > On 03/22/2011 03:19 PM, Alexandre Bergel wrote: >> Hi Toon, >> >> Thanks for having taken the time to reply. >> I understand your and Eliot's email but I am left unconvinced. >> >> Alexandre >> >> >> >> On 22 Mar 2011, at 09:02, Toon Verwaest wrote: >> >>> The problem is exactly what you had at hand. Your bytecode WAS valid, but it was used in combination with an incompatible class layout. So validation here wouldn't solve anything. You always need to validate in a closed world to ensure you don't accidentally break everything. Whenever you change something, you need to ensure that you revalidate the relevant parts. In this case you could for example just have validated that your new class is a valid subclass of its superclass; which it was not. >>> >>> To make the system more secure obviously you would have to check those things, but if you add part of the API that circumvents these checks, like you were doing by calling "Class new" rather than using the ClassBuilder which does do the checks, everything breaks. The only authority that can actually ensure that you don't circumvent these checks is the VM. >>> >>> Obviously you can make sure already in your image that you have enough checks everywhere. You just don't have a crashproof mechanism that will chain your users down avoiding that they shoot themselves in the foot with segfaults. If you put it inside of the VM you -can- provide such a mechanism, because you don't execute anything unless you know it's safe. And as I said, this piece of code could be a piece of prevalidated Smalltalk code that's immutable from the rest of the image. >>> >>> cheers, >>> Toon >>> >>> On 03/22/2011 02:37 PM, Alexandre Bergel wrote: >>>>> But why we could not have a byecode validator at the image level that first make sure that byte code are in sync with the format of the objects. >>>>> Why this has to be done in the vm. >>>> I agree with Stef. It is not obvious for me why it has to be done at the VM. >>>> >>>> Alexandre >>> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 22, 2011

Re: [Pharo-project] Filesystem and FS extensions in Pharo book

by Mariano Martinez Peck

Max, don't worry too much about that. The idea is just to have a list of the available tools and a little description of what they are. Think of this for business or newcomers. If they go ahead with Pharo, then they will probably ask in the mailing list if they have a problem running/installing a tool. So, what you said, is good for me. Cheers mariano On Tue, Mar 22, 2011 at 1:49 PM, Max Leske <maxleske(a)gmail.com> wrote: > Yes, I understand that. My question is if I should create entries for the > "old" version since that one is working and has working extensions. > > Max > > > On 22.03.2011, at 13:37, StÃ©phane Ducasse wrote: > > > right now we are stuck because we started documenting and understanding > FS and coling publihsed a new one and he should merge our changes > > > > Stef > > > > On Mar 22, 2011, at 1:20 PM, Max Leske wrote: > > > >> Hey > >> > >> I miss Filesystem and its extensions (cURL, zip, git etc.) in the Pharo > book. I'd write the entries but I want your oppinion on whether we should > wait till the Filesystem rewrite in 1.2 is ready. > >> > >> My suggestion: > >> > >> ---- Pharo Tools > >> ---- ---- Filesystem > >> ---- ---- ---- Filesystem for Pharo 1.1 > >> ---- ---- ---- ---- extensions 1 ...n > >> ---- ---- ---- Filesystem for Pharo 1.2 > >> ---- ---- ---- ---- extensions 1 ...n > >> > >> Should we even list the "old" versions? The downside to that is that we > would have to wait for all the extensions to be updated. > >> What do you think? > >> > >> Max > >> > >> > > > > > > >

March 22, 2011

Re: [Pharo-project] Do you have a tool that works on Pharo ?

by Craig Latta

Hi Mariano-- > Chronos I mentioned your note to Alan Lovejoy, the developer of Chronos (a Date/Time library, see http://chronos-st.org ). -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

March 22, 2011

Re: [Pharo-project] Issue 3713 in pharo: Additional obsolete methods in PharoCore-1.2.image (2/15/11 9:08am)

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #2 on issue 3713 by marcus.d...(a)gmail.com: Additional obsolete methods in PharoCore-1.2.image (2/15/11 9:08am) http://code.google.com/p/pharo/issues/detail?id=3713 Next action: Make a slice or changset where all the methods are changed to call the deprecation method *and* are moved to the deprecated13 package.

March 22, 2011

Re: [Pharo-project] Issue 3262 in pharo: Debugger enhancement to open in a background process when the UI process is busy

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #5 on issue 3262 by marcus.d...(a)gmail.com: Debugger enhancement to open in a background process when the UI process is busy http://code.google.com/p/pharo/issues/detail?id=3262 (No comment was entered for this change.)

March 22, 2011