AltME groups: search

but Glass will be built exclusively using OpenGL... its going to 
be vastly superior to AGG in what it can do.  never mind pixel details... 
we will have millions of concurrent objects on screen all in real 
time.

But if you use HW to do anti-aliasing and filtering, things can look 
differently.

in any case, when you build a GUI with OGL, you build in such a way 
that everything scales, cause its sooo easy to do... its in fact 
free... like AGG.  so the fact that a GUI isn't exactly pixel perfect 
is secondary... since often you don't even have the same fonts on 
various OSes  ;-)

with extensions we can possibly use other timers, precise timers, 
and include that in the C code.  so if you open the sound ports in 
the extension and do the timing there... it could work... but its 
blocking right now... no async... so no real way to mix sound with 
other events... until async extension model is shared.

you can simply do a block to struct conversion within the C layer.


the extensions docs show how to read and create new blocks, with 
working examples... you just need to continue from there on.


googling how to connect to a dll in real time will give you examples 
in C, but many dll's which are distributed as tools also come with 
their equivalent static .lib files so you might not need to do a 
run-time link to the dll.  OpenGL, for example came with both.

hmm, wouldn't REBOL's object better represent a struct? Do we have 
API to access object btw? The trouble is, that the object member 
might be for e.g. a function, but maybe it is not problem at all? 
:-)

tombon:  the thing is that rebol has to map its datatypes to the 
basic and static data representations of C and other compiled languages. 
 the R2 tried to do this within rebol, but it ended-up being useless 
for many libs which used types that rebol cannot translate natively... 
like unsigned integers or single precision floats, arrays... etc.


extensions do the rebol datatype conversion in the C side, so that 
it can directly map ANY C code to a form that rebol functions can 
understand directly  and vice versa... so for now we could use blocks 
as an interface for structs, even though R3 doesn't understand anything 
about structs.  :-)  


Its MUCH faster to map in C and makes the lib completely integrated 
into REBOL when used.


So for example, we can use tuples as colors within REBOL, and the 
DLL's functions will be called with a struct  or an array, to map 
the 3 channels.

Direct support (including MAKE support) would be difficult without 
user-defined datatypes. You could do something semantically similar 
using extensions, with opaque handles for the types, and accessor 
commands for the rest. The declarations of the R2 version could in 
theory be compiled to extensions if necessary.

It is easier to use REBOL code once you've written it (due to compiilers 
and such), but whether it is easier to write it depends on various 
factors. In the case of /Library, the data model was a weird subset 
of a union between the C and REBOL data models, and simply couldn't 
easily handle many C-compatible APIs, and no APIs that weren't C 
compatible (C++, Delphi, Java, Objective C, ...). Extension wrappers 
are actually easier to write than /Library wrappers, and will eventually 
be able to do much more. Of course, once they are written, your criticisms 
apply.

I've used the R2 /library often and a part from mapping a few of 
the simple windows MAPI functions, I've never gotten it to do anything 
usefull and fantastic because there are simply so many discrepancies 
in types... callbacks crash notoriously and things like arrays and 
pointers are fudgy at best.


A part from the suggestions above, it is ALSO possible for us to 
build an extension which does dynamic library binding on the fly. 
 But that will require a bit more research to get working.  basically, 
we could build an extension which mimics and improves the /library 
system.

thanks, will look it to it too... although I have anidea for the 
ogre...  using "." for the member separations  :-)

ex: Ogre.FreeImageCodec.startup


all the extension has to do is wrap the call to its proper class 
path.   I would also have to build a struct/class lookup mechanism 
(which is the hard part)

yep, programmatically binding the engine is what I plan to do... 
especially since it will allows us to rebuild the binding at any 
moment just by flicking a switch and update it without any user-intervention.

