Settings DebuggerSettings - Versionsgeschichte

Sv: Weiterleitung nach Settings DebuggerSettings/en erstellt

2015-12-08T17:17:53Z

Weiterleitung nach Settings DebuggerSettings/en erstellt

← Nächstältere Version		Version vom 8. Dezember 2015, 17:17 Uhr
Zeile 1:		Zeile 1:
	#redirect [[ Settings DebuggerSettings ]]		#redirect [[ Settings DebuggerSettings/en ]]
	[[Category: Incomplete]]		[[Category: Incomplete]]
	[[Category: Empty]]		[[Category: Empty]]

Sv: Weiterleitung nach Settings DebuggerSettings erstellt

2015-12-08T17:17:36Z

Weiterleitung nach Settings DebuggerSettings erstellt

← Nächstältere Version		Version vom 8. Dezember 2015, 17:17 Uhr
Zeile 1:		Zeile 1:
	== ~~Debugger~~ Settings ==		#redirect [[ Settings DebuggerSettings ]]
		⚫	[[Category: Incomplete]]

			[[Category: Empty]]
	=== Overview ===

	These settings control if a debugger is to be shown when
	errors, exceptions and breakpoints are encountered.
	For free running tests (and also, if expecco is executed under the control of
	another QM master), these flags should be off. In that case, breakpoints are
	ignored and errors/exceptions lead to the corresponding activity/testcase
	to fail.

	However, during test development, the debugger is a very useful tool which
	helps alot in finding errors inside the testsuite itself.
	You will probably want to enable the debugger then.

	Notice, that the individual block test/demo execution offers two run buttons,
	one using the settings as set in the expecco settings (i.e. the same that will
	be active when the suite is executed as a whole),
	and another (with a little bug in its icon), which enables debugging,
	no matter what was specified in the settings.

	During test development, you will usually want to use that debug-run.


	=== Debug all Exceptions ===
	Controls if a debugger should be opened for all exceptions;
	this includes internal notifications, such as inconclusive, success and failure notifications.
	Also, this affects the behavior for non-coded elementary actions.
	With this flag on, executions behave the same as if started with the
	"Debug-Run"-button: [[Datei:RunWithDebugger.gif]]

	=== Debug Activity Code ===
	Controls if a debugger is opened for errors/exceptions which happen while
	an activities' elementary code is being executed.
	This only applies to user-coded elementary actions (i.e. those with Smalltalk or JavaScript code).
	No debugger is opened for errors in remote procedure calls.
	Also, no debugger is opened if the exception is handled or ignored by the current activity.


	=== Debug Handled Exceptions in Activity Code ===
	Controls if a debugger is opened for errors/exceptions which happen while
	an activities' elementary code is being executed.
	This only applies to user-coded actions (i.e. those with Smalltalk or JavaScript code).
	No debugger is opened for errors in remote procedure calls.


	=== Debug Pin Value Type ===
	Controls if a debugger is opened if the output value for a pin is not compatible
	with the pin's datatype. This is checked during execution.


	=== Debug 'halt' Messages ===
	By placing a "<CODE>halt()</CODE>" call into your code, explicit (programmed) breakpoints can be added
	to your elementary code. Typically, this is a statement like "<CODE>this.halt()</CODE>" or simply "<CODE>halt()</CODE>"
	in JavaScript, or "<CODE>self halt</CODE>" in Smalltalk code.
	This flag controls if a debugger is opened when such a program breakpoint is reached.
	For debugging, these halts can be put into elementary code, where a debugger is opened
	for single stepping or to look at the activities' local variables. For real test execution,
	halts should be disabled.
	The default is to ignore halts.

	=== Allow Empty Compound Activities (no Steps) ===
	Controls if empty compound actions (i.e. unimplemented) are reported as an error.

	=== Debug Expecco ===
	Controls if a debugger is opened for errors/exceptions which happen inside
	expecco itself (i.e. not related to user-written activity code or test execution).
	In the best of all worlds, there are no such events, but well...
	This should normally only be turned on by the expecco development team.

	=== Suspend Actions while a Debugger is Open ===
	If checked (which is the default), new activities are blocked from being executed
	in parallel, whenever a debugger is already open.
	This prevents the popping of many debuggers, if there is an error (or an explicit halt)
	in a step's activity, which is triggered multiple times. Especially, if it is triggered
	by incoming streamed values.

	You should only uncheck this, if you are about to debug producer/consumer scenarios,
	in which you want to single step through multiple activities in parallel.


	=== MessageTally on Execution ===
	If checked, execution times of elementary activities are measured and
	an execution profile is generated after the execution (on the Transcript window).
	This is useful to find out where time is spent for performance optimizations.


⚫	[[Category:~~Settings~~]]

Cg: /* Debug all Exceptions */

2014-04-09T18:41:56Z

Debug all Exceptions

← Nächstältere Version		Version vom 9. April 2014, 18:41 Uhr
Zeile 28:		Zeile 28:
	Also, this affects the behavior for non-coded elementary actions.		Also, this affects the behavior for non-coded elementary actions.
	With this flag on, executions behave the same as if started with the		With this flag on, executions behave the same as if started with the
	"Debug-Run"-button: [[Datei:~~Beispiel~~.gif]]		"Debug-Run"-button: [[Datei:RunWithDebugger.gif]]

	=== Debug Activity Code ===		=== Debug Activity Code ===

Cg: /* Debug all Exceptions */

2014-04-09T18:41:24Z

Debug all Exceptions

