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

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

by Toon Verwaest

The problem is exactly what you had at hand. Your bytecode WAS valid, but it was used in combination with an incompatible class layout. So validation here wouldn't solve anything. You always need to validate in a closed world to ensure you don't accidentally break everything. Whenever you change something, you need to ensure that you revalidate the relevant parts. In this case you could for example just have validated that your new class is a valid subclass of its superclass; which it was not. To make the system more secure obviously you would have to check those things, but if you add part of the API that circumvents these checks, like you were doing by calling "Class new" rather than using the ClassBuilder which does do the checks, everything breaks. The only authority that can actually ensure that you don't circumvent these checks is the VM. Obviously you can make sure already in your image that you have enough checks everywhere. You just don't have a crashproof mechanism that will chain your users down avoiding that they shoot themselves in the foot with segfaults. If you put it inside of the VM you -can- provide such a mechanism, because you don't execute anything unless you know it's safe. And as I said, this piece of code could be a piece of prevalidated Smalltalk code that's immutable from the rest of the image. cheers, Toon On 03/22/2011 02:37 PM, Alexandre Bergel wrote: >> But why we could not have a byecode validator at the image level that first make sure that byte code are in sync with the format of the objects. >> Why this has to be done in the vm. > > I agree with Stef. It is not obvious for me why it has to be done at the VM. > > Alexandre

March 22, 2011

[Pharo-project] [update 1.3] #13101

by stephane ducasse

13101 ----- - Cleaning Polymorph overrides. Part one

March 22, 2011

Re: [Pharo-project] Filesystem and FS extensions in Pharo book

by Max Leske

Yes, I understand that. My question is if I should create entries for the "old" version since that one is working and has working extensions. Max On 22.03.2011, at 13:37, StÃ©phane Ducasse wrote: > right now we are stuck because we started documenting and understanding FS and coling publihsed a new one and he should merge our changes > > Stef > > On Mar 22, 2011, at 1:20 PM, Max Leske wrote: > >> Hey >> >> I miss Filesystem and its extensions (cURL, zip, git etc.) in the Pharo book. I'd write the entries but I want your oppinion on whether we should wait till the Filesystem rewrite in 1.2 is ready. >> >> My suggestion: >> >> ---- Pharo Tools >> ---- ---- Filesystem >> ---- ---- ---- Filesystem for Pharo 1.1 >> ---- ---- ---- ---- extensions 1 ...n >> ---- ---- ---- Filesystem for Pharo 1.2 >> ---- ---- ---- ---- extensions 1 ...n >> >> Should we even list the "old" versions? The downside to that is that we would have to wait for all the extensions to be updated. >> What do you think? >> >> Max >> >> > >

March 22, 2011

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

by Marcus Denker

On Mar 22, 2011, at 1:35 PM, StÃ©phane Ducasse wrote: > But why we could not have a byecode validator at the image level that first make sure that byte code are in sync with the format of the objects. > Why this has to be done in the vm. > Because you can not gurantee that they are not changed after. Or that the code is changed that does the checking. or... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 22, 2011

Re: [Pharo-project] Filesystem and FS extensions in Pharo book

by StÃ©phane Ducasse

right now we are stuck because we started documenting and understanding FS and coling publihsed a new one and he should merge our changes Stef On Mar 22, 2011, at 1:20 PM, Max Leske wrote: > Hey > > I miss Filesystem and its extensions (cURL, zip, git etc.) in the Pharo book. I'd write the entries but I want your oppinion on whether we should wait till the Filesystem rewrite in 1.2 is ready. > > My suggestion: > > ---- Pharo Tools > ---- ---- Filesystem > ---- ---- ---- Filesystem for Pharo 1.1 > ---- ---- ---- ---- extensions 1 ...n > ---- ---- ---- Filesystem for Pharo 1.2 > ---- ---- ---- ---- extensions 1 ...n > > Should we even list the "old" versions? The downside to that is that we would have to wait for all the extensions to be updated. > What do you think? > > Max > >

March 22, 2011

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

by StÃ©phane Ducasse

But why we could not have a byecode validator at the image level that first make sure that byte code are in sync with the format of the objects. Why this has to be done in the vm. Stef

March 22, 2011

Re: [Pharo-project] Getting a functionning unstable image

by Marcus Denker

On Mar 22, 2011, at 1:25 PM, StÃ©phane Ducasse wrote: > +1 > > Now condenses change should work too :) > I am slowly adopting a radical "if we don't test it, it's will brake" point of view. I now even say: If we don't test it, it *should* be broken! Because it is dead code and should be removed. Marcus >>> So it was my fault finally: it's because I was too early, and started >>> from Pharo0.x, then applied this automated condenseSources: >>> >> Oh. >>> >>> That explains why I can never upgrade from a newer image... >>> I brought my 0.x image up to 1.2 by some tricky manual MC loading >>> and/or selective loading. >>> But now, things shall be easier :) >>> >> >> Yes... the thing is that everythign that we do not test will not work. We >> do not test updating 0.x --> 1.2. It *will* be broken. >> (And there is the question if it makes sense to keep these things working. >> I vote for investing into a declarative bootstrap instead, far more important) >> >> Marcus >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 22, 2011

Re: [Pharo-project] Getting a functionning unstable image

by StÃ©phane Ducasse

+1 Now condenses change should work too :) >> So it was my fault finally: it's because I was too early, and started >> from Pharo0.x, then applied this automated condenseSources: >> > Oh. >> >> That explains why I can never upgrade from a newer image... >> I brought my 0.x image up to 1.2 by some tricky manual MC loading >> and/or selective loading. >> But now, things shall be easier :) >> > > Yes... the thing is that everythign that we do not test will not work. We > do not test updating 0.x --> 1.2. It *will* be broken. > (And there is the question if it makes sense to keep these things working. > I vote for investing into a declarative bootstrap instead, far more important) > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

