World: r3wp

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.

TO-FILE is only for datatype coersion. It makes sense to have both.

Uh? All the to-* datatype conversion functions are implicitly to-rebol-* 
... why the need for a to-file that can produce "invalid" rebol file 
types and to-rebol-file that produces "valid" rebol file types? I'm 
looking for the reason/case where you would want to use to-file in 
preference to to-rebol-file.

The file! type is just a datatype. There's no guarantee that the 
file! refers to anything, or is even the right syntax.

to-rebol-file and to-local-file are more like a pair, too.  The other 
to-* are their own set.  For a new user, it seems more obvious that 
to-rebol-file and to-local-file would go together, I think.

I think the way things are with TO-FILE and TO-REBOL-FILE is just 
fine. I would be annoyed if TO-FILE took had the more complex functionality 
of TO-REBOL-FILE. I agree with BrianH.

Could I ask why rebzip.r will only unzip a gzip if the console is 
launched from rebview ( in this case 2.7.6) but not from rebcore? 
thanks

I guess it's because it relies on the PNG decoder for decompression 
which comes only with /View engine.

Btw, congratulation to the author, Vincent Ecuyer for this great 
library!