May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Trait exclusions

by StÃ©phane Ducasse

On May 31, 2013, at 1:28 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 31 May 2013 12:01, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> Hi Frank, >> >> On Wed, May 29, 2013 at 11:45 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> I have a Trait TGroup that requires #*, #identity and #inverse. I want >>> to construct a TField by composing TGroup with itself. One TGroup will >>> form the operations #*, #one, and #reciprocal while the other will >>> form #+, #zero and #negated. >>> >>> I don't want #identity or #inverse, because these apply to one >>> operation, and it makes TField's API ambiguous. That's what >>> TraitExclusion is for. >> >> maybe a diagram would help > > In explaining the problem, or an an alternative to the crazy > composition? I rather think that this - which doesn't work, and > prompted the question in the first place - is rather readable... _and > executable_: > > (TGroup @ {#* -> #+. #inverse -> #negated. #identity -> #zero} + > TGroup @ {#inverse -> #reciprocal. #identity -> #zero}) - {#identity. > #inverse} > > What I don't understand is > (a) why exclusion only applies to the rightmost trait in the composition and > (b) why aliases either break (in Pharo [1]) do they? > or do nothing (in Squeak), > where I'd expected to see implementations saying "self requirement". we removed self requirement because it was slow to compute in interactive mode. > > frank > > [1] https://pharo.fogbugz.com/default.asp?10803#78542 >

May 31, 2013

Lowecase class names

by Jan Vrany

Hi is there any reason why class builder does not allow lowercase classnames? Underscore is allowed, though. Jan

May 31, 2013

Re: [Pharo-dev] Trait exclusions

by Frank Shearar

On 31 May 2013 12:01, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi Frank, > > On Wed, May 29, 2013 at 11:45 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> I have a Trait TGroup that requires #*, #identity and #inverse. I want >> to construct a TField by composing TGroup with itself. One TGroup will >> form the operations #*, #one, and #reciprocal while the other will >> form #+, #zero and #negated. >> >> I don't want #identity or #inverse, because these apply to one >> operation, and it makes TField's API ambiguous. That's what >> TraitExclusion is for. > > maybe a diagram would help In explaining the problem, or an an alternative to the crazy composition? I rather think that this - which doesn't work, and prompted the question in the first place - is rather readable... _and executable_: (TGroup @ {#* -> #+. #inverse -> #negated. #identity -> #zero} + TGroup @ {#inverse -> #reciprocal. #identity -> #zero}) - {#identity. #inverse} What I don't understand is (a) why exclusion only applies to the rightmost trait in the composition and (b) why aliases either break (in Pharo [1]) or do nothing (in Squeak), where I'd expected to see implementations saying "self requirement". frank [1] https://pharo.fogbugz.com/default.asp?10803#78542

May 31, 2013

Re: [Pharo-dev] RPackage and overrides

by Igor Stasenko

On 31 May 2013 09:00, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 31.05.2013 um 02:56 schrieb Igor Stasenko <siguctua(a)gmail.com>: > >> ohohoho.. selector namespaces.. sounds like using nuclear weapon to >> get rid of cockroaches: > > You know that cockroaches are the ones that will survive a nuclear strike ? :) > yes, i know. And that's why i was using this metaphor :) > Norbert -- Best regards, Igor Stasenko.

May 31, 2013

Re: [Pharo-dev] Running coverage breaks the VM

by Igor Stasenko

