AltME groups: search

When I see that "Very simple. Easy to debug. " in the http://www.rebol.net/wiki/Inclusion_Methods
, I am quite confused about the meaning. What is it that is easy 
to debug? (the DO function?)

hmm, but when I consider, that every build is actually ad hoc, then 
it means, that you have to debug many times, while in case of a standard 
method you just debug the method, not ad hoc script/s

so "easy to debug" versus "no debug"

Just an idea about ad hoc versus standard debugging: "standard" actually 
means a specialized dialect optimized for the purpose at hand (so, 
easy to debug by definition). Ad hoc script means a general purpose 
language using more than just DO and LOAD, since they do not suffice 
on their own.

Yeah, most extensions probably wouldn't involve too many files to 
manage and code should be easy to debug by printing to output. I 
never looked at D closely, but it does seem to be a really nice alternative 
to using C/C++.

ahhh... compiled using debug mode.!

ok.... this is going to take a few minutes... since I have to update 
the release mode so it has the same setup as the debug mode.

I am unable to get the external dll working when doing a Release 
level build.  it compiles without any errors... 


but when running the same script which is working in debug mode, 
I get this  error in the console:


** access error: cannot open: %opengl-cgr.dll reason: "not found 
or not valid"

very strange

oddly, in debug mode its 100% stable.

I've had that too, but changing the optimizing on Release mode, I 
have just about the same issue as Christian.


in debug mode I've *never* had a crash yet. even on very small or 
huge datasets.


so AFAICT its a dreary compiler issue, and the worst of it is that 
I can't debug it, cause it *only* crashes when I'm not in Debug.

Example; say you are trying to debug an app and you have to print 
the contents of a word to the screen.
say you set the word 'value to 10
displaying value to the console can be done by using; print value
returns the result; 10


where as using  "?? value " instead, would return the word name with 
the value of the word beside it
value: 10


This prevents you from needed to add debugging code like'
print ["Value: " :value]

I have written my first bit of code that is starting to do something 
useful.

All the bad bits are mine & all the good bits are from the help I 
have been given here.

My main intention is to start off with code that I can understand 
& develop so any criticism would be most welcome.


My next step is to remove the debug code & replace it with code that 
stores all the information in a structured form for searching & further 
analysis.
Thanks for all your help with this.

filename: copy %/c/temp/cisco.txt   ;; cisco config file
host: copy []
interface: copy []
intDescription: copy []
intIpAddress: []
ipRoute: []
IntFlag: false
spacer: charset " ^/"
name-char: complement spacer

lines: read/lines filename

foreach line lines [          ;; move through lines

 parse/all line [copy temp ["interface" to end] ( ;; evaluated if 
 "interface" found preceeded by nothing else
		interface: copy temp 
		print interface           ;; debug code
		IntFlag: true)   

 | copy temp2 [" desc" to end] (  ;; evaluate if " desc" found preceeded 
 by nothing else
		if IntFlag [print temp2]     ;; debug
	) 
	| copy temp3 [" ip address" to end] ( ;; " ip address"
		print temp3    ;; debug
	)
	| copy temp4 ["hostname" to end] ( ;; "hostname"
		print temp4      ;; debug
	)

 | copy temp5 [name-char to end] ( ;;  any char except space or newline. 
 this must be last 
;		if IntFlag [print temp5]      ;; debug
		if IntFlag [print "!"]      ;; debug
		IntFlag: false
	)
	] 
]

;######################################

 the input file contains these lines which are extracted (except the 
 !) plus it has a load more lines that are ignored at the moment.

hostname pig
interface Null0
!
interface Loopback58
 description SLA changed this
!
interface ATM0
!
interface ATM0.1 point-to-point
!
interface FastEthernet0
 description my first port
!
interface FastEthernet1
 description test1
!
interface FastEthernet2
 description test2
!
interface FastEthernet3
!
interface Dot11Radio0
!
interface Vlan1
 description User vlan (only 1 vlan allowed)
!
interface Dialer0
 description $FW_OUTSIDE$
 ip address negotiated
!
interface BVI1
 description $FW_INSIDE$
 ip address 192.168.0.1 255.255.255.0
!
!########### end ##########

