AltME groups: search

Perhaps it is better to use call/output?

>> console-output: make string! 2000
== ""
>> call/output "ver" console-output
== 0
>> console-output
== "^/Microsoft Windows [Version 6.1.7601]^/"

This is a code pattern I use often, but always find it annoying to 
have to add a to-logic call each time in front of refinements.

Red/System Question: In a function, a local variable v1 is declared 
as struct! [ v2 [integer!]  ]. Once the function is called, v1 is 
in stack, v2 is in heap. When the function call is over, v1 is gone, 
but v2 is still in heap, right?

For example, there are spinlock-like constructions in Syllable's 
PThreads implementation that can often prevent having to call a kernel 
mutex. This makes them much more efficient, but you need atomic operations 
on access flags and counters to implement the user-space spinlocks 
and mutex shells

Actually, it was a private joke at Softinnov to call it like that, 
it was meant to be a project code name, not the language final name.

BTW, when you call functions from the console (FIRST, PROBE, LAST,...) 
defined in %boot.red, the interpreter will use the compiled version 
instead of evaluating their body....this is just to make Kaj even 
more confused. ;-)

_setmode call is used to properly set the DOS console to UTF-16 (Unicode 
mode).

Kaj: right, the `free` call here is unsafe. Actually both allocate/free 
calls in input were just meant for temporary use. The whole current 
console code is temporary, it will need to be replaced by a proper 
cross-platform full-featured console.

The compiler needs to do that at compile-time, so it needs to recognize 
what is a function! call and what is not.

Another thing: are natives more efficient than routines?

  Routines and natives are both Red/System code that use Red runtime 
  internal API, so they perform the same. In case of routines, you 
  might have a tiny overhead for integer! and logic! that are converted 
  back and forth between Red and Red/System, but it is really very 
  small, and only significant if you iterate a lot of times over a 
  routine call.


From the memory and boot time perspective, natives are more efficient 
because their body block is not stored internally  for reflection 
like routines. So, for functions like QUIT that should be part of 
Red core, it is better to implement them as natives, to save memory 
and booting time.

This will result in 'foo function been created at runtime (then JIT-compiled 
or interpreted on each call).

Would boot.red be a suitable place to put bindings for individual 
functions? I would like to add a simple CALL implementation

If you're thinking about OS bindings, they should go in %platform/ 
folder. Can't you add CALL to natives? If you need help I can give 
you a check-list of things to add to support a new native, it's pretty 
simple.

I'd like to keep it simple and quick for now, so I've done the CALL 
implementation externally in the C library binding, where the Red/System 
counterpart is

How are you supposed to implement an array, I can figure out some 
things about using a pointer, but I cannot believe it will work with 
the example value of 40000000h

What are you missing from using pointers?


I do not have a clue if this is a realistic value as a memory-address, 
that is why a simple array could come in handy.


The example is just showing how to do a dereferencing. It will probably 
crash on most systems if you use it with that value (reading should 
be safe on Windows, but writing not, as it is the default read-only 
memory starting page for PE executables). If you have a better alternative 
example that can work for real on all OS, feel free to submit a pull 
request. For example, retrieving the pointer value from an OS or 
C lib call would maybe be better (but much longer). My intention 
in this example was just to show how to dereference a pointer, how 
the pointer is initialized is a lesser concern.

Arnold: if you use DECLARE on pointer! or struct!, you already get 
an automatic memory allocation done by the compiler for you. Such 
memory will be statically allocated from the data segment (defined 
by the executable). 


Alternatively, you can use ALLOCATE to get a memory buffer for your 
array during the execution of your program (just don't forget to 
release it with a FREE call at some point).

Just want to briefly describe that in my expectation a C-level language 
means you can do things like you would when using C. So it is not 
that you would have to call functions/programs/libraries with C programs 
to do those things. So for speed issues or fast prototyping purposes 
or to do things not yet possible in another way you use the bindings. 
In my case I wanted to try to program a relative simple algorithm 
of which I have an example in C and I want to do that using Red or 
Red/System. I can accept it is too early at this stage.. at least 
for me but this kind of thing is what others will be doing in the 
near future and they discover you can do literally anything using 
Red and Red/System, as long as you make a C program to do it and 
call that. That is a bit of a black and white view, but that is how 
I see it.