On 31 May 2013 09:20, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ahh, that's why the code in CoInterpreter I was looking didn't match the C > code :D. Was looking at the wrong place, hehe. > > Igor, why do you say that this method should be reached only with vanilla > compiled methods? From the comment I understand > > "For interpreter performance and to ease the objectAsMethod > implementation eagerly > evaluate the primtiive, i.e. if the method is cogged and has a > primitive /do not/ evaluate > the machine code primitive, just evaluate primitiveFunctionPointer > directly." > Yes, my bad.. It is hard to see that in code: the logic to handle objects-as-method. So, yes, please fix executNewMethod and internalExecuteNewMethod with this additional check. > And in #addNewMethodToCache: there is as a first statement: > > [...] > (objectMemory isOopCompiledMethod: newMethod) > ifTrue: > [primitiveIndex := self primitiveIndexOf: newMethod. > primitiveFunctionPointer := self functionPointerFor: primitiveIndex inClass: > class] > ifFalse: > [primitiveFunctionPointer := #primitiveInvokeObjectAsMethod]. > [...] > > So I'd say that both objects as methods and primitives are kind of handled > in the same way after? > > > > On Fri, May 31, 2013 at 2:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 30 May 2013 20:06, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> > Ok, I was playing with flushing caches and stuff... Its still a bit >> > obsure >> > to me why the example in the workspace works and the code coverage >> > doesnot. >> > >> > However, I managed to hack the VM to make it work :). >> > >> > It looks like the VM is treating the objects as methods, as cog methods. >> > So >> > I added the following validation in the commonSend: >> > >> > methodHeader2 = longAt((GIV(newMethod) + BaseHeaderSize) + (HeaderIndex >> > << >> > ShiftForWord)); >> > >> > if (isCogMethodReference(methodHeader2) && >> > isCompiledMethodHeader(methodHeader2)) { >> > >> > /* begin externalizeIPandSP */ >> > >> > assert((((usqInt)localIP)) != (ceReturnToInterpreterPC())); >> > >> > GIV(instructionPointer) = oopForPointer(localIP); >> > >> > GIV(stackPointer) = localSP; >> > >> > GIV(framePointer) = localFP; >> > >> > executeCoggedNewMethodmethodHeader(1, methodHeader2); >> > >> > } >> > >> > >> > And it works :). >> > >> > I cc Eliot, so maybe he has an idea... >> > >> I touched this code. >> >> Original: >> >> CoInterpreter>>internalExecuteNewMethod >> <inline: true> >> "For interpreter performance and to ease the objectAsMethod >> implementation eagerly >> evaluate the primtiive, i.e. if the method is cogged and has a >> primitive /do not/ evaluate >> the machine code primitive, just evaluate >> primitiveFunctionPointer directly." >> primitiveFunctionPointer ~= 0 ifTrue: >> [| succeeded | >> self isPrimitiveFunctionPointerAnIndex ifTrue: >> [^self internalQuickPrimitiveResponse]. >> "slowPrimitiveResponse may of course context-switch. If >> so we must >> reenter the >> new process appropriately, returning only if we've found >> an >> interpreter frame." >> self externalizeIPandSP. >> succeeded := self slowPrimitiveResponse. >> instructionPointer = cogit ceReturnToInterpreterPC >> ifTrue: >> [instructionPointer := self iframeSavedIP: >> framePointer]. >> self internalizeIPandSP. >> succeeded ifTrue: >> [self return: self popStack toExecutive: true. >> self browserPluginReturnIfNeeded. >> ^nil]]. >> "if not primitive, or primitive failed, activate the method" >> (self methodHasCogMethod: newMethod) >> ifTrue: [self iframeSavedIP: localFP put: localIP >> asInteger. >> instructionPointer := cogit >> ceReturnToInterpreterPC. >> self externalizeFPandSP. >> self activateCoggedNewMethod: true. >> self internalizeIPandSP] >> ifFalse: [self internalActivateNewMethod] >> >> Now in subclass (NBCoInterpreter) >> i made this: >> >> internalExecuteNewMethod >> <inline: true> >> "For interpreter performance and to ease the objectAsMethod >> implementation eagerly >> evaluate the primtiive, i.e. if the method is cogged and has a >> primitive /do not/ evaluate >> the machine code primitive, just evaluate >> primitiveFunctionPointer directly." >> >> | methodHeader | >> >> methodHeader := self rawHeaderOf: newMethod. >> >> (self isCogMethodReference: methodHeader) ifTrue: [ >> self externalizeIPandSP. >> self executeCoggedNewMethod: true methodHeader: >> methodHeader. >> "we never reach here" >> ]. >> >> primitiveFunctionPointer ~= 0 ifTrue: >> [| succeeded | >> self isPrimitiveFunctionPointerAnIndex ifTrue: >> [^self internalQuickPrimitiveResponse]. >> "slowPrimitiveResponse may of course context-switch. If >> so we must >> reenter the >> new process appropriately, returning only if we've found >> an >> interpreter frame." >> self externalizeIPandSP. >> succeeded := self slowPrimitiveResponse. >> instructionPointer = cogit ceReturnToInterpreterPC >> ifTrue: >> [instructionPointer := self iframeSavedIP: >> framePointer]. >> self internalizeIPandSP. >> succeeded ifTrue: >> [self return: self popStack toExecutive: true. >> self browserPluginReturnIfNeeded. >> ^nil]]. >> "if not primitive, or primitive failed, activate the method" >> (self methodHasCogMethod: newMethod) >> ifTrue: [self iframeSavedIP: localFP put: localIP >> asInteger. >> instructionPointer := cogit >> ceReturnToInterpreterPC. >> self externalizeFPandSP. >> self activateCoggedNewMethod: true. >> self internalizeIPandSP] >> ifFalse: [self internalActivateNewMethod] >> >> === >> The intent of change was: >> - if method is cog method, execute it (the jited code takes care to >> call primitive, if it there) >> >> The old code logic was: >> - run primitive if it there >> - and only then, if no prim/or prim failed, try to run a jited code >> (but entry point is to the first bytecode of method, >> not to its start) >> >> This (old) logic prevents from using primitive 220 properly, because >> it is a "meta-primitive" - a marker >> that says that given method should: >> - always be jited >> - actual primitive is taken by copying machine code from compiled >> method trailer into CogMethod's primitive section. >> Therefore executing prim 220 (a C function) ~~ invoking method's >> primitive (a machine code generated by image). >> >> Still i cannot understand why code reaching this point, when a result >> of lookup is not a compiled method, but arbitrary object, because >> everything even in original code says: VM enters this method only if >> it found 100% vanilla guaranteed CompiledMethod, and not something >> which pretends to be it. >> As i understand , the logic to handle object-as-method is in method >> lookup.. but not in internalExecuteNewMethod, because VM can "execute" >> the only thing it knows, and it is CompiledMethod. >> >> Your test says, that Cog does something extra (some magic, which i >> failed to grasp) with object-as-method, >> like generating special kind of CogMethod which sends #run:as:in: message >> to it. >> >> I would like to hear Eliot's comments on this. >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