I have tried to understand & take on what I have been told, thanks. 
Is this worse or better. It does what I was looking to do & I know 
how to extend it in the same structure.  I am sure it would be educational 
for me if anyone has time to tear it to shreds please.


Should I stop using read/line now?  Would I get the benefit still? 
Or is the requirement too fragmented for this approach now?
Should I use functions anywhere instead?
Have I initialised my variables in the right & appropriate way?

filename: copy %/c/temp/cisco.txt   ;; cisco config file
outFile: copy %/c/temp/outFile.log  ;; tab separated output
hostname: copy []
interface: copy []
intDesc: copy []
intIpaddr: []
ipRoute: []
IntFlag: false
spacer: charset " ^/"
name-char: complement spacer

lines: read/lines filename


outInterface: [ write/append outFile reduce 

 [filename tab i tab hostname tab interface tab intDesc tab intIpaddr 
 newline]
]

clearInterface: [
	interface: copy []
	intDesc: copy []
	intIpaddr: []
]


interfaceRule: [ ["interface " copy temp-interface to end] (   ;; 
captures point-point as well

  if IntFlag outInterface           ;; start of new interface section 
  so output data collected previously.
		if IntFlag clearInterface        
		interface: copy temp-interface
		print ["! found at line " i]      ;; debug
		print current-line                ;; debug
		IntFlag: true
	)
]

descRule: [ [" description " copy intDesc to end] (  
		if IntFlag [print current-line]     ;; debug
	)
]
	
ipAddrRule: [[" ip address " copy intIpaddr to end] ( 
		print current-line                  ;; debug
	)
]

hostnameRule: [["hostname " copy hostname to end] ( ;; "hostname"
		print current-line                  ;; debug
	)
]

iprouteRule: [copy iproute ["ip route" to end] ( ;; "ip route"
		print current-line                  ;; debug
	)
]



IntFlagRule: [copy tempZZ [name-char to end] ( ;; not space or newline. 
this must be out of the int section

  if IntFlag outInterface      ;; end of interface section so output 
  data collected.
		if IntFlag clearInterface
		if IntFlag [print "!"]       ;; debug
		IntFlag: false               ;; 
	)
]

i: 0


foreach line lines [i: i + 1 ;; move through lines & track line number
	current-line: line       ;; for debug output
	parse/all line [         ;; parse only using rules below

  interfaceRule        ;; evaluated if "interface" found preceeded 
  by nothing else

  | descRule           ;; evaluate if " desc" found preceeded by nothing 
  else
		| ipAddrRule         ;; " ip address"
		| hostnameRule       ;; " hostname"
		| iprouteRule        ;; "ip route"

  | IntFlagRule        ;; unset interface flag if no longer in interface 
  section (no " ^/")
	] 
]

I don't have the time right now to debug the whole of it though... 
 ':-/

I have the same makedoc version 2.5.7 and view 1.3.2.3.1. I've tried 
that exact example as well though with verbose on I am seeing an 
error:

** Script Error: copy expected range argument of type: number series 
port pair
** Where: debug
** Near: copy/part here find here newline

Sorry, I came to the parse dialect from a history of using and making 
parser generators. It's annoying that the behavior of parse and the 
tricks you can use to optimize your parse rules have all of these 
arcane CS terms referring to them. At least the parse dialect is 
a lot more flexible than most of those parser generators, and easier 
to write, use and debug too.

I have a mysql wrapper that I use in production but haven't released 
because it need cleaning and docs, but if there is interest I could 
release for testing as is. id does things like:

print .db/get/all/sort/debug [mailing/m mailingLog/ml] [ml.dc m.email 
ml.url] [{ml._mailing=m.id}] [m.email asc ml.dc desc]

SELECT `ml`.`dc`,`m`.`email`,`ml`.`url` FROM `mailing` `m`,`mailingLog` 
`ml` WHERE ml._mailing=m.id ORDER BY `m`.`email`,`ml`.`dc` DESC
print .db/set/debug 'mailing 12 reduce['active false] 
UPDATE `mailing` SET `active`=0 WHERE id=12.0

print .db/get/all/flat/debug '_node_tree [_node _media] [{_tree=? 
AND _issue=?} 5443 22]

SELECT `_node`,`_media` FROM `_node_tree` WHERE _tree='5443' AND 
_issue='22'
..

