AltME groups: search

Hey Maxim, just a quick reply...


re 1) IMO that is not good argument. You can use GOB/DATA. It is 
really easy to change R3GUI rather to change GOB datatype.


re 2) Nope. There is no problem to have the current GOB/DRAW dialect 
for 3D commands. The current DRAW is completelz flexible and can 
be enhanced. Also if you are proposing abstracted way for 'renderers' 
then it shouldn't matter if you are rendering 2D or 3D objects so 
no need to have different dialects just because of 2D or 3D behaviour 
(see the OpenGL api, it is also mixed)


re 3) not sure what you are missing on the GOB! datatype..Can you 
clarify?


re 5) I disagree here: the 3D dialect is way to go. It should be 
possible to do a direct commands calls for simple things and use 
vertex arrays and other advanced features for bigger things. I don't 
see any problem why this couldn't be done by command dialect.

re 6) to 12) and the rest:
I'm not trying to make a 

cool" rebol plugin..." - so I hope you won't propose this Carl to 
put into the official HostKit distro :-P

The more you talk about your design the more it looks you are missing 
the point of Rebol need for HW acceleration in more generic sense. 
Don't take it personally, but your approach looks like just yet-another-opengl 
binding extension that every other language have. Until that I thought 
you are planning to do it in a more 'rebolish' way but nevermind, 
at least it is clear now. In any way I wish you good luck with your 
extension! ;)


BTW I think It's time to dust off my OpenGL accelerated R3 prototype 
soon... http://cyphre.mysteria.cz/tests/agg-hw.png(And it will work 
on *all* gfx cards made in the last 5 years ;))

I hope I get to it soon. i also wanted to fix the 'newline command 
handling in the text block which currently doesn't work well at the 
native level.

I tried to create a zip archive, but it is about the same size, so 
no help. IIRC there was some AltME version, which allowed to use 
bigger sizes? I think it would be good to have it as a command-line 
option for the server startup. It is my private world, and I would 
allow 20MB easily. It is not first time I got file bigger than 10MB 
I needed to post ....

I think so, you can specify it as a command-line parameter. But port 
numbers are limited, IIRC.

I have following in my altme.cmd command line script:

start altme -s "my-world" -p 5400

I've uploaded my FMOD extension test project to GitHUB:  https://github.com/Oldes/R3-extension-FMOD.

IThis is REBOL3's extension wrapper to FMOD API.

It has command for all 336 FMOD api functions, but 162 of them are 
just placeholders as it require more work.

I must say that this is my first C project which I'm using to learn 
C and REBOL Extensions, so feel free to correct me if you can.


Also I must note, that the main.c file was automaticaly generated 
so it's possible that not everything works, I tested just basics 
so far.

New update of RMA version of R3 host-kit is available at http://www.rm-asset.com/code/downloads/index.html

This release contains following changes:
-added active/inactive events
-fixed compiler warnings
-fixed modal window key events bug

-added window show states programatic handling (see SHOW command 
help)
-fixed unicode text rendering bug
-fixed memory leak in text dialect


NOTE: This version is also needed to be able run the latest R3GUI 
from RMA.

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 ;)

I've updated http://box.lebeda.ws/~rebolek/rebol/srec.rip.

The fibonacci function can now be written as:

fibr: command [
    len [integer!]
][
    o: 0
    repeat i len [
        o: o + i
    ]
    return o
]


and compiled to DLL. If you prefer c-code, just use string! with 
c-code in command's body, instead of block! with RebC dialect.

Anyway, if you don't use the dialect (the command body is string! 
with c-code), the compilation should work without any problem.

Looks like one need to be carful when designing the command interface 
(arguments) because if you insert an argument, the refinements shift 
to a new position. As the access to arguments on the c side is via 
positions you need to adjust your code. Need to think abou a good 
way to abstract this.

Re #6156: Pekr, we ARE NOT giving up on dialects!! There are many 
dialects in RE
BOL, and it is one of the main concepts.

What we 
are doing is removing the strong overlap in DELECT and COMMAND. If 
you l
ook at the DELECT method, it is a small subset of full dialects. 
It implements a
 form of function with optional arguments.

So, it's 
better to move that code into COMMANDS, and allow them to work that 
way
. This makes it much easier for people to learn and use. Even 
me!