Since Red needed jump tables, you can also go the other way around, 
and cast an integer/pointer to a function, then call it

or xnview command line - then you just need a CALL ....

Kaj: I've pushed a change in attributes handling for Red/System functions, 
you can now specify attributes or function's description doc-string 
in any order. I've replaced direct spec block access for attributes 
by a function call in deep compiler's code parts, so watch out for 
regressions especially in callbacks!

Actually, we could just make the compiler recognize such case and 
generate a call to the interpreter without you having to specify 
DO. The drawback would be that all subsequent values in that block 
level, would be passed to the interpreter too, as the compiler can't 
determine the expression boundaries. I'm not very fond of such option, 
but it is a possibility.

Sometimes, I'm such a dunce!  Something Kaj said in the past hit 
me as I lay awake in bed at 4:45am this morning.  IIRC, he said that 
Red/System could be used to extend R3.  My problem is that I need 
to perform some advanced processing on jpg images.  I wanted to do 
this natively in Red/System, but had issues getting the jpgs loaded 
into bitmap form.  R3 can already load jpgs into bitmap form, so 
why not  call a Red/System compiled executable to do the processing?

I meant path elements. Of course, when they're used in a function 
call, refinements are written as paths

BrianH:I don't believe a single second for R3 becoming even beta. 
Three or so years ago I wrote, what makes a good beta for me. So 
here it comes - give me a console, not a crap. Give me smtp, ftp 
etc schemes, without an excuse. Give us odbc, mysql, postgress, give 
us CALL. So - no matter how much advanced R3 is to R2, in a sence 
of a complete package, it is still pre-alpha ...

So `print [1 + 2]` could be compiled efficiently by the compiler 
(calling the native with a reduced block), while `print a` will directly 
call the native version.

I suggest to change the relaive part of "Readme.md" to:

Running the Red/System hello script
------------------------

1. From the REBOL console type:

    `call/show ""` ; (type this only once to fix Rebol 2 bug)

    `change-dir %red-system/`

2. Type: 

    `do/args %rsc.r "%tests/hello.reds"`
	

    the compilation process should finish with a `...output file size` 
    message.


3. The resulting binary is in `red-system/builds/`, go try it! type 
(on Windows):

    `call/wait/shell/console %builds/hello.exe`

I've removed Q from the console-specific module thinking it was in 
boot.red. :-) Needs some rest.... I will put Q back in console.red. 


Sorry Arnold. BTW, how do you manage to call quit the console if 
you redefine Q for custom usage?

Yes, see PLATFORM? routine in %boot.red (you can call it from console 
for testing).

It is intentional and has several purposes: 


a) avoiding the creation of an hidden context for each iterator instance 
and especially the costly deep BINDing of argument block on each 
call.


b) making the iterator word available outside of the loop, can be 
useful when early breaking from loop, avoiding the passing of the 
counter through a BREAK/RETURN. It can also be used to check if the 
loop counter has reached its limit or not.


c) it is IMHO counter-intuitive for users, after a few years you 
get used to it, but it is a wall that every new user will hit more 
than once. I think that the extra step of defining it as local word 
is really not a big deal in comparison. Also, FUNCTION constructor 
could be enhanced to take care of that for you.

You need to created a new context on each REPEAT call (or use some 
hacked way of caching it) and you need to BIND the loop body (even 
probably BIND/COPY it to be cleaner). Now think about the costs of 
nested loops...and all that because you don't want to define another 
local word, that could anyway be added for you by FUNCTION. Think 
twice about the trade-offs.

Huh, it seems that both current versions of R2 and R3 are not binding 
the loop body on each call to the hidden context:


>> foo: func [code [block!] /local a b][a: 1 b: 2 repeat i 10 code]
>> foo [a: a + b]
** Script Error: a has no value
** Where: foo
** Near: a: a + b


I'm pretty sure I've seen it, maybe in older versions. Anyway, if 
current Rebol versions are not making that binding on each call, 
it makes most of my point a) irrelevant. So, you can forget about 
the binding cost. :-) Still the other concerns and limitation remain.

