- Pharo-dev - lists.pharo.org

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

by Eliot Miranda

On Mon, Mar 21, 2011 at 12:13 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Mar 21, 2011 at 7:23 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> This would be a nice little topic... this bytecode verifier. >> > > Probably on top of Opal > The bytecode verifier must be in the VM. If it is up in the image it can be side-stepped. The VM is the ultimate executor of code and so it must apply verification. It could be written in Smalltalk and verified in Smalltalk and then translated. But it must be part of the VM and used by the VM before running any previously unverified method. best, Eliot > > >> >> Stef >> >> On Mar 21, 2011, at 2:57 PM, Toon Verwaest wrote: >> >> > Yes you are right! Bytecode validation would be very important here. If >> you ask me, the VM should only allow verified bytecode to be executed. Here >> it could have a dual model, where bytecodes are "internalized" whenever you >> give them to the VM first. At that point they are validated. Once it's >> internalized, it can't be modified anymore from the outside, since the >> Smalltalk world doesn't have direct access to the internalized version. All >> changes to the bytecode "source", needs to be propagated to the VM by >> re-internalizing it. >> > >> > This is exactly the model I'm using in Pinocchio... and that allows us >> to not use bytecodes in the first place :) You just need a way to map the >> internal version back onto the highlevel version for debugging. (We don't >> verify the bytecode yet though). >> > >> > Bytecode verification btw shouldn't be too hard. You just need to make >> sure that all the codes are safe for the instance at hand, and for the >> method contexts you create. Anything else is just a runtime semantical error >> which you can't guarantee, since you don't know what the programmer is >> trying to do. We don't verify it yet since I'm still designing my >> register-based bytecodes; and since I atm have too much work at hand :) >> > >> > cheers, >> > Toon >> > >> > On 03/21/2011 02:22 PM, Igor Stasenko wrote: >> >> On 21 March 2011 13:14, Toon Verwaest<toon.verwaest(a)gmail.com> wrote: >> >>> I couldn't agree more! >> >>> >> >>> However, here the problem is not that the format isn't a correct >> format. The >> >>> problem is that a bytecode is activated that is incompatible with the >> >>> instance format. So basically on every bytecode accessing an instance >> you >> >>> would have to check if this is a valid access. And as we all know, >> Smalltalk >> >>> avoids this; it makes things faster :) >> >>> >> >> In other words, a responsibility of having correct bytecode lies on >> >> image side, not on VM side. >> >> >> >> Adding a bytecode verifier to VM will be a lot of work.. And of course >> >> it could verify it only when you installing a method, >> >> not when you activating it. >> >> >> >>> Toon >> >>> >> >>> On 03/21/2011 12:49 PM, Igor Stasenko wrote: >> >>>> On 21 March 2011 11:29, Tudor Girba<tudor.girba(a)gmail.com> wrote: >> >>>>> Thanks, Toon! >> >>>>> >> >>>>> I changed the code to explicitly set the format, and it seems to fix >> the >> >>>>> problem: >> >>>>> >> >>>>> cls := Class new superclass: MooseElement; >> >>>>> setFormat: MooseElement format; >> >>>>> yourself. >> >>>>> cls compileSilently: 'mooseName ^ 1/0'. >> >>>>> element := cls new. >> >>>>> >> >>>>> Is this correct? >> >>>>> >> >>>> Yes, you should pay attention to have correct format. >> >>>> But of course VM could also be more cautios and verify if your class >> >>>> are well formed before creating an instance of it.. >> >>>> >> >>>> >> >>>> >> >>>>> Cheers, >> >>>>> Doru >> >>>>> >> >>>> >> >>> >> >>> >> >> >> >> >> > >> > >> >> >> >

March 21, 2011

Re: [Pharo-project] Thank you ProfStef

by Mariano Martinez Peck

On Mon, Mar 21, 2011 at 8:38 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Mon, Mar 21, 2011 at 7:59 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Thanks Laurent :) >> > > A nice documenting tool is great, good content far better :) So thanks Dale > & Mariano for their good documentation. We need more. > Yes. And what is more, is that from the same source we can have different outputs: class comments, pharo collaborative book, ProfStef, Help System, etc... > > Laurent. > > > >> >> >> On 21.03.2011, at 19:21, StÃ©phane Ducasse wrote: >> >> > Thanks Laurent! Since he did ProfStef. He just started with my examples >> :) >> > On Mar 21, 2011, at 1:50 PM, Max Leske wrote: >> > >> >> Just a short thank you Stef. When I thought about tackling Metacello >> configurations it felt like it was going to be tough. But then: ProfStef to >> the rescue! >> >> >> >> Really a great idea! How many other IDE's sport a tutorial mechanism >> that can be easily extended by anyone? Not many I guess... >> >> >> >> Cheers, >> >> Max >> > >> > >> >> >> >

