[squeak-dev] working on hydra, issue with BitBltPlugin.c

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] working on hydra, issue with BitBltPlugin.c

johnmci
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
=
=
=
========================================================================



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] working on hydra, issue with BitBltPlugin.c

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] working on hydra, issue with BitBltPlugin.c

johnmci
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
=
=
=
========================================================================



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] working on hydra, issue with BitBltPlugin.c

Steven W. Riggins
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
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] working on hydra, issue with BitBltPlugin.c

Steven W Riggins
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
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] working on hydra, issue with BitBltPlugin.c

johnmci
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
=
=
=
========================================================================