Well more progress at least it runs some bytecodes on osx before dying.
we get a primitive failure in primitiveRenderScanline, and it paints the screen with the walkback and lets me invoke the emergency debugger. However in looking it seems I"m missing a change to the bitblt plugin. Given that the interpreter has /* This entry point needs to be implemented for the interpreter proxy. Since BitBlt is now a plugin we need to look up BitBltPlugin:=loadBitBltFrom and call it. This entire mechanism should eventually go away and be replaced with a dynamic lookup from BitBltPlugin itself but for backward compatibility this stub is provided */ sqInt loadBitBltFrom(struct Interpreter *intr, sqInt bb) { void * fn; fn = ioLoadFunctionFrom("loadBitBltFrom", "BitBltPlugin"); if (fn == 0) { /* begin primitiveFail */ intr->successFlag = 0; return null; } return (((sqInt (*)(INTERPRETER_ARG_COMMA sqInt)) fn)) (INTERPRETER_PARAM_COMMA bb); } but BitBltPlugin.c is wrong. EXPORT(sqInt) loadBitBltFrom(sqInt bbObj) { return loadBitBltFromwarping(bbObj, 0); } Isn't C fun, typed language, sure that makes life easier we hear, at least smalltalk would have said oops no such method that requires TWO parms, not let me call a method with two parms hoping it would do the right thing. So we now passed in the pointer to the interpreter and then pretend it's the bitblt object, which of course is wrong because that does in this case cause the primtive to fail as it pulls data from the wrong place. -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
2008/5/1 John M McIntosh <[hidden email]>:
> Well more progress at least it runs some bytecodes on osx before dying. > > we get a primitive failure in primitiveRenderScanline, and it paints the > screen with the walkback and lets me invoke the emergency debugger. > However in looking it seems I"m missing a change to the bitblt plugin. > > Given that the interpreter has > > /* This entry point needs to be implemented for the interpreter proxy. > Since BitBlt is now a plugin we need to look up > BitBltPlugin:=loadBitBltFrom > and call it. This entire mechanism should eventually go away and be > replaced with a dynamic lookup from BitBltPlugin itself but for > backward > compatibility this stub is provided */ > > sqInt loadBitBltFrom(struct Interpreter *intr, sqInt bb) { > void * fn; > > fn = ioLoadFunctionFrom("loadBitBltFrom", "BitBltPlugin"); > if (fn == 0) { > /* begin primitiveFail */ > intr->successFlag = 0; > return null; > } > return (((sqInt (*)(INTERPRETER_ARG_COMMA sqInt)) > fn))(INTERPRETER_PARAM_COMMA bb); > } > > > but > > BitBltPlugin.c is wrong. > > EXPORT(sqInt) loadBitBltFrom(sqInt bbObj) { > return loadBitBltFromwarping(bbObj, 0); > } > > > Isn't C fun, typed language, sure that makes life easier we hear, at least > smalltalk would have said oops no such method that requires TWO parms, not > let me call a method with two parms > hoping it would do the right thing. So we now passed in the pointer to > the interpreter and then pretend it's the bitblt object, which of course is > wrong because that does in this case cause > the primtive to fail as it pulls data from the wrong place. > Of course, its just plain wrong - calling function which expects single argument with two. But i had no much choice, wrapping plugin function as primitive in interpreter is a bit awkward, but i understand that people had no much choice too - because of backward compatibility. This should be fixed after BitBltPlugin objectification. But it should work correctly under cdecl calling convention. If you call function with two parameters: f (intr , bbObj) and it expects only single one, then it will see only last parameter: f(arg == bbObj) { } So, there should be no problems, it may be in different place. -- Best regards, Igor Stasenko AKA sig. |
Ok, I have it a bit further, it walks, it talks. Well kinda. It seems
to digest the first few UI events then stops processing them. So now I need to puzzle out where the events go and why the carbon event handlers stop processing things after processing the window activate event. -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
Carbon event handlers? Why is this not fully Cocoa?
I see no reason to use any carbon calls in any new VM. You're dead on the iphone if you use Carbon. On May 1, 2008, at 10:22 PM, John M McIntosh wrote: > Ok, I have it a bit further, it walks, it talks. Well kinda. It > seems to digest the first few UI events then > stops processing them. So now I need to puzzle out where the events > go and why the carbon event handlers stop processing things after > processing the window activate event. > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <[hidden email]> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > |
In reply to this post by johnmci
Carbon event handlers? Why is this not fully Cocoa?
I see no reason to use any carbon calls in any new VM. You're dead on the iphone if you use Carbon. On May 1, 2008, at 10:22 PM, John M McIntosh wrote: > Ok, I have it a bit further, it walks, it talks. Well kinda. It > seems to digest the first few UI events then > stops processing them. So now I need to puzzle out where the events > go and why the carbon event handlers stop processing things after > processing the window activate event. > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <[hidden email]> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > |
Th Hydra VM had an objective of being a *minor* change to the existing
code base. Versus a completely new code base. Also designed so you could build a Hydra VM or non-Hydra VM using the same code base. For the problem situation here a Cocoa VM would have failed just as spectacularly. On May 14, 2008, at 9:01 AM, Steven W Riggins wrote: > Carbon event handlers? Why is this not fully Cocoa? > > I see no reason to use any carbon calls in any new VM. You're dead > on the iphone if you use Carbon. > > > On May 1, 2008, at 10:22 PM, John M McIntosh wrote: > >> Ok, I have it a bit further, it walks, it talks. Well kinda. It >> seems to digest the first few UI events then >> stops processing them. So now I need to puzzle out where the events >> go and why the carbon event handlers stop processing things after >> processing the window activate event. >> -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
Free forum by Nabble | Edit this page |