May 31, 2013

using fogbugz for other projects (like moose)

by Tudor Girba

Hi, Would it be possible and desired, to open the Pharo fogbugz infrastructure for other related projects? Namely, I am thinking of Moose, in particular given that various issues are directly relevant for Pharo as well? For projects like Moose, this would imply less costs. The question is if something in this direction is even desired. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

May 31, 2013

Re: [Pharo-dev] Keeping Pharo CPU usage low: how?

by Norbert Hartl

Am 31.05.2013 um 12:57 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > On May 31, 2013, at 11:39 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 31 May 2013, at 11:26, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> >>> Am 27.05.2013 um 10:17 schrieb phil(a)highoctane.be: >>> >>>> I was looking at the output of "top" for while and Pharo was trusting the top spot indeed. >>>> >>>> Well, I'll look at all that this evening and give back the impressions. >>>> >>>> I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot. >>>> >>> What is the use of having 20 idle images on one server? :) I think you can't easily say that it always adds on top. If your image is running at 100% the 2% off even if fully countable wouldn't be that much. But nevertheless it is a valid point and I cannot see pharo becomes more modern by stop polling in the mid-term future. >>> Anyway I played a little bit with the tweaks and there are things that make me wonder. I raised the limit for server mode but didn't get much benefit. Having a cycle pause of 100ms in serverMode and stopping the ui process still gave me a 1% CPU usage which is really a lot. Does anyone know in-depth what an image is doing? How to investigate? Maybe there are a lot of native polling things involved, too? >>> I need to dig deeper. >> >> Killing as much non-needed process is certainly step one. A clean image has these processes: >> >> 1. Delay scheduling process >> 2. Input events fetching process >> 3. The low space watcher >> 4. The weak array finalization process >> 5. Morphic UI process >> 6. The idle process >> >> So you killed 5. How did you do that exactly ? >> Is #serverMode still relevant when 5 is gone ? >> Would it be possible to kill 2 ? Is it needed for a headless server ? >> As long as file and socket IO keeps working, we're good. >> >> The rest is probably all needed. > > Did you try the server mode? > > WorldState serverMode: true. I did and it doesn't make a big difference what makes me wonder. So having quite some CPU usage with a static 50ms delay does mean that every cycle does many things or the CPU usage is not UI bound. Norbert