>> foo: func [code [block!]][repeat i 1000 code]
>> foo [i]
== 1000

So both R2/R3 do re-bind the body block on each call.

In %boot.red, UNLESS's second arg is called 'true-blk. Should it 
be 'false-blk? Or should both UNLESS and IF call it 'then-blk?

call "cat /proc/cpuinfo"

Endo, you could even make it a webservice that could be used with 
a simple WGET call from a command-line. ;-)

So, how does it work? When you need to interrupt the flow of code 
in a function in Red/System, currently you can just use EXIT/RETURN 
to make an early exit. But, sometimes, you need to go up through 
several nested calls, that's where the new THROW function comes handy. 
It will interrupt the execution and go up the call tree to find the 
first function that has the CATCH attribut set. It will then just 
resume execution after the last function call (from which the exception 
has been generated).


If no CATCH attribut is found, it will go up to global code and resume 
from there.

Important thing to note: system/thrown needs to be manually reset, 
as the last thrown value will stay there if no exception occured. 
Such reset could be done before each call to a function that could 
generate an exception or after processing the thrown value.

I've written a quick function that will take a Red char (UCS4) and 
output the equivalent UTF-8 as bytes stored in a struct!.


It can be used for the base of converting a Red sting to UTF-8. What 
is needed is to extract Red Char! s from the Red String, call the 
function and then appedn the UTF-8 to a c-string!

It would be best to do the conversions on the fly, that is why I 
want to wait for I/O get done to implement such conversion routines. 


Anyway, for doing it now, you need to allocate a new string, the 
best way to do it is:

    str: as red-string! stack/push*
    str/header: TYPE_STRING
    str/head: 0
    str/node:  alloc-bytes size


The new string! value will be put on stack, so any other call to 
a Red internal native or action might destroy it. Also, keep in mind 
that the GC is not there yet, so intensive I/O might quickly eat 
up all your RAM.

Peter, maybe you could user ALLOCATE function from Red/Sytem and 
let Kaj's code call FREE on UTF-8 buffers after usage?

Question: does a Linux shared library need to call __libc_start_main() 
or can it assume safely that this will be done by the host app?

Seeing how much trouble we had forcing us to call the C library setup 
in Red programs, I think libraries don´t need to do it, but that´s 
conjecture

Sorry, that came out incoherent: a library does not need to call 
__libc_start_main.

I'm doing some changes in the exit sequence of Linux/Syllable executables. 
Currently, the Red main() passed to __libc_start_main was never returning 
as it was calling exit(). I'm changing that now to give the libc 
a chance to call its .fini routines and let it handle the exiting.

I'd like to know what your development environment for Red/System 
is especially that used by Doc.
In the meantime...
	My development environment:
	OS: Windows 7
	Editor: Notepad++ v5.0.3
	  not the latest version but I prefer this one,

   using "Python" as the language for syntax highlithing and coloring

   (there is not a "REBOL" language) and used mainly for the folding 
   on indentation

   (I can not live without folding, and folding on indentation makes 
   life even easier)

   I have added a menu item with a keybord shortcut to run REBOL with 
   the currently shown file as argument.

   I have added also a menu item with a keybord shortcut to run my modified 
   version of REBOL-Word-Browser

 At the end of the r/s file I add these lines (mostly taken from Bruno 
 Anselme):
		#if OS = '???? [{
		REBOL []
		appname: "myprog"

  rs-dir: %../Red-master-0.3.2_Bruno/red-system                ; locate 
  here your red-system directory
		dest: rejoin [what-dir appname ]
		print [ "------ Compiling" appname "------" ]
		do/args rs-dir/rsc.r rejoin ["-o " dest " " dest %.reds ]

		print [ "Destination file:" dest ]
		call/wait/show/console dest
		halt
		;}]

 This way pressing the shortcut I can run REBOL that compiles the 
 program I am writing and than starts the program.
	Any suggestion is welcomed!

Kaj, it seems to me that you were confused by a few things:
- console script banner wrong statement (my fault)