Also, REBOL/Services will use this same method, because COMMANDS 
are not limited
 to just extensions... ah the secret is out: COMMANDS 
can also be attached to a
context, making them generally useful in 
REBOL code.

I will check the blog comments to make sure it's not 
misunderstood.

The way I see it is  that the code inside a command probably can 
be late bound to a context, rather than the global context, as it 
is now.


when extensions will support objects, this can be pretty powerfull, 
since commands can become virtual and private methods for an object 
where the data is stored in a stuct in the binary (C) side... 


which is EXACTLY what I need for liquid, where I need rebol dispatchers 
but native data storage, so it can scale to hundreds of billions 
of nodes, and yes I already have the solution for the storage/memory 
engine if Carl can give me the means.   :-D

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 :)

@ 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.  :-)

If no special AltME world is started for it, then R3 Chat is the 
answer. If I want to get Carl's attention, then magic command is: 
pu Carl - it will post private message to him ...

I have started to use WORDs as types in my extension arguments, but 
The code doesn't seem to follow the implementation...


In the docs it says that the words I define will start at 1 2 3... 
but the word I defined, seems to give me 152 when I pass it via the 
command...   here is a simplified code example:

in rebol:
import %my-extension.r
my-extension-func 'ext-defined-word


in C
RXIEXT int RX_Call(int cmd, RXIFRM *frm) {
	u32 action = 0;
	action = RXA_WORD(frm, 1);

	printf("%d", action);
}

prints out:    152

anyone else test word! as parameters in R3 extensions?

outer: func [] [load inner]
inner: command []

And you don't have to export the command if you don't want to.

The main thing: linear command evaluation blocks. The replacement 
for the delect method.


Once that's done, I'll release View, but only with the windowing/event 
system, not rendering... then, Cyphre can bring the rendering method 
back online as his time allows. (Or, you can do your own in OpenGL 
if you feel so inclined.)

http://www.rebol.com/r3/notes/command-blocks.html

After adding MinGW\bin and msys\1.0\bin to the windows command path 
and also copying rebol.exe to msys\1.0\bin folder, I was able to 
build it from a normal command window without modifying the makefile.

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?

Command arguments have limits on how many are passed. Those same 
limits would apply to object fields with your approach.

So objects with more than 7 fields wouldn't be supported? Command 
frames are marshaled, remember, they are not references to stack 
frames. If you want to pass an object and get access to its fields 
perhaps passing it as some kind of handle and getting access to the 
fields through accessor funcs would be better. Unless I misunderstood 
your code and you are doing this already.

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.

my extension building engine will probably be released tomorrow. 
  its currently building extensions which are 100% functional.


now I will add more types and implement the command interface directive 
so that we can mutilate how C code is bound on the REBOL side.

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!

no... just dont export them and do this:

lib: import %r3-test-extension.dll

lib/my-command arg arg arg

the way I see it is that for callbacks to be safe, the GC has to 
be momentarily locked.  otherwise memory swapping might occur within 
the core which isn't synchronised in the command (you get some pointers 
from the core) and those pointers might not exist anymore when the 
callback returns.

to make it work, carl would have to make a purpose-built C function 
which makes sure that memory used by a command is safely preserved 
for the length of the command, or something like that.

I'm hip deep in it right now...  I'm implementing the last "feature" 
which is the ability to format command arguments differently than 
the original C function parameters.


this will allow templating for extensions, just like in C++, and 
will also allow us to put litterals in the spec, so that one doesn't 
need to provide ALL parameters from the REBOL side.

this C header file:

//---------------------------------
// r3t_integer_add
//
// test: print [ r3t-integer-add 1 0 " > expecting: " 1]
// test: print [ r3t-integer-add 2 2 " > expecting: " 4]
// test: print [ r3t-integer-add 2 3 " > expecting: " 5]
// test: print [ r3t-integer-add 0 0 " > expecting: " 0]
// command-format: [object!]
extern int r3t_integer_add(int a, int b)


will tell the tool, to provide an object interface to the function 
rather than to expect two integers.

the assimilator is getting quite powerfull, we can now specify litteral 
values in the alternate command formats!


this allows C functions to be called with some of the arguments filled-in 
by default and requires one-less argument from the REBOL side of 
things.

