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

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

Re: [Pharo-project] Jtalk, a Smalltalk for web developers

by Hannes Hirzel

More compilers which compile from a dynamic language to JavaScript https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-comp… Smalltalk not mentioned yet .... --Hannes On 3/21/11, Richard Durr <richard.durr(a)googlemail.com> wrote: > As far as I can see, the only way to call external Javascript is by writing > Javascript-Code directly into a method like so: > doSomethingWith: anObject > {'return SOMELIBRARY.doSomething(anObject); '} > > is this correct? > The OMETA based Smalltalk->JS translator seem to let one use st-syntax for > direct access to javascript like so: > > doSomethingWith: anObject [ > SOMELIBRARY doSomething: anObject. > ] > > and CoffeeScript can use JS seamlessly in the same way. > > Best regards, > RD > > On Mon, Mar 14, 2011 at 7:36 PM, Nicolas Petton > <petton.nicolas(a)gmail.com>wrote: > >> Hi, >> >> I would like to share a project I'm working on on my spare time: Jtalk >> Smalltalk. >> >> http://nicolaspetton.github.com/jtalk >> https://github.com/NicolasPetton/jtalk >> >> Jtalk is an implementation of the Smalltalk language that compiles into >> JavaScript. >> >> Some features: >> - it is written in itself (including the parser/compiler) >> - it is self-contained >> - it compiles into efficient JS code >> - it uses the Squeak chunk format >> - Pharo is considered as the reference implementation >> >> I think Jtalk can be compared to CoffeeScript[1], Objective-J[2] or >> Clamato[3], from which it reuses some ideas and code. >> >> Jtalk includes an IDE with a class browser, transcript and workspace, an >> HTML canvas similar to Seaside and a jQuery binding. >> >> It is still a young piece of code, and some important features are still >> missing/incomplete. >> >> Cheers, >> Nicolas Petton >> >> [1] http://jashkenas.github.com/coffee-script/ >> [2] http://cappuccino.org/ >> [3] http://clamato.net >> >> >> >

March 21, 2011

Re: [Pharo-project] Issue 2299 in pharo: Do not hardcode the color for Workspaces from UIManager

by pharo＠googlecode.com

Updates: Status: Invalid Comment #4 on issue 2299 by marcus.d...(a)gmail.com: Do not hardcode the color for Workspaces from UIManager http://code.google.com/p/pharo/issues/detail?id=2299 This is already changed to be much simpler: edit: aText label: labelString accept: anAction "Open an editor on the given string/text" ^(Workspace openLabel: labelString) acceptContents: aText; acceptAction: anAction; yourself.

March 21, 2011

Re: [Pharo-project] Issue 2594 in pharo: GoferApiTest>>#testSubdirectoryRepository fails

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 2594 by marcus.d...(a)gmail.com: GoferApiTest>>#testSubdirectoryRepository fails http://code.google.com/p/pharo/issues/detail?id=2594 All test are green in 1.2

March 21, 2011

Re: [Pharo-project] Issue 2135 in pharo: New Icons

by pharo＠googlecode.com

Updates: Status: Invalid Comment #7 on issue 2135 by marcus.d...(a)gmail.com: New Icons http://code.google.com/p/pharo/issues/detail?id=2135 I don't know if it is good to have issues like this in the Bug Tracker... We should make a Wishlist somewhere.

March 21, 2011