March 21, 2011

Re: [Pharo-project] Thank you ProfStef

by laurent laffont

On Mon, Mar 21, 2011 at 7:59 PM, Max Leske <maxleske(a)gmail.com> wrote: > Thanks Laurent :) > A nice documenting tool is great, good content far better :) So thanks Dale & Mariano for their good documentation. We need more. Laurent. > > > On 21.03.2011, at 19:21, StÃ©phane Ducasse wrote: > > > Thanks Laurent! Since he did ProfStef. He just started with my examples > :) > > On Mar 21, 2011, at 1:50 PM, Max Leske wrote: > > > >> Just a short thank you Stef. When I thought about tackling Metacello > configurations it felt like it was going to be tough. But then: ProfStef to > the rescue! > >> > >> Really a great idea! How many other IDE's sport a tutorial mechanism > that can be easily extended by anyone? Not many I guess... > >> > >> Cheers, > >> Max > > > > > > >

March 21, 2011

Re: [Pharo-project] [COTDC] 34 - MCSystemCategoryParser

by laurent laffont

Could it be: I parse PackageInfo statement from Monticello packages file. Laurent. On Mon, Mar 21, 2011 at 8:02 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: MCSystemCategoryParser > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

March 21, 2011

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

by Mariano Martinez Peck

On Mon, Mar 21, 2011 at 7:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > This would be a nice little topic... this bytecode verifier. > Probably on top of Opal > > Stef > > On Mar 21, 2011, at 2:57 PM, Toon Verwaest wrote: > > > Yes you are right! Bytecode validation would be very important here. If > you ask me, the VM should only allow verified bytecode to be executed. Here > it could have a dual model, where bytecodes are "internalized" whenever you > give them to the VM first. At that point they are validated. Once it's > internalized, it can't be modified anymore from the outside, since the > Smalltalk world doesn't have direct access to the internalized version. All > changes to the bytecode "source", needs to be propagated to the VM by > re-internalizing it. > > > > This is exactly the model I'm using in Pinocchio... and that allows us to > not use bytecodes in the first place :) You just need a way to map the > internal version back onto the highlevel version for debugging. (We don't > verify the bytecode yet though). > > > > Bytecode verification btw shouldn't be too hard. You just need to make > sure that all the codes are safe for the instance at hand, and for the > method contexts you create. Anything else is just a runtime semantical error > which you can't guarantee, since you don't know what the programmer is > trying to do. We don't verify it yet since I'm still designing my > register-based bytecodes; and since I atm have too much work at hand :) > > > > cheers, > > Toon > > > > On 03/21/2011 02:22 PM, Igor Stasenko wrote: > >> On 21 March 2011 13:14, Toon Verwaest<toon.verwaest(a)gmail.com> wrote: > >>> I couldn't agree more! > >>> > >>> However, here the problem is not that the format isn't a correct > format. The > >>> problem is that a bytecode is activated that is incompatible with the > >>> instance format. So basically on every bytecode accessing an instance > you > >>> would have to check if this is a valid access. And as we all know, > Smalltalk > >>> avoids this; it makes things faster :) > >>> > >> In other words, a responsibility of having correct bytecode lies on > >> image side, not on VM side. > >> > >> Adding a bytecode verifier to VM will be a lot of work.. And of course > >> it could verify it only when you installing a method, > >> not when you activating it. > >> > >>> Toon > >>> > >>> On 03/21/2011 12:49 PM, Igor Stasenko wrote: > >>>> On 21 March 2011 11:29, Tudor Girba<tudor.girba(a)gmail.com> wrote: > >>>>> Thanks, Toon! > >>>>> > >>>>> I changed the code to explicitly set the format, and it seems to fix > the > >>>>> problem: > >>>>> > >>>>> cls := Class new superclass: MooseElement; > >>>>> setFormat: MooseElement format; > >>>>> yourself. > >>>>> cls compileSilently: 'mooseName ^ 1/0'. > >>>>> element := cls new. > >>>>> > >>>>> Is this correct? > >>>>> > >>>> Yes, you should pay attention to have correct format. > >>>> But of course VM could also be more cautios and verify if your class > >>>> are well formed before creating an instance of it.. > >>>> > >>>> > >>>> > >>>>> Cheers, > >>>>> Doru > >>>>> > >>>> > >>> > >>> > >> > >> > > > > > > >

March 21, 2011

Re: [Pharo-project] Thank you ProfStef

by Max Leske

