- Pharo-dev - lists.pharo.org

Re: [Pharo-project] compiled VM with Alien for JNIPort

by Luc Fabresse

2011/5/10 Serge Stinckwich <serge.stinckwich(a)gmail.com> > Hi Laurent, > > i'm interested by a report with your experiment with JNIPort. > +1 #Luc > Regards, > > On Tue, May 10, 2011 at 3:55 AM, laurent laffont > <laurent.laffont(a)gmail.com> wrote: > > OK I will try. > > > > For info I want to use JNIPort just to write some small Java script to > > learn and prototype on several Java frameworks. Prototyping with Java is > > tedious. I've tried Groovy, it's better but lacks all goodies of Pharo > IDE. > > So I thought JNIPort would be a good candidate to play with. > > > > Laurent. > > > > > > On Mon, May 9, 2011 at 10:39 PM, Fernando Olivero < > fernando.olivero(a)usi.ch> > > wrote: > >> > >> In case you just want to quickly use Alien , the latest vm's from John > >> came with the plugin . > >> For example, Lumiere using Alien, works on Squeak 4.2.2beta1U. > >> Fernando > >> > >> On Mon, May 9, 2011 at 10:01 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > On 9 May 2011 21:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> >> > >> >> > >> >> On Mon, May 9, 2011 at 11:27 AM, laurent laffont > >> >> <laurent.laffont(a)gmail.com> > >> >> wrote: > >> >>> > >> >>> On Mon, May 9, 2011 at 4:02 PM, laurent laffont > >> >>> <laurent.laffont(a)gmail.com> wrote: > >> >>>> > >> >>>> Hi, > >> >>>> > >> >>>> is there a compiled VM available with Alien for OSX ? I want to use > >> >>>> JNIPort. > >> >>> > >> >>> > >> >>> Second question, if I need to compile the VM, which one should I use > >> >>> for > >> >>> Alien ? Cog is OK ? > >> >> > >> >> Yes. Cog is OK. > >> > > >> > And what plugin? NewsqueakIA32ABIPlugin, right? > >> > > >> >> > >> >>> > >> >>> Laurent > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > Igor Stasenko AKA sig. > >> > > >> > > >> > > > > > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > >

May 11, 2011

[Pharo-project] [MethodTrailer] #getSourceCodeBySelector: and #getSourceCodeByIdentifier: are not implemented

by Mariano Martinez Peck

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

May 11, 2011

[Pharo-project] [update 1.3] #13188

by Marcus Denker

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.

May 11, 2011

[Pharo-project] [NativeBoost] Need your ideas, what platform-neutral assembler syntax you would like to have

by Igor Stasenko

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.

May 11, 2011

[Pharo-project] Call for ideas for DBXTalk UI

by Mariano Martinez Peck

Hi guys. Thanks to the ESUG SummerTalk, DBXTalk team has started to work with the new products of the DBXTalk suite. However, for one of the tools in special we would like to hear your opinion. Just a little introduction to the two other tools: 1) A new Glorp port from VW to Pharo. In addition, we provide the DBX driver for Glorp, by the name of GlorpDBX. Guillermo Polito is mostly working on this. 2) A new tool that uses Magritte and the database metadata to automatically generate the mappings between objects and tables. The idea is to do it two-way: a) read the metadata from an existing database -> create magritte descriptions -> generate Glorp mappings -> query with Glorp b) write magritte descriptions for the mappings -> generate database schema -> generate Glorp mappings -> query with Glorp or something like that....it is not completely decided but that's the idea. This way we can autogenerate the Glorp mappings and then use Glorp normally. Santiago Bragagnolo is working mostly on this. The third product, and here the question, is going to be a UI for the DBXTalk suite. This UI would do the core functionalities of tools like SQLDeveloper, MySQL Explorer, pgAdmin, etc. This is basically: - visualize and get information of: tables, views, schemas, relations, indexes, etc. - be able to modify the previous items and impact them in the database - write queries and get results So...why this tool if we can also use external tools like SQLDeveloper, MySQL Explorer, pgAdmin, etc ? a couple of reasons: 1) having the tool inside the image is easier (just the same way you sometimes install an Eclipse plugin instead of using such programs) 2) the same tool works for all databases 3) we can customize it with particular things of DBX Gisela Decuzzi is working mostly on this. Now....what use cases do you think are useful for such UI ? what kind of things would you like ? what things we can do that are related to Glorp and to the magritte tool? what things can we do to have even more advantages than just using external programs ? I have the following things in mind: - Special console for DBX/Glorp logs. - Be able to edit Magritte description for mappings. - Sync the tables and mapping while edditing. - A new inspector for inspecting restultsets, where you see one rows and columns. Let us know. Once again, thanks ESUG for the sponsorship to the team. Mariano http://marianopeck.wordpress.com