- internal "Latin-1" naming (like in Python's internals) which might 
be misleading (there's no other closer naming in Unicode for one 
byte representation AFAIK, though some people call it "UCS-1", maybe 
we should adopt that too).

- "Unicode support" seems to imply to you that *all* possible Unicode 
encodings have to be supported (with encoders/decoders). It doesn't, 
having just one encoding supporting the full Unicode range (like 
UCS-4) is enough for claiming "Unicode support".

btw, just curious - what is it generally usefull for, to call Red 
from R/S? I can imagine it in reverse direction, but when you would 
need any such callback?

Added new #call compilation directive to enable calling Red functions 
from Red/System.

Syntax:
    #call [<red-fun-name> <arg1> <arg2> ...]

Notes:
- it can be used only in routines body or #system body block.

- only function! value can be invoked (refinements not supported).

- arguments are either literal values or Red/System global/local 
variables.

- type casting (to a Red internal datatype) is allowed in arguments 
(avoids wasting an extra variable).

So you can call Red apps from Red/System, but you can't call Red/System 
apps from Red/System, correct?

The #call directive invokes a Red function, it has nothing to do 
with Rebol's CALL native.

R is a compiled Red app. RS and RS2 are compiled Red/System apps. 
From RS2, I can #call into R, but not RS, correct?

No, it's not Rebol's CALL native.

Right, I understand that. I don't mean CALL, I mean #call.

There's no way you can call any function from one process to another.

#call is meant for calling Red code from Red/System in the same app.

BTW, I've hesitated to name it #callback instead of #call.

Actually, it's fairly simple, think about a GUI app that sends a 
click event to your Red/System binding, how do you pass the event 
to Red code if you can't call it from Red/System. ;-)

I've started a Red counterpart of the Red/System binding with the 
C library:
http://red.esperconsultancy.nl/Red-C-library/dir?ci=tip


I'll implement C library bindings there as far as they're useful 
at the Red level. So far there's a simple CALL implementation.

There's a WAIT refinement, but like in R3, this simple CALL always 
waits, and there are no other refinements yet

I've extended the Red interpreter console with the ability to load 
and run a script file, given as an optional program argument. It 
also has CALL now, so you can run simple programs with the intepreter 
and script the operating system.


As before, ready built binaries are available in the test repository, 
in */Red/console-pro:
http://archives.esperconsultancy.nl/Red-test/dir?ci=tip

At a request, I upgraded R3 on Try REBOL from 2.99.111, the last 
official RT version, to Andreas' current build, the ongoing 2.101 
series. Not many changes, but some bug fixes.

http://tryrebol.esperconsultancy.nl


Graham programmed a nice bot for Stack Overflow chat that is able 
to call the Try REBOL web service to execute code examples and post 
the result.

I dropped the cURL dependency from my red-base distribution. This 
means that it now only depends on a few libraries that can be expected 
to be included in all platforms. This version of the Red interpreter 
can now be used on Windows as a single executable, without any extra 
libraries. The Windows version red-base.exe is here:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip&name=MSDOS/Red


It has versions of READ and WRITE for local file I/O, but no network 
I/O. It also has the other functionality from the C library, such 
as INPUT, ASK, GET-ENV, CALL, NOW and RANDOM, but for more functionality 
you still have to use red-core and red, and download the extra libraries 
for Windows.

I changed the Red 0MQ interface to optimise the memory use during 
receiving of messages:

http://red.esperconsultancy.nl/Red-ZeroMQ-binding/info/2a1541af57


SEND and RECEIVE have been renamed to send-string and receive-string, 
because they currently handle messages as UTF-8 text. When Red gets 
a binary! type, versions for binary messages will be added, and there 
will probably be type agnostic SEND and RECEIVE wrappers again. Previously, 
you used

message: receive socket


to receive a string message. Now you pass a premade string! (similar 
to call/output in R2):

message: ""
receive-string socket message


This means that you can choose between creating new strings for each 
message (with COPY) or reusing the same string. In the latter case, 
some Red/System code in receive-string makes sure that no extra Red 
memory is used, and that all used system and 0MQ memory is freed 
again. By optimising memory use, this also improves performance of 
message throughput.

Video number 5 posted. This one uses routine to call a Red/System 
function from a Red script.

New World alpha release at
https://github.com/Geomol/World


- Added better networking using cURL library, libcurl (OS X and Linux)
- Added tasks incl.:
	- task! datatype
	- task-id! datatype
	- TASKS native function
	- task? and task-id? mezzanines

 - Task support for many functions incl. HELP, SOURCE, FIRST, SECOND, 
 PICK, COMPILED? and DISASM
	- KILL mezzanine to call TASKS/KILL

- Added inter-task communication using SEND and RECEIVE native functions
- Added support for messages to WAIT as: wait 'message

- Added preemptive multitasking using TASKS/TICKS to specify number 
of Virtual Machine instructions per task run (default is 200)

- Added timers for tasks triggered by WAIT native and READ native, 
when reading from url
- Task yield can be achieved by: wait 0
- Changed ;{ } comment syntax to ;( )
- Parens can now span several lines at the prompt
- Added system/console/paren
- Added support for pressing <Esc> to stop execution of main task

- Sending input via pipe to World started with a script will activate 
input without echo and without <tab>-completion etc.. (Not sure how 
and if this works under Windows.)
- Added support for picking 'Re and 'Im of complex numbers
- Better implementation of TRY

- New test versions of IF and EITHER, that can take other than block! 
arguments
- Added more tests

REBOL/core does not include the ability to call shared libraries. 
REBOL/View does.

Thanks for the welcome back message.
 

 I left off asking about the mySQL driver. So I want to insert into 
 a database a random number the code already generated and associate 
 it with an email address that was provided by a CGI form. Have yet 
 to create this in the real world but for now let us assume I will 
 call the database "customers". The people who process the credit 
 card and collect the email address advised me that the address will 
 be labelled "trnEmailAddress".


 After finding the mySQL driver Here is what I figured out using placeholders 
 for things like password, etc. Would appreicate knowing if this is 
 correct.

; Loads MySQL driver
do %mysql-driver/mysql-protocol.r
; Opens connection to MySQL server
db: open mysql://[[user][:pass]@]host[:port]/database


; Send query to database server. Enters random number from above. 
customers is probably the name of the database I will create

insert db ["INSERT INTO customers VALUES (?,?)" "trnEmailAddress" 
"token"]



 Next I need to insert an existing PDF file (an e-book) into a directory 
 created by the script. The directory will be named after a random 
 number that was earlier generated by the script. I am astounded that 
 I can not find the command to copy a file. So the variable assigned 
 to this random number is called "token".

 So I have the following.

make-dir %token/


 How do I copy a file into this new directory? Also, is that the corecct 
 way to make a directory?

Basically, you create an HTML file and put it on your webserver. 
Let's call it "form.html":


<form action="form.cgi"><input type="text" name="word"><input type="submit"></form>


Then you create a REBOL CGI matching the "action" used above, so 
"form.cgi", and also put it on your webserver:

#!/usr/local/bin/rebol278 -cs
REBOL []
cgi-values: construct decode-cgi system/options/cgi/query-string


;; Now you can access the "word" value submitted via the HTML form
;; as cgi-values/word.

;; Let's echo the value back to the user, as an example:
print rejoin [
  "Content-type: text/html" crlf
  crlf
  cgi-values/word
]

For R2: native loops are faster than mezzanine (function) loops, 
so much faster that their individual differences amongst themselves 
are almost irrelevant. For R3 all loops are native (except FIND-ALL, 
temporarily), so the big difference is one-time-per-call bind/copy 
overhead for binding loops, versus not having that for non-binding 
loops.

AdrianS:  Not mixing at all.  I am done with taking something like 
MarkDown which is limited in syntax and "adding features" to make 
it do more things.  That's how the beast we call the DOM came to 
be.  An awful thing.  You can't talk about the syntax without talking 
about the design of the parser.  They can't be separated.

The only externally visible change is that sys/load-ext-module and 
sys/load-module return 3 values instead of 2. If you don't have any 
code that calls those functions directly, then all working code won't 
be affected. The only code outside of sys-load.r that could hypothetically 
call those functions would have been written by Ladislav for include, 
or Saphiron for their encapper, but even then it's unlikely. Andreas, 
you could grep Saphiron's sources to tell me if those functions are 
referenced outside of sys-load.r.

I use .r for scripts that are expected to run in R2 or R3, .r2 for 
R2-only scripts and .r3 for R3-only scripts. However, a lot of my 
scripts are .cmd and call themselves with the appropriate Rebol.

I use .cmd instead of .bat because the tricks you use to call Rebol 
safely require cmd.exe (in NT-based Windows) and won't work with 
command.com (in Win9x/Me). It's not necessary to use .cmd for this, 
but it's a good reminder.

Or just use syscalls .The posix extension I am working on will provide 
these features, template based creation too. 
for windows you can use this api call.  


http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991(v=vs.85).aspx

example:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363875(v=vs.85).aspx

After the current build streamlining work, I plan to look into better 
stdio and a more versatile "call" next.

yes, call is migthy when proper designed. using os.execute and io.popen 
all the times with lua. highly underestimated for it's capabillities 
but not easy to built.

would be VERY valuable if you could make call better.

However, on linux is easy to ovverride any problem using "call", 
in the end I prefer this way.

Id depends, how fast is CALL, but especially on Linux, there should 
be very little overhead. E.g. I found out, that PHP, for Unicode 
conversions, just calls iconv. If you don't call the function in 
loop, I would go the CALL way, with tiny wrapper parsing results 
back. But - CALL on R3 misses /output and /wait ...

We need some bounty to bring R3 CALL on par with R2 :-)

