- Pharo-dev - lists.pharo.org

[Pharo-project] Mailinglist archive not working
by Torsten Bergmann May 12, 2011

May 12, 2011

Looks like the mail archive is not working: See http://lists.gforge.inria.fr/pipermail/pharo-project/2011-May/date.html last mail is from May 10 13:44:40 Anyone able to tell the inria admins... Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0

[Pharo-project] Configuration of Ring
by Veronica Isabel Uquillas Gomez May 12, 2011

May 12, 2011

Dear all, The work on Ring is in progress. I have been experimenting with Ring in several tools: FileContentsBrowser (replacing the pseudo classes), Recent Message List and Recent Submissions (replacing the sourced method references), and Torch (extending its change model). An initial configuration of Ring is done. The repository is named Ring and it can be loaded in Pharo (Core or Dev) 1.2 and 1.3. For loading only the core: (ConfigurationOfRing project version: '1.3') load: 'MinimalCore'. Best Regards, Veronica Uquillas

3 3

[Pharo-project] [update 1.3] #13192
by StÃ©phane Ducasse May 11, 2011

May 11, 2011

13192 ----- - post transcript

1 0

[Pharo-project] a test
by StÃ©phane Ducasse May 11, 2011

May 11, 2011

1 0

Re: [Pharo-project] [Esug-list] moose = smalltalk ambassador
by Tudor Girba May 11, 2011

May 11, 2011

