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

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by Mariano Martinez Peck

> > - avoid using category in your package. > > I know you answer Frederic but I am curious, why not using categories in a package? Or I misunderstood that best, mariano

June 9, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by StÃ©phane Ducasse

Hi frederic Here is some feedback - Continue!!! Now could you: - add a class comment to classes. I have to browse the class - categorise the methods. - avoid using category in your package. I do not want to have undocumented new code in pharo. - Instead of fields can you use InstVar Fields is not smalltalkish - when we use an inspector/explorer we can see really fast the value of iv without having to click on something. may be you should propose something classListIndex : 1 - Why when I browse a symbol I do not get #in front? - In some case we have contents what is it? - why when I browse an array I do not get # - roots are not obviously displayed It seems that you lost your symbol openOn: t1 | t2 t3 t4 | t3 := MorphicToolBuilder new. (t4 := (t2 := self new on: t1; yourself) buildWith: t3) openInWorld. ^ t2 Stef On Jun 9, 2009, at 7:31 PM, Frederic Pluquet wrote: > Hello Alex, > > On Tue, Jun 9, 2009 at 4:26 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: > Hi Frederic, > > It looks really good. I tried to used it instead of the Explorer. > Few comments: > - Unfolding a branch that contains an element with a very > very long > printOn: seems to freeze the system. > > Ok, I should limit the size of the generated string (with ... at the > end). > > I got an error niDescription not found. > > Do you have an example I can reproduce ? > > - I spend a lot of time in unfolding branches to see field > content. > Maybe field values could be displayed without having to unfold ? > > Good idea. I'll see what I can do. > > Cheers, > > FrÃ©d > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 9, 2009

[Pharo-project] strange problem with tests

by Gabriel Brunstein

I have a problem with some test cases. If I run them from the browser, they run successfully but if I run them from the test runner they fail sometimes but sometimes not. It is not a problem of process because there isn't any fork in the code. By the way, I checked the names of the process for both codes at all time and they are the same. What is more, if i add something like "Transcript show: 'something'" at the beginning of each method, they always run successfully. Any idea??

June 9, 2009

Re: [Pharo-project] Syntax error loading Coral

by StÃ©phane Ducasse

luc > > "UnixProcess>>argsAsFlatArrayAndOffsets:". I guess it is an UTF-8 > > problem. > > Any ideas for a solution ? could you repost an email with a clear test showing that it breaks? like that the UnixProcess father may answer :) Stef

June 9, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by Frederic Pluquet

Hello Alex, On Tue, Jun 9, 2009 at 4:26 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi Frederic, > > It looks really good. I tried to used it instead of the Explorer. > Few comments: > - Unfolding a branch that contains an element with a very very long > printOn: seems to freeze the system. Ok, I should limit the size of the generated string (with ... at the end). > I got an error niDescription not found. Do you have an example I can reproduce ? > - I spend a lot of time in unfolding branches to see field content. > Maybe field values could be displayed without having to unfold ? Good idea. I'll see what I can do. Cheers, FrÃ©d

June 9, 2009

Re: [Pharo-project] vm-maker

by StÃ©phane Ducasse

On Sun, May 24, 2009 at 1:13 PM, John M McIntosh <johnmci(a)smalltalkconsulting.com > wrote: Begin forwarded message: From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> Date: May 24, 2009 1:35:01 AM PDT (CA) To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> Subject: [Pharo-project] Could not load VMMaker in 10315 Reply-To: Pharo-project(a)lists.gforge.inria.fr Hi I did ScriptLoader loadFFI Then loaded VMMaker-dtl.122 Then proceeded when asked about klatt. And I got Cannot compile -- stack including temps is too deep what did I miss? Nothing. There is a method in the GeniePlugin who's stack is too deep to compile with closures. Here are some workarounds and solutions in increasing levels of difficulty: 1. since the GeniePlugin is inessential simply move it to another package and ignore the problem (this is what we have done at Qwaq). 2a. Since the method is never executed one can temporarily change the stack limit (e.g. CompiledMethod classPool at: #LargeFrame put: 57) and load the package, reverting the stack limit after loading (Compiledmethod classPool at: #LargeFrame put: 56) 2b. change CompiledMethod>>needsFrame: so that proceeding from the error still creates a compiled method (i.e. remove the ^ return from the method so that it reads needsFrameSize: newFrameSize "Set the largeFrameBit to accomodate the newFrameSize" | largeFrameBit header | largeFrameBit := 16r20000. (self numTemps + newFrameSize) > LargeFrame ifTrue: [self error: 'Cannot compile -- stack including temps is too deep']. header := self objectAt: 1. (header bitAnd: largeFrameBit) ~= 0 ifTrue: [header := header - largeFrameBit]. self objectAt: 1 put: header + ((self numTemps + newFrameSize) > SmallFrame ifTrue: [largeFrameBit] ifFalse: [0]) then file-in the method and proceed through the warning. Both of these are tedious but since you're probably not going to be changing the method and since Monticello won't recompile it once it is loaded it'll sit there quite happily once compiled. 3. refactor the GeniePlugin method into an outer args parser and an inner engine method and solve the problem. Since VMMaker will inline anyway this shouldn't make performance worse. I haven't done this because I'm not the author and it is quite a complex method. 4. modify the Closure compiler so that it reuses temporaries in optimized blocks. The method compiles with the BlueBook compiler because in 1 to: n do: [:i| .......]. ... 1 to: n do: [:i| .......]. the two block variables "i" are the same "physical" variable stored in the same location in the home context (because BlueBook blocks do not have local arguments or temporaries). But in the Closure compiler they are logically distinct variables and if the blocks were real and not optimized they would occupy different "physical" locations. Since they are optimized blocks their temporaries do get allocated in the home context, but they occupy different locations, and hence the stack size is larger in the Closure compiler. The Closure compiler could be modified to use a more sophisticated temporary variable scope analysis that would allow it to determine that the first block's "i" is out of scope when the second block is compiled and hence that the location can be reused. This is non-trivial because it requires rewriting much of the temporary scope management (see TempVariableNode>>scope[:] & senders of scope:). If I had hit the stack limit in more than this one method I probably would have tried to solve this but for now there are fatter fish to fry. I plan that eventually the Cog VM will support a CompiledMethod format that will have a higher argument, temp and total frame size limit, but this isn't a priority right now. Apologies Eliot Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== On Jun 9, 2009, at 3:56 PM, danil osipchuk wrote: > Hello squeak people > > Does anyone have a hint how to get (with reasonable effort) current > vmmaker setup? May be there is a prepared image somewhere? I'm > interested in building vm on windows. When I follow these > instructions: http://wiki.squeak.org/squeak/6102 i stuck during > loading of vmmaker from the squeak-map > > regards, > Danil > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

