Re: [BLACKBOX] Possible compiler bug ?

From: [at]} <luowy{>
Date: Tue, 20 Dec 2011 08:50:23 GMT

n��u��.&�I8������^x��:
��z{mʗ�{�V�
��z{S���}�ĝ��xjǺabout BB/Obern light weight source debugger:

I know the common interactive debuggers(delphi,C++)usually create
a new app(process) as debugger process!

But a BB/oberon module only run in a same process of the framework!


some idea about BB/Obern light weight source debugger:
If We can:
0, add a watcher for debugger thread in framework main loop;
1,add a new a debugg thread for this(or those)debugModelist,like Kernel.Try.
2,add a new marker type for breakpoint,compiler will output a trap instruction.
3,rewrite the Kernel.TrapHandler to hadle debuger trap: show source Caret,update
   stack trap view(var view,code view...), handle keyboard message....,
   
then we can do a debug task in framework:
1, choose debugModelist,set breakpoint(or single step debug).
2,Debuger.Try Module.Command
3, run to breakpoint(or single step debug),Debuger.TrapHandler take over work,after update it's stack view,jumpto framework loop, wait for
   keyboard shortcut to continue!
4,press F8,F7..for next breakpoint or sinle step..
5,stop the debug thread or Moudle.Command end or Debuger.Try end.
 

 p.s: single step use BB code file's ref block.


How to build a window's debugger ?? I have not any debugger knowledge.

welcome any suggestion!




 
----- ?? -----
???: Aubrey.McIntosh{([at]})nowhere.xy
? ?: Re: [BLACKBOX] Possible compiler bug ?
? ?: 2011?12?20? 10:28:46

The source debugger idea arises every few years. The members close to ETH express a fairly strong view that interactive debuggers lead to poor design practices, and that the trap viewer works very well. We found and fixed a compiler error in only a few email messages in 48 hours, this is astonishing.

I sometimes wonder about a special marker so that we can recompile a source to set (multiple) breakpoints, but an ASSERT(~debugThis IN debugModelist)works with the system as it is, preserves an audit trail. I put such constants in a bottom level module.

-- 
Aubrey McIntosh, Ph.D.
1502 Devon Circle
Austin TX 78723-1814
http://home.grandecom.net/~amcintosh/aubrey/Search/
----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})LISTS.OBERON.CH
n��u��.&�I8������^x��:
��z{mʗ���bq�b��
��z{m���}�ޝ��xjǺ
��z{C��h�+b�v���!���~)^���{\rtf1\ansi\ansicpg1252\fromtext \deff0{\fonttbl
{\f0\fswiss\fcharset0 Arial;}
{\f1\fmodern Courier New;}
{\f2\fnil\fcharset2 Symbol;}
{\f3\fmodern\fcharset0 Courier New;}
{\f4\fswiss\fcharset128 MS Mincho;}
{\f5\fswiss\fcharset134 SimSun;}}
{\colortbl\red0\green0\blue0;\red0\green0\blue255;}
\uc1\pard\plain\deftab360 \f0\fs20 about BB/Obern light weight source debugger:\par
\par
I know  the common interactive debuggers(delphi,C++)usually create \par
a new app(process) as  debugger process! \par
\par
But a BB/oberon module only run in a same process of the framework!\par
\par
\par
some idea about BB/Obern light weight source debugger:\par
If We can: \par
0, add a watcher for debugger thread in framework main loop;\par
1,add a new a debugg thread for this(or those)debugModelist,like Kernel.Try.\par
2,add a new marker type for breakpoint,compiler will output a trap instruction.\par
3,rewrite the Kernel.TrapHandler to hadle debuger trap: show source Caret,update\par
   stack trap view(var view,code view...), handle keyboard message....,\par
   \par
then we can do a debug task in framework:\par
1, choose debugModelist,set breakpoint(or single step debug).\par
2,Debuger.Try  Module.Command\par
3, run to breakpoint(or single step debug),Debuger.TrapHandler take over work,after update it's stack view,jumpto framework loop, wait for\par
   keyboard shortcut to continue! \par
4,press F8,F7..for next breakpoint or sinle step..\par
5,stop the debug thread or Moudle.Command end or Debuger.Try end.\par
 \par
\par
 p.s: single step use BB code file's ref block.\par
\par
\par
How to  build a window's debugger ?? I have not any debugger knowledge. \par
\par
welcome any suggestion!\par
\par
\par
\par
\par
 \par
\htmlrtf{\f4\fs20\htmlrtf0 ----- \'8c\'b4\'95\'b6 ----- \htmlrtf\f0}\htmlrtf0 \par
\htmlrtf{\f5\fs20\htmlrtf0 \'b7\'a2\'bc\'fe\'c8\'cb: Aubrey.McIntosh{([at]})ALUMNI.UTEXAS.NET \htmlrtf\f0}\htmlrtf0 \par
\htmlrtf{\f5\fs20\htmlrtf0 \'d6\'f7\'a1\'a1\'cc\'e2: Re: [BLACKBOX] Possible compiler bug ?\htmlrtf\f0}\htmlrtf0 \par
\htmlrtf{\f5\fs20\htmlrtf0 \'ca\'b1\'a1\'a1\'bc\'e4: 2011\'c4\'ea12\'d4\'c220\'c8\'d5  10:28:46\htmlrtf\f0}\htmlrtf0 \par
\par
The source debugger idea arises every few years. The members close to ETH express a fairly strong view that interactive debuggers lead to poor design practices, and that the trap viewer works very well. We found and fixed a compiler error in only a few email messages in 48 hours, this is astonishing.\par
\par
I sometimes wonder about a special marker so that we can recompile a source to set (multiple) breakpoints, but an ASSERT(~debugThis IN debugModelist)works with the system as it is, preserves an audit trail. I put such constants in a bottom level module.\par
\par
\par
\par
-- \par
Aubrey McIntosh, Ph.D.\par
1502 Devon Circle\par
Austin TX 78723-1814\par
http://home.grandecom.net/~amcintosh/aubrey/Search/\par
\par
\par
\par
----\par
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})LISTS.OBERON.CH}}n��u��.&�I8������^x��:

Received on Tue Dec 20 2011 - 09:50:23 UTC