May 31, 2013

Re: [Pharo-dev] Trait exclusions

by Damien Cassou

Hi Frank, On Wed, May 29, 2013 at 11:45 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > I have a Trait TGroup that requires #*, #identity and #inverse. I want > to construct a TField by composing TGroup with itself. One TGroup will > form the operations #*, #one, and #reciprocal while the other will > form #+, #zero and #negated. > > I don't want #identity or #inverse, because these apply to one > operation, and it makes TField's API ambiguous. That's what > TraitExclusion is for. maybe a diagram would help -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 31, 2013

Re: [Pharo-dev] Keeping Pharo CPU usage low: how?

by Marcus Denker

On May 31, 2013, at 11:39 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 31 May 2013, at 11:26, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 27.05.2013 um 10:17 schrieb phil(a)highoctane.be: >> >>> I was looking at the output of "top" for while and Pharo was trusting the top spot indeed. >>> >>> Well, I'll look at all that this evening and give back the impressions. >>> >>> I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot. >>> >> What is the use of having 20 idle images on one server? :) I think you can't easily say that it always adds on top. If your image is running at 100% the 2% off even if fully countable wouldn't be that much. But nevertheless it is a valid point and I cannot see pharo becomes more modern by stop polling in the mid-term future. >> Anyway I played a little bit with the tweaks and there are things that make me wonder. I raised the limit for server mode but didn't get much benefit. Having a cycle pause of 100ms in serverMode and stopping the ui process still gave me a 1% CPU usage which is really a lot. Does anyone know in-depth what an image is doing? How to investigate? Maybe there are a lot of native polling things involved, too? >> I need to dig deeper. > > Killing as much non-needed process is certainly step one. A clean image has these processes: > > 1. Delay scheduling process > 2. Input events fetching process > 3. The low space watcher > 4. The weak array finalization process > 5. Morphic UI process > 6. The idle process > > So you killed 5. How did you do that exactly ? > Is #serverMode still relevant when 5 is gone ? > Would it be possible to kill 2 ? Is it needed for a headless server ? > As long as file and socket IO keeps working, we're good. > > The rest is probably all needed. Did you try the server mode? WorldState serverMode: true. Marcus

May 31, 2013

Re: [Pharo-dev] Keeping Pharo CPU usage low: how?

by Igor Stasenko

On 31 May 2013 11:26, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 27.05.2013 um 10:17 schrieb phil(a)highoctane.be: > > I was looking at the output of "top" for while and Pharo was trusting the > top spot indeed. > > Well, I'll look at all that this evening and give back the impressions. > > I want to run several instances of Pharo on the box and it will for sure add > up. Say, 20 x 2% gives an awful lot. > > What is the use of having 20 idle images on one server? :) I think you > can't easily say that it always adds on top. If your image is running at > 100% the 2% off even if fully countable wouldn't be that much. But > nevertheless it is a valid point and I cannot see pharo becomes more modern > by stop polling in the mid-term future. > Anyway I played a little bit with the tweaks and there are things that make > me wonder. I raised the limit for server mode but didn't get much benefit. > Having a cycle pause of 100ms in serverMode and stopping the ui process > still gave me a 1% CPU usage which is really a lot. Does anyone know > in-depth what an image is doing? How to investigate? Maybe there are a lot > of native polling things involved, too? > I need to dig deeper. > each ms, a heartbeat thread wakes up and triggers interrupt processing. this is equivalent to polling each 1ms just yesterday we discussed this.. the problem is how to avoid interrupt processing each ms and support green threading at same time. i know that hardware given plenty of opportunities to do that.. but the problem is that most of it available only in privileged mode. i hate to see that: hardware allows much better scheduling handling, but we're doomed to use ineffective scheme, because of OS limitations. > Norbert > > Phil > -- Best regards, Igor Stasenko.

May 31, 2013