and since we can specify as many alternate command formats as we 
want per C function, we can build a library of parameter-less rebol 
commands which call the C functions with usefull values built-in 
to the extension.

as a testament to what is now possible with the new assimilation 
engine, just look at how insanely flexible it is at allowing you 
to provide just about any interface to a command...

using this information in the C header...

// command-template: [obj [object!]] prefix: obj- suffix: 3
// command-name: rxt-iadd
// command-template: [a [integer! decimal!] b [integer!]]
// command-template: [obj [object! x y]] prefix: xy-
// command-name: plus10
// command-template: [10 [litteral!] value [integer!]]

extern int r3t_integer_add(int a, int b)


;--------------------------------------

one ends up with this command interface... all calling the same C 
function.

    rxt-module: {REBOL [
        Title: {r3-test-extension extension}
        Name: r3-test-extension
        Type: extension
        Exports: []
    ]
    rxt-obj-r3t-integer-add3: command [ obj [object!]]
    rxt-rxt-iadd: command [ a [integer! decimal!] b integer!]
    rxt-xy-rxt-iadd: command [ obj [object!]]
    rxt-plus10: command [ value integer!]

    rxt-r3t-integer-mult: command [ a [integer! decimal!] b [integer! 
    decimal!]]

;----------------------------------------


note that in this setup, auto-exports is set to false and an rxt-prefix 
was added to every command name automatically.

also note that the command templates are not required, they just 
allow you to manipulate how a C function is mapped to REBOL.  there 
are still many features to come, but right now I am working on finishing 
the last phase of assimilation which is the actuall extensigon C 
source code generation.

btw, this command  


rxt-r3t-integer-mult: command [ a [integer! decimal!] b [integer! 
decimal!]]


was automatically generated by a function without any command-template, 
later in the header file.

well, the fact that you don't have to write the command extension 
code itself in order to implement those 5 different interfaces is 
already a benefit.

http://www.rebol.com/r3/docs/concepts/extensions-making.html#section-17
says it's out of date and I'm really having trouble including words 
as symbols in a result block of an extension command. 

It works fine with an *INIT_BLOCK defined as


 const char *init_block = "REBOL [\nTitle: {Power Management}\nName: 
 power\nType: extension\nExports: [power-status]\n]\n"

     "lib-boot:           does [map-words words] ;-- Is that a good idea?\n"

     "words:             [ac-line battery remains of high low critical 
     charging]\n"
	    "map-words:    command [words [block!]]\n"
	    "power-status: command []\n"
;

if after IMPORT %power.dll I call SYSTEM/MODULES/POWER/LIB-BOOT.


Is there a way to have IMPORT automatically execute the LIB-BOOT 
code with a simple extension not included into the host code with 
host-kit?

I'm trying to return a block containg a word not taken from a commands 
arguments. Say, I want to return a block like [BATTERY CHARGING]: 

That works with

	u32 *word_ids = 0; // used to hold word identifiers
	enum power_words {W_POWER_BATTERY = 1, W_POWER_CHARGING};

	RXIEXT int RX_Call(int cmd, RXIFRM *frm, void *data) {
		/* .... */

		v.int32a = word_ids[W_POWER_BATTERY];
		RXI_SET_VALUE(s, pos++, v, RXT_WORD); 
		v.int32a = word_ids[W_POWER_CHARGING];
		RXI_SET_VALUE(s, pos++, v, RXT_WORD);
	
		/* .... */
   	}


only after importing the DLL I "manually" init the words with a MAP-WORDS 
command. I was thinking that IMPORT eventually triggers LIB-BOOT 
init-code from the INIT_BLOCK. It seems like the init code is not 
executed.

That MAP-WORDS command only does:

	word_ids = RXI_MAP_WORDS(RXA_SERIES(frm, 1));
	return RXR_TRUE;

Ouch! Now that problem above has a really simple solution: Just putting 
the module init code in the CONST CHAR *INIT_BLOCK works great:

	const char *init_block =
	    "REBOL [\n"
	        "Title:   {Power Management}\n"
	        "Name:    power\n"
	        "Type:    extension\n"
	        "Exports: [power-status capture-screen]\n"
	    "]\n"

     "words:          [ac-line battery remains of high low critical charging]\n"
	    "map-words:      command [words [block!]]\n"

     "power-status:   command [{Returns ac-line and battery status information.}]\n"

     "capture-screen: command [{Returns screenshot as an image.}]\n"
	    "map-words words\n";


