2009/8/4 Mariano Martinez Peck <[email protected]> > > > 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? >
It worked fine for me. About the test, I think it can be done, at the level of MethodContext>>tryPrimitiveFor: method receiver: receiver args: arguments. The problem would be how to get the correct parameters to test. method could be something like the CompiledMethod related to Win32Window>>getFocus (but should better be something os-independent) receiver would then be Win32Window and arguments just #(). The question is where will aMethodContext come from. > > >> >> >> 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 > -- Javier Pimás Ciudad de Buenos Aires
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