James: sorry for the delay, still not found time for docs but her 
it is "as is.."  /debug is your friend, get started, load Dock driver 
, then load  http://reboot.ch/rebol/mysql-wrapper.txtthen:
;set a list of connections:
.db/databases: [
  ;local
  mydb1.local mysql://user:[password-:-127-:-0-:-0-:-1]/mydb1
  mydb2.local mysql://user:[password-:-127-:-0-:-0-:-1]/mydb2

  ;online
  mydb1 mysql://user:[password-:-127-:-0-:-0-:-1]:3307/mydb1
  mydb2 mysql://user:[password-:-127-:-0-:-0-:-1]:3307/mydb2
]
;use a db (if not open will open it automatically):	
.db/use 'mydb1

;without wrapper:
do http://softinnov.org/tmp/mysql-protocol-41.r
db: open mysql://localhost/db1
nodes: send-sql/named {SELECT `id` `name` `data` FROM `node`}

node: send-sql/named {SELECT `id` `name` `data` FROM `node` WHERE 
`id`='1'}

;with wrapper:
do http://softinnov.org/tmp/mysql-protocol-41.r
do http://reboot.ch/rebol/mysql-wrapper.txt
.db/databases: [
	db1 mysql://localhost/db1
	db2 mysql://localhost/db2
]
.db/use 'db1
nodes: .db/get/all 'node [id name data] none
node: .db/get 'node [id name data] [{`id`=?} 1]
;if you follow the rule to name your primary-key "id",
;you can use this shorter version:
node: .db/get 'node [id name data] 1

;/debug is your friend, use it to see the generated query

.db/get/debug 'node 'id 1   
;   "SELECT `id` FROM `node` WHERE id=1.0 LIMIT 0,1"

use /debug it will print query to the console without sending it 
to the server so you can play and understand how it works

On second thought, that wouldn't help. Try adding a few -j LOG rules 
to help debug.

Yeah I started looking at the code. It's a bit hard to debug for 
me though. The error doesn't give any line number, it just says "near 
show main". I searched for "show main" and found three occurances 
in the source. I'm completely new to REBOL so going through everything 
in the code would take me quite some time without being able to narrow 
it down first because everything looks alien to me and I have to 
look it up to see if something in the script looks wrong. Is there 
some good tutorial available on debugging REBOL code? Or is there 
some trick to find out the last line that was executed? I do have 
access to the terminal at that point, the view is frozen but the 
terminal still accepts commands.

During boot of Kubuntu 7.10 linux, I noticed a message that flashed 
by, something like
... corrupt .. not cleanly unmounted(?)... 

I checked all the logfiles listed by syslogd-listfiles -a and didn't 
find "corrupt" or "clean" in any of them.
These are the files I checked:
$ lsa `syslogd-listfiles  -a`
-rw-r----- 1 syslog adm  10197 2010-07-09 17:04 /var/log/auth.log

-rw-r----- 1 syslog adm 190194 2010-07-09 16:02 /var/log/daemon.log
-rw-r----- 1 syslog adm 119543 2010-07-09 15:56 /var/log/debug
-rw-r----- 1 syslog adm 210453 2010-07-09 15:56 /var/log/kern.log
-rw-r----- 1 syslog adm 191106 2010-07-09 17:02 /var/log/messages
-rw-r----- 1 syslog adm   8051 2010-07-09 17:02 /var/log/syslog
-rw-r----- 1 syslog adm   3580 2010-07-09 15:56 /var/log/user.log

I'd like to know the way to capture those boot messages.
Any ideas?

A report about my adventures:

sudo aptitude install libxaw7 libxmu6
[sudo] password for gouslar: 

0 packages installed, updated or deleted. 0 bytes of archives received.
Ok
sudo aptitude search libxaw7 libxmu6

i A libxaw7                         - X11 Athena Widget library  
               

p   libxaw7-dbg                     - X11 Athena Widget library (debug 
package) 

