World: r3wp

Designing gui in rebol is quite simple, with rebgui even more....
So one aproach would be:
1. Make interface look like it shoud be
2. attach code to be executed on events

I don't think there is a particularly REBOLish way to write large 
programs. You just figure out a reasonable way to do it.

:)

V: similar with dialects...

So no magic rebol wand to make it better than the rest ? :)

actually there might be: generate REBOL code with REBOL.

aha.... thats more like it :)

I had an idea.... :) bare with me.... is it possible to start a script 
that would while running, change itself (file on disk), and than 
transfer control to this new version of itself ?

No reason why not.

I once built a db protocol using a dialect, which would generate 
the server side code and the client side code. Both sides were dialects 
too. This was wrapped inside another dialect which could build the 
server and multiple client programs by preprocessing and putting 
together multiple other scripts. Works pretty well and it takes about 
5 minutes to add a new command to the protocol and update server 
and client.

Henrik: What did you mean by generating code?

When I started writing applications that requiered data entry, I 
always first wrote an object that takes text as input (something 
like this: "'Name' c20 'Address' c30 'Town' c30) and displays modal 
dialog with those fields, OK and Cancel buttons, and all the logic 
that is needed...

So all my data entry dialogs looked and worked the same and all that 
usually fit in one screen of code....

I'll need a minute to understand what you wrote :)

I created the screens first .. then built the data structures and 
then the supporting code after that.

By generating code, I mean generating scripts, dialects or things 
that don't make sense or is too heavy to create in runtime.

RebGUI already has support for forms

though my app was started prior to that functionality

Vladimir, it's a poor explanation, so don't get a headache. :-) Basically 
REBOL allowed me to create a dialect that would flesh out a database 
protocol in one single 10k script and then use that dialect to separate 
bits and pieces out in a server and client part. That way, I didn't 
have to manually write a server script and a client script in two 
separate parts.

That was ment just as example of how one small thing can make life 
much easier.....

Well, I used rebol to make lookup table data for my asm code :)

I guess its something like that? making code from data ? sort of....

when you know enough REBOL, you can flip a problem in any angle to 
your advantage. here it was advantageous to keep two separate parts 
strictly in sync.

got it.... :)

yes, like state tables. I use that too. :-)

actually, I added some doc descriptions to the dialect, so I could 
have autogenerated docs from the dialect too.

So what I got from this small discussion (in no particullar order)::
1. Create gui, create data, add supporting code...
2. Create rebol code with rebol...
3. Create a dialect or two (or more :)) specific to the task...

4. Create small code files and put them together using preprocessor...
5. Figure out a "reasonable" way to do it :)

I guess this is one of the freedoms you have, when no IDE is bogging 
you down or telling you how to do things. :-)

:) I already started writing self modifying code :) at least I think 
thats what it is... :)

Its working :) I guess this is cool.... Made a function in a separate 
file that calculates sum. But with a press on a button, I rewrote 
part of that  file with function that multiplies two numbers instead 
of adding... And from that point on its multiply that you get...
It has a lot of potential but have to find good use for it.... :)
Thanks guys, Im of to sleep, its been a long day.....

What I have found working with asynchronous functions that return 
data from database calls ... one should create some type of gui at 
the start of the call, and then replace that in the callback.

What I initially did was only create the GUI on completion of the 
call which was fine when testing on the LAN, but as soon as you got 
internet latencies ... it was not so good.

Does anyone know of a way to have a rebol script continue to execute 
even after it recieves an error?


I have a script VERSION-TESTER, that will gather code examples and 
create another script VT-SCRIPT that will test them all out against 
the newest version of R3 alpha.


VT-SCRIPT is extremely simple, capturing all console results into 
an ECHO file, but I need a way to have the script continue even when 
it finds an error.
Any ideas?  See this simple example:

Rebol [script: %VT-Script.r   will verify R3 documented examples]
echo  %VT-Results.txt
print {Results below generated from %VT-Script.r}
print {---------------------------------------TIME examples			}
print {var: now														}
       var: now
print {print var													}
       print var
print {7-Apr-2009/11:53:26-6:00             	<-- same?			}
print {}
print {---------------------------------------WRITE examples		}
print {write %junkme.txt "This is a junk file."						}
       write %junkme.txt "This is a junk file."
print {print read %junkme.txt										}
       print read %junkme.txt
print {This is a junk file.                 	<-- same?			}
print {}
print {write/binary %data compress "this is compressed data"		}
       write/binary %data compress "this is compressed data"
print {print decompress read %data									}
print {this is compressed data              	<-- same?			}
print {}
print {---------------------------------------PROTECT examples		}
print {test: "text"													}
       test: "text"
print {protect test													}
       protect test
print {append test "a"												}

print {** Script error: protected value or series - cannot modify	}
print {** Where: append												}
print {** Near: append test "a"										}
print {}
print {** Note: use WHY? for more about this error					}
print {}
print {----------------------------------------OTHER examples		}
print {unset [var]													}
       unset [var]
print {print var													}
       print var
print {** Script error: var has no value    	<-- same?			}
print {}
print {** Note: use WHY? for more about this error					}
print {}
print {---------------------------------------TEST COMPLETED		}

print {See results stored in %VT-Results.txt file}
echo off

How does ERROR work?  What does the kernal actually do when it encounters 
an error?

I see that errors condition can be trapped with commands such as 
TRY, DISARM, ATTEMPT, but is there a way I can capture the printed 
results of an error without the error causing my script to stop running?

I think you can't, unless you settle for printing the error object. 
That's possible. The console error messages themselves can't be reached, 
I think.

Hi Henrik

It is just fine that the console error messages print whatever they 
print, but I want some way of having my script continue depsite the 
error message encountered.

Is there a way to have REBOL invoke a separate independent console 
that it could do its own commands in.  Then, I could simply submit 
one rebol command per session, and capture the results in the ECHO 
file regardless of wheter the command errored out or not.  

Could that work?

it should be enough to:

probe disarm error

I added that at the head of my VT-SCRIPT, but it didn't work

** Script error: error has no value

sorry, I thought you had a result to test.

I've been reading up a little on generating errors at http://rebol.com/r3/docs/concepts/errors-generating.html
one line in particular captured my attention:


The error message generated for my-error can be printed without stopping 
the script:

disarmed: disarm err
print bind (get disarmed/id) (in disarmed 'id)
this doesn't go into that using my-function

-- Not sure if this has any legs for me?

if you want to generally test the entire script, the only way is 
to wrap it in a TRY or the elements you run in a TRY. REBOL will 
stop evaluating a block if it encounters an error in it.

Yes, but there must be ways to trap an error without stopping the 
script.

Or are you saying that another function such as TRY will "insulate" 
the error from causing my script to stop running?

'err in that example means you have evaluated a block and the result 
is returned to 'err. you can then test if 'err contains a good result 
or an error like so:

if error? err [
	print "oops"
]

or more useful:

if error? err [probe disarm err]

that's the only way. the only way to simply keep going is to wrap 
small bits of code in TRY and that's not good style.

trying to understand -- :-/  (still a newbie!!!)

OK, lets take a simple example that I know errors out
UNSET [x]
print x

x is undefined and has no value

so how would I change the PRINT X in such a way to capture an error 
withotu stopping the script?

But, if the command succeeds without error, I want to get the results 
of that as well

unset [x]
set/any 'err try [print x]
if error? err [
	probe disarm err
]

and you may continue after that if err is not an error.