so far, my options are:

 -a direct wrapper generator coded in REBOL using C++ sources, with 
 an advanced  C++ declaration to R3 Extension converter, 
	-I try out SWIG build an R3 extension output module for it, 

 -I use another language binding as the one to base mine with, and 
 make a specific tool to convert it to an R3 extension.

 -do a manual (and painfull) convertion, using a few generic scene 
 interaction commands.


One thing I'd like, is to add some way for the OGRE extension to 
be able to call REBOL code directly via callbacks, using their Extensive 
hooks throughout the api.


Although this will be slower than if the callbacks where in C, obviously, 
some parts of REBOL are swift enough (like series management) that 
they just might make the cut for REAL time rendering hooks.  Well 
implemented, they would be fast enough for common GUI interaction 
events for sure.

GLASS is a general purpose GUI using advanced dataflow programming 
at its core.  I've got some prototypes of various pieces of GLASS 
using R2 and AGG which work really well, but I've been waiting to 
be able to do HW gfx before Investing time on the real GLASS, which 
integrates the prototypes and new stuff too.

will start by playing around with the C++ stuff, basically building 
a simple scene.... when that is working, I'll try to build an extension, 
allowing me to do the same calls via R3

just the fact that you can retarget the whole 3D engine to direct 
X, OpenGL (or another if you wanted to do so) is really impressive.

I know... but we can build code around the fact that its symbols 
won't be used for a long time.  like I say, its not something you 
do without knowing what you are doing.  any commands refereing to 
the old lib, can be replaced with no-ops raising errors... this would 
make it safe.

Sounds cool. Now all you have to do is run it on the output of the 
preprocessor.

In case you were wondering, this is the main reason I was working 
so hard on R3 - so I could work on a project like this. Now that 
the parsing advancements are happening, soon R3 will be good enough 
for me to do my projects. For me, R3 will be released.

The standard REBOL DO dialect isn't compilable, though in theory 
PARSE could be if it were made less dynamic. What we could do is 
a compilable dialect that would resemble a subset of the DO dialect, 
similar to RPython of the PyPy project.

my point has always been, that IN GENERAL, REBOL code is not compilable. 
that is, for every compiler you write, i can write a piece of REBOL 
code that is perfectly legit but your compiler can't compile. That, 
however, does not mean that you can't compile 99% of existing REBOL 
code. In fact, I do have a compiler that can handle most REBOL code 
(it's unfinished, i need to add some kind of type inference to make 
it useful enough). it can already take REBOL code as input, and produce 
optimized REBOL code as output.

In either case, compiling REBOL requires thinking about REBOL and/or 
compilation differently, and trying to do so would push the envelope 
of compilation as a subject. And thus would make an interesting project 
:)

Maxim, Brian,
your suggestions were correct. Thanks


I succeded with very few modifications to the example given by Carl:
( tool: Visual Studio 2003)

- the source file extension must be changed from .c to .cpp for a 
cpp compilation
- in reb-ext-lib.h change the line 
#define RXIEXT _declspec(dllexport) to
#define extern "C" RXIEXT _declspec(dllexport) 


I have not fully tested the extension, but I was able to do a simple 
Text To Speak using windows SAPI5

I try to keep this as short as possible.

Imagine you have this file, called %test.r:

==file==

REBOL[
    Title: {Simple extension test}
	Name: ext-test
	Type: extension
	Exports: []
]

map-words: command []{
    word_ids = RXI_MAP_WORDS(RXA_SERIES(frm, 1));
    return RXR_TRUE;
}

fibc: command[
    len [integer!]
]{
    RXA_TYPE(frm, 1) = RXT_INTEGER;

    i64 o = 0;
    i64 l = RXA_INT64(frm, 1);
    i64 i;

    for (i = 0; i <= l; i++)
        o = o + i;

    RXA_INT64(frm, 1) = o;

    return RXR_VALUE;
}

add5: command [
    a [integer!]
][
    a: a + 5
    return a
]

==end of file==


And now imagine that in R3 console you are in the directory where 
you have the file %test.r .
Now you type:

>> compile %test.r
>> import %test.dll
>> fibc 10
== 55
>> add5 5
== 10

