evaluation

While evaluating Rebol for Mail Flow management Client project I have questions on a couple of issues. 1. Do you allow multithreading? Any code snippet? 2. What do you use for debugging tools and unit test frameworks?

Hi Boris, << 1. Do you allow multithreading? Any code snippet? >> REBOL doesn't support native multithreading. Maarten's latest release of Rugby has cooperative multithreading in it as an example of how you might approach it. << 2. What do you use for debugging tools and unit test frameworks? >> Since REBOL doesn't support step tracing at this time, the console and embedded print statements are the most common debugging tools I think, at least they are for me. There is also a unit testing script (based on JUnit?), called rebol-unit. --Gregg

1. You can start processes via command line in paid versions of rebol. The master could then start as many slaves as it needs. No forking in native rebol. Here is a simple 2 line a piece master and slave demo, made in about two minutes. This is one way to communicate between processes. ------------------------- rebol [] ; slave script conn: first wait open/lines tcp://:3333 forever [error? try [probe do first wait conn]] ------------------------- rebol [] ; master script port: open/lines tcp://127.0.0.1:3333 forever [insert port input] ------------------------- You may also should be able to tie processes together with better performance by using C functions. I cant give you an example of that. Does anybody know if you could fork using a C function from REBOL? 2. Testing is done at the console level. Generally REBOL is easy to test and debug once you understand how evaluation occurs. When an undefused error occurs, the program breaks into console mode, much like BASIC. At this moment you can peer into your program, test values and functions, somewhat useful. Usually though, you add probes into the suspect area of your program to make sure it is doing what you expect. Almost all bugs I encounter are fixed within a minute or two, and often just seconds. The tools are not nearly on the level of Visual BASIC, though somehow debugging goes pretty easy in REBOL. I suppose its because you can manipulate your code easier to find the bug, and that you can track down what happens during evaluation word by word. Bottom line, REBOL programs just come together faster and easier than other languages I use. For some things REBOL is not ideal, but for allot of programs it is the way to go. For most graphical network apps, I would give it an easy 3x productivity over any other language I know. Especially larger apps, if designed rebol ground up (i.e. not picky about GUI components), I would not be surprised to see 5x, or even 10x productivity. This is coding and debugging time, total project time wont change as much because documentation and design considerations wont necessarily go any faster. Although by reducing the number of people involved in the project, you could see even higher gains through improved coordination and communication. The real challenge is finding a REBOL programmer with 5 years experience. --Ryan Boris Garbuzov wrote:

Gotta agree with that. The earliest version of Rebol I can find on my hard drive is version 1.0.0.3, and that has a file date of 1/Oct/1998, which is less than 4 years ago. On Tue, 30 Apr 2002 19:27:58 -0700 Ryan Cole <[ryanc--iesco--biz]> wrote: .

> The real challenge is finding a REBOL programmer with 5 > years experience.