The "magic" is the last line, where MAP_WORDS WORDS is evaluated 
ofter loading the module, that command inits the dll with the word 
ids used by the extension.

I have built a simple R3 extension for ODBC database access. Although 
more work needs to be done in the unicode area and configurable rowset 
max-rows retrieval as well as catching some GC-related bugs, basic 
functionality like selects, inserts, updates and statement parameters 
is there and working for most major types like LOGIC!, INTEGER!, 
DECIMAL!, TIME! and STRING! I have to test with more databases / 
odbc database drivers. 


I have, however, major problems in working with date values. I just 
don't manage to retrieve date values passed to a command or to return 
a proper date value. So, has anybody succeeded in working with date 
values and probably knows how to create, access and calculate them? 
Sadly, I've found no example code related to date values and there 
isn't much documentation too. Any info is greatly appreciated!

I've looked in DevBase, but haven't asked questions there yet. I've 
scanned all the extensions documentation on DocBase and the header 
files in the host-lib/extension packages. 


I didn't even manage to read a date value in a simple command like 
   TEST-DATE: COMMAND [DATE [DATE!]]      About every member n the 
REBOL value c-union type seemed to only contain zero values.

Hmm, I think I've to check this again. At least, a simple 

    RXIEXT int RX_Call(int cmd, RXIFRM *frm, void *data) {
        return RXR_VALUE
    }
    
returns a proper date value for

    test-date: command [date [date!]]
    
I'll see if I can find some time to work on this evening.

I understand the REBOL part of it, but would like to see how to do 
the DLL trick part. Including the correct gcc command.

Could you upload the C source as well? Btw.. I would rather use linkage 
to MagickWand.dll to be able use direct commands instead of command 
line like IM commands.

yes,  the above discussion is wait command inside loop.
BTW what time events you mean?

Any news how implementing command wrappers for AGG goes? Or on GUI 
status in gerenal? :-)

If this is the issue there are two solutions.

1. even now you can set the transformation matrix for example using 
MATRIX command(or other matrix related commands)  to change that

2. internally in the AGG code there is a way how to change the order 
in which the scanlines of the framebuffer are rendered in the Y-axis. 
In other words you can flip the Y axis.

We we look at this from the performance POV:

-IIRC the transformation matrix is *always* used in the graphics 
pipeline so it doesn't matter if the matrix is set to 'top-letf' 
or 'bottom-left' or whatever else. There is no performance difference.

The only difference is that if you want to change the 'origin' you 
need to put one mroe command into the DRAW dialect block. I think 
you will agree that one more matrix command in the block can be assumed 
as almost no performance penalty.

I misunderstood your suggestion, Robert. I thought you were talking 
about adding an IF command to the layout dialect, not to the code 
in the ().

The IF command in the dialect would get rid of the COMPOSE and do 
this: view [button if (condition) button button]

That is what I meant by a Parse-like IF. Possibly not doable in the 
layout dialect, due to overhead.

the gob will act as a container for an OpenGL context (and viewport).


so a single gob! will store the whole 3d scene, not just a single 
poly/shape.   I guess I'll have a command block similar to gob!/draw 
 to define some aspects of a 3D scene (though not everything... since 
3D is pretty heavy... probably things will be loadable from ram and 
disk)

The standard design pattern applied to undo/redo is the Command pattern, 
which implies that everything you want to undo or redo is a command 
that knows what it means to perform an action and apply its inverse, 
and the target of the action.

also most undo/redo tie-in commands with macros and/or actual gui 
buttons and menus... sort of like the internal API for the lower-level 
stuff.


each of these commands/actions puts itself on the undo stack  and 
usually has a counter command...  add-text/remove-text, edit-record/restore-record, 
etc.

Kaj, if you have any links to fully native GUI applications for Android 
that don't use any Java or Dalvik at all, please post them. I have 
been looking for any indications that such things are possible, and 
haven't found any yet. The SDL seems to be linked as an NDK library, 
not as something used to make native apps. All of the native apps 
I've seen are command-line only and not runnable from an icon in 
the applications list. I'll keep looking.

