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

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

by Alexandre Bergel

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] Issue 1909 in pharo: Rectangle In place merging for Morphic

by pharo＠googlecode.com

Comment #5 on issue 1909 by fernando...(a)gmail.com: Rectangle In place merging for Morphic http://code.google.com/p/pharo/issues/detail?id=1909 Could this issue be closed? Given the that Juan's significative speedup in GUI in CUIS is somehow related to this, without changing anything.

March 22, 2011

Re: [Pharo-project] Issue 3753 in pharo: SimpleMorphic Layout Code missing

by pharo＠googlecode.com

Comment #6 on issue 3753 by fernando...(a)gmail.com: SimpleMorphic Layout Code missing http://code.google.com/p/pharo/issues/detail?id=3753 Regarding the FileDialogs, the current mechanism for requesting them in Pharo (Morphic) is to go through the UIManager. For instance, UIManager default confirm: 'Yes' label: 'Are you there?'. For the specific one you mentioned, browse the remaining methods of UIManager in the method category 'ui-requests' Hope it helps

March 22, 2011

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

by Toon Verwaest

Exactly! :) On 03/22/2011 02:40 PM, Marcus Denker wrote: > On Mar 22, 2011, at 2:35 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. > >> I have the impression that you give a particular status to the bytecodes. I have the feeling that we should not. > Yes, to be interpretable without having to check at runtime. > >> 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? > Because we don't want to check everything, else it is too slow. > >> You could have the necessary guards in the VM. > Slow. > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

March 22, 2011

Re: [Pharo-project] Issue 1836 in pharo: Adding dedicated accessors for VM parameters

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #15 on issue 1836 by marcus.d...(a)gmail.com: Adding dedicated accessors for VM parameters http://code.google.com/p/pharo/issues/detail?id=1836 (No comment was entered for this change.)

March 22, 2011

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

by Toon Verwaest

On 03/22/2011 03:35 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? > > 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 Well, there is 1 alternative. Check at runtime if what the bytecode wants to do is safe. And that's what you basically suggest. This imposes a high runtime overhead however and that by itself makes that an unwanted approach. The same is true for debuggers and profilers. Depending on what your task at hand is, you don't want this to interfere with the speed of the system. In other cases however you are just fine with knowing where you spend most of your time based on your model. These are 2 different things. And I do agree very strongly that it's most often more interesting to have the high-level view. If you want the bytecode to run safely but -also- as fast as possible, I don't see a way around precomputing if it is valid. This is how VMs optimize things all the time; that's exactly why register-based bytecodes are faster than stack-based bytecodes. You avoid doing at runtime what you know at compilation time. Obviously it gives the same effect in both cases, but you avoid an overhead with the increased risk of doing things wrongly. However, your solution of having a VM that safely executes bytecodes doesn't bring the verification to the image! It keeps it in the VM, just in a different location. Now every execution of a bytecode needs to perform the check, while beforehand you only would do it once for the whole method. Even worse! My approach would allow you to write the verification in Smalltalk code; it's just Smalltalk code running in a privileged sector of the VM. Your code will be pure C code. And why would you need Smalltalk-level verification anyway if your bytecodes already do the checks anyway? This seems duplicate work with no gain. (it basically would just check that your compiler is surely not broken :)) cheers, Toon > > 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 >>

March 22, 2011

Re: [Pharo-project] Issue 1765 in pharo: JPEGReadWriter>>#decompressionTest should be made into a Sunit Test

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #6 on issue 1765 by marcus.d...(a)gmail.com: JPEGReadWriter>>#decompressionTest should be made into a Sunit Test http://code.google.com/p/pharo/issues/detail?id=1765 Attached changeset removes the broken and unsent method. Attachments: RemoveDecompressionTest.1.cs 147 bytes

March 22, 2011

Re: [Pharo-project] [ANN] SqueakNOS update released!

by Javier PimÃ¡s

