June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Log fwk

by Edgar J. De Cleene

On 6/3/12 8:11 PM, "Santiago Bragagnolo" <santiagobragagnolo(a)gmail.com> wrote: > I have added a metacello configuration for the project: > There's only one version, so bleeding edge. > > Gofer new > Â Â Â squeaksource3: 'PaulLePoulpe'; > Â Â Â package: 'ConfigurationOfPaulLePoulpe'; > Â Â Â load. > Â Â Â > ConfigurationOfPaulLePoulpe project bleedingEdge load In both Pharo 1.4 and Pharo 2.0 updated I get this odd: Gofer new Â Â Â Argument expected ->squeaksource3: 'PaulLePoulpe'; Â Â Â package: 'ConfigurationOfPaulLePoulpe'; Â Â Â load. When I do by hand, start to load until I got the attached error. Edgar

June 4, 2012

Re: [Pharo-project] [ConcreteTypeInference] news.

by Edgar J. De Cleene

On 6/3/12 10:31 PM, "Santiago Bragagnolo" <santiagobragagnolo(a)gmail.com> wrote: > Hi all! > > > Â I'm announcing four new posts on the blog, > > Concrete types - A little brief about concrete types to understand the > mechanisms > http://concretetypeinference.blogspot.com.ar/2012/06/concrete-types.html > > About mechanisms part 1 - talking about problems getting green the tests :). > This revision is about contexts of block evaluation > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > locks-on.html > > About mechanisms part 2 - This revision is about a pretty weird scenario > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > locks-called.html > > Metacello configuration - nothing to add to the title. > http://concretetypeinference.blogspot.com.ar/2012/06/metacello-concretetype… > erence-project.html > > > Good week. > > I enjoying your blog and your work. > Please continue. > > Y me gustarÃa te unas a http://ar.groups.yahoo.com/group/squeakRos/ > > Edgar

June 4, 2012

[Pharo-project] Slides and Pictures PharoConf

by Marcus Denker

Hello, We now have an archiving page for PharoConf2012: http://rmod.lille.inria.fr/web/pier/Events/PharoConf2012 This has all Slides, Success Story presentations and the slides from the "Speed Dating" session. In addition, there are some photos for the two day. Marcus -- Marcus Denker -- http://marcusdenker.de

June 4, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Phil (list)

