2009/8/4 Javier Pimás <[email protected]> > I'm glad it worked, and very pleased with the fast responses. Now, how does > this patch get merged to the pharo trunk?
Did it work for you ? When people say the fix actually works well, it will be closed and commited to pharo inbox (I can do it) and then integrated in a new image. I would be obviously be lovely to have a unit test for this, but I don't don't know if this is possible. What do you think? > > > 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. I didn't understand you, but yes, please open a new thread and ticket if necessary. Best, Mariano > > > 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
