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

Re: [Pharo-project] Issue 3834 in pharo: Add support for Threaded VMs in Process

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3834 by marcus.d...(a)gmail.com: Add support for Threaded VMs in Process http://code.google.com/p/pharo/issues/detail?id=3834 in 13099

March 21, 2011

[Pharo-project] [update 1.3] #13099

by Marcus Denker

13099 ----- Issue 3834: Add support for Threaded VMs in Process -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2011

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

by Tudor Girba

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? Cheers, Doru On 21 Mar 2011, at 10:57, Toon Verwaest wrote: > This does crash whenever you subclass a class which has instance variables and you try to access those instance variables. The problem is that you don't properly initialize your class, leaving you with a Class that has a wrong format. For example: > > cls := Class new superclass: Class; yourself. > cls format > > returns 2. 2 basically means it's an object with pointers but with 0 instance variables. If you instantiate the 'cls' I just made it also crashes. Why? Well, class has an initialize method that is compiled to write to the fields of the new instance. It puts an empty method dictionary into the class you create as an instance of my cls. This segfaults because you are writing outside of memory. > > So just make sure you properly create classes, with a proper format! > > This test should crash all VMs btw... at least at some point. Since you are writing in random memory it might take longer to notice it in some cases; especially when padded memory is owned by the garbage collector :) > > cheers, > Toon > > On 03/21/2011 10:24 AM, Tudor Girba wrote: >> Hi, >> >> Alex recently wrote a test in Moose that seems to crash the Cog VM at least on Mac. >> >> How to reproduce: >> >> - download the following image >> http://dl.dropbox.com/u/18323746/Tmp/moose-crashing-cog-jit.zip >> >> - execute the following code in the workspace (already provided in the image) >> cls := Class new superclass: MooseElement; yourself. >> cls compileSilently: 'mooseName ^ 1/0'. >> element := cls new. >> >> - I used all of the followings and they all crashed: >> https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/4/art… >> https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Cocoa/2… >> http://www.mirandabanda.org/files/Cog/VM/VM.r2370/Cog.app.tgz >> http://www.mirandabanda.org/files/Cog/VM/VM.r2361/Cog.app.tgz >> >> >> The strange thing is that the crash only happens when we subclass MooseElement, but not another class. >> >> Could someone take a look? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Every thing should have the right to be different." >> >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow."

March 21, 2011

[Pharo-project] Issue 3840 in pharo: ivar errorHandler in Process seems to be unused

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3840 by marcus.d...(a)gmail.com: ivar errorHandler in Process seems to be unused http://code.google.com/p/pharo/issues/detail?id=3840 errorHandler has just accessors. These are not sent in core.

March 21, 2011

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

by Bert Freudenberg

It's surprising to me that you find this "news". SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad. Loading Squeak code is inherently dangerous. Installing code usually executes "initialize" methods immediately. That could easily wipe your disk, since almost nobody is using the VM's sandbox (AFAIK, only Etoys uses that feature). OTOH this is not much different from installing a Linux package which also executes "install scripts" that potentially could do a lot of danger. But e.g. the trunk repository is not world-writable so there is no immediate risk. It would be a lot safer if we had signed MCZ packages. Or even better, a tamper-proof history (like git). - Bert - On 21.03.2011, at 03:24, Matthew Fulmer wrote: > As demonstrated by the VMMaker team, SqueakSource has a rather > serious security vunerability: > > http://bugs.squeak.org/view.php?id=7617 > > Below is the dialog that led to this discovery: > > > On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote: >>>> Hmm, wouldn't applying the âdefaultâ naming scheme prevent such >>> overwrites? >>>> >>>> That is, now there would be >>>> VMMaker-oscog-eem.52 >>>> for Elliots version and >>>> VMMaker-oscog-IgorStasenko.52 >>>> for Igors version. >>>> What would prevent us from that? >>>> >>>> I don't see a naming conflict. I've been using VMMaker-oscog.NN since >>> the beginning and Igor has been using VMMaker-oscog-IgorStasenko.NN. This >>> isn't about names, it's about content. Igor is miffed I didn't merge in >>> some changes he made when I published VMMaker-oscog.52, right Igor? >>>> >>> >>> No, youâobviously accidentallyâoverwrote his version of the 18th of March: >>> >> >> So how did Monticello allow me to do that? That's a /bad/ bug. >> >> >>> >>>>>> >>> Name: VMMaker-oscog.52 >>> Author: IgorStasenko >>> Time: 18 March 2011, 12:45:14 am >>> UUID: a2810aac-4423-6740-b70e-7e821b979cb4 >>> Ancestors: VMMaker-oscog-IgorStasenko.50, >>> VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 >>> >>> Merge with oscog-49-51 & Esteban-50 >>> <<<< >>> >>> which has the same file name as yours: >>> >>>>>> >>> Name: VMMaker-oscog.52 >>> Author: eem >>> Time: 20 March 2011, 9:31:20 am >>> UUID: 1241a856-8570-4725-a069-a6d3d8a8a222 >>> Ancestors: VMMaker-oscog.51 >>> >>> Fix primitiveFlushCacheByMethod for objects-as-methods. >>> <<<< > > -- > Matthew Fulmer (a.k.a. Tapple) >