And that's all.


If you want to try it, you need to have TCC (TinyC Compiler) - get 
it from http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25-win32-bin.zip
The script expects it instaled to %/c/tcc/ but it can be changed.
Then go to r3 console and type:

>> do http://box.lebeda.ws/~rebolek/rebol/srec.rip
>> cd %srec/
>> do %srec.r


Then you can try COMPILE etc. (see above). %test.r is included in 
the archive.

SREC is shortcut for Simple REBOL Extension Compiler.
    
Enjoy! (if it works ;)

so, Robert, not sure if you understood all of these replies as even 
I had a bit of a tough time to "get" them.


Right now, Extensions only allow REBOL to call functions from a dll. 
  What I would like is to simply improve the extension model so  
it can also call REBOL code, as a callback or something else, but 
there are a few issues which make this a non-trivial thing to do.


So far there seems to be a generalized idea that there should be 
a different kind of extension which allows this, but I see no reason 
why it should be another, different. api.  having one DLL   for  
REBOL -> DLL  and another for  DLL -> REBOL  makes absolutely no 
sense to me.   IMHO we need a single DLL able to do both.  Even if 
it means a little bit more work to design it.

agreed - just don't put another burden on user. By dismissing DLL 
interface, many users will not be able to make otherwise usefull 
things at all. So if it can be done in terms of current extension 
API, even if it would mean some additional work, let's add it. I 
don't want to hear, that in order to do a callback, feature available 
in R2, I hav to do some other tricks.

IIRC (the dialect is 3 years old and I haven't touched it for few 
years, I just made some fixes in last few days to run it under R3), 
most loops are translated to C's WHILE. You can try writing some 
RebC code and when you COMPILE it, in the %work/ directory you can 
find %your-filename.c file, where you can see the dialect translated 
to C. Do not expect it to be optimized in any way :)

I'm fine with PD - code is just organized characters. Milion monkeys 
with typewriters can do same thing ;) so why licensing anything. 
But that's offtopic - the license will not be deffinitely more restrictive 
than BSD and it may be PD as well. Depends on my mood when I add 
it to header ;)

Playing with the extension example: IMO it's done  to complicated.


- Why do I need make-ext.r? Do I always need it or just for this 
specific example?

- Why is the init block a const char array and not just a plain ASCII 
text?

How do I return a new string back to Rebol?

Is there anyway to do a callback? Or trigger R3 to do something? 
At the moment I use a localhost port for this.

I'm not as much help in this as I'd like, since the current API is 
just fine for what I need to do - at least until we get device extensions. 
Maxim has been more help, since his needs aren't met by the current 
system. If you are writing a database API, your experience will likely 
help refine the model too.

Rebolek, that is not really true - the function still takes a fixed 
number of argument, and you're just passing a unset! value to some 
of them (which is a side effect of R2 passing unset! at the end of 
the block, i think R3 does not even do that)

Ok, so I've not yet provided everything that you'll need to do it. 
I divided the
 extensions release into a few stages:

1. simple - 
just simple access to commands and args
2. series - access to series 
values of various types
3. objects - access to objects (of all types)
4. 
codecs - support for codecs
5. host-lib - ability to bundle extensions 
with the host-lib itself.

So, I need to get you a bit more... in 
fact along the lines that you mention.

It's the dispatch. Right now with extensions, when you make a command! 
it makes a function that is dispatched by a function in the extension 
based on a number (which you can think of ay a key), to code that 
handles the command (the value associated with the key). In theory 
this is not that different from an object! grabbing data from one 
of its slots based on the keyword you pass it. Apparently commands 
will be able to dispatch to objects soon, and the functions assigned 
to slots of that object will handle the command code.


The DELECT dialect model was based on rebcode, mostly on its JIT 
binding. DELECT added the out-of-order, possibly optional argument 
handling to the dialect decoding phase, but the dispatch phase was 
mostly left out (I commented on this at the time). The command! type 
has the dispatch model, but uses the function call model for calling 
the commands. The overlap that Carl mentions is in the mapping of 
keys to command handlers.