p   libxaw7-dev                     - X11 Athena Widget library (development 
hea

i A libxmu6                         - X11 miscellaneous utility library 
        

p   libxmu6-dbg                     - X11 miscellaneous utility library 
(debug p
Ok
sudo ldconfig
Ok
ldd 042/altme 
...
	libXaw7.so.7 => not found
	libXmu.so.6 => not found
...
Ok
ls /usr/lib/i386-linux-gnu/libXmu*
No such file(s).
Ok
ls /usr/lib/i386-linux-gnu/libXaw*
No such file(s).
Ok

Then, I installed rebol-2.7.8.4.3-4.amd64.deb from maxvessi.net.

(GTK-DEBI installer was saying to 47 additional packages, then it 
hung before downloaded anything. I killed some processes it created. 
Then I re-ran gdebi, it said all dependencies of 'rebol' are satisfied 
and installed 'rebol' quickly.)

Then, I re-ran:

ldd 042/altme 
...
	libXaw7.so.7 => not found
	libXmu.so.6 => /usr/lib32/libXmu.so.6 (0xf75c3000)
...
Ok
sudo aptitude install libXaw7 libxaw7-dbg libxaw7-dev
...it installed 21 new package...
Ok
ldd 042/altme 
...
	libXaw7.so.7 => not found
...
Ok
042/altme 

altme: error while loading shared libraries: libXaw7.so.7: wrong 
ELF class: ELFCLASS64
Ok

josh negative size for a line .... the issue no one would imagine. 
 lol but a good debug  lol this kind of issue can be really annoying 
for an miss parsing of the SVG data content for example -> crash 
so you  stend lot of hours trying to see if the crash comme from 
your SVG renderer engine from the SVG file or from rebol or from 
the engine or rebol/view VM ^^ you are right a message comming fromt 
the VM like "Error the size entrer for the lline is negative  " isntead 
of the vm crash would be nice  ^^

Not here. In the browser i trust me, so i disable the save-question. 
On my side, i could start script immediate, instead of showing first. 
But for a debug-demo i prefer feedback :)

it looks at user-prefs [ debug ] ...

I'll have to debug now to handle whatever changed in Rebol to cause 
it to stop working.

Doesn't the Official Guide have a "debug loader" that islotes the 
missing bracket to the nearest object/function?

The order of the include files seems to have an effect the error...


I moved the rebol mezz functions to the begining and now I get this 
error:

** Script Error: user-prefs has no value
** Where: vbug
** Near: if not dbg: user-prefs/debug [exit]

so, if encapping anything with view

user-prefs: [ debug: false ]

** Script Error: user-prefs has no value
** Where: vbug
** Near: if not dbg: user-prefs/debug [exit]

Graham suggested: user-prefs: [ debug: false ]

 I tried Gahams suggestion but I get another error:
** Script Error: Invalid path value: debug
** Where: vbug
** Near: if not dbg: user-prefs/debug [exit]

user-prefs: make object! [ debug: false ]

I did not make it an object! Just had user-prefs: [debug: false]

Works now!

Thanks again Graham!

what have you tried so far to debug this?

Why only that computer and only when encapped is my question..


The work computer is FDNY property and locked down somewhat so its 
hard to debug if its the computer's issue...

What is the best way to debug software made with the SDK?

i removed some debug instructions, it's a little more faster now. 
Don't forget i have to rewrite the video emulation too. So it will 
be definitivly faster (i hope).

It was harder to debug Icon than any other language I've used. Not 
because the language required you to be smarter, but because error 
handling was badly designed. It always seemed ironic to me: In a 
language where "failure" was the name of a common control flow, real 
failure wasn't handled very well.

I was a big fan of Icon back before there was REBOL, but that goal-directed 
evaluation made Icon harder to debug than any other language in practical 
use, including assembler. That experience made it a lot easier to 
write PARSE code though :)

Chrome will have more traction with normal people. FF is still geek 
driven. In that regard, IE has more to worry about. FF has to worry 
if Chrome becomes better for geeks, e.g. dev, debug, extend. 


Both could benefit from its source and how they all decide to cooperate. 
If they decide to compete with Google, it will make a lot more work 
for them, and how they spin things will be important.

There was an article today on IE8's performance, which was cited 
as horrible, twice as slow as IE7, but I'm not trusting this source 
yet, as they could have been testing a debug build

All of the beta builds are debug builds, AFAIK.

