- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Zinc problem

by Norbert Hartl

Am 06.12.2011 um 16:23 schrieb Sven Van Caekenberghe: > 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. I have a fix for it. But I can't commit because squeaksource is down. Basically I changed ZnUtils>>writeQueryFields:on: to ZnUtils>>writeQueryFields:withTextEncoding:on: which uses encodeForHTTPWithTextEncoding: instead of encodeForHTTP. In ZnApplicationFormUrlEncodedEntity it checks for the encoding and uses the appropriate method. This is not nice but en par with the previous solution. I think the default behaviour (which encoding to use) needs to be configurable as well. The only thing that points towards a default is the w3c recommendation to use utf-8 for url safe encoding. But there is no strong reason to use any of those. Norbert

Dec. 6, 2011

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

by StÃ©phane Ducasse

> > Yes. With the experiment of Tobias, the #writeSnapshot: and #loadDefinitions took only 1% of the whole process.....soâ¦ the problem is - classbuilder - logging - â¦ so we should go step by step > > 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] Questions about Weak classes

by Igor Stasenko

Its an object format specific stuff. The weak object can have a fixed slots (ivars) which are strongly referenced, and only variable slots are weakly referenced. If you will want to make ivars to be also weakly referenced, then you will need another object format. On 6 December 2011 16:14, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. I have two small questions related to weak objects. > > 1) It seems all Weak objects are variable. ALWAYS. Why?Â It doesn't make > sense to have a fixed weak object ? > > 2) We have the methods: > > variableByteSubclass: t instanceVariableNames: fÂ classVariableNames: d > poolDictionaries: s category: cat > variableSubclass: t instanceVariableNames: fÂ classVariableNames: d > poolDictionaries: s category: cat > variableWordSubclass: t instanceVariableNames: f classVariableNames: d > poolDictionaries: s category: cat > > So... WHY we have then: > > weakSubclass: t instanceVariableNames: fÂ classVariableNames: d > poolDictionaries: s category: cat > > rather than > > variableWeakSubclass: t instanceVariableNames: fÂ classVariableNames: d > poolDictionaries: s category: cat > > is there any reason I am not seeing? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

Dec. 6, 2011

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