If you unify the command mapping models between DELECT and command!, 
then that code can be shared. This means that the DELECT function 
could do the out-of-order dialect decoding, then dispatch the operations 
as commands. Values of the command! type would continue to be called 
like regular functions in DO code or by APPLY, and then dispatch 
using the same dispatch code as above. On the other end, commands 
would either dispatch to objects (including modules perhaps) or extensions.


By the sound of it, this might also allow the command! type to serve 
as a method pointer, but we'll have to wait to see about that :)

I think I could have something working for non multi-threaded stuff 
in a little while... I'm working on this now... its the time I have 
to do it ... after that...
I return from a sanity preserving week of vacation.


and yes I hope I can help with the development, especially since 
I have two different devices which need to be added.  

with the current host I might make my hackback do some usefull tests 
to help shape a working model aka prototype.

but the coupling with the core run-time is practically abscent.  
there is only one function I can use to have the run-time do anything 
and thats a pretty simple... do_rebol_string() which basically runs 
a block of code in the global space... beyond that I've only got 
network/file like ports, which basically are streamed I/O.  


I can't create data directly and leave it at the port, in a block, 
like I'd do for a proper event queue.   This is currently my pet 
peeve about the host... 


but let's not be judgmental... I'm VERY happy I have the host, so 
I can at least try to rig something up with bailing wire, duct tape, 
pliers, a bit of string & epoxy glue.  


 Extensions & the core allows me to hide this under a nice fiberglass 
 body  ;-)

But I will try to do this and specify the datatype. We will see.

@ brian: I understand what you say about working around... but, with 
the host right now, I can't do anything else than hack up a solution 
in order for extensions to have callbacks.  99% of the real work 
is inside the extension.  when the host will be improved, the extension 
work won't change.  I can't wait for things to happen... this solution 
is just for my own use, and it gives me a good perspective on how 
to help with a real solution.  


I'm also brushing up on my C skills (I haven't done any in over a 
decade!) so doing this stuff is a good exercise anyways.


right now, if I can show to Carl how complicated it is to do some 
stuff, he will have an explicit example and have a better reference 
for practical solutions.  Doing anything... its all just theories. 
 look at the notes on delect and command... this is similar... lets 
start with something.  see where that leads us and then, we have 
a reference to pick on and critique.  


We can have better ideas for the api, just by having something bad 
to start with.... and believe me.. I know my hack sucks ... but I've 
got part of the solution complete, and compiling without warnings, 
and some code sharing between extensions api and the host.  :-)

Maxim, you do realize that the purpose of the current host release 
is to test and improve the host model, right? Not to build final 
projects? If you run into problems in the host model, try to fix 
them, not work around them. Otherwise your work is a waste since 
the host interfacing model is going to change in the next version, 
hopefully based on your and my feedback. And a callback solution 
that doesn't integrate with R3's multitasking model is worse than 
having none at all - since any code that might be written to use 
it would need rewriting, and probably rearchitecting, very soon.

brian, yes we can add our own devices... in fact, it seems quite 
easy, and I will probably be adding a DB trigger device within a 
week or two.  :-)


the thing is that there aren't any exposed or documented *native* 
hooks from the host into the core... 


so far, I've got a callback library (called wire) working which executes 
rebol code in global context using the Reb_Do_String() r3lib.dll 
exported function  :-)


now I just need to use that library within the extension and see 
how it goes... the moment I have *something* which works... I'll 
stop improving the hack... from there on, I'll just work on the architecture 
of the caller and callee, to see how we could make it simple and 
easy to setup, from the extension and within the application using 
that extension... generically.


