Author Topic: 02debugger : a debugger for o2  (Read 6552 times)

0 Members and 1 Guest are viewing this topic.

Charles Pegge

  • Guest
Re: 02debugger : a debugger for o2
« Reply #15 on: May 28, 2018, 02:18:37 PM »
A simpler alternative is to embed the debugger interface, as o2 source code which could be included in any program being tested. This would make it much easier to access variables and structures

It requires a very small addition to o2, for invoking the debugger per-procedure or per-line.


JRS

  • Guest
Re: 02debugger : a debugger for o2
« Reply #16 on: May 28, 2018, 02:42:37 PM »
I like this idea better than an external debugger. I could use it with DLLC.

Charles Pegge

  • Guest
Re: 02debugger : a debugger for o2
« Reply #17 on: May 29, 2018, 06:16:11 AM »
(Charles,

Alongside a more common WinDiff, WinMerge is another excellent tool to easily locate, examine and process the differences between various versions of same documents, predominantly program sources. I'm using it on a day-to-day basis.)


Mike,

I'm eager to understand the diff algorithms. In a slightly different form, they could be very useful for matching code-patterns in large projects. This would be very useful for abstraction and optimisation.

JRS

  • Guest
Re: 02debugger : a debugger for o2
« Reply #18 on: May 29, 2018, 06:45:51 AM »
If O2 used Github as intended, you would already have the tools your interested in.

Arnold

  • Guest
Re: 02debugger : a debugger for o2
« Reply #19 on: June 01, 2018, 10:59:19 AM »
Hi Charles, Laurent,

hopefully my intention is not misinterpreted.

This is the code of an older example (classLibraryCompo.o2bas). In the original state it will crash. It will crash if I uncomment line 68 and comment line 69-71. It will also crash if I comment line 68-line 71, or comment line 68,70,71 and keep line 69. As is (using the print statements) it will work.

I assume something is missing with Oxygen.dll. But how would I find the problem using O2debugger.exe or the new tracer facility of Oxygen or any other tool? Currently I only use print statements and trial and error, but somehow I think I should act more systematically.

Roland

Code: OxygenBasic
  1.  
  2. '
  3. '
  4. '
  5. '         ###############
  6. '       ###################
  7. '      ###               ###
  8. '     ###    ###          ###
  9. '    ###    ## ##         ###
  10. '    ###   ##   ##        ###
  11. '    ###  ##     ##       ###
  12. '    ###  ##      ##      ###
  13. '    ###  ##      ##      ###
  14. '    ###   ####  ##      ###
  15. '     ###    ####       ###
  16. '      ###             ###
  17. '       ###           ###
  18. '         #############
  19. '           #########
  20.  
  21.  
  22. '-------------
  23. 'CLASS LIBRARY
  24. '=============
  25.  
  26.   'Oxygen dependent
  27.  '#file "greeting.dll"
  28.  
  29.   'Oxygen independent
  30.  includepath "$/inc/"
  31.   '$dll
  32.  '$filename "greeting.dll"
  33.  '#include "RTL32.inc" 'UNCOMMENT
  34.  
  35.   extern
  36.  
  37.   class greeting
  38.   '=============
  39.  
  40.   bstring hi,bye
  41.  
  42.   method hello(string n)
  43. 'print "in method hello"  
  44.  print hi n
  45.   end method
  46.  
  47.   method goodbye(string n)
  48.   print bye n
  49.   end method
  50.  
  51.   method free()
  52.   del hi
  53.   del bye
  54.   del this
  55.   print "freed"
  56.   end method
  57.  
  58.   end class
  59.  
  60.   '#recordof greeting
  61.  
  62.  
  63.   function NewGreetingObject() as greeting*, export
  64.   =================================================
  65.   new greeting g  
  66.   g.hi="Hello "
  67.   g.bye="Goodbye "
  68. 'print "new greeting g = " @g
  69. sys *address = @g  
  70. print "new greeting address = " @address
  71. print "new greeting @g = " @g
  72.   return @g
  73.   end function
  74.  
  75.   end extern
  76.  
  77.  
  78.   extern virtual
  79.   class greeting
  80.   ==============
  81.   method hello(string n)
  82.   method goodbye(string n)
  83.   method free()
  84.   end class
  85.   end extern
  86.  
  87.   'declare NewGreetingObject lib "greeting.dll" () as greeting
  88.  
  89.   greeting g at NewGreetingObject()
  90. 'print "@g = " @g  
  91.  g.hello   "world"
  92.   g.goodbye "world"
  93.   g.free
  94.  

Laurent

  • Guest
Re: 02debugger : a debugger for o2
« Reply #20 on: June 01, 2018, 12:11:10 PM »
Hi Arnold, Roland,

No need o2debugger here : the compiler is indeed involved.

Lorand (same pronunciation in french than Laurent)

A simpler alternative is to embed the debugger interface, as o2 source code which could be included in any program being tested. This would make it much easier to access variables and structures

It requires a very small addition to o2, for invoking the debugger per-procedure or per-line.
I'm sure that will limit the debug possibilities. If the goal is just to follow the execution ok but to see the variable values and other nice features not possible. Trust me. Just have a look to the chm file. I could later explain how a debugger works.
For now I continue to complete the missing features. I'll reduce le number of lines modified in the O2 dll source code and see how generate the debugging data an external file.

Mike Lobanovsky

  • Guest
Re: 02debugger : a debugger for o2
« Reply #21 on: June 02, 2018, 01:11:12 AM »
Lorand (same pronunciation in french than Laurent)

Nah, not quite: "o" in "Lor..." is open like in "alors" while "o" in "Laur..." is deep like in "l'eau", n'est-ce pas? But yes, "...rand" is pretty much the same as "...rent" indeed. :)

Hi there, Mr Roland "Arnold" Lorand! :D


Charles Pegge

  • Guest
Re: 02debugger : a debugger for o2
« Reply #22 on: June 03, 2018, 02:02:31 AM »
Hi Roland,

I think you can systematise the location of bugs. But the rest of the bug-fixing process will often involve running a series of code modifications to establish the behaviour of the code, followed by a detailed step-through to understand the erratic behaviour, and then a consideration of the best solution to the problem. These latter stages, which consume the most time, require a range of skills which I doubt could be automated.

Anyway, the example you gave was an interesting one, and is restored to the OOP examples. It took about 30 mins to characterize the bug symptoms, another hour to identify the behaviour at the assembler level. Another hour to trace the origin of the bug. 1 minute for a quick fix: A mere d=0. Then another hour or two to go for a deeper, and more robust fix, saving some lines of code in the process.


Arnold

  • Guest
Re: 02debugger : a debugger for o2
« Reply #23 on: June 03, 2018, 08:01:01 AM »
Hi Charles,

probably my approach is wrong. It is clear now that I must ask if it is about the compiler. But I work on some small projects which do not yet work quite correctly and I am sure this happens because of my faulty logic. In the meantime it is my ambition not to ask you about trifles every time.

I will try O2debugger with some working examples. This should give a better insight into the possible use of a debugger, which is another new territory for me.

@Mike,
I once selected an anagram as member name and did not notice the consequences. But this is ok. Unfortunately I see my messages like little letters which need a signature. In this regard I behave like the guy in "The Big Bang Theory" who can not get rid of his habits. And I must admit it is not so easy to do this. It is like giving up smoking.

Mike Lobanovsky

  • Guest
Re: 02debugger : a debugger for o2
« Reply #24 on: June 03, 2018, 09:23:20 AM »
Roland,

Your messages are perfect! They are descriptive, informative, and precise to the most minute detail. Please keep up posting in this very style. I enjoy reading them all, even if I don't always respond. :)