March 22, 2011

Re: [Pharo-project] [COTDC] 34 - MCSystemCategoryParser -- help needed, seriously

by StÃ©phane Ducasse

continue please continue Stef On Mar 22, 2011, at 8:14 AM, laurent laffont wrote: > Hi people, > > almost no participation in COTDC last days. > > I'm not a Smalltalk guru and even 30mn to look at code is sometimes not enough for me to understand some stuff alone. > > I like COTDC because of http://code.google.com/p/pharo/wiki/CommentOfTheDayContest ==> documentation. > > But quality / good comment is needed and there's ~600 classes without comment remaining. So if we want a 100% good commented Pharo in 2 years from now, we should do it every day. > > Laurent Laffont > > On Mon, Mar 21, 2011 at 8:36 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > 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 22, 2011

Re: [Pharo-project] String>>#base64Encoded

by StÃ©phane Ducasse

Thanks may be we should record this nice explanation in the help or something like that. On Mar 22, 2011, at 7:45 AM, Sven Van Caekenberghe wrote: > > On 21 Mar 2011, at 21:52, StÃ©phane Ducasse wrote: > >> On Mar 21, 2011, at 9:42 PM, Sven Van Caekenberghe wrote: >> >>> Hi, >>> >>> It took me quite some time today to figure this out and it might be relevant for others too: >>> >>> it turns out that String>>#base64Encoded introduces newlines which you definitively do not want when doing Basic HTTP Encoding for example. The tricky part is that it works when you stay below a certain length. >> >> when would it makes sense? > > Base64 encoding ( http://en.wikipedia.org/wiki/Base64 ) is a techique to encode binary data in ASCII strings using a radix 64 representation. It came from the early days of the internet where is was used to encode binary stuff in mail messages (part of MIME encoding). For these usages, line breaks make sense, since some email client break lines themselves, and by preformatting you prevent that, for example: > > (Base64MimeConverter > mimeEncode: (ZnClient get: 'http://www.pharo-project.org/favicon.ico') entity readStream > multiLine: true) contents > > 'AAABAAEAEBAAAAEAIABoBAAAFgAAACgAAAAQAAAAIAAAAAEAIAAAAAAAAAAAABMLAAATCwAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0K1+/+2tF//lpRj/0J1F/86x > kP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQso7/ > 1Zw1/+ekF//koBf/zZdF/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAADLrIr/yI05/9SLG//UvKP/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAA3s2//8qrjf8AAAAAAAAAAAAAAADClmr/28m4/wAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACpayz/rH1S/9K9q/8AAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxKeP/4lWLv9+Tiz/oXtc/97P > xf8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYxrj/ > oX1j/2RBNP+QbFT/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAC6m4H/1MGz/+7m4v/Ltqb/tJR3/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAsJWF/1tHVf+qkIH/4tTL/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAANG8rf9GPGj/IiJn/19MYP/Mt6n/AAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANXEuP9NQGj/IiiB/youf/8NFnb/Qztx/9PC > t/8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADczcL/mIGA/y8ziP8nMZj/ > GSGF/4l2hP/Tw7n/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMy4 > q/8pMZj/JzKi/yUxov+znJb/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAADezsT/d3Om/1dt0f9cZrz/v6mf/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAJqapP+i3f//iazZ/9/Pwv8AAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBqIv/lYps/7Caev8AAAAAAAAAAAAA > AAAAAAAA/g8AAP8H8L//wwAA/nMAAP8fNcL/BwAA/4cAAP8HAAD/DwAA/wc4FP4DAAD+AwAA > /wf///8H////hzp0/48AAA==' > > Base64 encoding is also used a lot in cryptography to encode binary data like hashes or even for silly obfuscation. For example, in HTTP, Basic Authentication is a defined as a HTTP header called 'Authorization' with as value 'Basic' <space> <credentials> where credentials is obtained by Base64 encoding <username>:<password>. > > ZnRequest>>#setBasicAuthenticationUsername: username password: password > self headers > at: 'Authorization' > put: 'Basic ', (ZnUtils encodeBase64: (username, ':', password)) > > ZnUtils class>>#encodeBase64: string > ^ (Base64MimeConverter mimeEncode: string readStream multiLine: false) contents > > Here you don't want line breaks since it would break the common assumption that a header is a single line (technically, multiline headers do exist, but that is another story). > > Now, as long as the input string is below 55 characters in length, no line breaks will be introduced. In code (assuming no line line breaks will be introduced by our email clients or the mailing list software inbetween; re-execute in a workspace if necessary): > > (Base64MimeConverter > mimeEncode: ((String new: 54) atAllPut: $A) readStream > multiLine: true) contents > > 'QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB' > > (Base64MimeConverter > mimeEncode: ((String new: 54) atAllPut: $A) readStream > multiLine: false) contents > > 'QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB' > > (Base64MimeConverter > mimeEncode: ((String new: 55) atAllPut: $A) readStream > multiLine: true) contents > > 'QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB > QQ==' > > (Base64MimeConverter > mimeEncode: ((String new: 55) atAllPut: $A) readStream > multiLine: false) contents > > 'QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ==' > > Please note, this is not a bug, just a gotcha that can go unnoticed for quite some time. > > Sven > > PS: Base64 decoding is clever enough to transparently deal with line breaks. > >>> This can easily be solved by invoking Base64MimeConvertor with the #mimeEncode: <string> multiLine: false >>> >>> Zinc HTTP Components now does this consistently through ZnUtils class>>#encodeBase64: >>> >>> Sven > >

March 22, 2011