I'm getting metaphorically killed by the FOREACH function blowing 
a system assertion 1207 periodically. I'm trying to process a couple 
thousand files and it's dying before it's finished. The script will 
need to be rewritten to call another R3 instance per file, just to 
make sure that it completes.

AFAICT noone has used get-words in a SET block call before, even 
in R2 code.

R3 CALL seems pretty useless to me compared to R2. Is there anybody 
trying to improve it?

Yep, we call it gaming the test.

Pekr: "BrianH:I don't believe a single second for R3 becoming even 
beta. Three or so years ago I wrote, what makes a good beta for me. 
So here it comes - give me a console, not a crap. Give me smtp, ftp 
etc schemes, without an excuse. Give us odbc, mysql, postgress, give 
us CALL. So - no matter how much advanced R3 is to R2, in a sence 
of a complete package, it is still pre-alpha ..."

But yes, we need more schemes (also in included-by-default modules) 
and a decent CALL, agreed.

BrianH: well, I was long time a proponent of R3. What attracted me 
most were devices, even more modularity, etc. But - let's not be 
deluded. If you are careful enough, you could see, that ppl mention 
some things here or in regards to Red, eg. asking - is View going 
to be available? Let's not ingore, that many ppl started to use REBOL, 
because it was kind of complete package - console, call, dbases, 
networking, gui ...