the code in between can change completely, it wouldn't actually change 
the extension or application code (that's the idea anyways)... just 
a few includes and headers which map how to link to the callback 
system.  I'll also try to build a device, just to see how that can 
be used instead of callbacks... but I still need to use a callback 
from the extension in order to access the host... so for now my hack 
is essential, whatever I do.


in this case, I'll be dispatching the GLUT events within the rebol 
using this architecture... I should have an interactive OpenGL window 
by tomorrow... crossing my fingers.


for now I am busy rebuilding my old OpenGL project within the new 
cleaned-up MSVS solution I've been working on for 2 days now... there 
are soooo many properties, its scary and long to setup... especially 
in this setup where there are several interdependent projects within 
the solution... but now, at least, when I change stuff at any layer 
and build, it builds all the stuff correctly in one step...

I know have added callbacks to extensions using a little hack with 
an intermediary dll I built, loaded by the host and any extension 
that needs to run rebol code.   so its fun to know that in the end... 
we already have ways to tailor the executable to what we need even 
when it officially doesn't support what you need.  :-)


obviously we can't do everything, but this little test is already 
nice.  right now I execute code when the OpenGL window is resized....

I will be adding events for mouse clicks and keyboard presses, so 
I can start interacting with the 3D rendered stuff.

yes... R3 is a completely different ball game than R2    :-D

yay!  real event model in place and functional for the OpenGL extension... 
its not a permanent solution but it will do for now.f


now the tedious job of creating stubs for a few hundred functions 
begins!


and hopefully by next week the first applications to show this off 
will be demoable  :-)


currently, including callbacks which create an object at each refresh, 
I can't  resize the window faster than the engine can redraw it (up 
to 1440x900, in 32 bit color, with a few shaded polygons ) , and 
this includes hundreds of lines of rebol being printed in the DOS 
shell.

The point of handle! is to store a value that REBOL can't really 
do anything with without native code. So it's a great place to put 
pointers.

I can make a simple /library like dll loader for windows if anyone 
really needs it.    I won't put time on this unless there is a real 
need, but if you need it, just speak up, its fairly easy for me to 
do.


a simple struct dialect would take a few hours to iron-out tops. 
 it would be much more flexible than the struct! datatype for sure.

I can make a simple /library like dll loader for windows if anyone 
really needs it.    I won't put time on this unless there is a real 
need, but if you need it, just speak up, its fairly easy for me to 
do.


a simple struct dialect would take a few hours to iron-out tops. 
 it would be much more flexible than the struct! datatype for sure.

I saw that one, but it doesn't seem to be the right approach. Two 
reasons:

- .so and .dynlib aren't dynamicly linked library formats on Windows, 
.dll isn't on Linux, etc.

- It kind of defeats the purpose of extensions: making all of that 
platform-specific stuff go away.


Don't get me wrong, the current behavior also has the second problem. 
Extensions are imported like modules, and so the code that is asking 
for them has to specify the filename to load them. However, *that* 
code is supposed to be cross-platform, so putting a platform-specific 
filename in their Needs list is inappropriate.


What do you think of using a generic filename extension like .rx 
for extensions, then having LOAD translate to the native filename? 
Or on platforms that don't require a specific filename extension 
for their dynamic library loader (like Windows), you could use the 
.rx extension directly.

Doesn't negate my argument. Having them named .rx will mark them 
as extensions, which have a specific calling convention that must 
be supported. Nonetheless, if you do decide to also allow the default 
platform dynamic library naming convention, only allow the name supported 
by the current platform. So no .dll on Linux, no .so on OS X, no 
.dylib on Windows.

We do. Simplifying the code would be to just support .rx and have 
the LOAD-EXTENSION native in the host code do the translation.

hehehe  I'll do my first tests, and then I'll see If I can wrap the 
platform-specifc parts of the process through dyncall's source code. 
 this way we will be able to compile the /library extension for any 
platform without any source code changes.


my design is to use header file macros which actually map the calling 
conventions based on your platform... THAT I can definitely borrow 
from dyncall if it BSD licensed :-)