Yes, we use Ubuntu (10.04 and 10.10 should work). We should write some detailed description of the build process in the blog and update the ConfigurationOf, but meanwhile: To build SqueakNOS from scratch a) Take the image you want to NOSify, and load into it VMMaker, net and SqueakNOS, in that order from squeaksource. b) Clone the git repo and place it so you get a squeaknos folder inside your platforms dir. Use a standard VM, not cog nor stack (unless you want to make them work ;). c) Generate with VMMakerTool. After setting the platforms dir, you'll be able to select squeaknos platform from the list. As path to generation, it must be .../platforms/squeaknos/src32. d) enter comand line and in squeaknos dir do: $> make kernel #if you are going to copy it into a hard-disk image or $> make iso #if you want a bootable CD image if you make a kernel only, then you'll probably need to copy the kernel to the vmdk. There is a script for that in scripts dir. It's recommended to have VMWare player installed. Regards, Javier. On Tue, Mar 22, 2011 at 4:41 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 March 2011 00:09, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > > we use "squeaknos" platform, which is mainly a unix one minus libc with a > > custom makefile. All platform support files are in the git repo, and the > > slang is generated with VMMakerTool selecting squeaknos platform. > > > > My question was, should i build it under unix , or can also build > under Mac and Win32? > And is there any instruction about steps how to build it? > I wanna to play with it a little. > > > On Mon, Mar 21, 2011 at 6:21 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 21 March 2011 17:30, Javier PimÃ¡s <elpochodelagente(a)gmail.com> > wrote: > >> > For all those who may be intrested, we are glad to announce that we > have > >> > just uploaded an updated version of SqueakNOS to our site. You can > find > >> > the > >> > updated download links here. > >> > This release adds the following items to the previous version: (99.9% > >> > modeled with objects) > >> > - Improved support for ATA devices access > >> > - Implementation of a model of files and directories > >> > - Implementation of FAT32 filesystem > >> > - Support for reading sources from the hard disk > >> > - Support for X86 paging setup and handling of page faults > >> > - Implementation of a model of free and used memory > >> > - Implementation of image snapshotting (based on the paging mechanism) > >> > - Based on Pharo, but also supporting Squeak and Cuis > >> > - Added some primitives for communicating between VM and image > >> > - Support for Alien and FFI > >> > - Added basic support for writing to serial via VM so that it's > possiblo > >> > to > >> > out debug info to the outside world. > >> > - Added pretty basic ATA benchmarks > >> > - Added some scripts to automatize work done from the outside world > >> > - Many code cleanups > >> > Future directions are: > >> > - Support for Cog VM > >> > - Investigate replacing SqueakNOS plugin with NativeBoost so that we > do > >> > more > >> > on the image > >> > - Offloading memory pages to disk > >> > - More tests > >> > - Benchmarks > >> > For the brave ones, remember that you can always generate a SqueakNOS > >> > image > >> > by using the ConfigurationOfSqueakNOS (which is a bit outdated now), > or > >> > by > >> > manually loading the packages from monticello. Also to generate a > >> > SqueakNOS > >> > VM download its code from GIT (hosted on sourceforge.net) > >> > Don't forget to visit squeaknos.blogspot.com for news and > instructions. > >> > We > >> > hope to be able to write more soon. > >> > Many thank's t all the people who made it possible to understand the > >> > code > >> > and to develop all this. > >> > SqueakNOS' Team > >> > > >> > >> Which platform used to build SqueakNOS VM? > >> > > -- > Best regards, > Igor Stasenko AKA sig. > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 22, 2011

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Milestone-1.3-DevImage Comment #16 on issue 3620 by marcus.d...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 (No comment was entered for this change.)

March 22, 2011

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

by Marcus Denker

On Mar 22, 2011, at 2:35 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. > I have the impression that you give a particular status to the bytecodes. I have the feeling that we should not. Yes, to be interpretable without having to check at runtime. > 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? Because we don't want to check everything, else it is too slow. > You could have the necessary guards in the VM. Slow. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 22, 2011