August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Debbuging problems, FFI

by Marcus Denker

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 > 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 <marianopeck(a)gmail.com> > 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 <elpochodelagente(a)gmail.com> > > 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 <marianopeck(a)gmail.com> > > > > 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > > 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 <elpochodelagente(a)gmail.com > > 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 <marianopeck(a)gmail.com> > > 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 <elpochodelagente(a)gmail.com> > 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 > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > 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 > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2009

Re: [Pharo-project] Wrong values of variables showed in execution context when doing self break?

by Mariano Martinez Peck

On Tue, Aug 4, 2009 at 8:24 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > 2009/8/4 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: > > > > Here is an example to reproduce it. Maybe somebody has already opened a > > ticket for this problem. To try you can doit the following code and look > at > > the values shown of x and y in the bottom left list of debugger. > > > > AClassToTest doSomeThingWith: 14@17. > > I can't reproduce your bug. Please try again in a 10402 image or later > and open an issue tagged Milestone-1.0 if you can still reproduce it. > Also attach the code to the issue so that people can load easily. I also did it but didn't find something strange. Perhaps a screenshot may help. best, mariano > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 4, 2009

Re: [Pharo-project] Wrong values of variables showed in execution context when doing self break?

by Damien Cassou

2009/8/4 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: > > Here is an example to reproduce it. Maybe somebody has already opened a > ticket for this problem. To try you can doit the following code and look at > the values shown of x and y in the bottom left list of debugger. > > AClassToTest doSomeThingWith: 14@17. I can't reproduce your bug. Please try again in a 10402 image or later and open an issue tagged Milestone-1.0 if you can still reproduce it. Also attach the code to the issue so that people can load easily. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 4, 2009

Re: [Pharo-project] Debbuging problems, FFI

by Javier PimÃ¡s

2009/8/4 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2009/8/4 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > >> 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 <marianopeck(a)gmail.com> >> >> 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 <elpochodelagente(a)gmail.com> >>> >>> 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 <marianopeck(a)gmail.com> >>>> >>>> >>>>> >>>>> 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>>>> >>>>>> 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 < >>>>>> elpochodelagente(a)gmail.com> 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 <marianopeck(a)gmail.com> >>>>>>> >>>>>>> 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 <elpochodelagente(a)gmail.com> >>>>>>>> >>>>>>>>> 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 >>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> 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 >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Javier PimÃ¡s >>>> Ciudad de Buenos Aires >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 4, 2009

[Pharo-project] Wrong values of variables showed in execution context when doing self break?

by Javier PimÃ¡s

This is another one that is weird. When I debug some code by introducing a self break statement, I usually get the values of the variables shown in the bottom of the debugger all messed up. It should be noted that "doiting" something which has self break opens a different debugger than debuging code directly. Here is an example to reproduce it. Maybe somebody has already opened a ticket for this problem. To try you can doit the following code and look at the values shown of x and y in the bottom left list of debugger. AClassToTest doSomeThingWith: 14@17. after creating AClassToTest: 'From Pharo0.1 of 16 May 2008 [Latest update: #10373] on 4 August 2009 at 1:07:23 am'! Object subclass: #AClassToTest instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'BreakPointBroken'! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! AClassToTest class instanceVariableNames: ''! !AClassToTest class methodsFor: 'as yet unclassified' stamp: 'JEP 8/4/2009 00:29'! do: aBoolean ifTrue: tBlock ifFalse: fBlock aBoolean ifTrue: tBlock ifFalse: fBlock. ^true. ! ! !AClassToTest class methodsFor: 'as yet unclassified' stamp: 'JEP 8/4/2009 00:53'! doSomeThingWith: aPoint | x y | self break. self do: false ifTrue: [ x := aPoint x. y := aPoint y. ] ifFalse: [ 1 + 1. ]. ^x. ! ! -- Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 4, 2009

Re: [Pharo-project] Debbuging problems, FFI

by Mariano Martinez Peck

2009/8/4 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > 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 <marianopeck(a)gmail.com> > > 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 <elpochodelagente(a)gmail.com> >> >> 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 <marianopeck(a)gmail.com> >>> >>> >>>> >>>> 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>>> >>>>> 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 < >>>>> elpochodelagente(a)gmail.com> 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 <marianopeck(a)gmail.com> >>>>>> >>>>>> 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 <elpochodelagente(a)gmail.com> >>>>>>> >>>>>>>> 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 >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> 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 >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Javier PimÃ¡s >>> Ciudad de Buenos Aires >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 4, 2009

Re: [Pharo-project] Debbuging problems, FFI

by Javier PimÃ¡s

I'm glad it worked, and very pleased with the fast responses. Now, how does this patch get merged to the pharo trunk? 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 <marianopeck(a)gmail.com> > 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 <elpochodelagente(a)gmail.com> > > 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 <marianopeck(a)gmail.com> >> >> >>> >>> 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>> >>>> 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 < >>>> elpochodelagente(a)gmail.com> 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 <marianopeck(a)gmail.com> >>>>> >>>>> 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 <elpochodelagente(a)gmail.com> >>>>>> >>>>>>> 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 >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> 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 >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 4, 2009

Re: [Pharo-project] Fix for issue 981 Author class in pharo

by Serge Stinckwich

On Sat, Aug 1, 2009 at 6:05 AM, Miguel CobÃ¡<miguel.coba(a)gmail.com> wrote: > I have tested the SLICE of issue 981 on a new Pharo 10401 beta image > and an updated 10402 > image and it loads without problems. > > Should I mark this as milestone 1.0 or isn't elegible for this first release? > I know that my opinion is biased, but I think that the 1.0 version of > pharo should have the > initials problem solved in order to base all the subsecuent code not > to depende on initials. > > Comments? > Has anyone confirmed that the functionality is correct? > What about the format of the name and the message prompt? Normaly, during in beta phase, no new functionality should be commit, only bug patches. But maybe you can consider this one as a patch ;-) -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Aug. 4, 2009

Re: [Pharo-project] 2 new plugin (for VMPluginOverview)

by Mariano Martinez Peck

On Sun, Aug 2, 2009 at 7:22 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Maybe someone is able to include the following plugins > in http://code.google.com/p/pharo/wiki/VMPluginOverview. > I cc Michael who I think is the one who does this task. > > Thanks > Torsten > > > > OpenVGPlugin.dll > ================ > [1] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-August/137911.h… > > Cryptography.dll > ================ > http://leves.web.elte.hu/cryptography/ > -- > Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate > fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 3, 2009

[Pharo-project] [update] #10404

by Marcus Denker

10404 ----- Fixes included: Issue 1006: cleanUpForRelease should remove empty methodcategories Issue 1005: ScriptLoader cleanupForRelease asks for initials... Issue 984: RenderBugz tests revised to avoid extraneous timing issues (Mantis 7045) Issue 900: Fix CodeLoader>>#exportCodeSegment:classes:keepSource: closed because not relevant: Issue 327: possible fix for monardig ifNotNil: inlining Open Reports left for 1.0: 49 -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Aug. 3, 2009