To do this probably requires some extra style modes. Given the design 
of the R3 GUI, you can add special abilities globally to styles, 
such as the current debug red rectangle. You can probably add some 
actors to alter the behavior of styles to be suitable for a GUI editor.

THAT would be damn hard to debug.

Liquid has been tested under R3 and crashes it outright.  so R3 support 
for liquid will wait until R3 is a bit more stable, unfortunately. 
 I have enough stuff to debug without having to wonder if its the 
platform that's causing the bugs in the first place.

If you can confirm that it works for you under XP, then you can try 
Vista.  Must surely make it easier to get it working first before 
trying to debug it

No.  I wasn't sure where to begin to debug this.

Do you launch Cheyenne with root privileges (for <1024 listen ports) 
? Use this command line to debug : ./cheyenne -vvv

Just as a reminder for those currently using Cheyenne/RSP, you can 
add the DEBUG keyword in your webapp config section in %httpd.cfg 
to display a menu with useful debugging info.

Although it is possible to take advantage of multi-core technology 
by running several applications processes in parallel, the real benefit 
would be for multi-threaded applications. The challenge then is to 
change single-threaded or sparsely threaded applications into multi-threaded 
and also to debug them.

Erlang has unique properties for taking 
advantage of multi-core technology
One of the fundamental properties 
of the Erlang language is built-in support for very light-weight 
processes, each with its own memory, and using explicit message passing 
for their communication. Because of this most applications written 
in Erlang are realized as a number of cooperating Erlang processes 
representing something in the problem domain of the application, 
for example active call sessions, connections or transactions. Typically 
this will result in many thousands of simultaneously executing processes 
in a heavily loaded application.

The parallelism already present 
in most Erlang applications makes them ideal for taking advantage 
of multi-core technology, without there being any need to modify 
them.

The only thing needed is an Erlang virtual machine (VM) which 
works in a multi-threaded way, and that is what we now are releasing 
in Erlang/OTP R11B.

I had to use a hex editor to debug this

