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

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

by StÃ©phane Ducasse

>>> > > 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! Now you see why I originally proposed tristan, then martin, then mariano to work on a fast binary serializer :)

Dec. 6, 2011

Re: [Pharo-project] issue 5048 broke Pharo Kernel

by StÃ©phane Ducasse

how can we fix it? Because we believe that Transcript should not be packaged in Stream. Now may be in its own package. Stef On Dec 6, 2011, at 3:40 PM, Pavel Krivanek wrote: > Hi, > > the issue http://code.google.com/p/pharo/issues/detail?id=5048 broke > Pharo-Kernel build on CI server. > > -- Pavel >

Dec. 6, 2011

Re: [Pharo-project] UIManager

by StÃ©phane Ducasse

On Dec 6, 2011, at 12:30 PM, Henrik Sperre Johansen wrote: > On 06.12.2011 11:46, Henrik Sperre Johansen wrote: >> Is it just me, or is UIManager gradually turning into a new SystemDictionary/Project? >> >> Cheers, >> Henry > And by that I mean equivalent to those classes in purity of purpose and simplicity; > UIManager used to have a clear purpose - Provide a polymorphic interface for accessing common GUI dialogs for code which doesn't care which GUI framework is in use. > > Right now, MorphicUIMananger also has methods for > - Component building (a poor mans ToolBuilder, basically) > - Global state accessor, not polymorphic (world and uiProcess handling ) > - Debugger components building (!) yes I already filled in a issue on that > - Accessing common Smalltalk tools (not necessarily a bad thing, but shouldn't that be the responsibility of ToolRegistry? IE a UIManager should install a proper ToolRegistry when activated, not provide an extra layer of indirection you HAVE to use if you say, want your app to work headlessly) > - something called interactiveParserFor: I have no idea what means. > - etc. etc. etc. If you have some proposal I'm all ears. Now I just do not have time for it. > > Cheers, > Henry > > > >

Dec. 6, 2011

Re: [Pharo-project] UIManager

by StÃ©phane Ducasse

On Dec 6, 2011, at 11:46 AM, Henrik Sperre Johansen wrote: > Is it just me, or is UIManager gradually turning into a new SystemDictionary/Project? yes it is. I want to move some methods (creating UI to their own class) And I do not understand UIManager vs UITheme and other. stef > > Cheers, > Henry >

Dec. 6, 2011

Re: [Pharo-project] Zinc problem

by Norbert Hartl

Am 06.12.2011 um 16:23 schrieb Sven Van Caekenberghe: > 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' It is because MimeTypes types are the same instance. If I do | client entity | client := ZnClient new. entity := client applicationFormUrlEncodedEntity. entity contentType charSet: 'iso-8859-1' then in ZnClient>> applicationFormUrlEncodedEntity you use ZnMimeType>>applicationFormUrlEncoded which gets the sole instance from a pre-initialized dictionaries MimeTypes. If I set the charSet once it will alter subsequent entities created this way. Norbert

Dec. 6, 2011

Re: [Pharo-project] VM freezes sending #basicNew to Stream subclass

by StÃ©phane Ducasse

On Dec 5, 2011, at 3:00 PM, Marcus Denker wrote: >>>>>>> >>>>>>> I'm stuck too, and the Debugger is currently unusable in Pharo 1.4 (I >>>>>>> just can't step overâ¦) >>>>>> >>>>>> Strange. Because I use it. >>>>>> Do you have a scenario that we can focus on to fix the problem you see. >>>>>> >>>>>> > > So with Camillo, we found that reverting the change of Eliot (that we > added for testing...) helps: > > http://code.google.com/p/pharo/issues/detail?id=4998 > > I will do that revert in 14246 > > (And no, we should not have added the change. But than, how can one > test without testing?) by loading it. But we should also get knowledge on this part of the system > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de >

Dec. 6, 2011

Re: [Pharo-project] Zinc problem

by Norbert Hartl

Am 06.12.2011 um 17:08 schrieb Norbert Hartl: >> 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 :) Ok, roll back :) After I wrote this it gave me a strange feeling that I told something stupid. ZnClient does work for me now. It is just when I upgrade my pharo image with system updates I end up with a ZnClient that has all method protocols but no methods on the instance side. The version is marked as MarcusDenker.172. If I load manually a new zinc package ZnClient is ok again. Norbert

Dec. 6, 2011

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