Re: [Pharo-dev] RPackage and overrides
Am 31.05.2013 um 02:56 schrieb Igor Stasenko : > 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 ? :) Norbert
Re: [Pharo-dev] Reflectivity beta
Sounds great! What happens if a method is recompiled. All metalinks are gone then? Norbert Am 30.05.2013 um 18:15 schrieb Camille Teruel : > Hello everyone, > > Reflectivity beta is out ! > > Reflectivity is a tool that permit to annotate AST nodes with "metalinks". > You can put metalinks at different "positions": > before: the metalink is executed before the node > instead: the metalink is executed instead the node > after: the metalink is executed after the node > onError: the metalink is executed only if the execution of the node raises an > error > onSuccess: the metalink is executed only if the execution of the node raises > no error > > When you put metalinks on some node of a method's AST, a wrapper is installed > in place of the method. When executed, this wrapper compiles an expanded > version of the AST that takes metalinks into account and install the > resulting compiled method. > > Examples: > > increaseAllNumbersIn: aCompiledMethod > "A method that increases all numbers in aCompiledMethod" > aCompiledMethod reflectiveAST > forAllNodes: [ :node | node isLiteral and: [ node value > isNumber ] ] > putInstead: [ :node | RFMetalink fromExpression: (node value + > 1) asString ]. > > removeMetalinksIn: aCompiledMethod > aCompiledMethod reflectiveAST removeAllMetalinks > > In nautilus, you have a menu entry called 'Edit metalinks' that permit to > edit the metalinks of the node corresponding to the selected piece of code. > As an example use case, another entry called 'Put breakpoint' adds a metalink > that corresponds to 'Halt now' before the selected node. > > Remember that it is a beta, so you might find errors and things are likely to > change. > > You can load Reflectivity with: > > Gofer it > smalltalkhubUser: 'RMoD' project: 'Reflectivity'; > configuration; > loadDevelopment > > Or you can download it from RMoD's CI: > https://ci.inria.fr/rmod/job/Reflectivity/ > > Camille
Re: [Pharo-dev] Running coverage breaks the VM
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."
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 wrote:
> On 30 May 2013 20:06, Guillermo Polito 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 */
> >
> > assertusqInt)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
>
> "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
>
> "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
> a
Re: [Pharo-dev] Running coverage breaks the VM
Actually, from CoInterpreter:
addNewMethodToCache: class
"Override to refuse to cache other than compiled methods.
This protects open PICs against having to test for compiled methods."
(objectMemory isOopCompiledMethod: newMethod) ifFalse:
[primitiveFunctionPointer := #primitiveInvokeObjectAsMethod.
^self].
super addNewMethodToCache: class
On Fri, May 31, 2013 at 9:20 AM, Guillermo Polito 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."
>
> 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 wrote:
>
>> On 30 May 2013 20:06, Guillermo Polito 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 */
>> >
>> > assertusqInt)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
>>
>> "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
>>
>> "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: [
>> se
Re: [Pharo-dev] Reflectivity beta
On 31 mai 2013, at 09:03, Norbert Hartl wrote: > Sounds great! What happens if a method is recompiled. All metalinks are gone > then? Yes indeed. If you have the method: foo self bar with a metalink on the message node and you recompile it to: foo self qux; bar; bar. then it is hard to tell which node(s) should adopt the metalink because there is no way to tell which #bar message of the second version is the one from the first version. I would love to have an editor where you manipulates ast nodes directly. With such an editor the developer would have feedback of where the metalinks are. In the underlying model, AST nodes would have an equivalence relation to say whether two nodes are different versions the same or not. This model could also be really useful for versioning and diff too. > > Norbert > > Am 30.05.2013 um 18:15 schrieb Camille Teruel : > >> Hello everyone, >> >> Reflectivity beta is out ! >> >> Reflectivity is a tool that permit to annotate AST nodes with "metalinks". >> You can put metalinks at different "positions": >> before: the metalink is executed before the node >> instead: the metalink is executed instead the node >> after: the metalink is executed after the node >> onError: the metalink is executed only if the execution of the node raises >> an error >> onSuccess: the metalink is executed only if the execution of the node raises >> no error >> >> When you put metalinks on some node of a method's AST, a wrapper is >> installed in place of the method. When executed, this wrapper compiles an >> expanded version of the AST that takes metalinks into account and install >> the resulting compiled method. >> >> Examples: >> >> increaseAllNumbersIn: aCompiledMethod >> "A method that increases all numbers in aCompiledMethod" >> aCompiledMethod reflectiveAST >> forAllNodes: [ :node | node isLiteral and: [ node value >> isNumber ] ] >> putInstead: [ :node | RFMetalink fromExpression: (node value + >> 1) asString ]. >> >> removeMetalinksIn: aCompiledMethod >> aCompiledMethod reflectiveAST removeAllMetalinks >> >> In nautilus, you have a menu entry called 'Edit metalinks' that permit to >> edit the metalinks of the node corresponding to the selected piece of code. >> As an example use case, another entry called 'Put breakpoint' adds a >> metalink that corresponds to 'Halt now' before the selected node. >> >> Remember that it is a beta, so you might find errors and things are likely >> to change. >> >> You can load Reflectivity with: >> >> Gofer it >> smalltalkhubUser: 'RMoD' project: 'Reflectivity'; >> configuration; >> loadDevelopment >> >> Or you can download it from RMoD's CI: >> https://ci.inria.fr/rmod/job/Reflectivity/ >> >> Camille
Re: [Pharo-dev] Reflectivity beta
On May 31, 2013, at 9:04 AM, Norbert Hartl wrote: > Sounds great! What happens if a method is recompiled. All metalinks are gone > then? > Yes, because they have no semantic knowledge other than the AST node. Starting to match trees to put back links is difficult *and* does not work really, either. E.g if I put a link on self foo. and then add a second self foo. just in front, where will the retained link be? And them, the new method could be completely different. Maybe the user putting the link did not want it on all sends called foo, but on all self sends? No way to tell… they just do not carry the intention of the developer. For that one needs higher levels to take care. The idea is that the links are low-level, you always use them in a managed way. E.g. a line-based breakpoint would be manage by the debugger, the links in an AOP system would be managed by the PointCut (which declaratively specifies where to put links). Edit method --> level above puts links again. In the *long* term I want Pharo to not manipulate text but ASTs directly, in this case it is easy to maintain the links as the AST does not change. But this is Pharo5 or so ;-) But even that does not remove then need of higher levels. Because if the user put links on all ivar accesses, the code I add will not magically have those links even in this case, because the existing do not encode the intention "I want links on all Ivar access". Marcus
Re: [Pharo-dev] Reflectivity beta
Indeed, this would be fantastic :) Doru On Fri, May 31, 2013 at 9:45 AM, Camille Teruel wrote: > > On 31 mai 2013, at 09:03, Norbert Hartl wrote: > > Sounds great! What happens if a method is recompiled. All metalinks are > gone then? > > > Yes indeed. If you have the method: > foo > self bar > with a metalink on the message node and you recompile it to: > foo > self > qux; > bar; > bar. > > then it is hard to tell which node(s) should adopt the metalink because > there is no way to tell which #bar message of the second version is the one > from the first version. > I would love to have an editor where you manipulates ast nodes directly. > With such an editor the developer would have feedback of where the > metalinks are. > In the underlying model, AST nodes would have an equivalence relation to > say whether two nodes are different versions the same or not. > This model could also be really useful for versioning and diff too. > > > Norbert > > Am 30.05.2013 um 18:15 schrieb Camille Teruel : > > Hello everyone, > > Reflectivity beta is out ! > > Reflectivity is a tool that permit to annotate AST nodes with "metalinks". > You can put metalinks at different "positions": > >- before: the metalink is executed before the node >- instead: the metalink is executed instead the node >- after: the metalink is executed after the node >- onError: the metalink is executed only if the execution of the node >raises an error >- onSuccess: the metalink is executed only if the execution of the >node raises no error > > > When you put metalinks on some node of a method's AST, a wrapper is > installed in place of the method. When executed, this wrapper compiles an > expanded version of the AST that takes metalinks into account and install > the resulting compiled method. > > Examples: > > increaseAllNumbersIn: aCompiledMethod > "A method that increases all numbers in aCompiledMethod" > aCompiledMethod reflectiveAST > forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ] > putInstead: [ :node | RFMetalink fromExpression: (node value + 1) asString > ]. > > removeMetalinksIn: aCompiledMethod > aCompiledMethod reflectiveAST removeAllMetalinks > > In nautilus, you have a menu entry called 'Edit metalinks' that permit to > edit the metalinks of the node corresponding to the selected piece of code. > As an example use case, another entry called 'Put breakpoint' adds a > metalink that corresponds to 'Halt now' before the selected node. > > Remember that it is a beta, so you might find errors and things are likely > to change. > > You can load Reflectivity with: > > Gofer it > smalltalkhubUser: 'RMoD' project: 'Reflectivity'; > configuration; > loadDevelopment > > Or you can download it from RMoD's CI: > https://ci.inria.fr/rmod/job/Reflectivity/ > > Camille > > > -- www.tudorgirba.com "Every thing has its own flow"
Re: [Pharo-dev] Amber's new stepping debugger
Finally! It will be very useful! пятница, 31 мая 2013 г., 1:26:01 UTC+4 пользователь nicolas petton написал: > > Hi guys! > > Today I was able to debug Amber code with a stepping debugger for the > first time! > The debugger is based on an AST interpreter with a small stack > implementation. > > Here's a short video of the debugger in action: > https://www.dropbox.com/s/43mli1wwbdwj5kx/amber-debugging.mov > > While it's an early version, it is already usable :) > > cheers, > nico
Re: [Pharo-dev] Running coverage breaks the VM
I'll make a summary from what I understand... Maybe we should move this
discussion to the VM list, but I'm not sure.
- Igor made changes to support the primitive 220
- those changes may try to activate a non-method object
- I added a check to tell if it is a compiled method or not to the new
code, so if it's not it flows through the old method handling (which uses
the primitiveFunctionPointer I assume right from the CoInterpreter
implementation)
This, I see should be taken into account into #internalExecuteNewMethod and
#executeNewMethod, which are preeety similar and both have the same
change :).
Maybe I'm making nonsense again, It's difficult to say to me. I just want
to help fixing this.
Tx!!!
Guille
On Fri, May 31, 2013 at 9:28 AM, Guillermo Polito wrote:
> Actually, from CoInterpreter:
>
> addNewMethodToCache: class
> "Override to refuse to cache other than compiled methods.
> This protects open PICs against having to test for compiled methods."
> (objectMemory isOopCompiledMethod: newMethod) ifFalse:
> [primitiveFunctionPointer := #primitiveInvokeObjectAsMethod.
> ^self].
> super addNewMethodToCache: class
>
>
> On Fri, May 31, 2013 at 9:20 AM, Guillermo Polito <
> guillermopol...@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."
>>
>> 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 wrote:
>>
>>> On 30 May 2013 20:06, Guillermo Polito
>>> 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 */
>>> >
>>> > assertusqInt)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
>>>
>>> "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: localF
[Pharo-dev] A screenshot we should remind today
happy nostalgia :-) Cheers, -- Pavel <>
Re: [Pharo-dev] Reflectivity beta
Am 31.05.2013 um 09:48 schrieb Marcus Denker : > > On May 31, 2013, at 9:04 AM, Norbert Hartl wrote: > >> Sounds great! What happens if a method is recompiled. All metalinks are gone >> then? >> > > Yes, because they have no semantic knowledge other than the AST node. > > Starting to match trees to put back links is difficult *and* does not work > really, either. > > E.g if I put a link > on > self foo. > > and then add a second > self foo. > > just in front, where will the retained link be? > > And them, the new method could be completely different. Maybe the user > putting the link did not want it > on all sends called foo, but on all self sends? No way to tell… they just do > not carry the intention of the developer. > For that one needs higher levels to take care. > > The idea is that the links are low-level, you always use them in a managed > way. E.g. a line-based > breakpoint would be manage by the debugger, the links in an AOP system would > be managed by the > PointCut (which declaratively specifies where to put links). Edit method --> > level above puts links again. > > In the *long* term I want Pharo to not manipulate text but ASTs directly, in > this case it is easy to maintain the > links as the AST does not change. But this is Pharo5 or so ;-) > But even that does not remove then need of higher levels. Because if the user > put links on all ivar accesses, the > code I add will not magically have those links even in this case, because the > existing do not encode the intention > "I want links on all Ivar access". I don't think that editing the AST directly solves this problems. You can always remove things in a way so that bringing them back makes you loose the meta information. But then it maybe is not necessary to put something like that as a AST feature. If I programmatically annotate AST nodes I will have some code that does it. Then I only need to know when some method has changed and I can reapply the annotations/metalinks. To preserve exisiting metalinks I would have to know before and after a method has changed so I'm able to reapply the exact same thing there. Besides Announcements I could add metalinks to the compiler that triggers my code to manage metalinks of my code. There is always a way to go meta. Wonderful! Time for me to make my first 3.0 tests :) Norbert
[Pharo-dev] [update 3.0] #30175
30175 - 10812 CommandlineTestRunner >> #stderr is not returning properly https://pharo.fogbugz.com/f/cases/10812 10807 Scanning wrong token produces DNU https://pharo.fogbugz.com/f/cases/10807 10809 Path>>isAbsoluteWindowsPath: can be optimized https://pharo.fogbugz.com/f/cases/10809 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.87.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-UI-MarcusDenker.68.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-MarcusDenker.161.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Tests-Core-MarcusDenker.28.diff
Re: [Pharo-dev] [amber-lang] Amber's new stepping debugger
Great work! Norbert Am 30.05.2013 um 23:26 schrieb Nicolas Petton : > Hi guys! > > Today I was able to debug Amber code with a stepping debugger for the first > time! > The debugger is based on an AST interpreter with a small stack > implementation. > > Here's a short video of the debugger in action: > https://www.dropbox.com/s/43mli1wwbdwj5kx/amber-debugging.mov > > While it's an early version, it is already usable :) > > cheers, > nico
Re: [Pharo-dev] A screenshot we should remind today
On 31 May 2013 09:31, Sven Van Caekenberghe wrote: > > > On 31 May 2013, at 10:01, Pavel Krivanek wrote: > > happy nostalgia :-) > > Cheers, > -- Pavel > > > > +1 > > It is amazing that so much of it still lives on. > > We've come a long way and the future is bright ;-) > > Note how also the collaboration model changed: from 'All right reserved' to MIT, from one lab to the whole world. I agree with the sentiment, but "All rights reserved" is a copyright thing, not a licence thing [1]. Pharo _still_ has "all rights reserved". It's just that Pharo doesn't need to say so because the Berne Convention makes it implicit. So it's more that the copyright is "The Pharo Project and Contributors" than "some random private corporation" that's the important part! frank [1] http://en.wikipedia.org/wiki/All_rights_reserved
Re: [Pharo-dev] No Internationalization (nor Multilingual) Project in bug tracker
On May 30, 2013, at 11:37 PM, Nicolas Cellier wrote: > OK, i have opened https://pharo.fogbugz.com/default.asp?10811 (pre-requisite) > and https://pharo.fogbugz.com/default.asp?10801 > I think that was the hardest part of my work > The rest is just Smalltalk coding ;) (you'll find two SLICES in inbox) > > The most boring stuff is yet to come: final harvesting process... > Nicolas we are working on parallelirizing it. If you want we can show you how you can commit directly to pharo. We could do a pair programming integration session. Stef
Re: [Pharo-dev] Reflectivity beta
> I would love to have an editor where you manipulates ast nodes directly. Me too. And we got killed by the state of the Scanner. Old infrastructure always bite us hard. We ask gisela to check with PetitParser and sync with Camillo/Damien/"Lukas"/Guillaume for the introduction of error handling in PetitParser. Stef
Re: [Pharo-dev] Amber's new stepping debugger
cool! Stef On May 30, 2013, at 11:26 PM, Nicolas Petton wrote: > Hi guys! > > Today I was able to debug Amber code with a stepping debugger for the first > time! > The debugger is based on an AST interpreter with a small stack > implementation. > > Here's a short video of the debugger in action: > https://www.dropbox.com/s/43mli1wwbdwj5kx/amber-debugging.mov > > While it's an early version, it is already usable :) > > cheers, > nico
[Pharo-dev] Handling error with PetitParser
We would like to see if we can use PetitParser to build syntax hilighting and for this we need to see if there is a way to specify error handling. Does any of you know? So far we tried to use the RBSCanner but it does not really work for what we need Stef
Re: [Pharo-dev] Reflectivity beta
Really cool! Has anyone already tried to build coverage tests based on it? -- Pavel On Thu, May 30, 2013 at 6:15 PM, Camille Teruel wrote: > Hello everyone, > > Reflectivity beta is out ! > > Reflectivity is a tool that permit to annotate AST nodes with "metalinks". > You can put metalinks at different "positions": > >- before: the metalink is executed before the node >- instead: the metalink is executed instead the node >- after: the metalink is executed after the node >- onError: the metalink is executed only if the execution of the node >raises an error >- onSuccess: the metalink is executed only if the execution of the >node raises no error > > > When you put metalinks on some node of a method's AST, a wrapper is > installed in place of the method. When executed, this wrapper compiles an > expanded version of the AST that takes metalinks into account and install > the resulting compiled method. > > Examples: > > increaseAllNumbersIn: aCompiledMethod > "A method that increases all numbers in aCompiledMethod" > aCompiledMethod reflectiveAST > forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ] > putInstead: [ :node | RFMetalink fromExpression: (node value + 1) asString > ]. > > removeMetalinksIn: aCompiledMethod > aCompiledMethod reflectiveAST removeAllMetalinks > > In nautilus, you have a menu entry called 'Edit metalinks' that permit to > edit the metalinks of the node corresponding to the selected piece of code. > As an example use case, another entry called 'Put breakpoint' adds a > metalink that corresponds to 'Halt now' before the selected node. > > Remember that it is a beta, so you might find errors and things are likely > to change. > > You can load Reflectivity with: > > Gofer it > smalltalkhubUser: 'RMoD' project: 'Reflectivity'; > configuration; > loadDevelopment > > Or you can download it from RMoD's CI: > https://ci.inria.fr/rmod/job/Reflectivity/ > > Camille >
Re: [Pharo-dev] Keeping Pharo CPU usage low: how?
Am 27.05.2013 um 10:17 schrieb p...@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. Norbert > Phil > > > On Mon, May 27, 2013 at 10:07 AM, Norbert Hartl wrote: > > Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe : > >> BTW, load & cpu usage numbers can be very hard to interpret. > > really? CPU usage is pretty easy and you can see this in most OSses directly. > 100% CPU usage is full :) Load isn't that much harder. It's just the load of > the scheduler queue. So if some needs a rule of thumb > > safe CPU load = number of cores/processes * 0.7 > theoretical optimal CPU load = number of core/processes > > Everything above should really be investigated because you entered the zone > where additional CPU load can drive your machine unresponsive. > You have less CPU usage but high load? Investigate I/O usage! > > I know you know that, Sven. I just wanted to mention it because this comes up > from time to time. Compared to memory consumption, CPU, scheduler and I/O are > easier targets IMHO. > > For Phil the point isn't the health of the system. It is EC2. You have to pay > for the CPU usage on EC2 so I think he had the impression there is room for > improvement. And indeed there is. But if you calculate it through it isn't > really a factor. > > Norbert > >
Re: [Pharo-dev] Keeping Pharo CPU usage low: how?
On 31 May 2013, at 11:26, Norbert Hartl wrote: > > Am 27.05.2013 um 10:17 schrieb p...@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. Are there any (slightly busy) processes inside the VM that we can't see at the Smalltalk level ? > Norbert > >> Phil >> >> >> On Mon, May 27, 2013 at 10:07 AM, Norbert Hartl wrote: >> >> Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe : >> >>> BTW, load & cpu usage numbers can be very hard to interpret. >> >> really? CPU usage is pretty easy and you can see this in most OSses >> directly. 100% CPU usage is full :) Load isn't that much harder. It's just >> the load of the scheduler queue. So if some needs a rule of thumb >> >> safe CPU load = number of cores/processes * 0.7 >> theoretical optimal CPU load = number of core/processes >> >> Everything above should really be investigated because you entered the zone >> where additional CPU load can drive your machine unresponsive. >> You have less CPU usage but high load? Investigate I/O usage! >> >> I know you know that, Sven. I just wanted to mention it because this comes >> up from time to time. Compared to memory consumption, CPU, scheduler and I/O >> are easier targets IMHO. >> >> For Phil the point isn't the health of the system. It is EC2. You have to >> pay for the CPU usage on EC2 so I think he had the impression there is room >> for improvement. And indeed there is. But if you calculate it through it >> isn't really a factor. >> >> Norbert >> >> >
Re: [Pharo-dev] Keeping Pharo CPU usage low: how?
I don't know how to do this for Linux based VMs (which is what I'll need in the end) but can do some experiments with Apple Xcode Instruments. That's something I've wanted to do for a long time as this gives deep insight on how a program is behaving. http://en.wikipedia.org/wiki/Instruments_%28application%29 http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html Thanks for looking into this. Maybe could we do a chapter on these matters in one of the Pharo books. The point of having idle VMs is that when one machine is hit by a peak of usage, the other instances can swallow the load. Now, I am not talking about a single EC2 VM, but a group of them, each having a set of VMs. FWIW, AIMP3 playing MP3s all the time is 9%-11% on an old PIV 3Ghz, while Skype takes 1% idling Phil On Fri, May 31, 2013 at 11:26 AM, Norbert Hartl wrote: > > Am 27.05.2013 um 10:17 schrieb p...@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. > > Norbert > > Phil > > > On Mon, May 27, 2013 at 10:07 AM, Norbert Hartl wrote: > >> >> Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe : >> >> BTW, load & cpu usage numbers can be very hard to interpret. >> >> >> really? CPU usage is pretty easy and you can see this in most OSses >> directly. 100% CPU usage is full :) Load isn't that much harder. It's just >> the load of the scheduler queue. So if some needs a rule of thumb >> >> safe CPU load = number of cores/processes * 0.7 >> theoretical optimal CPU load = number of core/processes >> >> Everything above should really be investigated because you entered the >> zone where additional CPU load can drive your machine unresponsive. >> You have less CPU usage but high load? Investigate I/O usage! >> >> I know you know that, Sven. I just wanted to mention it because this >> comes up from time to time. Compared to memory consumption, CPU, scheduler >> and I/O are easier targets IMHO. >> >> For Phil the point isn't the health of the system. It is EC2. You have to >> pay for the CPU usage on EC2 so I think he had the impression there is room >> for improvement. And indeed there is. But if you calculate it through it >> isn't really a factor. >> >> Norbert >> >> > >
Re: [Pharo-dev] Keeping Pharo CPU usage low: how?
Am 31.05.2013 um 11:38 schrieb Sven Van Caekenberghe : > > On 31 May 2013, at 11:26, Norbert Hartl wrote: > >> >> Am 27.05.2013 um 10:17 schrieb p...@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 ? I didn't kill it. I just did MorphicUIManager default uiProcess suspend > Is #serverMode still relevant when 5 is gone ? I was asking myself the same question. > Would it be possible to kill 2 ? Is it needed for a headless server ? That could be one of the more busy processes. So if we stop 5. there is no point in running 2., right? Or asking the other way round: What is included in input events fetching? keyboard and mouse or something else, too? > As long as file and socket IO keeps working, we're good. > Yes and it is quite interesting to see how much polling is going on there. I think those two are the ones that would benefit the most from having an event based native adaption. Norbert > The rest is probably all needed. > > Are there any (slightly busy) processes inside the VM that we can't see at > the Smalltalk level ? > >> Norbert >> >>> Phil >>> >>> >>> On Mon, May 27, 2013 at 10:07 AM, Norbert Hartl wrote: >>> >>> Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe : >>> BTW, load & cpu usage numbers can be very hard to interpret. >>> >>> really? CPU usage is pretty easy and you can see this in most OSses >>> directly. 100% CPU usage is full :) Load isn't that much harder. It's just >>> the load of the scheduler queue. So if some needs a rule of thumb >>> >>> safe CPU load = number of cores/processes * 0.7 >>> theoretical optimal CPU load = number of core/processes >>> >>> Everything above should really be investigated because you entered the zone >>> where additional CPU load can drive your machine unresponsive. >>> You have less CPU usage but high load? Investigate I/O usage! >>> >>> I know you know that, Sven. I just wanted to mention it because this comes >>> up from time to time. Compared to memory consumption, CPU, scheduler and >>> I/O are easier targets IMHO. >>> >>> For Phil the point isn't the health of the system. It is EC2. You have to >>> pay for the CPU usage on EC2 so I think he had the impression there is room >>> for improvement. And indeed there is. But if you calculate it through it >>> isn't really a factor. >>> >>> Norbert >>> >>> >> > >
Re: [Pharo-dev] Reflectivity beta
On 31 mai 2013, at 11:16, Pavel Krivanek wrote: > Really cool! Has anyone already tried to build coverage tests based on it? Not yet, that's brand new stuff so nobody did anything with it. > -- Pavel > > On Thu, May 30, 2013 at 6:15 PM, Camille Teruel > wrote: > Hello everyone, > > Reflectivity beta is out ! > > Reflectivity is a tool that permit to annotate AST nodes with "metalinks". > You can put metalinks at different "positions": > before: the metalink is executed before the node > instead: the metalink is executed instead the node > after: the metalink is executed after the node > onError: the metalink is executed only if the execution of the node raises an > error > onSuccess: the metalink is executed only if the execution of the node raises > no error > > When you put metalinks on some node of a method's AST, a wrapper is installed > in place of the method. When executed, this wrapper compiles an expanded > version of the AST that takes metalinks into account and install the > resulting compiled method. > > Examples: > > increaseAllNumbersIn: aCompiledMethod > "A method that increases all numbers in aCompiledMethod" > aCompiledMethod reflectiveAST > forAllNodes: [ :node | node isLiteral and: [ node value > isNumber ] ] > putInstead: [ :node | RFMetalink fromExpression: (node value + > 1) asString ]. > > removeMetalinksIn: aCompiledMethod > aCompiledMethod reflectiveAST removeAllMetalinks > > In nautilus, you have a menu entry called 'Edit metalinks' that permit to > edit the metalinks of the node corresponding to the selected piece of code. > As an example use case, another entry called 'Put breakpoint' adds a metalink > that corresponds to 'Halt now' before the selected node. > > Remember that it is a beta, so you might find errors and things are likely to > change. > > You can load Reflectivity with: > > Gofer it > smalltalkhubUser: 'RMoD' project: 'Reflectivity'; > configuration; > loadDevelopment > > Or you can download it from RMoD's CI: > https://ci.inria.fr/rmod/job/Reflectivity/ > > Camille >
Re: [Pharo-dev] Keeping Pharo CPU usage low: how?
On 31 May 2013 11:26, Norbert Hartl wrote: > > Am 27.05.2013 um 10:17 schrieb p...@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.
Re: [Pharo-dev] Keeping Pharo CPU usage low: how?
On May 31, 2013, at 11:39 AM, Sven Van Caekenberghe wrote: > > On 31 May 2013, at 11:26, Norbert Hartl wrote: > >> >> Am 27.05.2013 um 10:17 schrieb p...@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
Re: [Pharo-dev] Trait exclusions
Hi Frank, On Wed, May 29, 2013 at 11:45 PM, Frank Shearar 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
Re: [Pharo-dev] Keeping Pharo CPU usage low: how?
Am 31.05.2013 um 12:57 schrieb Marcus Denker : > > On May 31, 2013, at 11:39 AM, Sven Van Caekenberghe wrote: > >> >> On 31 May 2013, at 11:26, Norbert Hartl wrote: >> >>> >>> Am 27.05.2013 um 10:17 schrieb p...@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
[Pharo-dev] using fogbugz for other projects (like moose)
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"
Re: [Pharo-dev] Running coverage breaks the VM
On 31 May 2013 09:20, Guillermo Polito 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 wrote:
>>
>> On 30 May 2013 20:06, Guillermo Polito 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 */
>> >
>> > assertusqInt)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
>>
>> "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
>>
>> "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"
>> ].
>>
>
Re: [Pharo-dev] RPackage and overrides
On 31 May 2013 09:00, Norbert Hartl wrote: > > > Am 31.05.2013 um 02:56 schrieb Igor Stasenko : > >> 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.
Re: [Pharo-dev] Trait exclusions
On 31 May 2013 12:01, Damien Cassou wrote:
> Hi Frank,
>
> On Wed, May 29, 2013 at 11:45 PM, Frank Shearar
> 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
[Pharo-dev] Lowecase class names
Hi is there any reason why class builder does not allow lowercase classnames? Underscore is allowed, though. Jan
Re: [Pharo-dev] Trait exclusions
On May 31, 2013, at 1:28 PM, Frank Shearar wrote:
> On 31 May 2013 12:01, Damien Cassou wrote:
>> Hi Frank,
>>
>> On Wed, May 29, 2013 at 11:45 PM, Frank Shearar
>> 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
>
Re: [Pharo-dev] using fogbugz for other projects (like moose)
We could create a tag for moose without problem I guess. I will let the experts answer. Stef > 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"
[Pharo-dev] [update 3.0] #30176
30176 - 10770 Comment of on:send:to: https://pharo.fogbugz.com/f/cases/10770 10805 Obsolete behaviors remaining: an Array(AnObsoleteDefaultCommandLineHandler class AnObsoleteDefaultCommandLineHandler) https://pharo.fogbugz.com/f/cases/10805 10811 Add an InvalidUTF8 exception https://pharo.fogbugz.com/f/cases/10811 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Zinc-Character-Encoding-Core-MarcusDenker.9.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-MarcusDenker.125.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Multilingual-TextConversion-MarcusDenker.48.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Announcements-Core-MarcusDenker.42.diff
Re: [Pharo-dev] using fogbugz for other projects (like moose)
If I understand correctly, the tag is used to denote the component. In the case of Moose we have multiple of these sub-components and somehow they would need to be captured. Looking at the existing tracker, we have the categories as listed below. Perhaps this would pollute too much the Pharo space? Component-MooseCore Component-Famix Component-SmalltalkImporter Component-RPackage Component-Mondrian = Visualization engine Component-Roassal= Visualization engine Component-Glamour Component-Glamour-Seaside Component-Algos Component-Fame Component-Finder = Issue relates to program UI Component-Install= Utility and installation scripts Component-Docs = Issue relates to end-user documentation Component-MooseTools Component-ExternalTools = External tools such as inFusion, srcML, VerveineJ Component-Test Component-CAnalyzer = FAMIX extension dedicated to C Component-DSM Component-SmallDude Component-XML= XMLParser and Pastell (XPath query facility) Component-Spy= The Spy profiling framework Component-Hapao = The Hapao test coverage tool Component-PetitParser Component-AutoMoose Component-Arki Component-VerveineJ Component-VerveineCSharp Component-EyeSee Component-Metanool Component-GlamorousToolkit Cheers, Doru On Fri, May 31, 2013 at 1:33 PM, Stéphane Ducasse wrote: > We could create a tag for moose without problem I guess. > I will let the experts answer. > > Stef > > 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" > > > -- www.tudorgirba.com "Every thing has its own flow"
Re: [Pharo-dev] Trait exclusions
On 31 May 2013 12:32, Stéphane Ducasse wrote:
>
> On May 31, 2013, at 1:28 PM, Frank Shearar wrote:
>
>> On 31 May 2013 12:01, Damien Cassou wrote:
>>> Hi Frank,
>>>
>>> On Wed, May 29, 2013 at 11:45 PM, Frank Shearar
>>> 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?
I'm not sure what "they" refers to. Assuming you meant "do aliases
break in Pharo?" yes they do: the alias expects the new name to
already exist in the method dictionary. So if you write your trait
Trait named: #TMyTrait
uses: TSomething @ {#aMethod -> #notWrittenYet}
category: 'Thing'
then you get a KeyNotFound because TMyTrait doesn't have
#notWrittenYet in its method dictionary. It should be fairly easy to
fix; I just raised the ticket.
If you meant "do exclusions only apply to the rightmost trait?", yes
they do. The comment in both Pharo and Squeak say that - binds tighter
than @ or +. That's fine. To me, that would mean that S + T @ {#m ->
#z} - {#m} would remove #m from T. But I thought that (S + T @ {#m -
#z}) - {#m} would mean "remove m from S + T @ {#m - #z}", but it
doesn't. That might simply be a TraitComposition bug. I don't know,
which is why I'm asking :)
>> 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.
Ah, ok. Fair enough!
frank
>> frank
>>
>> [1] https://pharo.fogbugz.com/default.asp?10803#78542
Re: [Pharo-dev] Amber's new stepping debugger
Amazing work Nicolas , the debugger is a huge reason why I Love smalltalk so much. Makes the use of amber very compelling. -- View this message in context: http://forum.world.st/Pharo-dev-Amber-s-new-stepping-debugger-tp4690847p4690988.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] A screenshot we should remind today
Kinda ironic that I code for fun since 1988 , learned so many programming languages but only recently I heard about this interesting language called "Smalltalk". It could have ended my search very soon if I did started with smalltalk instead , but alas :D -- View this message in context: http://forum.world.st/Pharo-dev-A-screenshot-we-should-remind-today-tp4690921p4690989.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Running coverage breaks the VM
It is fixed in latest vm (which you can get from the zeroconf script
http://get.pharo.org/vmLatest) :).
Guille
On Fri, May 31, 2013 at 1:25 PM, Igor Stasenko wrote:
> On 31 May 2013 09:20, Guillermo Polito 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
> wrote:
> >>
> >> On 30 May 2013 20:06, Guillermo Polito
> 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 */
> >> >
> >> > assertusqInt)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
> >>
> >> "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
> >>
> >> "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/ evalu
[Pharo-dev] Release Artefact 1.0, the PDF framework
We are proud to announce that Artefact is available in 1.0 version. You can download it from: http://smalltalkhub.com/#!/~RMoD/Artefact Artefact is a framework to generate PDF documents. It is fully written in Smalltalk and doesn't require any native library. Artefact is light, platform independant and offer to users a high level of abstraction in order to easily creating PDF documents. * completely written in Smalltalk (and only Smalltalk), * complete freedom about the order of creation for pages, elements... (no need to follow the document order) * multi format and orientation for pages * page composition based on reusables PDF elements, * extensibility by offering a composition standard to create your own high level elements * styleSheet that can be reused in many documents and avoid wasting time and place with duplication * image support with the JPEG format * pre-defined high level elements like datagrid * support PDF compression to produce compact files A basic documentation is available in the help browser. Many examples are implemented in the PDFDemos class. -- *Olivier Auverlot and Guillaume Larcheveque*
Re: [Pharo-dev] using fogbugz for other projects (like moose)
Humm, I would say this is overkill :P, there would be more Moose projects than Pharo ones. So far we followed the strategy of having 1 fogbugz project per external project. On 2013-05-31, at 13:52, Tudor Girba wrote: > If I understand correctly, the tag is used to denote the component. In the > case of Moose we have multiple of these sub-components and somehow they > would need to be captured. Looking at the existing tracker, we have the > categories as listed below. > > Perhaps this would pollute too much the Pharo space? > > Component-MooseCore > Component-Famix > Component-SmalltalkImporter > Component-RPackage > Component-Mondrian = Visualization engine > Component-Roassal= Visualization engine > Component-Glamour > Component-Glamour-Seaside > Component-Algos > Component-Fame > Component-Finder = Issue relates to program UI > Component-Install= Utility and installation scripts > Component-Docs = Issue relates to end-user documentation > Component-MooseTools > Component-ExternalTools = External tools such as inFusion, srcML, VerveineJ > Component-Test > Component-CAnalyzer = FAMIX extension dedicated to C > Component-DSM > Component-SmallDude > Component-XML= XMLParser and Pastell (XPath query facility) > Component-Spy= The Spy profiling framework > Component-Hapao = The Hapao test coverage tool > Component-PetitParser > Component-AutoMoose > Component-Arki > Component-VerveineJ > Component-VerveineCSharp > Component-EyeSee > Component-Metanool > Component-GlamorousToolkit > > Cheers, > Doru > > > > > On Fri, May 31, 2013 at 1:33 PM, Stéphane Ducasse > wrote: > >> We could create a tag for moose without problem I guess. >> I will let the experts answer. >> >> Stef >> >> 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" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow"
Re: [Pharo-dev] using fogbugz for other projects (like moose)
Actually in fogbugz you have project and area. For example if you create a bug on project Mate you can choose between Mate DSL, Mate SSA or Virtual CPU in the area select box. So you could do something similar for moose and then we would only see 1 label moose in project select box. So I think Moose can be added to the bug tracker without 'polluting' the Pharo space this way. 2013/5/31 Tudor Girba > If I understand correctly, the tag is used to denote the component. In the > case of Moose we have multiple of these sub-components and somehow they > would need to be captured. Looking at the existing tracker, we have the > categories as listed below. > > Perhaps this would pollute too much the Pharo space? > > Component-MooseCore > Component-Famix > Component-SmalltalkImporter > Component-RPackage > Component-Mondrian = Visualization engine > Component-Roassal= Visualization engine > Component-Glamour > Component-Glamour-Seaside > Component-Algos > Component-Fame > Component-Finder = Issue relates to program UI > Component-Install= Utility and installation scripts > Component-Docs = Issue relates to end-user documentation > Component-MooseTools > Component-ExternalTools = External tools such as inFusion, srcML, VerveineJ > Component-Test > Component-CAnalyzer = FAMIX extension dedicated to C > Component-DSM > Component-SmallDude > Component-XML= XMLParser and Pastell (XPath query facility) > Component-Spy= The Spy profiling framework > Component-Hapao = The Hapao test coverage tool > Component-PetitParser > Component-AutoMoose > Component-Arki > Component-VerveineJ > Component-VerveineCSharp > Component-EyeSee > Component-Metanool > Component-GlamorousToolkit > > Cheers, > Doru > > > > > On Fri, May 31, 2013 at 1:33 PM, Stéphane Ducasse < > stephane.duca...@inria.fr> wrote: > >> We could create a tag for moose without problem I guess. >> I will let the experts answer. >> >> Stef >> >> 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" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
Re: [Pharo-dev] Lowecase class names
On May 31, 2013, at 1:32 PM, Jan Vrany wrote: > Hi > > is there any reason why class builder does not allow lowercase > classnames? Underscore is allowed, though. > In the past people started too add check to make sure that we only use the naming that people are supposed to use. The place these checks where placed was the class builder. Over time it has shown that this is not good: it has do be done on a higher level. (we already removed certain checks, e.g. about variable capitalization). We should at some point introduce something that does these kinds of checks for the tools, but allows one to just do anything when needed at the lower level… Marcus
Re: [Pharo-dev] Running coverage breaks the VM
I'll have to give this a try once I've upgraded my machine. I only
have GLIBC_2.11 and this requires GLIBC_2.15.
Excellent news though!
frank
On 31 May 2013 14:17, Guillermo Polito wrote:
> It is fixed in latest vm (which you can get from the zeroconf script
> http://get.pharo.org/vmLatest) :).
>
> Guille
>
>
> On Fri, May 31, 2013 at 1:25 PM, Igor Stasenko wrote:
>>
>> On 31 May 2013 09:20, Guillermo Polito 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
>> > wrote:
>> >>
>> >> On 30 May 2013 20:06, Guillermo Polito
>> >> 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 */
>> >> >
>> >> > assertusqInt)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
>> >>
>> >> "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]
>> >>
[Pharo-dev] zeroconf --headless/-headless
Hi, If I try to execute './pharo Pharo.image' after downloading the latest Pharo Vm with the zero conf script it fails with the error: unknown option: -headless. If I download the stable one it works. Cheers, Andrei
[Pharo-dev] [update 3.0] #30177
30177 - 10718 More commands for Node Navigation https://pharo.fogbugz.com/f/cases/10718 10411 flush after nextChunkPut: https://pharo.fogbugz.com/f/cases/10411 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/NodeNavigation-MarcusDenker.38.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Streams-MarcusDenker.135.diff
Re: [Pharo-dev] Release Artefact 1.0, the PDF framework
Images are automatically built by a continuous integration job: https://ci.inria.fr/pharo-contribution/job/Artefact/. On Fri, May 31, 2013 at 3:30 PM, Guillaume Larcheveque wrote: > We are proud to announce that Artefact is available in 1.0 version. > > You can download it from: http://smalltalkhub.com/#!/~RMoD/Artefact > > Artefact is a framework to generate PDF documents. It is fully written in > Smalltalk and doesn't require any native library. Artefact is light, > platform independant and offer to users a high level of abstraction in order > to easily creating PDF documents. > > * completely written in Smalltalk (and only Smalltalk), > * complete freedom about the order of creation for pages, elements... (no > need to follow the document order) > * multi format and orientation for pages > * page composition based on reusables PDF elements, > * extensibility by offering a composition standard to create your own high > level elements > * styleSheet that can be reused in many documents and avoid wasting time > and place with duplication > * image support with the JPEG format > * pre-defined high level elements like datagrid > * support PDF compression to produce compact files > > A basic documentation is available in the help browser. Many examples are > implemented in the PDFDemos class. > > -- > Olivier Auverlot and Guillaume Larcheveque > -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Re: [Pharo-dev] Release Artefact 1.0, the PDF framework
Awesome guys! I'll have to take a look soon. Max On 31.05.2013, at 16:00, Damien Cassou wrote: > Images are automatically built by a continuous integration job: > https://ci.inria.fr/pharo-contribution/job/Artefact/. > > On Fri, May 31, 2013 at 3:30 PM, Guillaume Larcheveque > wrote: >> We are proud to announce that Artefact is available in 1.0 version. >> >> You can download it from: http://smalltalkhub.com/#!/~RMoD/Artefact >> >> Artefact is a framework to generate PDF documents. It is fully written in >> Smalltalk and doesn't require any native library. Artefact is light, >> platform independant and offer to users a high level of abstraction in order >> to easily creating PDF documents. >> >> * completely written in Smalltalk (and only Smalltalk), >> * complete freedom about the order of creation for pages, elements... (no >> need to follow the document order) >> * multi format and orientation for pages >> * page composition based on reusables PDF elements, >> * extensibility by offering a composition standard to create your own high >> level elements >> * styleSheet that can be reused in many documents and avoid wasting time >> and place with duplication >> * image support with the JPEG format >> * pre-defined high level elements like datagrid >> * support PDF compression to produce compact files >> >> A basic documentation is available in the help browser. Many examples are >> implemented in the PDFDemos class. >> >> -- >> Olivier Auverlot and Guillaume Larcheveque >> > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >
Re: [Pharo-dev] Hosting your own SmalltlakHub: turning off/on the web
Hi Nico, First, let me say that without a lot of pain, I have my own (actually, its for a client) SmalltalkHub instance running with Pharo 2.0, mongoDB, nginx and HTTPS :) Usually we need the web interface quite infrequently, that is, when we create a new user or a new project. So I would like to turn off the website for most of the time and just turn it on when I need something like that. Of course when I mean turn off the website I mean that: only the website. Monticello should continue working :) One "solution" I found is that since I have nginx listening in an SSL port and then this is forwarded to the port zinc is listening, I can just turn off nginx. That way noone can reach the website from outside... but maybe there is a better solution... Thanks! -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Release Artefact 1.0, the PDF framework
Thats really great. I'll have to find some time to have a look at it. cheers -ben Guillaume Larcheveque wrote: We are proud to announce that Artefact is available in 1.0 version. You can download it from: http://smalltalkhub.com/#!/~RMoD/Artefact Artefact is a framework to generate PDF documents. It is fully written in Smalltalk and doesn't require any native library. Artefact is light, platform independant and offer to users a high level of abstraction in order to easily creating PDF documents. * completely written in Smalltalk (and only Smalltalk), * complete freedom about the order of creation for pages, elements... (no need to follow the document order) * multi format and orientation for pages * page composition based on reusables PDF elements, * extensibility by offering a composition standard to create your own high level elements * styleSheet that can be reused in many documents and avoid wasting time and place with duplication * image support with the JPEG format * pre-defined high level elements like datagrid * support PDF compression to produce compact files A basic documentation is available in the help browser. Many examples are implemented in the PDFDemos class.
Re: [Pharo-dev] zeroconf --headless/-headless
yep we switched to --headless maybe we have to sit with esteban and add a compatibility option '-headless' again. The image-side of 2.0 and 3.0 are already prepared for that. Actually we changed all long options to use '--' like real unix commands :P On 2013-05-31, at 16:02, Andrei Vasile Chis wrote: > Hi, > > If I try to execute './pharo Pharo.image' after downloading the latest > Pharo Vm with the zero conf script it fails with the error: unknown option: > -headless. If I download the stable one it works. > > Cheers, > Andrei
[Pharo-dev] Bug in SmalltalkHub "delete package"
Hi guys. I tried to remove a package from the "remove package" button in the website. The package is indeed removed from the website, but if you take a fresh image, add the repository and add it to monticello, you still can see and browse the removed package any idea how to solve it? I need to remove packages for real... thanks! -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] zeroconf --headless/-headless
Hey, Now the argument are with: - - no ? It should be --headless ? I'm not sure. Camillo has probably already fixed it reading your mail anyway 2013/5/31 Andrei Vasile Chis > Hi, > > If I try to execute './pharo Pharo.image' after downloading the latest > Pharo Vm with the zero conf script it fails with the error: unknown option: > -headless. If I download the stable one it works. > > Cheers, > Andrei > -- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
[Pharo-dev] How can I remove a user from SmalltalkHub?
That :) Thanks! -- Mariano http://marianopeck.wordpress.com
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=linux/203/ 3 regressions found. FuelTests.FLMethodContextSerializationTest.testDoIt Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testObsoleteClasses
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=mac/203/ 3 regressions found. FuelTests.FLMethodContextSerializationTest.testDoIt Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testObsoleteClasses
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=win/203/ 3 regressions found. FuelTests.FLMethodContextSerializationTest.testDoIt Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testObsoleteClasses
Re: [Pharo-dev] [ANN] A small Filetree extension for git integration
On 30.05.2013, at 09:53, Goubier Thierry wrote: > Le 29/05/2013 17:43, Max Leske a écrit : >> Cool! > > Thanks > >> Just so you know: I'm working on FileSystem-Git which will use LibGit >> bindings through NativeBoost. But it will take me quite a while to finish. > > I tried FileSystem-Git (not sure I tried the best version) but didn't managed > to get it to work with my pre-existing git repo. Not tried much, because I > got FileTree to work as I used to in 1.4. To be honest, I haven't put much effort in keeping a running version around after I started to rewrite it. Most things do work I think but I wouldn't recommend to use FileSystem-Git at the moment (which is a shame but I'd rather have people use a version of which I can comfortably say I'm proud of. At the moment the multiple repositories, unfinished implementation / rewrites are a mess... > >> Thanks for the effort! It will make my work easier too since I can now >> update my filetree repo better :) > > Tell me if it works the way you would expect it to. I don't really know my > way around git apart from the basics common to all version systems, and I'll > be willing for suggestions. I'll take a look when I get back to hacking. Max > > Thierry > > >> Cheers, >> Max >> >> >> On 29.05.2013, at 17:31, Goubier Thierry wrote: >> >>> Hi all, >>> >>> I've added an extension to filetree:// in Monticello, named gitfiletree://, >>> which adds the git commands to automagically commit new versions of >>> packages in a filetree repository inside a larger git repository (i.e. >>> Pharo + any fun and interesting language I have to use such as C under git). >>> >>> It relies on OS-Process (to be able to send git commands over a shell) and >>> Filetree (of course), and it's on SmalltalkHub. >>> >>> http://smalltalkhub.com/#!/~ThierryGoubier/MonticelloFileTree-Git/ >>> >>> If anybody is interested in suggesting improvements (such as how to query >>> and load specific versions or better ways to use git commands)? >>> >>> At the moment, it should be able to handle mixed MC and others >>> repositories, and multiple packages in the same git. >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des Systèmes Temps Réel Embarqués >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> >> >> > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des Systèmes Temps Réel Embarqués > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >
Re: [Pharo-dev] Bug in SmalltalkHub "delete package"
On Fri, May 31, 2013 at 5:48 PM, Mariano Martinez Peck wrote: > Hi guys. I tried to remove a package from the "remove package" button in the > website. The package is indeed removed from the website, but if you take a > fresh image, add the repository and add it to monticello, you still can see > and browse the removed package > > any idea how to solve it? I need to remove packages for real... please report the bug to http://code.google.com/p/smalltalk-hub/issues/list with *precise* steps and details on how to reproduce. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
[Pharo-dev] [update 3.0] #30178
30178 - 10714 General update https://pharo.fogbugz.com/f/cases/10714 10816 ReleaseTest>>#testUndeclared fails in Opal RegressionTests https://pharo.fogbugz.com/f/cases/10816 10815 failing in Opal regressionTEst: DebuggerTest.testBasic https://pharo.fogbugz.com/f/cases/10815 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/ToolsTest-MarcusDenker.denker.36.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NewList-MarcusDenker.44.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.5.diff
Re: [Pharo-dev] zeroconf --headless/-headless
Hi, Yes now the arguments are with --. Just that the zero conf scripts still use -. It can be easily fix, but then the stable vm will not work any more as it needs -. So the zero conf should use - for the stable vm and -- for the latest vm. On Fri, May 31, 2013 at 5:48 PM, Clément Bera wrote: > Hey, > > Now the argument are with: - - no ? > It should be --headless ? > > I'm not sure. > Camillo has probably already fixed it reading your mail anyway > > > 2013/5/31 Andrei Vasile Chis > >> Hi, >> >> If I try to execute './pharo Pharo.image' after downloading the latest >> Pharo Vm with the zero conf script it fails with the error: unknown option: >> -headless. If I download the stable one it works. >> >> Cheers, >> Andrei >> > > > > -- > Clément Béra > Mate Virtual Machine Engineer > Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq* >
Re: [Pharo-dev] Pharo 3.2 Meeting
Yes but not to replace the current ones, just to allow the use :) On 31 May 2013, at 19:38, Frank Shearar wrote: > Hmm... "Circular menu" - are you talking about implementing pie menus? > > frank > > > On 31 May 2013 17:05, Camille Teruel wrote: >> Hello everyone! >> >> Here is the plan for pharo 3.2. As you can see June will be a busy >> month! >> Camille >
Re: [Pharo-dev] Pharo 3.2 Meeting
Excellent! frank On 31 May 2013 18:40, Esteban Lorenzano wrote: > Yes but not to replace the current ones, just to allow the use :) > > On 31 May 2013, at 19:38, Frank Shearar wrote: > > Hmm... "Circular menu" - are you talking about implementing pie menus? > > frank > > > On 31 May 2013 17:05, Camille Teruel wrote: >> >> Hello everyone! >> >> Here is the plan for pharo 3.2. As you can see June will be a busy >> month! >> Camille > >
Re: [Pharo-dev] zeroconf --headless/-headless
Yeah I waited until we release the new vm... But I'll just change the latest script as you suggested. I won't have time today if you want you can push a new configuration for zeroconf, Jenkins will test everything ;-) On May 31, 2013 7:16 PM, "Andrei Vasile Chis" wrote: > Hi, > > Yes now the arguments are with --. > Just that the zero conf scripts still use -. > > It can be easily fix, but then the stable vm will not work any more as it > needs -. > So the zero conf should use - for the stable vm and -- for the latest vm. > > > On Fri, May 31, 2013 at 5:48 PM, Clément Bera wrote: > >> Hey, >> >> Now the argument are with: - - no ? >> It should be --headless ? >> >> I'm not sure. >> Camillo has probably already fixed it reading your mail anyway >> >> >> 2013/5/31 Andrei Vasile Chis >> >>> Hi, >>> >>> If I try to execute './pharo Pharo.image' after downloading the latest >>> Pharo Vm with the zero conf script it fails with the error: unknown option: >>> -headless. If I download the stable one it works. >>> >>> Cheers, >>> Andrei >>> >> >> >> >> -- >> Clément Béra >> Mate Virtual Machine Engineer >> Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq* >> > >
Re: [Pharo-dev] [amber-lang] Amber's new stepping debugger
Impressive, that's a real step forward. Laurent On Thu, May 30, 2013 at 11:26 PM, Nicolas Petton wrote: > Hi guys! > > Today I was able to debug Amber code with a stepping debugger for the > first time! > The debugger is based on an AST interpreter with a small stack > implementation. > > Here's a short video of the debugger in action: > https://www.dropbox.com/s/43mli1wwbdwj5kx/amber-debugging.mov > > While it's an early version, it is already usable :) > > cheers, > nico
[Pharo-dev] Rubric screencast
Hi all, It shows how one can use user defined selection and icons to manage text parts. http://vimeo.com/67400546 cheers Alain
Re: [Pharo-dev] zeroconf --headless/-headless
fixed it: http://get.pharo.org/vmLatest works now under linux additionally I added a small CLI introduction to http://get.pharo.org ;) On 2013-05-31, at 20:21, Bruni camillo wrote: > Yeah I waited until we release the new vm... But I'll just change the > latest script as you suggested. I won't have time today if you want you can > push a new configuration for zeroconf, Jenkins will test everything ;-) > On May 31, 2013 7:16 PM, "Andrei Vasile Chis" > wrote: > >> Hi, >> >> Yes now the arguments are with --. >> Just that the zero conf scripts still use -. >> >> It can be easily fix, but then the stable vm will not work any more as it >> needs -. >> So the zero conf should use - for the stable vm and -- for the latest vm. >> >> >> On Fri, May 31, 2013 at 5:48 PM, Clément Bera wrote: >> >>> Hey, >>> >>> Now the argument are with: - - no ? >>> It should be --headless ? >>> >>> I'm not sure. >>> Camillo has probably already fixed it reading your mail anyway >>> >>> >>> 2013/5/31 Andrei Vasile Chis >>> Hi, If I try to execute './pharo Pharo.image' after downloading the latest Pharo Vm with the zero conf script it fails with the error: unknown option: -headless. If I download the stable one it works. Cheers, Andrei >>> >>> >>> >>> -- >>> Clément Béra >>> Mate Virtual Machine Engineer >>> Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq* >>> >> >>
Re: [Pharo-dev] Rubric screencast
Hi Alain! Impressive! Would it be possible to have an element of the text responsive to some interaction? For example, if in my text field I enter the value 100. Can I click on it (and remain the mouse button down) and move the mouse to increase or decrease this numerical value? Many systems promoting the idea of live programming use this technique to interact with their system. For example: https://vimeo.com/66085662 Cheers, Alexandre On May 31, 2013, at 2:54 PM, plantec wrote: > Hi all, > It shows how one can use user defined selection and icons to manage text > parts. > http://vimeo.com/67400546 > cheers > Alain -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Pharo 3.2 Meeting
Excellent! Alexandre On May 31, 2013, at 12:05 PM, Camille Teruel wrote: > Hello everyone! > > Here is the plan for pharo 3.2. As you can see June will be a busy > month! > Camille -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Rubric screencast
On 1 June 2013 01:25, Alexandre Bergel wrote: > Hi Alain! > > Impressive! Very. But only feature-wise. Speed-wise is not. Is it related to recording? hoping that live version faster. > Would it be possible to have an element of the text responsive to some > interaction? For example, if in my text field I enter the value 100. Can I > click on it (and remain the mouse button down) and move the mouse to increase > or decrease this numerical value? > > Many systems promoting the idea of live programming use this technique to > interact with their system. For example: https://vimeo.com/66085662 > many? I never seen anything as flexible as in some old Squeak examples/demos (including etoys). ( Bret Victor ~~ many :) > Cheers, > Alexandre > > > On May 31, 2013, at 2:54 PM, plantec wrote: > >> Hi all, >> It shows how one can use user defined selection and icons to manage text >> parts. >> http://vimeo.com/67400546 >> cheers >> Alain > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Rubric screencast
On 1 juin 2013, at 01:48, Igor Stasenko wrote: > On 1 June 2013 01:25, Alexandre Bergel wrote: >> Hi Alain! >> >> Impressive! > > Very. But only feature-wise. > Speed-wise is not. Is it related to recording? yes, my computer is slow and the screen recording make it inresponsive > hoping that live version faster. just try it :) But I think there is a lot of place for improvement: A selection is a PolygonMorph. Maybe a dedicated version should be done. Cheers Alain > > > > -- > Best regards, > Igor Stasenko. >
[Pharo-dev] Fwd: Vm-dev Digest, Vol 83, Issue 46
Begin forwarded message: > On Fri, May 31, 2013 at 1:11 PM, Eliot Miranda wrote: > >> >> >> On Fri, May 31, 2013 at 12:54 AM, Max Leske wrote: >> >>> >>> Bump. >>> >>> Doesn't anybody feel that corrupt blocks are a problem? IMHO that's >>> something that should *never* happen. >>> >> >> But what's happening here is that the Fuel serializer is allowing the >> serialization of blocks without serializing their outer context and method, >> and later the reconstruction of blocks against the *wrong* version of a >> method. This is a Fuel bug. IMO the right solution is for Fuel to >> serialize the method of the block, and on reconstruction replace the >> reconstructed method with the method in the system iff the reconstructed >> method is the same as that in the system, but substitute the recinstructed >> method if it differs from the system's version (or of course if the >> system;s version is missing). this mimics the system's behaviour with >> unbound methods, where e.g. a block holds onto a method and the code of a >> class is recompiled, resulting iun that block holding onto an unbound >> method. >> > > Sorry, "without serializing their outer context and method" is wrong; > "without serializing their method"
