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

Re: [Pharo-dev] using fogbugz for other projects (like moose)

by ClÃ©ment Bera

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 <tudor(a)tudorgirba.com> > 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.ducasse(a)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*

May 31, 2013

Re: [Pharo-dev] using fogbugz for other projects (like moose)

by Camillo Bruni

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 <tudor(a)tudorgirba.com> 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 <stephane.ducasse(a)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"

May 31, 2013

Release Artefact 1.0, the PDF framework

by Guillaume Larcheveque

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*

May 31, 2013

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

by Guillermo Polito

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

May 31, 2013

Re: [Pharo-dev] A screenshot we should remind today

by kilon

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-tp46909… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 31, 2013

Re: [Pharo-dev] Amber's new stepping debugger

by kilon

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-tp4690847p469… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 31, 2013

Re: [Pharo-dev] Trait exclusions

by Frank Shearar

On 31 May 2013 12:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 31, 2013, at 1:28 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 31 May 2013 12:01, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> Hi Frank, >>> >>> On Wed, May 29, 2013 at 11:45 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> I have a Trait TGroup that requires #*, #identity and #inverse. I want >>>> to construct a TField by composing TGroup with itself. One TGroup will >>>> form the operations #*, #one, and #reciprocal while the other will >>>> form #+, #zero and #negated. >>>> >>>> I don't want #identity or #inverse, because these apply to one >>>> operation, and it makes TField's API ambiguous. That's what >>>> TraitExclusion is for. >>> >>> maybe a diagram would help >> >> In explaining the problem, or an an alternative to the crazy >> composition? I rather think that this - which doesn't work, and >> prompted the question in the first place - is rather readable... _and >> executable_: >> >> (TGroup @ {#* -> #+. #inverse -> #negated. #identity -> #zero} + >> TGroup @ {#inverse -> #reciprocal. #identity -> #zero}) - {#identity. >> #inverse} >> >> What I don't understand is >> (a) why exclusion only applies to the rightmost trait in the composition and >> (b) why aliases either break (in Pharo [1]) > > do they? 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

May 31, 2013

Re: [Pharo-dev] using fogbugz for other projects (like moose)

by 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.ducasse(a)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"

May 31, 2013

[update 3.0] #30176

by Marcus Denker

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-… http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Multilingual-TextConversion-M… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Announcements-Core-MarcusDenk…

May 31, 2013

Re: [Pharo-dev] using fogbugz for other projects (like moose)

by StÃ©phane Ducasse

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"

May 31, 2013