Personally, I want to work on the database support because that is 
what I need the most and have the most experience with. I expect 
that others will need networking stuff more, and yet others will 
need CALL or a better console.

This patch uses /usr/bin/open on OSX, maintains the previous handlers 
on other platforms. In addition, I replaced the system() calls with 
fork+exec to avoid firing up another shell; one byproduct of this 
is that exec errors no longer print to the console (though this could 
have been hackishly solved by adding some redirects to the system() 
call string in the existing codebase).

For #1991 se need a better approach. We aren't at the point where 
we would need to disable a feature while we wait to figure it out, 
at least for something you have to explicitly call.

In the constrained #1993 FOR, the constraint is a feature. It will 
protect you from infinite loops that you don't intend, regardless 
of what start, end and bump say. You would have to go out of your 
way to make an infinite loop, by setting the index in code that you 
wrote. That way, you know you can safely call FOR when you don't 
even know what start, end and bump are.

loop - 1 - 100'000 calls 0:00:02.108
for - 1 - 100'000 calls 0:00:00.508
loop - 1'000'000 - 1 call 0:00:00.304
for - 1'000'000 - 1 call 0:00:01.122

R3 results:
loop - 1 - 100'000 calls 0:00:01.539
for - 1 - 100'000 calls 0:00:00.683
loop - 1'000'000 - 1 call 0:00:00.358
for - 1'000'000 - 1 call 0:00:01.144