Trying to debug other people's RSP errors where the client doesn't 
record them :(

Production vs Debug mode. In Production mode, when an RSP error occurs, 
Cheyenne displays a general error page (or a custom one if defined 
in config file) and logs the error on server.

Doc, is it this line here to increase the nymber of helper processes?

			shared/pool-max: any [all [flag? 'debug 0] 8]

This is not so good then .. is there a way we can debug this?

You could put a couple of debug lines around your call/wait and log 
them to a file to see if your CALL always returns.

Not crashed since Thursday .. so can't debug.

pool-max value should be changed in %cheyenne.r (shared/pool-max: 
any [all [flag? 'debug 0] 8]). Just replace the 8 value by the new 
value. It's not yet exposed in %httpd.cfg file.

For debugging purpose, start cheyenne with the -debug command-line 
option, it forces RSP to reload everything at each request.

The debug mode is also very nice, catching before redirecting also 
helps a lot

If you have propositions for improving the debug mode, I'll be glad 
to hear them. 


I'm currently working on a new Cheyenne release with a big cleanup 
of all debug and error logging done by background RSP processes. 
It will basically generate only 2 log files : error.log and debug.log. 
You'll be able to send content to debug.log file using some functions 
like : 

- debug/print data

- ?? word

New Cheyenne 0.9.19 beta version available for testing at : http://cheyenne-server.org/tmp/cheyenne-r0919.zip


Tested only on Windows  (my Linux image network has currently some 
issues).

ChangeLog (diff-ed from last test version) :


 o RSP: an HTTP redirection in 'on-page-start won't evaluate the page 
 script anymore.
	

 o CGI: mezz function READ-CGI now patched to be compatible with Cheyenne. 
 That's
	  the right way of reading POST data in REBOL CGI scripts.
	  
	o RSP: fixed a bug in session/add when setting a block! value.
	

 o Task-handler: fixed a network error on first packet read (high 
 load + fast hardware).
	

 o Task-handler: TCP keepalive mode activated (test workaround half-closed 
 connections).
	
	o Task-master: 
			o 'no-delay mode removed and replaced by 'keep-alive mode

   o now forks a new process as soon as one dies (not waiting for a 
   new request)

   o fix a long standing bug in queued job module name mismatching (can 
   happen under extreme load)
			o minor code cleanup
	

 o Uniserve: 'no-delay TCP network mode now switched off for all connections. 
 Fixes a

   stability issue on Vista and probably on UNIX with very high load.


 o RSP: fix a bug in 'decode-multipart when there's no file received.
	

 o UniServe: new logger service. Now all info or error logs, and debug 
 messages from

   CGI/RSP scripts are written in %trace.log. Additionnaly, you can 
   now log messages
	  using :
	  
	  		- debug/print msg 	; msg [string!]
	  		- debug/probe value 	; any mold-able value
	  		- ?? word		; works like REBOL's '?? function
	  		- ? msg		; alias for debug/print
	  

 o RSP: in debug mode, page generation time and SQL queries stats 
 now added at bottom
	  of pages.
	  
	o RSP: error in events from %app-init.r now logged.
	

 o RSP: fix a rare RSP freezing issue when an error occurs in %RSP.r 
 (for example, by
	  a user script that breaks RSP sandbox).
	  

 o RSP: sanboxing now protects from Exit/Return/Break calls made outside 
 of a
	  function context.
	  
	o RSP: %misc/rsp-init.r file removed.
	

 o RSP/CGI: New config keyword added in global sections : 'worker-libs. 
 It lists the

   librairies to load when a worker process is started. An optional 
   'on-quit section can

   be added to call cleanup code when the process quits. Examples :
	  
	  		worker-libs [
				%libs/mysql-protocols.r
				...
			]
		or	
			worker-libs [
				%libs/mysql-protocols.r
				...
				on-quit [
					%/libs/free-resources.r
				]
			]
	

 o Task-master: now you can reset all worker processes without stopping 
 Cheyenne. This

   is usefull when you need to force non-RSP/CGI files reload (helper 
   scripts, 3rd party
	  librairies,...). 
	  
	  	Usage:
	
			Windows : tray icon -> Reset Workers
		

   UNIX : kill -s USR1 <pid>	(<pid> is Cheyenne's main process ID)
	 
	 

  o Added a -w command line option to set the worker processes number. 
	 
	   	Usage:
	   
	  		$ cheyenne -w <n>		(n [integer!] : CGI/RSP process number)
	   

    Use -w 0 to help debug CGI/RSP code by resetting worker processes 
    after each request.
	   (it's like calling "Reset workers" after each request).

Command line option -debug has been replaced by -w 0

It's something like framework... if you check the httpd.cfg, you 
can see something like:
webapp [
	virtual-root "/testapp"
	root-dir %www/testapp/
	auth "/testapp/login.rsp"
	;debug
]

When you that access the server with starting with the virtual-root, 
it's proccessed by Cheyenne using the %www/testapp/app-init.r file 
where are several handlers which are processed by the process. So 
you don't have to for example think how to update session time etc.

Cheyenne serves static resources from the main process (UniServe 
process), but CGI and RSP are executed by pre-forked worker processes. 
So yes, writing to the same file from RSP script can be an issue 
if you don't have a mean to ensure that write accesses are serialized. 
I had that issue recently for RSP log/debug file, I had to build 
a small logger service in the main process to be able to serialize 
 write access (after stress testing different file locking solutions 
from REBOL, no one seemed reliable enough to me). 


I thought about adding a synchronization service in Cheyenne that 
could be used to (but not only) address the write file sync issue. 
That could work for low sync needs (like writing to a file once every 
few seconds), but for massive sync needs (dozens or hundreds of sync 
req/s), I'm afraid that the TCP port overhead would be too costly...(maybe 
a separate sync server process with persistent TCP connections could 
be good enough even for heavy uses?)

Graham: you can set your webapp (or at domain level) in debug mode 
(using the 'debug keyword in config file). If the debug mode could 
be tested, it could allow you to enable/disable the captcha system 
(or anything else) based on the working mode (debug / in production). 
I'll add that to the todo list also.

That could be already tested right now, thought. Just use : 

debug?: to-logic find request/config 'debug

(the 'on-page-start handler could be a good place for that)

Is there anything I can do to debug what is going on?

If there's nothing I can do to debug this, I'll restart cheyenne

That's for the example, you can drop it. It's not needed anymore, 
the timings are now (from 0.9.19) automatically inserted by the RSP 
engine in debug mode (when DEBUG keyword is found in the webapp config 
block).

DEBUG: I'm I right that the newest version doesn't send a Rebol error 
to the client anymore? How can I re-enable this "feature" for non-web-app 
pages?

Something like: debug: true?

DEBUG: you're right. You can re-enable that by adding a DEBUG keyword 
in httpd.cfg in domain or webapp config block..

DEBUG: Can I enable it via a RSP API call or a flag for just a specific 
RSP file?

Try adding this line at the beginning of the RSP script (it shouldn't 
affect other scripts) : 

debug-banner/active?: yes

Is debug-banner page-local or app-local?

DEBUG: I tried the debug-banner stuff but it doesn't work.

** Script Error : debug-banner has no value 
	** Where: rsp-script 

	** Near:  [debug-banner/active?: yes

Prefixing it with debug/ doesn't work as well.

It looks like it's more complicated to activate the debug mode from 
within a RSP script than it seemed first.

Btw, you can run Cheyenne in verbose mode (-vvv or even -vvvvv), 
it's easier to debug this way. During the boot process, Cheyenne 
will list mods callback matrix allowing you to see/debug the execution 
order for your mod's callbacks.

I am porting an app to the latest cheyenne, I tried -vv and -vvv 
and uncommented the debug option in cfg file but I can't make output 
+ error  -- in case of error - show up in the browser. I saw trace.log 
and chey-pid*.log but that doesn't help me debug current case. Is 
there a way to show in browser while developing?

For showing errors in the browser, just put the DEBUG keyword in 
the webapp config block.

Hi Doc. I am "porting" to 0.9.19 , the main thing that was causing 
causing the confusion since I didn't yet fully get it  was that "do" 
inside one of  another file that was "do-ed" didn't seem to use path 
relative to the that file but to web-app and before that wirtualroot 
property wasn't correct, I added the folder below root path.. now 
it works, and debug makes the whole output visible so I made it work 
better also.

But I have one really really big request for future if it's not yet 
possible :) could you make another flag besides debug (like devel) 
that would not add the debug info bar to webpages but would just 
show the error output in case of it (yer olde way - without the debug) 
.. or is this somehow possible to set up already?

I will survive if I have to be in debug mode all the time :) I thought 
it will add some output to ajax responses too and make them unworkable 
but you seem to thought of this :)

The debug menu is inserted is a </head> or <body> tags are found 
in the output. Most of Ajax responses are either JSON data or HTML 
snippets (not reloading the whole page, so without <body> tag), so 
they're not modified.

There's no way to have the debug mode without the debug menu currently, 
but it should be easy to add an option to define the debug level. 
I'm adding that to v0.9.20 todo list (scheduled for releasing before 
the end of this month).

just one detail idea for improvement .. when you intercept redirection 
in debug mode you can use javascript to set focus on the link to 
continue already so developer just presses space or enter and it 
continues. No need to leave keyboard for mouse or to press tab tab 
tab .. enter :)  
document.getElementById('java2s').focus()

but sounds also the most awesome stability feature :) ... I looked 
at it, I will again .. this is a simple app at the end so I can test 
it quickly 


so I won't only criticise the new debug/log functionality ... for 
having it on server it's awesome that the trace log is made so I 
can just look at it and see it there were any errors for users, etc 
.. for that endo of the deal it's great

Doc.. just a tiny bug report.. when I am working with latest version 
in debug mode firebug reports me javascript warning: I haven't been 
digging into if this is supposed to be a bug or intentional...
>> test for equality (==) mistyped as assignment (=)?

>> [Break on this error] if (node = document.getElementById('menu' 
+ id)) {\n

Max: trace.log is only used in verbose mode or in RSP debug mode. 
Access logs are available in %log/ folder (either in Cheyenne's home 
folder or in folder defined with LOG-DIR config keyword).

Try debug/probe instead.

debug/probe mold spec
 inserted on the first line...

got debug/probe working now. it definitely stops at 'send-confirmation.

oh that's it. I just need to fill that function up with debug/probes 
and it works. :-) got a mail now.

I think we unearthed a lot of things that we otherwise would just 
bump into along the way, anyway. I'm still not safe on the email 
issue, as the debug lines are still present.