← Nächstältere Version		Version vom 9. April 2014, 18:41 Uhr
Zeile 28:		Zeile 28:
	Also, this affects the behavior for non-coded elementary actions.		Also, this affects the behavior for non-coded elementary actions.
	With this flag on, executions behave the same as if started with the		With this flag on, executions behave the same as if started with the
	"Debug-Run"-button: [[Datei:Beispiel.~~jpg~~]]		"Debug-Run"-button: [[Datei:Beispiel.gif]]

	=== Debug Activity Code ===		=== Debug Activity Code ===

Cg: /* Debug all Exceptions */

2014-04-09T18:39:00Z

Debug all Exceptions

← Nächstältere Version		Version vom 9. April 2014, 18:39 Uhr
Zeile 28:		Zeile 28:
	Also, this affects the behavior for non-coded elementary actions.		Also, this affects the behavior for non-coded elementary actions.
	With this flag on, executions behave the same as if started with the		With this flag on, executions behave the same as if started with the
	"Debug-Run"-button: ~~<IMG ALIGN=top SRC="runWithDebug_button.gif">~~.		"Debug-Run"-button: [[Datei:Beispiel.jpg]]



	=== Debug Activity Code ===		=== Debug Activity Code ===

Cg am 9. April 2014 um 18:38 Uhr

2014-04-09T18:38:15Z

← Nächstältere Version		Version vom 9. April 2014, 18:38 Uhr
Zeile 86:		Zeile 86:
	an execution profile is generated after the execution (on the Transcript window).		an execution profile is generated after the execution (on the Transcript window).
	This is useful to find out where time is spent for performance optimizations.		This is useful to find out where time is spent for performance optimizations.


			[[Category:Settings]]

Cg: Die Seite wurde neu angelegt: „== Debugger Settings == === Overview === These settings control if a debugger is to be shown when errors, exceptions and breakpoints are encountered. For fre…“

2014-04-09T18:37:38Z

Die Seite wurde neu angelegt: „== Debugger Settings == === Overview === These settings control if a debugger is to be shown when errors, exceptions and breakpoints are encountered. For fre…“

Neue Seite

== Debugger Settings ==

=== Overview ===

These settings control if a debugger is to be shown when
errors, exceptions and breakpoints are encountered.
For free running tests (and also, if expecco is executed under the control of
another QM master), these flags should be off. In that case, breakpoints are
ignored and errors/exceptions lead to the corresponding activity/testcase
to fail.

However, during test development, the debugger is a very useful tool which
helps alot in finding errors inside the testsuite itself.
You will probably want to enable the debugger then.

Notice, that the individual block test/demo execution offers two run buttons,
one using the settings as set in the expecco settings (i.e. the same that will
be active when the suite is executed as a whole),
and another (with a little bug in its icon), which enables debugging,
no matter what was specified in the settings.

During test development, you will usually want to use that debug-run.

=== Debug all Exceptions ===
Controls if a debugger should be opened for all exceptions;
this includes internal notifications, such as inconclusive, success and failure notifications.
Also, this affects the behavior for non-coded elementary actions.
With this flag on, executions behave the same as if started with the
"Debug-Run"-button: <IMG ALIGN=top SRC="runWithDebug_button.gif">.

=== Debug Activity Code ===
Controls if a debugger is opened for errors/exceptions which happen while
an activities' elementary code is being executed.
This only applies to user-coded elementary actions (i.e. those with Smalltalk or JavaScript code).
No debugger is opened for errors in remote procedure calls.
Also, no debugger is opened if the exception is handled or ignored by the current activity.

=== Debug Handled Exceptions in Activity Code ===
Controls if a debugger is opened for errors/exceptions which happen while
an activities' elementary code is being executed.
This only applies to user-coded actions (i.e. those with Smalltalk or JavaScript code).
No debugger is opened for errors in remote procedure calls.

=== Debug Pin Value Type ===
Controls if a debugger is opened if the output value for a pin is not compatible
with the pin's datatype. This is checked during execution.

=== Debug 'halt' Messages ===
By placing a "<CODE>halt()</CODE>" call into your code, explicit (programmed) breakpoints can be added
to your elementary code. Typically, this is a statement like "<CODE>this.halt()</CODE>" or simply "<CODE>halt()</CODE>"
in JavaScript, or "<CODE>self halt</CODE>" in Smalltalk code.
This flag controls if a debugger is opened when such a program breakpoint is reached.
For debugging, these halts can be put into elementary code, where a debugger is opened
for single stepping or to look at the activities' local variables. For real test execution,
halts should be disabled.
The default is to ignore halts.

=== Allow Empty Compound Activities (no Steps) ===
Controls if empty compound actions (i.e. unimplemented) are reported as an error.

=== Debug Expecco ===
Controls if a debugger is opened for errors/exceptions which happen inside
expecco itself (i.e. not related to user-written activity code or test execution).
In the best of all worlds, there are no such events, but well...
This should normally only be turned on by the expecco development team.

=== Suspend Actions while a Debugger is Open ===
If checked (which is the default), new activities are blocked from being executed
in parallel, whenever a debugger is already open.
This prevents the popping of many debuggers, if there is an error (or an explicit halt)
in a step's activity, which is triggered multiple times. Especially, if it is triggered
by incoming streamed values.

You should only uncheck this, if you are about to debug producer/consumer scenarios,
in which you want to single step through multiple activities in parallel.

=== MessageTally on Execution ===
If checked, execution times of elementary activities are measured and
an execution profile is generated after the execution (on the Transcript window).
This is useful to find out where time is spent for performance optimizations.