Re: [Pharo-project] About super initialize

by StÃ©phane Ducasse

Ok you convinced me. Alain I will go over your fixes again because I stopped in the middle :) Stef On Jun 9, 2009, at 1:01 PM, Alain Plantec wrote: > Lukas Renggli a Ã©crit : >>> I do not think that we will hev speed impact but yes we should run >>> that. >>> Still I have the impression that for direct subclasses of Object >>> super >>> initialize is unnecessary >>> >> >> If you follow this pattern refactoring code (moving classes in >> hierarchies) can easily introduce bugs. Furthermore it is already >> complicated enough for beginners to know when to call super >> initialize >> and when not (the class side). So I would strive for the simplest and >> most uniform solution --- always call super initialize. >> >> > I could not say it better, this is exactly what I think. > > alain > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

Re: [Pharo-project] BookMorph removal slice

by StÃ©phane Ducasse

ok I will integrate that. On Jun 9, 2009, at 12:01 AM, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> Now I would do the following: >> remove >> BookMorph >> > SLICE-BookMorphRemoval-alain_plantec.1 is in PharoInbox > > alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

Re: [Pharo-project] Fwd: Issue 584 in pharo: SqueakPageCache generateURL -> DNU because pathForFile is not defined on ServerFile

by StÃ©phane Ducasse

I would remove also squeakPage :) On Jun 8, 2009, at 11:18 PM, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> I was thinking to move ObjectOut and little friends out of kernel and >> out them in a dedicated package >> Then clean MorphObjectOut. >> There would be nice examples of reflective uses of Smalltalk but I'm >> not sure that they still work. >> Now I would do the following: >> remove >> BookMorph >> TabbedPalette >> SqueakPageCache >> > why not keep also SqueakPageCache then if SqueakPage is to be kept ? > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

Re: [Pharo-project] Syntax error loading Coral

by Oscar Nierstrasz

Yes, it is still on my to-do list. Have been busy with Pharo By Example. - on On Jun 9, 2009, at 16:04, Alexandre Bergel wrote: > As far as I am aware of, only a small experiment was realized in Bern. > Oscar said he will allocate a student on it. > > Alexandre > > > On 9 Jun 2009, at 08:35, Mariano Martinez Peck wrote: > >> >> >> 2009/6/9 Luc Fabresse <luc.fabresse(a)gmail.com> >> 2009/6/9 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> pharo scripts to rename iPhoto pictures??? >> >> Writing scripts using Pharo (instead of Bash, Ruby,...) is the >> objective of Coral. >> So, Coral could be used to rename files in the future. >> >> wow! Is somewhere documentation or information I can read about ? >> >> Thanks! >> >> Mariano >> >> >> >> >> On Mon, Jun 8, 2009 at 5:48 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >>> wrote: >>> Hi all, >>> >>> I tried to load Coral in the latest dev image using ScriptLoader >>> and I got a syntax error in >>> "UnixProcess>>argsAsFlatArrayAndOffsets:". I guess it is an UTF-8 >>> problem. >>> Any ideas for a solution ? >> >> Not right on top of my head but this is cool that you tried it. I >> want to write pharo scripts >> to rename my iPhoto pictures and lot more. >> >>> >>> #Luc >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009