Max, I don't know what you do but the overall concept would be:
1. Loading the DLL dynamically

2. Finding all requested functions dynamically (Windows has a call 
for this where you provide a string of the function name (just can't 
remember the call name)).

3. Implementing a generic R3 extension function that will be marshalled 
on Rebol site so that the first parameter will the function name 
and than all paraemters (I would use a block here).
4. Rearrange all this to call the Win32 function.

Robert, three problems with that approach (even just on Windows):

- Not all DLLs export that info, some just export numbered entry 
points ane expect you to use a .def file or some such.

- Even for the DLLs that do export names, the C-compatible APIs don't 
have info about function arguments, data structures, ...

- The languages that have real reflection models and encoded info 
(Delphi, C++, .NET, Java) aren't compatible with an R2-style model.

Which is what Maxim is working on. You can't use reflection with 
C-style APIs, and API models that you can use reflection on can get 
their own extensions to access them :)

Robert,  even if you know the function arguments, how do you call 
the function itself?


the extension will be compiled, so we can't create generic function 
calls.   The calling convention is part of a function's compilation 
process, on Windows any DLL may have three different argument passing 
methods simultaneously!!


get the problem is that you have to push arguments on the stack and 
retrieve them.  there are NO C functions which manipulate the stack 
directly.  these are always done via assembly, either inline or libraries.

Ok, I might have missed something. If you want to make it totaly 
dynamic than you are right. My ideas was more like a hybrid soltuion. 
Keeping the R2 structure how to deal with DLLs within R3(so you avoid 
porting code) but get use the R3 extensions model. Well, but you 
need to do the R3 extension. Not what most people would expect...

Here's the place to ask that question, Robert. The answer is that 
there may not be a way to do that until the next (redesigned) host 
kit comes out.

What I want to do is return a string that is LOADed before being 
returned.

Sorry, do you mean that you want to return new, non-string REBOL 
data in a block that you make? Right now you can do that (sort-of) 
with a limited set of datatypes supported, and it gets marshalled. 
There may be hacks to create more, but others would have to answer 
that with the current system.

Example: Rebol code sends [a b [c d] [e [f g]] h i] to extension. 
The extension makes a string out of this and stores it. Later the 
extension should take the string and make block out of it, so that 
the script gets a block! and can do result/1, result/b etc.

Carl,   what is left to do for the extension model to support view 
as an extension..

I mean, with absolutely no graphics, or view events related code 
within the core ?

yeah, but some tricks are MUCH easier and probably quite faster to 
do in R3.

You are thinking about scale relative to the wrong number. It's not 
a matter of how many lines the parse rules have, it's a matter of 
how many additions there are in R3 parse, and there aren't that many. 
Make the compiler once, and it will compile quickly. It could even 
do so at runtime.

Although Cyphre and I have both been able to build it using Mingw, 
other's have not been able to do so, and we're not sure why as of 
yet.


Therefore, we're not quite ready to distribute the host-kit to everyone, 
because we need more testing on it. However, if you want to actually 
test it (windows only), then ask Henrik for the download URL.

The host kit comes with all files necessary to build itself.  In 
theory, all you need to do is type "make" and it will produce R3/View 
(as r3.exe).  Also, make core will produce a core exe, w/o graphics.

The code includes some new host source files, for example to handle 
windowing and the related events.


Although this release comes with the AGG sources needed to do the 
build, note that these sources are pre-GNU versions, so are a bit 
older.


In addition, I suspect Maxim or someone may want to try creating 
an OpenGL version.


Soon, we plan to take a long look at making PAIR! into a float-based 
point, to allow better control with graphics. This somewhat non-trivial 
due to the assumptions in code that PAIR! is integer only with truncation 
for math operations.

Ok by me, but someone will need to collect the comments and issues. 
 You want to do that?

Pretty easy to do, but let's take this one step first.

So, we will want to get the makefile maker to do the right thing.

So, what header files do you find a need to generate above?

CMake does basically the same thing your "makefile maker" tries do 
to.

