- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why CompiledMethod print string shows #identityHah ?

by Mariano Martinez Peck

On Tue, Dec 6, 2011 at 5:05 PM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > On 06.12.2011 16:18, Mariano Martinez Peck wrote: > >> Hi guys. When printing compiled methods we get something like: >> >> >> TestCase >> #assert: -> (TestCase>>#assert: "a >> CompiledMethod(585629696)") >> >> Where the number is the #identityHash. I have never really needed that, >> and even more, I always want to print: >> >> TestCase >> #assert: -> 'TestCase>>#assert:' >> > Are you sure? > Would have helped you at the start of > http://forum.world.st/Problem-**with-CompiledMethodTrailer-** > td3508018.html<http://forum.world.st/Problem-with-CompiledMethodTrailer-td3508018.html> > :) > > Not sure if the identityHash of the print string helped that much there. > >> So...my question is, is there any reason why it makes so much sense to >> print the identityHash of a CompiledMethod ? >> > > Not really sure. > It's just seems to have been that way for a long time. > Yes but mayte it was so so a long time where identityHash as memory address, in which case it would make more sense? > > Cheers, > Henry > > -- Mariano http://marianopeck.wordpress.com

Dec. 6, 2011

Re: [Pharo-project] Loading MCZ freezes, but loading the source.st works?

by Levente Uzonyi

On Tue, 6 Dec 2011, Henrik Sperre Johansen wrote: > On 06.12.2011 16:35, Mariano Martinez Peck wrote: >> >> >> On Tue, Dec 6, 2011 at 4:30 PM, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >> On 06.12.2011 15:55, Mariano Martinez Peck wrote: >>> >>> >>> On Mon, Dec 5, 2011 at 4:21 PM, Stefan Marr <pharo(a)stefan-marr.de >>> <mailto:pharo@stefan-marr.de>> wrote: >>> >>> Hi: >>> >>> I got here a Monticello package that does not properly load >>> using the Metacello configuration. The image freezes and >>> cmd+. does not pop up a debugger anymore. >>> >>> Is there a way to force Monticello/Metacello to fall back on >>> the included source instead of using the binary snapshot? (I >>> guess that is going wrong for some reason). >>> >> Not very elegant, but you can delete the .bin from the .mcz file, >> and it should fall back to importing from sources. >> >>> >>> >>> The binary snapshot is only for the definitions. The source is >>> always get from the .sources. >> I'm not sure what you mean, but the source compiled when you >> install an MCDefinition, is taken from the .bin if that was the >> source of it. (its source instvar is a string, not a pointer to >> source location in .sources file). >> >> >> >> It seems I was wrong. All I wanted to say is that the final representation >> of code (classes, compiled methods, etc) are compiled from source code. >> The snapshot does not include a "binary represenation of the code". The >> code is always needed. What I thought is that it was always from sources.st >> <http://sources.st> , but you say it can be from the bin as well. > Yup! > > OT: Which, as you surely know, is also why a more radical > rethinking/restructuring than the neat experiment Tobias Pape posted recently > is needed if one wanted to take full advantage of a Fuel monticello format :) > Eliminate the compilation step, and mcz loading would probably be FAST! 5% faster? :) Levente > > Cheers, > Henry >

Dec. 6, 2011

[Pharo-project] [COTDC] 92 - TSortable

by sean＠clipperadams.com

92 classes done 793 classes remaining Continuing in Collections... Today: TSortable 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 p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Dec. 6, 2011

Re: [Pharo-project] Zinc problem

by Norbert Hartl