btw - will DELECT still remain? New COMMAND type seems to remove 
the ability to have random order of parameters. And quite honestly 
- I don't like it. It might be good for very fast low level engines, 
where speed matters, but I still want the flexibility of random parameters. 
So - will DELECT remain for dielact builders, or will we have to 
fall-back to full parse in such a case?

DELECT could be used to convert a dialect block with unordered and/or 
parameters to commands into a command block with ordered, mandatory 
arguments. It does it already; all that would be necessary is to 
have if generate its results in a flat block rather than nested blocks. 
There would be no need to remove it - just change the output format.

ok, but that is a fringe case which probably got put there specifically 
to allow that specific pattern so that some command-line functions 
can be simplied... 
its not the intended use of Rebol.


argument passing by reference is rarely used (a few mezzanines and 
highly specialized situations)

they are mainly used for command-lines and code analysis funcs (?? 
for example)

inside?: no
parse-ml "...your text..." func [command data] [
    either inside? [
        ?? command ?? data
        if command = </tag> [inside?: no]
    ] [
        if command =  <tag> [inside?: yes]
    ]
]

call/wait/output was (for me) the most used scenario, wrapping some 
command-line tools and obtaining the result. That way you can simply 
wrap e.g. SQLite.exe result, without the need to have proper driver 
...