Do we have a test files to run to check if all areas of R3 that is 
implemented is working?

Jocko, you need to do more :)

continuing Request for object lookup within host/extensions here....



Here is a proposal (using example C code) for OBJECT access within 
extensions  this uses the EXACT same API as commands, and with just 
a little bit of work on the extensions API by Carl and a single hook 
within the r3core, we could allow callbacks within objects.


the advantage is that we re-use the same safe sand box as commands, 
and don't require to do much coding to enable it, AFAICT.


since object lookup is performed on demand, we can very rapidly supply 
an object to the command, and it doesn't cause any heavy-handed conversion 
at each command call if the object isn't needed.  more fine-grained 
control could be added so we don't need to frame the whole object, 
but it would be usefull as-is already.

RXIEXT int RX_Call(int cmd, RXIFRM *frm) {
	i64 i;
	
	// objects are frames, exactly like command arguments.
	RXIFRM *obj;
	

 // return values are also frames (with one argument), for type-checking 
 purposes.
	RXIFRM *rval;
	
	if (cmd == 1) {
		// ask the core for a frame which represents object.
		// attributes are returned in order they appear in object
		//

  // the command frame doesn't include the object frame, only a handle 
  to the

  // object which the core can understand. we then ask for the object 
  frame on-demand.
		obj = RXA_OBJ(frm, 1);
		
		switch (RXA_TYPE(obj, 1)) {
			case RXT_INTEGER:
	            i = RXA_INT64(obj, 1);
				break;
			
			// we could build a frame for supplying arguments to the eval
			case RXT_FUNCTION:
				rval = RXA_EVAL(obj, 1);
				if (RXA_TYPE(rval, 1) == RXT_INTEGER){
	            	i = RXA_INT64(rval, 1);
				} else {
					// return error
				}
				break;
			
			// wrong type
			default:
				// return error
				break;
		}
		
		// do something with the value
		my-native-function(i);

	}
}

so what do you guys think?

re: "GC recycling interruptions"  if we can browse the objects directly 
from extensions a lot of the need to "bake" command access within 
blocks and execute via do-commands is alleviated in the first place.

sure.


would there be a way to inspect an object to build something like 
in native C ?:

foreach words-of object [
	; ... do something ...
]

Well... I find that most coders don't pay close attention to their 
garbage side effects, but in a GUI sysetm, it's wise to do so.

As you can see here .. Max took it upon himself to do something about 
swig R3B0L support http://www.rebol.net/cgi-bin/r3blog.r?view=0231

I had to do this http://jira.rebolsource.net:8080/browse/REBOLKIT-6

one fun thing is that we do not have to use the C source types as 
the interfaces for the commands.

my next test is to build a generic object to parameter map.

so, if you have a C func declared as:
int myFunc (int a, int b)

you'll be able to call it from rebol using:

obj: context [a: 1 b: 2]
myFunc obj

not safelly. 


 while in the command, if you run arbitrary code, the GC might swap 
 the references you have while your in the command.  so that when 
 you return values, the data they used to refer ot do not exist anymore!

For example, in the case of two modules with same function names, 
you can use a direct reference to clarify which one you're referring 
to, or bind your code to a specific module. Easy to do.

I think we'll want to do that to some extent.

But we can't do that at present ... start a thread to call our extension

What we probably should do is designate a PORT type for intertask 
messaging, and make it easy to use.

If you are adding a module to the module list, and there is an existing 
module of that name, then the new module either overrides it, replaces 
it, or doesn't get added (possibly with an error triggered, but so 
far not). The question is which one to do in the particular circumstances. 
The factors are whether it is the same module, for whatever "same" 
means here considering it might be reloaded or still source; whether 
the versions are the same or greater; whether the existing module 
has already been made or is still source, and the same for the module 
to be added.

breakup rendering of an sequence into several threads and instead 
of messaging long running threads and having to build a complex application... 
you just something like