May 11, 2011

Re: [Pharo-project] compiled VM with Alien for JNIPort

by laurent laffont

So following Mariano's blog and pharocasts I've built Cog with IA32ABIPlugin (works, cool !) When starting the JVM following JNIPort instructions on SqueakSource wiki, the VM crashes. GDB bt gives: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x000d267a in primCallOutIntegralReturn () at /Users/laurentlaffont/dev/pharo/vm/blessed/src/plugins/IA32ABI/IA32ABI.c:500 #2 0x00023a3e in interpret () at /Users/laurentlaffont/dev/pharo/vm/blessed/src/vm/gcc3x-cointerpmt.c:2037 #3 0x962ede02 in __CFRunLoopDoObservers () #4 0x962a9d8d in __CFRunLoopRun () #5 0x962a9464 in CFRunLoopRunSpecific () #6 0x962a9291 in CFRunLoopRunInMode () #7 0x934dce04 in RunCurrentEventLoopInMode () #8 0x934dcaf5 in ReceiveNextEventCommon () #9 0x934dca3e in BlockUntilNextEventMatchingListInMode () #10 0x9644778d in _DPSNextEvent () #11 0x96446fce in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #12 0x96409247 in -[NSApplication run] () #13 0x964012d9 in NSApplicationMain () #14 0x00078247 in main (argc=1, argv=0xbffff680, envp=0xbffff688) at /Users/laurentlaffont/dev/pharo/vm/blessed/platforms/iOS/vm/Common/main.m:52 (gdb) Any idea ? Laurent. On Tue, May 10, 2011 at 12:37 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Mon, May 9, 2011 at 1:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 9 May 2011 21:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Mon, May 9, 2011 at 11:27 AM, laurent laffont < >> laurent.laffont(a)gmail.com> >> > wrote: >> >> >> >> On Mon, May 9, 2011 at 4:02 PM, laurent laffont >> >> <laurent.laffont(a)gmail.com> wrote: >> >>> >> >>> Hi, >> >>> >> >>> is there a compiled VM available with Alien for OSX ? I want to use >> >>> JNIPort. >> >> >> >> >> >> Second question, if I need to compile the VM, which one should I use >> for >> >> Alien ? Cog is OK ? >> > >> > Yes. Cog is OK. >> >> And what plugin? NewsqueakIA32ABIPlugin, right? >> > > No, just IA32ABIPlugin. The difference between the two is only > that NewsqueakIA32ABIPlugin implements immutability checks. > > >> >> > >> >> >> >> Laurent >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >

May 10, 2011

[Pharo-project] [update 1.3] #13188

by StÃ©phane Ducasse

