evaluation
[1/4] from: boris::garbuzov::marketingtips::com at: 30-Apr-2002 13:30
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?
[2/4] from: greggirwin:mindspring at: 30-Apr-2002 17:37
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
[3/4] from: ryanc:iesco:biz at: 30-Apr-2002 19:27
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:
[4/4] from: gchiu:compkarori at: 1-May-2002 18:03
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.
--
Graham Chiu