March 21, 2011

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

by Marcus Denker

On Mar 21, 2011, at 9:27 AM, Tobias Pape wrote: > Am 2011-03-21 um 03:24 schrieb Matthew Fulmer: > >> As demonstrated by the VMMaker team, SqueakSource has a rather >> serious security vunerability: >> >> http://bugs.squeak.org/view.php?id=7617 >> >> Below is the dialog that led to this discovery: >> > > > Note that SqueakSource 2 and 3 are unaffected of this bug. > Moreover, find attached a quick fix that is a backport of > the conflict handling in SqueakSource 2 to the original > SqueakSource. > Ok, we added the fix. We verified and versions are not overridden. The strange thing is that MC in the image thinks it was successful and gets confused. A restart of the image shows the correcnt data, so on the squeaksource side the meta data is ok. So as a first workaround, this is working but we should look into a correct error handling on the MC on the image side later. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2011

[Pharo-project] Issue 3839 in pharo: MC Browser refresh does not refresh everything

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3839 by marcus.d...(a)gmail.com: MC Browser refresh does not refresh everything http://code.google.com/p/pharo/issues/detail?id=3839 ... if you attempt to override a version on SqueakSourse, MC thinks it is successful. Restarting the image then shows the correct version of the package in the remote repository

March 21, 2011

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

by Toon Verwaest

This does crash whenever you subclass a class which has instance variables and you try to access those instance variables. The problem is that you don't properly initialize your class, leaving you with a Class that has a wrong format. For example: cls := Class new superclass: Class; yourself. cls format returns 2. 2 basically means it's an object with pointers but with 0 instance variables. If you instantiate the 'cls' I just made it also crashes. Why? Well, class has an initialize method that is compiled to write to the fields of the new instance. It puts an empty method dictionary into the class you create as an instance of my cls. This segfaults because you are writing outside of memory. So just make sure you properly create classes, with a proper format! This test should crash all VMs btw... at least at some point. Since you are writing in random memory it might take longer to notice it in some cases; especially when padded memory is owned by the garbage collector :) cheers, Toon On 03/21/2011 10:24 AM, Tudor Girba wrote: > Hi, > > Alex recently wrote a test in Moose that seems to crash the Cog VM at least on Mac. > > How to reproduce: > > - download the following image > http://dl.dropbox.com/u/18323746/Tmp/moose-crashing-cog-jit.zip > > - execute the following code in the workspace (already provided in the image) > cls := Class new superclass: MooseElement; yourself. > cls compileSilently: 'mooseName ^ 1/0'. > element := cls new. > > - I used all of the followings and they all crashed: > https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/4/art… > https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Cocoa/2… > http://www.mirandabanda.org/files/Cog/VM/VM.r2370/Cog.app.tgz > http://www.mirandabanda.org/files/Cog/VM/VM.r2361/Cog.app.tgz > > > The strange thing is that the crash only happens when we subclass MooseElement, but not another class. > > Could someone take a look? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing should have the right to be different." > > > >

March 21, 2011

[Pharo-project] test crashing the cog vm

by Tudor Girba

Hi, Alex recently wrote a test in Moose that seems to crash the Cog VM at least on Mac. How to reproduce: - download the following image http://dl.dropbox.com/u/18323746/Tmp/moose-crashing-cog-jit.zip - execute the following code in the workspace (already provided in the image) cls := Class new superclass: MooseElement; yourself. cls compileSilently: 'mooseName ^ 1/0'. element := cls new. - I used all of the followings and they all crashed: https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/4/art… https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Cocoa/2… http://www.mirandabanda.org/files/Cog/VM/VM.r2370/Cog.app.tgz http://www.mirandabanda.org/files/Cog/VM/VM.r2361/Cog.app.tgz The strange thing is that the crash only happens when we subclass MooseElement, but not another class. Could someone take a look? Cheers, Doru -- www.tudorgirba.com "Every thing should have the right to be different."

March 21, 2011

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

by Richard Durr

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