13188 ----- - Issue 4177: New TranscriptWindow and several fixes to the (new) Transcript adoption. Thanks a lot Fernando Olivero. 3112: ThreadSafeTranscript >> #endEntry is Morphic dependent. 3948: Transcript and ThreadedTranscript needs to be merged. 4023: Transcript clear prints Transcript after clearing prior text. 4039: To open ThreadSafeTranscript . 4067: Transcript does not work with system fonts (Win XP) (TranscriptModel>>displayOn: aForm uses StandardFonts now) 4093: alt_t (fixed by loading the post load: send initializeDesktopCommandSelectors for the worlds) 4116: minimizing, then output to transcript: redraw problems. Big thanks to fernando *** APPLAUS *** You see guys trust works :) Stef

May 10, 2011

Re: [Pharo-project] Cog doesn't load anymore in PharoCore1.3 because of the removal of AbstractLauncher

by Mariano Martinez Peck

sooo.. opinions? On Sun, Apr 24, 2011 at 8:11 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > If Cog really needs it we should create a separate repostiroy like > PharoCogSupport and put the class there and add it as a dependency of Cog in > ConfigurationOfCog. > Another hacky way is to add a #preLoadDoit: in ConfigurationOfCog that > does a #compile: of AbstractLauncher > > Cheers > > Mariano > > > > On Sun, Apr 24, 2011 at 7:37 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> AbstractLauncher was removed in: >> http://code.google.com/p/pharo/issues/detail?id=4002 >> >> Cog has a subclass from AbstractLauncher called CommandLineLauncher, >> hence, it cannot be loaded anymore >> >> CommandLineLauncher has no class comment and no sender. So I have no idea >> what it does, nor if it can be removed from cog, nor how to solve this >> problem in Pharo. >> >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

May 10, 2011

Re: [Pharo-project] add temp does not add the temp in 1.3 13179

by Mariano Martinez Peck

Thanks Lukas. I put your code in a slice and it works. http://code.google.com/p/pharo/issues/detail?id=4153 On Tue, May 3, 2011 at 8:38 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I can reproduce it everywhere, in Pharo 1.2 and 1.3. I don't think it > has anything to do with Shout or eCompletion. It looks like the > problem is that the new text editor that doesn't consequently reuse > the same Text object but instead creates new ones. The method > #compile:classified:withStamp:notifying:logSource: depends on the fact > that this is always the same Text instance, even after editing. > Luckily we can fix that easily, but there might be other subtle bugs > lingering around: > > TClassAndTraitDescription>>compile: text classified: category > withStamp: changeStamp notifying: requestor logSource: logSource > | methodAndNode | > methodAndNode := self compile: text asString classified: category > notifying: requestor > trailer: self defaultMethodTrailer ifFail: [^nil]. > logSource ifTrue: [ > " replace 'text' with 'methodAndNode node sourceText' " > self logMethodSource: methodAndNode node sourceText > forMethodWithNode: methodAndNode > inCategory: category withStamp: changeStamp > notifying: requestor. > ]. > self addAndClassifySelector: methodAndNode selector withMethod: > methodAndNode > method inProtocol: category notifying: requestor. > self instanceSide noteCompilationOf: methodAndNode selector meta: > self isClassSide. > ^ methodAndNode selector > > On 3 May 2011 17:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > it does not work in OB in 1.3 nor in the plain default browser. > > Now in plain 1.3-core it is working in the default browser. So this is > probably linked with a package loaded in the dev image. I was thinking OC? > > > > Stef > > > > > > On May 3, 2011, at 2:30 PM, Johan Brichau wrote: > > > >> > >> On 03 May 2011, at 10:14, Mariano Martinez Peck wrote: > >> > >>> aha.... I didn't try that ;) > >>> So...in 1.2.1 adding from a browser does work, but not from the > debugger? > >>> And in 1.3 none of them? > >> > >> > >> I don't know about 1.3 but it's one of the things I started to notice > about 1.2.1 this week. > >> In the browser, it works fine. > > > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Mariano http://marianopeck.wordpress.com

May 10, 2011

[Pharo-project] [COTDC] 62 - MIMEType

by laurent laffont

Today: MIMEType Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

May 10, 2011