Hi Nial, On 11 May 2011, at 11:13, Niall Ross wrote: > Dear Tudor, > this is great; this kind of making the outside world aware of Smalltalk is just what we need. :) > Jazoon (http://jazoon.com) is before ESUG 2011 in Edinburgh. I hope you will take the opportunity while there to advertise us. I will try. Cheers, Doru > You can download the conference poster (high-resolution jpeg or pdf) from > http://dl.dropbox.com/u/7726739/ESUG_Promo.jpg > or > http://dl.dropbox.com/u/7726739/ESUG_Promo.pdf > and the conference flyers from > http://dl.dropbox.com/u/7726739/ESUG_Postcard.pdf > and the website is > http://www.esug.org/Conferences/2011 > > I look forward to seeing the latest state of moose in Edinburgh. > Wishing you luck with your conferences > Niall Ross > > Tudor Girba wrote: > >> Hi, >> >> Moose (http://moosetechnology.org) is a Smalltalk ambassador. Actually, I think it's the best ambassador we have right now to persuade professional developers to look into Smalltalk. >> >> Let me tell you why. >> >> Moose is a platform for software and data analysis and includes components like: Glamour, Mondrian or PetitParser. Moose solves a real and important problem that developers (both Smalltalkers and non-Smalltalkers) have: how to improve the productivity of the effort spent on assessment. Moose is an innovation in this domain because it enables a completely different approach through which developers craft their own tools fast (http://humane-assessment.com) The cool thing is that they build these tools by programming Smalltalk in Pharo, and thus they get to learn the language and the platform first. >> >> Moose also comes with exposure. For example, this year I will be presenting Moose and humane assessment at some large industry oriented conferences: >> - Jazoon (http://jazoon.com) >> - GotoCon Aarhus (http://gotocon.com/aarhus-2011/) >> - GotoCon Amsterdam (http://gotocon.com/amsterdam-2011/) >> >> All in all, if you want to promote Smalltalk, and Pharo in particular, you might want to look into it. And you are always welcome to contribute, follow us and make noise: >> - http://www.moosetechnology.org >> - http://twitter.com/#!/moosetechnology >> - http://www.facebook.com/pages/moosetechnologyorg/152851281427491 >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "No matter how many recipes we know, we still value a chef." >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ >> >> >> >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

1 0

[Pharo-project] [update 1.3] #13190
by StÃ©phane Ducasse May 11, 2011

May 11, 2011

13190 ----- Preparing loading of Transcript fixes

1 0

[Pharo-project] [update 1.3] #13189
by Marcus Denker May 11, 2011

May 11, 2011

13189 ----- Issue 4195: failing tests: TestObjectsAsMethod Issue 4157: TextColor is ignored in large TextEditors -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [MethodTrailer] #getSourceCodeBySelector: and #getSourceCodeByIdentifier: are not implemented
by Mariano Martinez Peck May 11, 2011

May 11, 2011

If we see CompiledMethodTrailer >> sourceCode "Answer the source code of compiled method. Note: it does not attempts to read from source files using sourcePointer, nor reconstruct the source code using temp names" (kind == #EmbeddedSourceQCompress or: [ kind == #EmbeddedSourceZip ]) ifTrue: [ ^ data ]. kind == #SourceBySelector ifTrue: [ ^ method methodClass getSourceCodeBySelector: method selector ]. kind == #SourceByStringIdentifier ifTrue: [ ^ method methodClass getSourceCodeByIdentifier: data ]. ^ nil But neither #getSourceCodeBySelector: nor #getSourceCodeByIdentifier: are implemented. In fact, it is easy to modify their test and make them red. Change #testSourceBySelectorEncoding or #testSourceByIdentifierEncoding and add a send to #sourceCode. Example: testSourceBySelectorEncoding | trailer | trailer := CompiledMethodTrailer new. trailer setSourceBySelector. self assert: (trailer kind == #SourceBySelector ). self assert: (trailer size = 1). trailer sourceCode. So...I don't know why they are not implemented, but if this was work "unfinished", we should at least make that clear and not to appear that it is supported but at the end it is not. So, if that's the case, I suggest to put nice comments explaining that and in addition implement: Behavior >> getSourceCodeBySelector: ^ self notYetImplemented Behavior >> getSourceCodeByIdentifier: ^ self notYetImplemented What do you think ? -- Mariano http://marianopeck.wordpress.com

1 0

[Pharo-project] [update 1.3] #13188
by Marcus Denker May 11, 2011

May 11, 2011

13188 ----- Issue 4194: Embed source code for methods which get uninstalled from their classes. Issue 4185: Minor fix in PluggableListMorph Issue 4183: SmalltalkImage>>abandoTempNames uses old method trailer bytes Issue 4179: Deprecate (or remove) DirectoryURI Issue 4193: OpaqueURI problem In Windows Issue 4186: Bug encoding CompiledMethod with sourcePointer = 0 Issue 4182: Morphic Halos to select color not working Issue 4184: CommentReference(Object)>>doesNotUnderstand: #methodClass Issue 4171: Bugs in RecentMessageList Issue 4153: add temp does not add the temp in -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [NativeBoost] Need your ideas, what platform-neutral assembler syntax you would like to have
by Igor Stasenko May 10, 2011

May 10, 2011

Hi, i took a look at Cog's abstract opcode syntax. Check the CogRTLOpcodes class>>initialize for description, and check the Cogit category 'abstract instructions' at instance side for actual syntax. Things i don't like: register naming. In cog you should use following register names: FPReg := -1. SPReg := -2. ReceiverResultReg := GPRegMax := -3. TempReg := -4. ClassReg := -5. SendNumArgsReg := -6. Arg0Reg := -7. Arg1Reg := GPRegMin := -8. DPFPReg0 := -9. DPFPReg1 := -10. DPFPReg2 := -11. DPFPReg3 := -12. DPFPReg4 := -13. DPFPReg5 := -14. DPFPReg6 := -15. DPFPReg7 := -16. They are mapping 1:1 to real registers on your machine. But while such names could make sense in some cases for Cog, in NativeBoost using register named like SendNumArgsReg will be confusing.. Okay... actually this is not a big deal, i could always use aliases with different names (suggestions?). But i would really like you opinion on Cog's native code syntax. Here how the native code assembly looks in cog: genDoubleArithmetic: arithmeticOperator preOpCheck: preOpCheckOrNil "Receiver and arg in registers. Stack looks like return address" <var: #preOpCheckOrNil declareC: 'AbstractInstruction *(*preOpCheckOrNil)(int rcvrReg, int argReg)'> | jumpFailClass jumpFailAlloc jumpFailCheck jumpSmallInt doOp | <var: #jumpFailClass type: #'AbstractInstruction *'> <var: #jumpFailAlloc type: #'AbstractInstruction *'> <var: #jumpSmallInt type: #'AbstractInstruction *'> <var: #jumpFailCheck type: #'AbstractInstruction *'> <var: #doOp type: #'AbstractInstruction *'> self MoveR: Arg0Reg R: TempReg. objectRepresentation genGetDoubleValueOf: ReceiverResultReg into: DPFPReg0. self MoveR: Arg0Reg R: ClassReg. jumpSmallInt := objectRepresentation genJumpSmallIntegerInScratchReg: TempReg. objectRepresentation genGetCompactClassIndexNonIntOf: Arg0Reg into: SendNumArgsReg. self CmpCq: objectMemory classFloatCompactIndex R: SendNumArgsReg. jumpFailClass := self JumpNonZero: 0. objectRepresentation genGetDoubleValueOf: Arg0Reg into: DPFPReg1. doOp := self Label. preOpCheckOrNil ifNotNil: [jumpFailCheck := self perform: preOpCheckOrNil with: DPFPReg0 with: DPFPReg1]. self gen: arithmeticOperator operand: DPFPReg1 operand: DPFPReg0. jumpFailAlloc := objectRepresentation genAllocFloatValue: DPFPReg0 into: SendNumArgsReg scratchReg: ClassReg scratchReg: TempReg. self MoveR: SendNumArgsReg R: ReceiverResultReg. self RetN: 0. "We need to push the register args on two paths; this one and the interpreter primitive path. But the interpreter primitive path won't unless regArgsHaveBeenPushed is false." self assert: methodOrBlockNumArgs <= self numRegArgs. jumpFailClass jmpTarget: self Label. preOpCheckOrNil ifNotNil: [jumpFailCheck jmpTarget: jumpFailClass getJmpTarget]. self genPushRegisterArgsForNumArgs: methodOrBlockNumArgs. jumpFailClass := self Jump: 0. jumpSmallInt jmpTarget: self Label. objectRepresentation genConvertSmallIntegerToIntegerInScratchReg: ClassReg. self ConvertR: ClassReg Rd: DPFPReg1. self Jump: doOp. jumpFailAlloc jmpTarget: self Label. self compileInterpreterPrimitive: (coInterpreter functionPointerForCompiledMethod: methodObj primitiveIndex: primitiveIndex). jumpFailClass jmpTarget: self Label. ^0 And here an example of NativeBoost code: emitArgumentsCoercion: gen " input - none, output - an arguments array in remmappable oops stack top" | asm proxy args argOop i | asm := gen asm. proxy := gen proxy. args := gen reserveTemp. argOop := gen reserveTemp. asm label: 'emitArgumentsCoercion>>'. proxy createInstanceOf: Array size: (gen fnSpec arguments size). proxy pushRemappableOop: EAX. i := 0. gen fnSpec arguments do: [:arg | arg type readOop: (EBP ptr + arg offset) generator: gen. asm mov: EAX to: argOop. proxy popRemappableOop. asm mov: EAX to: args. proxy storePointer: i ofObject: args withValue: argOop. i := i+1. proxy pushRemappableOop: args. ]. asm label: '<<emitArgumentsCoercion'. gen releaseTemps: 2. The code is of course doing different things.. but these example is actually to indicate a following observation: even when i will introduce platform-neutral code, in most cases you won't see a pure assembly language, but instead you will see a mix of usual smalltalk code and assembler. If you can see, in both examples above you see a direct instructions intermixed with another methods. And it is totally normal, because for obvious reasons, even for assembler code, there are a lot of repetitious patterns, and you refactor repetitive code into separate methods (a thing which you normally do if you follow DRY principle). So, i mean: its okay. I could change the assembler syntax to anything. But code will still be looking mostly the same, for most of code-generation routines. Of course, if you write a pure-assembly routine, it will be pure. But in practice you won't do it too often, because you can reuse stuff which already been done, or even use higher-level abstract syntax (i have one somewhere in my garage ;). But still, question remains open: should i take a Cog's assembler syntax as a base, or create own? The pro for Cog-syntax that if some day we move code generation from VM level to language, then we can just use existing code. But from another side, if i have tool which can produce a native code, from VM's perspective its completely irrelevant , where this code comes from and what assembler syntax were used to generate it. Also, we don't have to constrain ourselves, because Cog's assembler (and its implementation) were designed by taking into account that it should be translatable to C, while in NB we're always could use tricks like #perform: and block closures, which of course not available in slang. Sorry for long tiresome posts.. But i need your feedback and opinion. -- Best regards, Igor Stasenko AKA sig.

1 0