so for example, if an application halts due to an error... the stack 
is effectively empty, since its back to the command-line.  :-(

ex:  I added a voluntary 0 / 0 to generate an error.

liquid/add[3]/instigate() [
** Math error: attempt to divide by zero
** Where: / unless cleanup switch foreach either if insti
** Near: / 0 plug/dirty?: plug/valve/purify plug if all [
    plug/re...

>> stack 10
== none

and the plus package is on by default, unless you switch it off on 
the command-line.  which is a good idea IMO.

There is no reason that R3 can't have standard builds that include 
everything. In fact, the blog says as much: Most of the options are 
opt-out based on a command line option, not opt-in. But we definitely 
need some stuff to be opt-in, like graphics stuff on OSes like Linux 
that don't necessarily have the supporting libraries.

Yeah, I was thinking an opt-out command-line option would be the 
best. That way we can keep running with all the functions we've gotten 
used to.

yeah, the command-line is a program like any other.. its just the 
I/O from the shell which is really complex in MS... 


the actual text user interactive session is totally controlable... 
just look at python's IDLE which is basically an example of R2's 
console but in DOS console.

pekr, its a console application, just like our current R3 CLI.   
a console is simply a place which accepts lines of input interactively 
and spawns processing upon hitting a complete command.

Pekr, Andreas is right. The problem is that the 'flag' if the app 
is of Console or GUI type is set at compile time. So when you execute 
file th Windows kernel just checks that flag and if set to 'Console' 
immediately creates console *before* the main() of your programm 
is called. So even if you put: ShowWindow(console, SW_HIDE); as the 
first command in your app you'll always see the console window for 
a while, which is not so nice ;)

Based on some simple experiments I did some time ago, mezzanines 
are roughly 2.5 times slower than the aequivalent command (i.e. extension 
function).

My 2 cents. 

It appears to me that the new RETURN command is underated currently.
It can compete in many places with idioms involving FIND + COPY.

I wanted to avoid using objects as an extension's command argument, 
but I decided that it will be more user friendly to use object directly 
anyway... more work on C side, but it worths for it.

make a new native as an extension, link it as a command :-)

Command is the best solution for me... I just wonder if there is 
not a better way how to write it in C, like using pointers or something 
like that

Command call frames are not made up of 128bit values, afaik, they 
are 64bit unions.

Whenever /View/Pro or /Command was invented.

The non-dialected behaviors seem simple enough (for the purposes 
of discussion I've read the docs). The problem is in the dialect, 
especially these:

- "Negative values can be used to skip in the series without returning 
that part:"  Why not use a 'skip keyword for that?

- "Note that for greater control, you can use simple parse rules:" 
 Which ones?

It really is a dialect, but the language is not confusing (first 
case) and not well defined (second case). Using keywords would make 
the dialect easier to understand (and thus use), and potentially 
more efficient to implement using command dispatch.

I'm curious: How can you get a word 'b bound to a function context, 
when the function is not running, you don't have access to the original 
function body, and all you have is a word 'a bound to that same context? 
No command or extension tricks either - they're already assumed to 
be unsafe.

I'm curious: How can you get a word 'b bound to a function context, 
when the function is not running, you don't have access to the original 
function body, and all you have is a word 'a bound to that same context? 
No command or extension tricks either - they're already assumed to 
be unsafe.

 - I offer you this statement, which I *can* prove in a reasonable 
 sense:


- I assume, that F is a function having a context with more than 
one variable (Otherwise, there is nothing to prove, is there?)

-, so, for the simplification, let's assume, that there are variables 
'var-a and 'var-b in F's context, such that:

- the Attacker has already access to the variable 'var-a bound to 
the F's context

- , but he does not have the access to the variable 'var-b bound 
to the F's context yet

- now, let's assume, that having access to the variable 'var-b in 
the F's context he would be able to "do some harm" (whatever that 
"harm" is)


Provided, that the above conditions are met, the Attacker is already 
able to do the harm even not having the variable 'var-b bound to 
the F's context available yet. Do I have even to prove the statement?

Neither R2 nor R3 considers it to be a problem making this directory 
in WinXP:

make-dir %.../


but the directory is never made, as far as I can tell. Doing it from 
a command prompt returns that the directory already exists.

From the loading modules doc: "...if a version number appears before 
any module name, it is assumed to be the REBOL system version.

  Needs: [3.0.2 mysql 2.3.0 http-server 1.0.1]

 Is there an explicit alternative? And how would you specify that 
 you need View or Command rather than Core?

And for checksums, would 
 it make sense to allow a keyword before the checksum, so you could 
 choose md5, sha1, or something else in the future? An unmarked binary 
 could still be sha1. I know it maps to the /check refinement on IMPORT 
 as well. I'm just thinking of implicit meaning versus long lifecycles.

Gregg, for R3 the View, Core and Command stuff are considered to 
be capabilities, not builds. With the host kit, we are assuming dozens 
of different builds (afaik). If you want View capabilities, put its 
module in your Needs header. Yes, I'm aware that they aren't yet 
fully modularized, but that is the plan.

There are certain advantages to writing user scripts for the front 
end code:

- The user context will be task-local, so a lot of the multitasking 
problems will go away.

- The user context is shared by all scripts running in the same task. 
It acts like a shared isolated context.

- User scripts have fewer settings in their headers. For that matter, 
they can have no header at all. Every command you enter into the 
command line is a separate script, for instance.

this is true of all lit-word arguments and is probably why we don't 
use them often, they brake the visible chain of command.

(previous line is for scripts, obviously makes no sense for the command 
line hehehe)

it should return the time, I've got ftp synching routines which use 
info? and use date/time.   so I'd bet its a limitation on the server, 
or its using a non-standard date string in its LIST command.

You might also try connecting with the FTP server with a command 
line client like NcFTP and looking at the listings directly.

Git is small

 on Linux. But has to install half of the command line userspace of 
 Linux on Windows if you want to use it there (when last I checked).

Quick notes:


I downloaded via the Git link that Oldes posted above. It's ~12MB 
(reasonable.)


Installed fine on XP.  Yes, this is a shell version, which is fine 
with me since I like to use scripts anyway for merges, builds, and 
releases.


I have yet to try git with github. It would be great if someone could 
post the magic command line to checkout  the existing repository 
(anonymous currently),


Regarding GUI version: it would not be difficult for someone to wrap 
a few REBOL calls it to give you a bit more GUI feel. Not perfect 
of course, but something clickable.

But you do not get that if you just clone someone else's repository 
in a read-only fashion... i.e. with the clone command " git clone 
git://github.com/rebolsource/r3-hostkit.git ".  It's easy enough 
to fix later, but you can do it up front by starting with a fork 
if you know you are planning on making changes and sending them back 
to the project.

The respective command for that is "git push".

Btw, I strongly recommend doing a:
$ git config --global color.ui auto

Which will instruct git to use ANSI colors in command output to the 
terminal.

So, there's a git patch command to emit patch file?

Is there a command for renaming files?

From the command line:
$ git clone http://github.com/rebolsource/r3-hostkit.git

Ah, it was me then, running Andreas's command without checking the 
setting first.

Andreas, it is easy to move the TO-* to the command line.   It was 
originally put in a file to try to keep the gcc line shorter (easier 
to see compiler warnings.)

Well, there are detections available at that level, as well, such 
as the uname command on Unixy systems