Igor, On Jun 4, 2012, at 1:55 AM, Igor Stasenko wrote: > On 3 June 2012 18:01, Phil (list) <pbpublist(a)gmail.com> wrote: >> On Jun 3, 2012, at 11:31 AM, Marcus Denker wrote: >> >>> >>> How do people do it with Java? Java .jar files are as easy to decompile as Smalltalk bytecode... >>> >> >> ProGuard (http://proguard.sourceforge.net/) is a popular method. In its obfuscation phase it will rename most class and method names (i.e. anything that doesn't need to be externally visible) to meaningless names so MyClass.MyMethod becomes something like a.a. It can also generate a mapping file so that when bug reports / crashes occur, the developer can map the gibberish names back to the original names. Before the obfuscation phase, it has optimization and shrinking phases to eliminate code that doesn't need to be included for release (debugging code etc.) >> > > so, what prevents others from writing de-obfuscating tool and then > read nice sources? De-obfuscating what? The reverse mapping resides with the developer. So a determined hacker can see that class 'a' has methods 'a', 'b', 'c' and has instance vars 'a', 'b', 'c', 'd', and 'e'. (Literally, that's what the names get turned into) Granted, there are some clues left behind (a few classes/methods that need to be externally referenced and classes/methods that your code calls out to), but *your* code has essentially been turned into high-level undocumented assembly code that won't be that much more obvious than what can be produced by a good disassembler. One weakness of ProGuard obfuscation is that it is fairly static in its mapping (though even if they randomized it a bit, it probably wouldn't be that hard to do a structure-diff of the code to figure out how the latest release mapped to an older release using a tool like Moose)... i.e. you get a bit of naming drift as the number of classes and methods change, but the order of mapping is static. > > no matter what you do, as long as you distribute executable code to > masses, it can be reverse-engineered. You can only make it harder. > But there is good way to prevent this from happening: stop selling > binary files, > start selling real support for your software, ship updates regularly, > make customers happy. > Then you will be immune from any piracy, because nobody will think > pirating your software, > because it is useless without your support. > I agree that it does nothing to prevent reverse-engineering by someone who's dedicated and getting support provides significant value. The situation is no different with with languages that emit true binary code: if it can be run on the users machine, it can be cracked/reverse-engineered. However, it does make the effort quite a bit more tedious without intention revealing names. I've decompiled several of my own obfuscated Java apps and come to the conclusion that if I were attempting to reverse-engineer my own stuff without the knowledge of why things ended up as they did, I'd have a much easier time just reimplementing it as knowing what I did doesn't help me at all with the 'why'. Sure, if one had a highly valued application a group of like-minded individuals could figure it out in short order... but ah, what a problem to have :-) Anyway, I was just trying to address the question of how Java apps address the issue. > > > -- > Best regards, > Igor Stasenko. > Thanks, Phil

June 4, 2012

Re: [Pharo-project] ClassBoxes... bitrotted, or usable?

by StÃ©phane Ducasse

Hi jan > - having a class Selector that get evaluated into a symbol. You can then achieved selector namespaces, which does not incur a cost at execution. Indeed we should just agree that this is the semantics we want for class extensions for example :) Jan did you have a look at http://timelessrepo.com/refinements-in-ruby Because I would like to know if there are more selector or classbox oriented or something else? Stef . > I do not understand the idea. Could you give an example? > > > Cheers, Jan > > > >> >> Cheers, >> Alexandre >> >> >> On Jun 1, 2012, at 10:55 AM, Frank Shearar wrote: >> >>> I mused with a colleague about how I'd like to see "lexically scoped >>> monkey patching", and he pointed me to some guys that want to add that >>> to Ruby (http://timelessrepo.com/refinements-in-ruby) Note the >>> inspiration for their work: ClassBoxes! >>> (http://scg.unibe.ch/research/classboxes) >>> >>> I remember reading the paper years ago, and started working through it >>> again now. Something that's not clear to me is this: does ClassBoxes >>> require VM-side changes? (Because it changes the method lookup, after >>> all, searching packages for methods before working up the inheritance >>> tree.) If so, how invasive are they? If not, do we have a ball-park >>> estimate of how much work it would be to update ClassBoxes to a more >>> recent Squeak/Pharo? >>> >>> I'm more than happy to do the dogwork. I'd just like to know whether >>> I'm signing up for months of work or not. >>> >>> Thanks! >>> >>> frank >>> >> > >

June 4, 2012

Re: [Pharo-project] [ANN] Roassal 1.28

by StÃ©phane Ducasse

Thanks alex and others. Now did you have a look at Athens? Because you have vector graphics inside the image **now**. And this is working. Stef > Dear Fellow, > > A couple of weeks ago we have released the Roassal visualization engine. Many of you gave us feedback and we are deeply grateful for this. > > Since we released the first version, we have closed 25 issues [*]. Many things are left to do, especially to satisfy all the requirements from the Moose community. > > We are currently working on an HTML exporter for Roassal. We know this is a highly wanted feature. In a couple of weeks we should be able to deliver it. > > Since the first release of Roassal, we have worked very hard on it and we will continue to do so. > > Thanks to all of you! > Alexandre, Vanessa, Juan Pablo > > [*] http://code.google.com/p/objectprofile/issues/list?can=1&q=status=Fixed%20c… > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

June 4, 2012

Re: [Pharo-project] ClassBoxes... bitrotted, or usable?

by Jan Vrany

