World: r3wp

What I need is a utility that will take a rebol script, and parse 
it out by function, attempting to intepret it until it reaches an 
error.

ok i do it now

hehe

With forth, you could at least tell by the words in the dictionary 
where things had gone sour

I've spent the last hour trying to find this unmatched bracket

We could use a static analyzer, like LLVM has:

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/9

It took you an hour?! What technique were you using to find the missing/extra 
bracket?

binary chop

doesn't work well when your gui code is about 10k long

I use bracket matching in Notepad++, and a little patience. Still 
slow, but not that slow.

Hmm. I find it hard to visualize how it could take so long.

shall I send you a picture of me tearing my hair out??

help the visualization process a little

That would be definitive.

:)

this is where dividing code in smaller bits helps as well as an easy 
to debug startup procedure :-)

%synapse.r is large by REBZOL standards.

I am using notepad++ at present to do the binary chop

(sorry, I'm having a typo day)

Actually Henrik, it is composed of 1000s of nodes of small amounts 
of code .. which is reassembled to the final source.  But I don't 
have a way of syntax checking each node.

finally found it!

One of the reasons I don't like code being mixed with GUI display 
elements.

Is your code in strings? Because otherwise you can just use LOAD 
to syntax check your program..

I get a stack overflow when I run the source from the interpreter

so I can't use that method.

You mean, from the rebol console, you

	>> do %synapse.r


and you always get a stack overflow (not just when you have a bug 
like this)?

Yes... but it's caused by my redefining 'now

..so I suppose you have to encap and run the executable after every 
change when debugging - I can see how that would be slow.

encap picks up the syntax error

Really? How does that cause a stack overflow?

Infinite recursion, I suppose.

Yeah ....

I redefine 'now to use real time taken from a NIST server

How fast is encap with a file that large? Does it deliver the error 
message immediately?

yes pretty immediate

My practice is usually make one change and then encap.  If I make 
two changes I'm in trouble.  Worse if I make changes while watchingTV 
:(

Ahh.. :) the real source of the trouble comes out :)

haha

First episode of NCIS NY

I don't know what other people do to manage code of this size ....

<What I need is a utility that will take a rebol script, and parse 
it out by function, attempting to intepret it until it reaches an 
error.>
I think there was one in the Official Guide (the book).

heh... I never got past the first chapter.  After that I used it 
as a bookend.

Looking at to-rebol-file and wondering what advantage it has over 
to file! ... they seem functionally equivalent to me.

Also, the help text for as-string says "Coerces any type of string 
...". Should that read "any type of series"?

>> to-file "c:\rebol\rebol.exe"
== %c:\rebol\rebol.exe
>> to-rebol-file "c:\rebol\rebol.exe"
== %/c/rebol/rebol.exe

>> exists? to-file "c:\rebol\rebgui\enfacecmd.exe"
== false
>> exists? to-rebol-file "c:\rebol\rebgui\enfacecmd.exe"
== true

Seems to be big functional differences on windows at least.

Mostly around driver letter and slash direction handling. I suppose 
the question then is, why doesn't to file! do what to-rebol-file 
does ... I don't see the point in using to-file to create an "invalid" 
file ... a bit like having both a to-decimal and to-rebol-decimal 
for example.

>> to-file "test.exe"
== %test.exe
>> to-local-file "test.exe"
== "test.exe"

to-local-file makes sense to me, it's the need for both to-file and 
to-rebol-file I'm curious about.