- Pharo-dev - lists.pharo.org

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

by Alexandre Bergel

Shouldn't it be: (Smalltalk at: #ConfigurationOfOCompletion) project version: 'stable' load. Instead? Alexandre Le 21 mars 2011 Ã 03:13, laurent laffont <laurent.laffont(a)gmail.com> a Ã©crit : > Mariano, > > I've added Autotest. > > I've seen a lot of Configuration example which won't work because of missing parenthesis: > > (Smalltalk at: #ConfigurationOfOCompletion) project version: '1.1.2' load. > > should be > > ((Smalltalk at: #ConfigurationOfOCompletion) project version: '1.1.2') load. > > > I cannot fix it now - must go to work. > > Laurent > > On Sun, Mar 20, 2011 at 11:40 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I've added: > > - Gofer > - Monticello > - Metacello > - Fuel > > If you can check and improve it..please do. It only took me 30 mins. > > Cheers > > Mariano > > > On Sun, Mar 20, 2011 at 11:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I forgot...If someone answer "but you can browse the MetecelloRepository" or "XX" or "blah"....the answer is that we are not targeting the same people. Someone that knows how that he has to browse MetacelloRepository, probably knows how to install the software, what it is, etc. > With this page (after, moved to the pharo website) we want to targe business and new comers. Imagine someone arriving to Pharo and asking himseld "mmmmm does Pharo have XXX that I have in YYY language? ". So the idea is to show all the available tools. > > Cheers > > Mariano > > > On Sun, Mar 20, 2011 at 10:42 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks mariano this is a good initiative. > > Stef > > On Mar 20, 2011, at 10:22 PM, Mariano Martinez Peck wrote: > > > ifTrue: [ self writeOnPharoBook: aTool] > > > > We need to improve our documentation. Right now, we have a collaborative book where everyone can join and write: http://book.pharo-project.org/ > > > > Here we have a list of tools that run on Pharo: http://book.pharo-project.org/book/PharoTools > > and it is REALLY important to have such list updated and maintained. > > > > So, if you have a tool that works in pharo and it is not there, please add it. If you don't have a user, I can create one for you. If you are TOO lazy, you can send by email the text to me and I write it. > > > > Thanks > > > > Mariano > > > > >

March 21, 2011

Re: [Pharo-project] [squeak-dev] [UPD] NativeBoost runs on new Cog VMs

by Bert Freudenberg

On 21.03.2011, at 03:12, Igor Stasenko wrote: > On 21 March 2011 02:43, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Sun, 20 Mar 2011, Igor Stasenko wrote: >> >>> Hello, >>> i just wanna to inform you that i adopted NativeBoost plugin for >>> building with latest Cog vms. >> >> Great. >> >>> >>> To build VM, you should have an image with VMMaker + CMakeVMMaker >>> packages installed. >>> >>> Then load NBIntaller package and do: >>> NBInstaller installCogPlugin >>> >>> There are new cmake configurations i added to build VMs with NB plugin >>> support. >> >> It's an old question, but I don't remember your answer, so: wouldn't it >> be better to add a command line switch for enabling NB? So even if a VM is >> compiled with NB, I can still turn it off if I want to. >> > > It is disabled by default, when you starting a new image. > This allows me to not care if some of the methods were carrying native > code saved into an image. > > For enabling a native code, one should invoke #primitiveEnable first. > You can customize a mechanism of enabling it in > NativeBoost class>>enableNativeCode > and put checking of command-line argument(s) there. > > And yes, i am against putting extra logic at plugin side :) > The reason is simple: if you using it, then you know what you doing, > and if you don't - then you safe anyways. IMHO it's a good idea to not allow native code execution if the VM sandbox is enabled. Just like e.g. OSProcess checks the SecurityPlugin for this. - Bert -

March 21, 2011

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

by Toon Verwaest

If this is all you are doing then yes, that is correct. If you expect the format to be different in the new subclass you will have to recalculate it, but since you aren't doing that in this example, this is fine. cheers, Toon On 03/21/2011 11:29 AM, Tudor Girba 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? > > 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

Re: [Pharo-project] allOverriddenMethods is confusing

by Henrik Johansen

On Mar 20, 2011, at 9:48 31AM, StÃ©phane Ducasse wrote: > So allOverriddenMethods returns all the methods of the complete system and it may be correct but strange to have it on the instance side. Probably for convenience, so you don't write self class allIOverriden... in methods like the one below. > Now my hypothesis is that > > >> overriddenMethodsDo: aBlock > "Enumerates the methods the receiver contains which have been overridden by other packages" > ^ self allOverriddenMethodsDo: [:ea | > (self isOverrideOfYourMethod: ea) > ifTrue: [aBlock value: ea]] > > check the complete system for every package snapshot and since we have a lot of override because of polymorph we pay the price. > I will fold the overrides first and try to understand mc > > > Stef Yes, allOverridenMethods returns all overrides in the entire system. Another example of what you have to do when using categories for packaging :) To figure out the overridden methods in your package, it - Checks class category is not yours - Scans source for old category. 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? 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

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