Hi - having a class Selector that get evaluated into a symbol. You can then achieved selector namespaces, which does not incur a cost at execution. I do not understand the idea. Could you give an example? Cheers, Jan > > Cheers, > Alexandre > > > On Jun 1, 2012, at 10:55 AM, Frank Shearar wrote: > >> I mused with a colleague about how I'd like to see "lexically scoped >> monkey patching", and he pointed me to some guys that want to add that >> to Ruby (http://timelessrepo.com/refinements-in-ruby) Note the >> inspiration for their work: ClassBoxes! >> (http://scg.unibe.ch/research/classboxes) >> >> I remember reading the paper years ago, and started working through it >> again now. Something that's not clear to me is this: does ClassBoxes >> require VM-side changes? (Because it changes the method lookup, after >> all, searching packages for methods before working up the inheritance >> tree.) If so, how invasive are they? If not, do we have a ball-park >> estimate of how much work it would be to update ClassBoxes to a more >> recent Squeak/Pharo? >> >> I'm more than happy to do the dogwork. I'd just like to know whether >> I'm signing up for months of work or not. >> >> Thanks! >> >> frank >> >

June 4, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Igor Stasenko

On 3 June 2012 18:01, Phil (list) <pbpublist(a)gmail.com> wrote: > On Jun 3, 2012, at 11:31 AM, Marcus Denker wrote: > >> >> How do people do it with Java? Java .jar files are as easy to decompile as Smalltalk bytecode... >> > > ProGuard (http://proguard.sourceforge.net/) is a popular method. Â In its obfuscation phase it will rename most class and method names (i.e. anything that doesn't need to be externally visible) to meaningless names so MyClass.MyMethod becomes something like a.a. Â It can also generate a mapping file so that when bug reports / crashes occur, the developer can map the gibberish names back to the original names. Â Before the obfuscation phase, it has optimization and shrinking phases to eliminate code that doesn't need to be included for release (debugging code etc.) > so, what prevents others from writing de-obfuscating tool and then read nice sources? no matter what you do, as long as you distribute executable code to masses, it can be reverse-engineered. You can only make it harder. But there is good way to prevent this from happening: stop selling binary files, start selling real support for your software, ship updates regularly, make customers happy. Then you will be immune from any piracy, because nobody will think pirating your software, because it is useless without your support. >> Â Â Â Marcus >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > > Thanks, > Phil -- Best regards, Igor Stasenko.

June 4, 2012

Re: [Pharo-project] McHttpRepository and text/plain

by Stuart Herring

Hi Sven, > -1 > > #asByteArray does an implicit text to bytes conversion (granted, a stupid one). > This will (and had conflicted in the past) with the text conversion done automatically by the HTTP client. > The response simply has to be binary because the data is binary. Yes, I understand. The important thing is that at the moment is that a misconfigured server results in something that gives the appearance of a Pharo bug. >> Failing that, the condition should probably be explicitly checked for >> and a more useful error message given, as the cause is far enough away >> from the symptom that it takes a bit of digging to find out what went >> wrong. > > +1 > > Yes, the error should be reported better. As it is today is not acceptable. > > Normally, the ZnClient>>#accept: option (in combination with #systemPolicy) would do the trick. > However, while a ZnMimeType text wildcard (text/*) is useful to require textual responses, no such general wildcard exists for (all) binary responses. We could try with (application/*) and hope that enough MC servers comply (I think most will use application/octet-stream or application/x-monticello anyway). > > I could try to make a 2.0 patch and see what happens. Excellent! Regards, Stuart

June 4, 2012

Re: [Pharo-project] [ConcreteTypeInference] news.

by Santiago Bragagnolo

In order to order my work i opened an issue tracker at google code. If you see any bug or somethig let me know it here http://code.google.com/p/concrete-type-inference 2012/6/3 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > Hi all! > > > I'm announcing four new posts on the blog, > > Concrete types - A little brief about concrete types to understand the > mechanisms > http://concretetypeinference.blogspot.com.ar/2012/06/concrete-types.html > > About mechanisms part 1 - talking about problems getting green the tests > :). This revision is about contexts of block evaluation > > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > > About mechanisms part 2 - This revision is about a pretty weird scenario > > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > > Metacello configuration - nothing to add to the title. > > http://concretetypeinference.blogspot.com.ar/2012/06/metacello-concretetype… > > > Good week. >

June 4, 2012