render-sequence: func [data frames] [ 
	repeat frame frames [
		dispatch 'pic-renders img: image-render data frame
	]  
	wait pic-renders 
	dispatch 'encode-movie do-encode %movie.mp4 img
]


the thing here is that the dispatch setup is external to the source 
code using bursts, and could be configured to use more or less threads.

you've got two independent bursts with a dependency

Carl - if you do tasks, we might get Cheyenne ported to r3 :-)

What we probably should do is designate a PORT type for intertask 
messaging, and make it easy to use.

Yes please. :-)

there is also a lot of work to do in order to provide support for 
more datatypes, but that can be done concurrently by a few of us, 
once the tools is public.

I didn't release the other version, because this formatting changes 
the generator algorythm, so that any work people would do to extend 
the tool, would have to be re-coded.

IMO IPC shouldn't be a default thing as there are zillions of ways 
how to do it.

One: yes, it would still be a problem even as an external extension. 
Two: we would have to do it as a host-embedded extension if we want 
to use this for the core intertask messaging solution, and that is 
the same as linking the code in.

Brian, I do commercial app development in REBOL as well as in-house.


Petr, I'm not here to defend Spread. I mentioned it because when 
I looked at it before, it was something I marked to remember because 
it wasn't too large or complex and didn't try to do too much (compared 
to, say, AMQP). 

I only played with it breifly, I didn't put it into production. 

I want a REBOL solution too. :-)

PeterWoo - you talk nonsense, which belongs in advocacy group :-) 
If you work for 35 years in enterprise, then tell me, if you met 
spread there. The messaging is done by so called middlewares. IBM 
has MQ series, SAP has XI. Those engines use the so called connectors. 
Everybody went the web-services route, hence having ability to talk 
SOAP might be more important for REBOL. I never argued against having 
as much libraries as possible wrapped to REBOL, the only thing I 
argued against is eventual 200KB library inclusion in REBOL, just 
to do IPC between REBOL tasks ...

Well - I don't mind. It is not about if I ever heard about it. It 
is all about - how much interoperability with outer world do we get? 
E.g. - can you talk to most Windows or Linux (Unix) apps with it, 
like Amiga Arexx? Can you talk to SAP, Orcle APPs, WebSphere, SharePoint, 
etc. enterprise apps? In fact and once again - -I expect having extensions 
to as many systems as possible, but we surely also know, how picky 
is Carl about what is going to be included into standard distro, 
and 50KB is considered being a big addition :-)

Is Carl prepared to do this though?

So, to mark an official release, like A110, is it only necessary 
to commit with that message, or do we need to make a tag as well?

Now someone should really write some short docs. This is so complex 
and surely was not created for normal mortal, who just wants to download 
few source files and build a distro? So I downloaded Tortoise Git, 
naively thinking this is all I need. No, so I installed Git preview 
version (not full msysGit). Now - what should I do? I created a directory 
called host-kit, right pressed mouse, and chose "create repository 
here" or something like that. Now once again I press right mosue 
button, and try either git-clone, or Git sync, but it does nothing 
... I think my problem might be (apart from being too dumb and not 
willing to spend tonnes of my free time with such complex stuff):

- I am required to have some kind of account at target site

- I don't have it somehow linked with SSH stuff (did not choose to 
use my putty installation during the installation phase)


How do I get the actual copy of R3 Host Kit? There might be plenty 
users as me, willing just to download recent sources, and build, 
not to commit anything ...

TortoiseGit's Sync dialog is basically one dialog with both pull 
and push in it. Pretty easy if you need to do either or both.

I think I will be more safe to just purge the directory befor syncing, 
as I don't introduce any changes to local files myself. OTOH I might 
do some small scripts for testing, and would like to not loose them 
...

If you want to always choose the remote changes, do not pull but 
_fetch_ and _reset_ instead.

Pekr, there's no need to purge, but it is a good idea to do that. 
 There have been various changes, some of which will not merge properly.