On Tue, Aug 4, 2009 at 12:30 PM, Marcus Denker <[email protected]> wrote:
> > On 03.08.2009, at 23:57, Javier Pimás wrote: > > > I'm glad it worked, and very pleased with the fast responses. Now, > > how does this patch get merged to the pharo trunk? > > > > Can you add an entry to the bugtracker? > > http://code.google.com/p/pharo/issues/list > > I should have some good description or a changeset or a SLICE. Than I > add it to pharo today... > Marcus, I already opened the ticket: http://code.google.com/p/pharo/issues/detail?id=1029 You have to do 2 things to make it work: 1) download latest ffi (FFI-Kernel-ar.11). You can evaluate "ScriptLoader loadFFI" 2) filein the attached changeset (in ticket) to ContextPart>>doPrimitive: primitiveIndex method: meth receiver: receiver args: I am just looking for testers and feedback before commiting it to pharo inbox. Best, Mariano > > Marcus > > > > The other thing I'd like to find out is why when using self break, I > > get in the debugger inspector a context where variables have wrong > > values. I'll open another thread on this. > > > > 2009/8/3 Mariano Martinez Peck <[email protected]> > > Thanks Javier Pimás and Andreas Raab for the excellent debugging and > > work. Andreas propose a fix (based in Javier work) and he has > > commited to Squeak. I look at the changes and try them in pharo. It > > works perfect!!! > > > > So, here is the ticket I open for pharo: > http://code.google.com/p/pharo/issues/detail?id=1029 > > > > You have to do 2 things to make it work: > > > > 1) download latest ffi (FFI-Kernel-ar.11). You can evaluate > > "ScriptLoader > > loadFFI" > > > > 2) filein the attached changeset (in ticket) to > > ContextPart>>doPrimitive: > > primitiveIndex method: meth receiver: receiver args: > > > > Please test it and let me know the results so that this can be > > integrated. > > > > For me it worked perfect. > > > > Best, > > > > Mariano > > > > 2009/8/2 Javier Pimás <[email protected]> > > > > I Think I found where the problem lies, it's just sitting there > > waiting to be resolved. > > > > To see what was happening I debugged the debuger, which was really > > weird. I found the answer when I broke into the step over button by > > adding a self break in OTCmdOverDebugger>>execute. After catching it > > I removed the break and stepped into everything to see how step over > > worked. The intresting part is in MethodContext(ContextPart)>>step, > > which sends interpretNextInstructionFor: self. The idea is this, > > instead of advancing the vm program counter within the vm code, the > > debugger simulates the execution cycle, step by step. It not so hard > > as it seems but also not very simple. The problem comes when the > > debugger tryies to simulate primitive calls. When the simulator > > detects a primitive, it issues a > > MethodContext(ContextPart)>>doPrimitive:method:receiver:args:, here > > you can see the detection: > > > > tryPrimitiveFor: method receiver: receiver args: arguments > > "..." > > | primIndex | > > (primIndex := method primitive) = 0 ifTrue: [^ > > PrimitiveFailToken]. > > ^ self doPrimitive: primIndex method: method receiver: receiver > > args: arguments > > > > well, the problem is that doPrimitive doesn't seem to implement all > > primitives (I recomend you to look it's code), but just a few ones. > > Also, as far as I can see, it calls primitive 19, which i found is > > (by looking vm C code) primitiveFail, and that primitive just sets a > > flag that says that something failed. > > > > Then, if my calculations are correct, the problem is that the FFI > > Call primitive needs to be handled by hand. I tryied adding this to > > ContextPart>>doPrimitive:method:receiver:args: > > > > primitiveIndex = 120 ifTrue: "Calling an FFI method, just evaluate > > it and return" > > [ meth valueWithReceiver: receiver arguments: arguments . > > ^self]. > > > > just before > > > > arguments size > 6 ifTrue: [^PrimitiveFailToken]. > > > > which I think almost worked. I think the primitive was executed, but > > this doesn't handle the execution context that is being simulated, > > and the stack gets corrupted. Somebody with more experience in > > ContextPart, MethodContext, etc. may give us a hand here, I think > > the fix is almost there. > > > > Bye, > > Javier. > > > > 2009/7/31 Mariano Martinez Peck <[email protected]> > > > > > > > > 2009/7/31 Javier Pimás <[email protected]> > > > > Does anybody know if the problem occurs just in Windows or in any > > OS? this can give a clue of the problem... > > > > > > I don't remember debugging in Windows, but in Linux I have this > > problem for sure. > > > > > > On Thu, Jul 30, 2009 at 11:28 PM, Javier Pimás < > [email protected] > > > wrote: > > Well, at least I feel better that I'm not crazy, (or not the only > > one...). Maybe if someone could give us a clue about it, we could > > spot where the problem is. Do you think it is a vm problem or > > something related to the smalltalk code? > > > > 2009/7/30 Mariano Martinez Peck <[email protected]> > > > > Yes. This is really annoying for me. I am writing a C library plugin > > since a year and a half and this is very frustrated :( > > You cannot debug when using FFI. I mean, you cannot get advantages > > of one of the best Smalltalk features! What I do is to write a self > > break before and after the call and use "proceed" but I don't like > > it at all. > > > > Once I tried to see what the problem was, but I was to difficult to > > me to understand it and fix it. We need a guru here I think hahaha. > > > > Best, > > > > Mariano > > > > 2009/7/30 Javier Pimás <[email protected]> > > Hi, I'm having problems with the debugger. Every time I try to debug > > code that uses FFI, if I step over a message that internally does an > > FFI call, I get an externalCallFailed error and then I land in > > MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: > > If I run the code without debugging, then I have no problems at all. > > > > I'm using SqueakPharo v3.11.2 with pharo0.1-10373web09.07.2. > > > > To reproduce it you can try this: > > > > ScriptLoader loadFFI. > > then load latest GLMorphic from squeaksource, and uncomment the > > "self break." in > > GLCanvas>>displayString:from:to:at:strikeFont:kern: > > > > doit > > World fullDrawOn: GLDisplayScreen testCanvas > > hit debug and step over until you reach > > ogl glTexImage2D: GLTexture2d with:... > > > > also you'll see wrong values for local vars, like aPoint which will > > look as #(nil nil nil nil nil) when it'll actually have a point. > > > > Is there any other way to set up a break point instead of adding > > self break to the code?? > > > > Thanks, > > Javier. > > > > -- > > Javier Pimás > > Ciudad de Buenos Aires > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > Javier Pimás > > Ciudad de Buenos Aires > > > > > > > > -- > > Javier Pimás > > Ciudad de Buenos Aires > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > Javier Pimás > > Ciudad de Buenos Aires > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > Javier Pimás > > Ciudad de Buenos Aires > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