Thanks Laurent :) On 21.03.2011, at 19:21, StÃ©phane Ducasse wrote: > Thanks Laurent! Since he did ProfStef. He just started with my examples :) > On Mar 21, 2011, at 1:50 PM, Max Leske wrote: > >> Just a short thank you Stef. When I thought about tackling Metacello configurations it felt like it was going to be tough. But then: ProfStef to the rescue! >> >> Really a great idea! How many other IDE's sport a tutorial mechanism that can be easily extended by anyone? Not many I guess... >> >> Cheers, >> Max > >

March 21, 2011

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

by StÃ©phane Ducasse

This would be a nice little topic... this bytecode verifier. Stef On Mar 21, 2011, at 2:57 PM, Toon Verwaest wrote: > Yes you are right! Bytecode validation would be very important here. If you ask me, the VM should only allow verified bytecode to be executed. Here it could have a dual model, where bytecodes are "internalized" whenever you give them to the VM first. At that point they are validated. Once it's internalized, it can't be modified anymore from the outside, since the Smalltalk world doesn't have direct access to the internalized version. All changes to the bytecode "source", needs to be propagated to the VM by re-internalizing it. > > This is exactly the model I'm using in Pinocchio... and that allows us to not use bytecodes in the first place :) You just need a way to map the internal version back onto the highlevel version for debugging. (We don't verify the bytecode yet though). > > Bytecode verification btw shouldn't be too hard. You just need to make sure that all the codes are safe for the instance at hand, and for the method contexts you create. Anything else is just a runtime semantical error which you can't guarantee, since you don't know what the programmer is trying to do. We don't verify it yet since I'm still designing my register-based bytecodes; and since I atm have too much work at hand :) > > cheers, > Toon > > On 03/21/2011 02:22 PM, Igor Stasenko wrote: >> On 21 March 2011 13:14, Toon Verwaest<toon.verwaest(a)gmail.com> wrote: >>> I couldn't agree more! >>> >>> However, here the problem is not that the format isn't a correct format. The >>> problem is that a bytecode is activated that is incompatible with the >>> instance format. So basically on every bytecode accessing an instance you >>> would have to check if this is a valid access. And as we all know, Smalltalk >>> avoids this; it makes things faster :) >>> >> In other words, a responsibility of having correct bytecode lies on >> image side, not on VM side. >> >> Adding a bytecode verifier to VM will be a lot of work.. And of course >> it could verify it only when you installing a method, >> not when you activating it. >> >>> Toon >>> >>> On 03/21/2011 12:49 PM, Igor Stasenko wrote: >>>> On 21 March 2011 11:29, Tudor Girba<tudor.girba(a)gmail.com> wrote: >>>>> Thanks, Toon! >>>>> >>>>> I changed the code to explicitly set the format, and it seems to fix the >>>>> problem: >>>>> >>>>> cls := Class new superclass: MooseElement; >>>>> setFormat: MooseElement format; >>>>> yourself. >>>>> cls compileSilently: 'mooseName ^ 1/0'. >>>>> element := cls new. >>>>> >>>>> Is this correct? >>>>> >>>> Yes, you should pay attention to have correct format. >>>> But of course VM could also be more cautios and verify if your class >>>> are well formed before creating an instance of it.. >>>> >>>> >>>> >>>>> Cheers, >>>>> Doru >>>>> >>>> >>> >>> >> >> > >

March 21, 2011

Re: [Pharo-project] Thank you ProfStef

by StÃ©phane Ducasse

Thanks Laurent! Since he did ProfStef. He just started with my examples :) On Mar 21, 2011, at 1:50 PM, Max Leske wrote: > Just a short thank you Stef. When I thought about tackling Metacello configurations it felt like it was going to be tough. But then: ProfStef to the rescue! > > Really a great idea! How many other IDE's sport a tutorial mechanism that can be easily extended by anyone? Not many I guess... > > Cheers, > Max

March 21, 2011

Re: [Pharo-project] allOverriddenMethods is confusing

by StÃ©phane Ducasse

> > > Since .changes has been trunkated since Polymorph was merged, you won't find any packages whose methods are actually overridden by the Polymorph overrides :P > > Cheers, > Henry > > PS. How does RPackage deal with overriden methods? it does not :) No overrides. > PPS. I profiled this long ago, while it did show up, removing overrides didn't actually have a noticeable impact on the loading speed of Monticello

March 21, 2011

[Pharo-project] ZeroMQ bindings for GNU Smalltalk

by Vijay Mathew

I have created a repository at https://github.com/vijaymathew/gst_zmq. I started off this project by attempting to write an FFI extension for Pharo but the call to `zmq_connect` is crashing the Squeak VM. But the extension worked like a breeze for GNU Smalltalk! -- Vijay

March 21, 2011