Max said: "split-path shoudn't invent information which isn't given 
to it"


I agree, if we consider split-path to be operating in string mode 
(the rejoin invariant). If we want to have a file-system aware option, 
what would we call the refinement? Or should it be a separate function?


As far as returning none for either part, it strikes me as inconsistent 
(if convenient, which it may be). That is, if you split a series 
into two parts, splitting at the head or tail should just give you 
an empty series for that part, shouldn't it? This comes back to my 
SPLIT-AT question.

It's not a bug, it's a limitation of Rebol's binding model. Needs 
is called before the script is bound, and before the module context 
even exists (if the Needs is in a module header). Due to a couple 
of tricks IMPORT can mostly as a function running in scripts (shared 
globally referencable context), but it's impossible for it to work 
as a function in modules because the target scope is impossible to 
determine and the code was bound already before it even started running. 
So, long story short, IMPORT is for calling from scripts, or for 
Needs to call internally, or for advanced code where you are doing 
your own exporting.

The generic problem to solve is this: You somehow have to specify 
what should happen for different actions. 


Let's start with the "somehow have to specify what should happen". 
For this you have some options:

1. Write the application logic code in the GUI spec block. For sort 
stuff OK, for long not.

2. Just call a function from the GUI spec block and write the rest 
somewhere elese. That's IMO the best way. I used FSM and just send 
"application logic events".

The next part is the "for different actions". Same here:

1. Name them explicitly on-* and specify the code with one of the 
options above.BTW: IIRC R3-GUI has click and right-click blocks for 
convinience.

2. Define an implicit mappging from block order to event type. 1st 
block = click, 2nd = right click, 3rd = double left, 4th double right, 
etc. IMO that's not a good style.


Overall what I never liked about VID was that is was not explicit 
enough. For big projects that's a must. For small you might skip 
this but if those projects get bigger, you are hit again.

The problem is, that while the R3-GUI is now more flexible by removing 
reactors, it is also more difficult to understand. I remember trying 
to understand the 'on-action issue in the past, now I briefly re-read 
the doc, and I still can't understand the design. I need following 
things to be cleared up for me, so that I can both use it, and possibly 
explain it to others:


1) If you look into Actors docs - http://development.saphirion.com/rebol/r3gui/actors/index.shtml#
, there is no mention of 'on-action actors. There are many actors 
listed, but not the 'on action one


2) The 'on-action actor is mentioned in the attached doc at the same 
URL, describing, why reactors were removed. So here is the definition 
of 'on-action: 

        a) "The ON-ACTION actor is useful if the style needs to call some 
        default action from multiple places (actors) in the style definition." 
        - understand the purpose, but why and when I would like to do such 
        thing? Any example easy to understand? Just one sentence maybe?

        b) "For example, the BUTTON style needs to call the default style 
        action from the ON-KEY actor and also from the ON-CLICK actor, so 
        it is better to call the ON-ACTION actor from the both code points 
        to avoid the necessity to override multiple style actors." - looking 
        at button or even clicker style definition, I can see no such stuff, 
        as 'on-key or 'on-click calling anything named 'on-action. That is 
        the part that is most confusing for me, and which did not help to 
        understand the 'on-action a little bit. Are we talking about the 
        'do-face here?


There is also a question, if better name could be found for 'on-action. 
Unless I can fully understand, what happens here, difficult to suggest. 
Now to make it clear - I am not judging architecture, just trying 
to get my head around the docs and button/style examples. And being 
average reboller - if I have difficulcy to understand it, the chances 
are, there is more ppl, which will strugle in that area?

 it is also more difficult to understand
 - frankly, *this* is difficult to understand:
* before, you had to understand both actors and reactors
* now you need to understand just actors, reactors vanished

...and you call it "more difficult to understand"?

Yes, I know - if I would have to write some small util for me, it 
surely would be R3 nowadays. The only thing I might miss is better 
CALL and maybe ftp protocol. But it can be solved ....

I toyed with the idea of writing a C-based dll that could take all 
the information for rendering an entire data structure from R2 so 
R2 would only have to make one method call to a dll per frame instead 
of thousands, but couldn't get enough higher priority items off my 
list to get started on it.