Am 06.12.2011 um 16:23 schrieb Sven Van Caekenberghe: > Norbert, > > On 05 Dec 2011, at 18:07, Norbert Hartl wrote: > >> As Zinc is now part of pharo may I assume that bug reports belong to the pharo tracker? > Ok. > Yes, please use the Pharo-Dev list. > >> I've discovered a problem in Zinc. If you execute this piece of code >> >> | client entity | >> client := ZnNeoClient new. >> entity := client applicationFormUrlEncodedEntity. >> entity at: 'testkey' put: 'Ã¶'. >> Transcript show: 'entity type: ', entity contentType printString; cr. >> Transcript show: 'encoded body: ', (String streamContents: [:stream| >> entity writeRepresentationOn: stream ]) >> >> You'll get (in pharo #13315) >> >> entity type: application/x-www-form-urlencoded;charset=iso-8859-1 >> encoded body: testkey=%C3%B6 >> >> As you can see the content type contains latin-1 as encoding while the body is utf-8 encoded. The utf-8 encoding comes from >> >> ZnUtils class>>writeQueryFields:on: >> >> that uses encodeForHTTP which uses utf-8 by default. >> >> Norbert > > Hmm, > > In my image, there is no charset attribute for that mime type, did you add it yourself ? > > ZnApplicationFormUrlEncodedEntity new contentType printString > > gives > > 'application/x-www-form-urlencoded' > I was wondering myself. I added a fixed encoding in my own code to test. Before I never saw the latin-1 appearing aynwhere. But I checked monticello and I did not alter zinc code. I'll check again. > On the other hand you are right: ZnUtils class>>writeQueryFields:on: does indeed always use the UTF8 based #encodeForHTTP of which there is also an encoding based variant that would be more correct I guess. > > I assume this is not a theoretical exercise and that you have actual code failing because of this ? > Yes. I need to issue url safe encoded parameters. When it comes to character encoding of safe url encoded things it gets hairy pretty quick. While with GET requests this is heavy to solve at all a charset addition should help when doing posts. So at least for tesing I need to take control over the encoding. And I think there are a lot of latin-1 encoded url safe encoded URLs and strings out there. And the server I need to deal with does not accept the utf-8 encoded stuff. > Please file a bug report. You could also suggest a fix based on the lastet version if you feel like it. Or at least some unit test. > http://code.google.com/p/pharo/issues/detail?id=5063 > If not, I will try to fix it, time permitting. > I hope I can spend some more time. But the usage of the encoding is burried deep in the process so I couldn't came up with an easy fix looking the first time. > Thanks for reporting this. > > Sven > > PS: ZnNeoClient has been renamed ZnClient since more than a month, you probably best use the latest version. > Yes, I know. As I wrote I tested this with #13315 and there is only ZnNeoClient. I updated pharo two times and rolled back. Then I remember you call it "the client has been renamed" but my code those not work with ZnClient. It looks as it has less in common with ZnNeoClient. So I postpone upgrading day after day :) Norbert

Dec. 6, 2011

Re: [Pharo-project] Why CompiledMethod print string shows #identityHah ?

by Henrik Sperre Johansen

On 06.12.2011 16:18, Mariano Martinez Peck wrote: > Hi guys. When printing compiled methods we get something like: > > > TestCase >> #assert: -> (TestCase>>#assert: "a > CompiledMethod(585629696)") > > Where the number is the #identityHash. I have never really needed > that, and even more, I always want to print: > > TestCase >> #assert: -> 'TestCase>>#assert:' Are you sure? Would have helped you at the start of http://forum.world.st/Problem-with-CompiledMethodTrailer-td3508018.html :) > > So...my question is, is there any reason why it makes so much sense to > print the identityHash of a CompiledMethod ? Not really sure. It's just seems to have been that way for a long time. Cheers, Henry

Dec. 6, 2011

Re: [Pharo-project] Loading MCZ freezes, but loading the source.st works?

by Mariano Martinez Peck

On Tue, Dec 6, 2011 at 4:44 PM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > On 06.12.2011 16:35, Mariano Martinez Peck wrote: > > > > On Tue, Dec 6, 2011 at 4:30 PM, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> On 06.12.2011 15:55, Mariano Martinez Peck wrote: >> >> >> >> On Mon, Dec 5, 2011 at 4:21 PM, Stefan Marr <pharo(a)stefan-marr.de>wrote: >> >>> Hi: >>> >>> I got here a Monticello package that does not properly load using the >>> Metacello configuration. The image freezes and cmd+. does not pop up a >>> debugger anymore. >>> >> >> >>> Is there a way to force Monticello/Metacello to fall back on the >>> included source instead of using the binary snapshot? (I guess that is >>> going wrong for some reason). >>> >> Not very elegant, but you can delete the .bin from the .mcz file, and >> it should fall back to importing from sources. >> >> >>> >> The binary snapshot is only for the definitions. The source is always get >> from the .sources. >> >> I'm not sure what you mean, but the source compiled when you install an >> MCDefinition, is taken from the .bin if that was the source of it. (its >> source instvar is a string, not a pointer to source location in .sources >> file). >> >> > > It seems I was wrong. All I wanted to say is that the final representation > of code (classes, compiled methods, etc) are compiled from source code. > The snapshot does not include a "binary represenation of the code". The > code is always needed. What I thought is that it was always from > sources.st , but you say it can be from the bin as well. > > Yup! > > OT: Which, as you surely know, is also why a more radical > rethinking/restructuring than the neat experiment Tobias Pape posted > recently is needed if one wanted to take full advantage of a Fuel > monticello format :) Eliminate the compilation step, and mcz loading would > probably be FAST! > > Yes. With the experiment of Tobias, the #writeSnapshot: and #loadDefinitions took only 1% of the whole process.....so... Now, for that radical change you mention, we have started to think a little bit: 1) we need to store the source code anyway. This is because we would need to recompile all CompiledMethod (because of instance variable accessing bytecodes) when the superclass of a class which is in the image changes it shape (hence, instance variables moved their index). For this purpose, we thought we can easily store the source code in the method trailer and serialize that. The thing is at materialization. What do we once we have materialized? we keep the sources in teh CM or we put them in the .changes file and we put back a .changes pointer in the trailer??? should a load of a package always store in .changes ? 2) Since we materialize classes without class builder, and this monster does everything together, we need to analyze what has to be done exactly when materializing a package for example: notify class creation/modification, validations (what happens if the class already exist, etc.), etc, etc. This is the most difficult part for us, since understanding what the classbuilder does is complicated.... Our progress is in FuelPackageLoader... Cheers -- Mariano http://marianopeck.wordpress.com

Dec. 6, 2011

Re: [Pharo-project] Loading MCZ freezes, but loading the source.st works?

by Henrik Sperre Johansen

On 06.12.2011 16:35, Mariano Martinez Peck wrote: > > > On Tue, Dec 6, 2011 at 4:30 PM, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> > wrote: > > On 06.12.2011 15:55, Mariano Martinez Peck wrote: >> >> >> On Mon, Dec 5, 2011 at 4:21 PM, Stefan Marr <pharo(a)stefan-marr.de >> <mailto:pharo@stefan-marr.de>> wrote: >> >> Hi: >> >> I got here a Monticello package that does not properly load >> using the Metacello configuration. The image freezes and >> cmd+. does not pop up a debugger anymore. >> >> Is there a way to force Monticello/Metacello to fall back on >> the included source instead of using the binary snapshot? (I >> guess that is going wrong for some reason). >> > Not very elegant, but you can delete the .bin from the .mcz file, > and it should fall back to importing from sources. > >> >> >> The binary snapshot is only for the definitions. The source is >> always get from the .sources. > I'm not sure what you mean, but the source compiled when you > install an MCDefinition, is taken from the .bin if that was the > source of it. (its source instvar is a string, not a pointer to > source location in .sources file). > > > > It seems I was wrong. All I wanted to say is that the final > representation of code (classes, compiled methods, etc) are compiled > from source code. The snapshot does not include a "binary > represenation of the code". The code is always needed. What I thought > is that it was always from sources.st <http://sources.st> , but you > say it can be from the bin as well. Yup! OT: Which, as you surely know, is also why a more radical rethinking/restructuring than the neat experiment Tobias Pape posted recently is needed if one wanted to take full advantage of a Fuel monticello format :) Eliminate the compilation step, and mcz loading would probably be FAST! Cheers, Henry

Dec. 6, 2011

Re: [Pharo-project] Loading MCZ freezes, but loading the source.st works?

by Mariano Martinez Peck

On Tue, Dec 6, 2011 at 4:30 PM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > On 06.12.2011 15:55, Mariano Martinez Peck wrote: > > > > On Mon, Dec 5, 2011 at 4:21 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > >> Hi: >> >> I got here a Monticello package that does not properly load using the >> Metacello configuration. The image freezes and cmd+. does not pop up a >> debugger anymore. >> > > >> Is there a way to force Monticello/Metacello to fall back on the included >> source instead of using the binary snapshot? (I guess that is going wrong >> for some reason). >> > Not very elegant, but you can delete the .bin from the .mcz file, and it > should fall back to importing from sources. > > >> > The binary snapshot is only for the definitions. The source is always get > from the .sources. > > I'm not sure what you mean, but the source compiled when you install an > MCDefinition, is taken from the .bin if that was the source of it. (its > source instvar is a string, not a pointer to source location in .sources > file). > > It seems I was wrong. All I wanted to say is that the final representation of code (classes, compiled methods, etc) are compiled from source code. The snapshot does not include a "binary represenation of the code". The code is always needed. What I thought is that it was always from sources.st, but you say it can be from the bin as well. > Which is why it's safe to do non-ascii code in mcz as long as you can read > from the .bin (As WideStrings are decoded properly), otherwise the .sources > will be read as latin1, though they weren't written as such if any of the > methods contained non-latin1, iirc. > > Cheers, > Henry > -- Mariano http://marianopeck.wordpress.com

Dec. 6, 2011

Re: [Pharo-project] Loading MCZ freezes, but loading the source.st works?

by Henrik Sperre Johansen

On 06.12.2011 15:55, Mariano Martinez Peck wrote: > > > On Mon, Dec 5, 2011 at 4:21 PM, Stefan Marr <pharo(a)stefan-marr.de > <mailto:pharo@stefan-marr.de>> wrote: > > Hi: > > I got here a Monticello package that does not properly load using > the Metacello configuration. The image freezes and cmd+. does not > pop up a debugger anymore. > > Is there a way to force Monticello/Metacello to fall back on the > included source instead of using the binary snapshot? (I guess > that is going wrong for some reason). > Not very elegant, but you can delete the .bin from the .mcz file, and it should fall back to importing from sources. > > > > The binary snapshot is only for the definitions. The source is always > get from the .sources. I'm not sure what you mean, but the source compiled when you install an MCDefinition, is taken from the .bin if that was the source of it. (its source instvar is a string, not a pointer to source location in .sources file). Which is why it's safe to do non-ascii code in mcz as long as you can read from the .bin (As WideStrings are decoded properly), otherwise the .sources will be read as latin1, though they weren't written as such if any of the methods contained non-latin1, iirc. Cheers, Henry

Dec. 6, 2011

Re: [Pharo-project] Zinc problem

by Sven Van Caekenberghe

Norbert, On 05 Dec 2011, at 18:07, Norbert Hartl wrote: > As Zinc is now part of pharo may I assume that bug reports belong to the pharo tracker? Yes, please use the Pharo-Dev list. > I've discovered a problem in Zinc. If you execute this piece of code > > | client entity | > client := ZnNeoClient new. > entity := client applicationFormUrlEncodedEntity. > entity at: 'testkey' put: 'Ã¶'. > Transcript show: 'entity type: ', entity contentType printString; cr. > Transcript show: 'encoded body: ', (String streamContents: [:stream| > entity writeRepresentationOn: stream ]) > > You'll get (in pharo #13315) > > entity type: application/x-www-form-urlencoded;charset=iso-8859-1 > encoded body: testkey=%C3%B6 > > As you can see the content type contains latin-1 as encoding while the body is utf-8 encoded. The utf-8 encoding comes from > > ZnUtils class>>writeQueryFields:on: > > that uses encodeForHTTP which uses utf-8 by default. > > Norbert Hmm, In my image, there is no charset attribute for that mime type, did you add it yourself ? ZnApplicationFormUrlEncodedEntity new contentType printString gives 'application/x-www-form-urlencoded' On the other hand you are right: ZnUtils class>>writeQueryFields:on: does indeed always use the UTF8 based #encodeForHTTP of which there is also an encoding based variant that would be more correct I guess. I assume this is not a theoretical exercise and that you have actual code failing because of this ? Please file a bug report. You could also suggest a fix based on the lastet version if you feel like it. Or at least some unit test. If not, I will try to fix it, time permitting. Thanks for reporting this. Sven PS: ZnNeoClient has been renamed ZnClient since more than a month, you probably best use the latest version.

Dec. 6, 2011