AltME groups: search

Interesting question on R3 Chat - is it possible to transfer opened 
file handle from REBOL to extension, or does file have to be reopened 
in extension and worked on from there?

Probably to BrianH: is it possible to open file in Rebol and transfer 
the filehandle to extension C routine? Or is it neccessry to give 
the filename as parameter and reopen in extension subroutine?

I already did a header file scanner a few years ago... but it wasn't 
recursive... nor did it resolve macros.

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

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

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

They don't have to be network or file port types either :)

I've checked the host code and afaict, you can add your own device 
types. You don't have to stick with just file, network and clipboard.

And I'd also keep the platform specific extensions in system/options/file-types

Windows is the one that needs to use the .rx extension the most, 
and the one that we definitely can use it. And system/options/file-types 
has to have the extension we are trying to LOAD, not what it might 
be translated to.

It's not hiding. Most of the executable file types on Windows are 
really DLLs, including .dll, .exe, .ocx, .vbx, ...

$ file ext/sample.so 

ext/sample.so: ELF 32-bit LSB shared object, Intel 80386, version 
1 (SYSV), dynamically linked, not stripped

$ ./r3 -sq
System object protected
>> append system/options/file-types [%.so extension]

== [%.bmp bmp %.gif gif %.png png %.jpg %.jpeg jpeg %.dll extension 
%.so extension]

>> import %ext/sample.so
>> add-mul 10 20 30
== 900

And have you tested by adding .so to system/options/file-types at 
runtime and then using IMPORT on an extension?

>> append system/options/file-types [%.rx extension]

== [%.bmp bmp %.gif gif %.png png %.jpg %.jpeg jpeg %.dll extension 
%.rx extension]

>> import %ext/sample.rx
>> add-mul 10 20 30
== 900

Cool, like Windows. I can make a mezzanine patch for the platform 
file-types that would work for all supported platforms if you like.

Fortunately the module system is based around importing into the 
system, rather than importing into modules directly. This means that 
you can have all of your platform-specific requirements handled by 
one module or script and then have the rest just reference by module 
name, not file name.

Andreas, what do you think of this code instead?

append system/options/file-types [%.rx extension]
switch fourth system/version [
	3 [append system/options/file-types [%.dll extension]]

 2 [append system/options/file-types [%.dylib extension %.so extension]]
	4 7 [append system/options/file-types [%.so extension]]
]

switch/default fourth system/version [
	3 [append system/options/file-types [%.rx %.dll extension]]

 2 [append system/options/file-types [%.rx %.dylib %.so extension]]
	4 7 [append system/options/file-types [%.rx %.so extension]]
] [append system/options/file-types [%.rx extension]]

append system/options/file-types switch/default fourth system/version 
[
	3 [[%.rx %.dll extension]]
	2 [[%.rx %.dylib %.so extension]]
	4 7 [[%.rx %.so extension]]
] [[%.rx extension]]

?

Further it's lost within the discussions at some point. I just wanted 
to provide the file so that it can be reviewed and included in the 
next release.

AltME File Sharing?

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

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

Yes, it basically boils down to an adapted Makefile along with an 
auto-generated header file (or defines) for platform-specific config.

Second, the config controls are already part of R3, and are triggered 
by the reb-to.h file.

CMake Input is a "CMakeLists.txt" file, which is written in "just 
another Makefile language".

Graham, did not visual studio 2010 convert properly the visual 2008 
project file to visual studio 2010 ?

I have successfully mechanically generated  a complete r3 extension 
and test script, by simply parsing a C language .h file.
  

if you have a makefile ready for your extension, it will even compile 
the extension for you and launch the test script in a single pass 
of the engine.

this is based on the latest r3 A101 build.

using comments in the C source, you can give instructions to the 
engine on alternate bindings and rebol test code you wish to compile.


the advantage is that these comments are side-by-side with the original 
C source file, so its easy to maintain.

the current code is a single ~16kb file,  so its not too large right 
now.


obviously as more types are added, this will grow, but since I'm 
using a "rebol-formatted intermediate source tree", its easy to improve.


the parser just generates a version of the C source in this "RFIST" 
format, and the generator only has to convert this into something 
else.


in time, we might even build different emitters for the "RFIST" data.

I notice that as long as my r3 instance is running, the dll I imported 
has a file lock on it.

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.

What file did Carl say contains the new documentation?

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.

Graham, you don't for a single machine, but you would need a memory 
mapped file, named pipe, or something else. The question is whether 
you want an IPC system that is limited to the local machine.

I added a second file, sample2.c, to demonstrate working with strings 
in A102: https://gist.github.com/bc820cc3eb301c79c1ef#file_sample2.c

Also compiles and loads fine for me.

With this version, all the inputs and outputs are files. I'm waiting 
for more specs before loading directly into memory. It's possible 
to convert many file formats (including tiff) into may others.

is your file a .c or .cpp  ?

you can try adding 

extern  void RL_Print(char *fmt, ...);

at the begining of your file.

I've got it... the file was .cpp instead of .c

Maybe I'm doing something wrong...

R3 current version: 2.100.110.3.1
It was released on: 2-Nov-2010/3:55:04.875

Your version is current.
>> do %r3-gui.r3

Script: "R3 GUI - load and start" Version: $Id: $ Date: 9-Dec-2010/10:32:04+1:00

>> change-dir %test-framework
== %test-framework

>> list-dir

core-tests.r   cpl_2_100_110_3_1.log         docs/          flags.r	test-framework.r
>> do %test-framework.r
Script: "Untitled" Version: none Date: 16-Jul-2010/13:05:26+2:00
Testing...
file: core-tests.r
LOAD/next removed. Use TRANSCODE.

Done, see the log file: /C/Documents and Settings/striker/Bureau/R3/test-framework/cpl_2_100_110_3_1.log
Total: 1 Succeeded: 0 Failed: 1


Log file :

file: core-tests.r

failed, file parsing unsuccessful
Total: 1 Succeeded: 0 Failed: 1

Why ?

(unless you changed the original file)

Seems to be better.  But what is final result expected ?

>> do %test-framework.r

Script: "Test-framework" Version: none Date: 19-Nov-2010/15:00:45+1:00

Script: "Line number" Version: none Date: 1-Nov-2010/14:21:20+1:00
Script: "Catch-any" Version: none Date: 3-Nov-2010/4:58:46+1:00
== make object! [
    log-file: none
    log: make function! [[report [block!]][
        write/append log-file to binary! rejoin report
    ]]
    skipped: none
    test-failures: none
    crashes: none
    dialect-failures: none
    succeeded: none
    failures: none
    exceptions: make object! [
        return: "return/exit out of the test code"
        error: "error was caused in the test code"
        break: "break or continue out of the test code"
        throw: "throw out of the test code"
 ...

Does RM-asset version of A110 support the SHAPE dialect? I can access 
the glyphs in OpenType Font File now, and I would like to draw the 
Chinese characters using SHAPE dialect in R3.

I would like to give GUI a try, but to be honest, the current public 
state is good only for reviewing, not for participation on the developement. 
I mean... I really don't want to hack one file which has 256kB. So 
I'm asking again, wouldn't it be better to put it into a real source-code 
system (or in case you have one already, which you probably have 
internaly, to create public mirror of it).

I would like to give GUI a try, but to be honest, the current public 
state is good only for reviewing, not for participation on the developement. 
I mean... I really don't want to hack one file which has 256kB. So 
I'm asking again, wouldn't it be better to put it into a real source-code 
system (or in case you have one already, which you probably have 
internaly, to create public mirror of it).

Henrik, wouldn't it be at least posible to pack the files separatly 
(not to have them all in one file)? It's really unusable for other 
people than you in such a state. Especially when you are modifying 
5-10 files per day.

Plan: The plan at first is to prioritize what styles mentioned above 
should be written first. It's not a complex roadmap.


Docs: will have to update the status on those, but some are available 
in the r3-gui-src.zip file.

same file at the begining #include <windows.h>

http://94.145.78.91/files/r3/gui/252.png


SCRUM tool prototype GUI example. We are exploring how to organize 
the GUI, as the R3 GUI can be used to prototype things now. The next 
step here is to get it integrated with the database reactors prototype 
written earlier. If that is done correctly, we should be able to 
switch from a prototype file database to a different database backend 
(SQL based) without touching any GUI code.

One naming tip - I noticed, in button.r3 source file for e.g., that 
we started to use multiple draw blocks? That's good. So - e.g. clicker 
style has two draw states (frames) - normal, and focus. Just a question 
- does "normal" sound good in english? Shouldn't be "default"?

Rebolek - yes, and that is why I prefer things having in one file 
per style ....

I mean - there is an engine. And then there are styles. My idea (maybe 
wrong :-) is, to have one file per style, containing everything style 
related. Or at least having max 2 files. panel.r3, panel-funcs.r3. 
I just don't know - looking into style definitions is a disappointment 
for me - there is only few basic things, and there should/could be 
more. First things which come in my mind is materials, then options 
block handling, and I can imagine even functions: [] slot, where 
all related functions could be put.


I'll leave it where it is now, before the system is more complete. 
But later on, if I have a feeling, that there is some usability problem 
for users, I'll restructure the system myself.

Robert - my long time experience is, that code reuse is very often 
being a trade-off. I can't even imagine, how you make new material 
for your new customer. You don't have any visual tool for that anyway. 
And I am not sure if I can if it is in separate file, or with each 
style. I can understand the plug-in mechanism, but I am just right 
now not sure, if it outweights the usability aspect. I simply remember, 
that I liked to use the AMOS basic. Because it allowed cool things 
rather easily. And if users like the system they use, they will use 
it, and extend it. And sometimes it is about how cleverly the code 
is organised. We will see, how it turns out ...

This doesn't seem to happen if I load the single GUI file and write 
my own Hello World

The crash seems to happen due to the TITLE widget, because it also 
crashes with the single file GUI

if you use a request function to display a message, this is the cause 
of the problem: the request function from RMA is bugged (and also 
the alert). You should either correct in the RMA r3-gui.r3 file, 
or, better, overload it. change the words group  by hgroup , and 
change the line doc (message) by text-area (message)

Cyphre - just some friendly opinion exchange, hopefully you will 
be able to understand my explanations (which don't necessarily represent 
my exact point of view):


- most ppl here are well aware of the fact, that RMA is a business 
entity, and hence has absolute right to do what makes sense for its 
business. The trick is, that in the end, it does not work for ppl, 
I will tell why later.


- The point above is even more difficult to understand, as RMA is 
offering its work for free, yet ppl still complain to something (including 
me of course)


- What might have failed is, that ppl might think, that accepting 
SCRUM method will mean, that we have finally found a viable model 
for  general R3 development, which will allow Carl to stay available 
 to small agile team of developers, isolated from the noise.


- Ppl were expecting GUI to probably appear in 2-3 month period. 
Althought Carl's GUI worked mostly on the surface, it was something 
ppl could experience. RMA's aproach is much broader aproach to usability 
and architecture. But - that resulted into refusal to provide usable 
demo. There was some attempt to provide style browser, but it was 
highly unusable to attract ppl.


- RMA seems not to understand (or it is not its priority) the importance 
of visuals. You surely remember the "design sells" claims, which 
are know for ages. Do you remember your Rebcon AGG demo? So much 
joy, so much applause. The current look of the GUI and its metrics 
just ruined the "hmm, nice" first look experience, and for no apparent 
reason, then constantly repeating "the skin will be done later". 
If so, it should not have been changed in the first place. (After 
porting the demo, my next area to play with is to try to play with 
material system, etc., and box-model style metrics)


- Ppl are well aware, that RMA is mostly on its own, and that even 
SCRUM methog did not work in regards to keep Carl attracted to such 
method in the long run. We are now facing the worst ever period of 
R3 development, where Carl apparently has some other projects, and 
R3 is almost stalled. Ppl are clever enough to realise, that we are 
being fed with some mid-time blogs, which should keep us distrated 
from the facts (huh, rebol file suffix importance anyone?), and we 
are also facing rushed releases as A111 is, and 2.7.8. was. You are 
free to not agree, but that is how I personally feel about the situation 
towards the RT. In the past I would probably write some letter to 
Carl, but I am at the point where I think, that RT is effectively 
burrying R3 under month by month. So - Carl is not able to find free 
time to continue with R3 development on a regular basis, and noone 
is denying his right to personal life, but - the fact is, that R3 
situation is at least - worrying. We wait for the beta plan for more 
than 4 months! If someone does not have time to even think how to 
proceed, then it is probably time to close the shop ... or open-source 
... but that will not happen. So - welcome the Amiga fate ... 


- And before someone else adds it, I will add it myself, as I believe 
I have my points right :-) Amen! Could I be wrong? Of course I could. 
You can easily state - hey, the situation is not like that, we know 
Carl works on this or that. Well - RMA knows, but that's it - the 
rest of the community is kept in information embargo from Carl. And 
that is difficult to deal with for many of us, who really like REBOL, 
and would like to see some coordinated development and the light 
in the end of the tunel once again ....

I implore you to read the discussion better - with an open mind. 
For example, the r3-gui.r3 file is from your own distribution

Regarding the date: currently, it is just the date of the file loading 
the whole GUI, which has not changed since December.

The r3-gui.r3 is the whole code, but it "gets" the information from 
the main (loader) file

The file with the whole code should at least have a modified date 
that matches when it was last built, or match the most recent modified 
date of its component parts.

Ladislav, thank you for the link http://www.rm-asset.com/code/level1/r3-gui/
. The point is that this link is a presentation page, referring to 
a second one (downloads) which at last leads to http://www.rm-asset.com/code/downloads/files/r3-gui.r3
... the link that I used from the beginning. And so far I have no 
means to check if the file that I use is the latest one. Are you 
sure from your side that this file has been updated, and corresponds 
to the version issued 28th, january ?

>> probe info? http://www.rm-asset.com/code/downloads/files/r3-gui.r3
connecting to: www.rm-asset.com
make object! [
    size: 263986
    date: 2-Feb-2011/9:31:04
    type: 'file
]

Header update:

REBOL [
    title: "R3-GUI"
    file: %r3-gui.r3
    from: "RM-Asset"
    url: http://www.rm-asset.com/code/downloads/
    history: http://www.rm-asset.com/code/level1/r3-gui/
    license: http://www.rebol.com/r3/rsl.html
    version: 1917
    date: 25-Feb-2011/17:50:30.907555
    purpose: "REBOL 3 GUI module"
]

Is this fix mentioned in the tickets you put ?

I did not read them up to now, I wanted to correct quickly the version 
which used an out of date r3-gui file.

For the other fixes, I will introduce them later (Or you, if you 
want). And I will take some time to make the other examples work, 
out of RMA documentation.

the two fixes that I put in my demo file are on the doc style, and 
on the request function

Hi, guys

Once again, congratulations for the excellent work done.

As Rebolek suggested in ALTME, I have some modifications to submit 
(of course, to check from your side) for the next r3-gui release.


I must first mention that I just realized this morning that the r3.exe 
 pre-compiled version of march 11th was not working properly, bugging 
with some very simple text displays (probably an old version). That's 
the reason why I did not update the demo with the most recent r3-gui 
file. By the way, the  build date displayed by the exe remains the 
same whatever the real building date. I don't know how we could have 
an automatic update of the build version.


Rebuilding from your sources (march 11th) allowed the demo to work 
properly apart from some appearence differences (I have even seen 
some bugs solved compared to my demo version). However, I will wait 
for your next weekly release ;-) to update my demo.

Coming back to the propositions of modifications :


It seems that there are definitions problems, or incompatibilities
in r3-gui (around line 66)        
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

in r3-gui (around line 1729) 
;-- scale: [decimal! decimal!]  
scale: [pair!]

also, I overload the drawing style by this code :
stylize [
    drawing: sensor [
        about: "Simple scalar vector draw block. Can be clicked."
        tags: [input tab]
        facets: [
            init-size: 100x100
        ]
        options: [
            drawing: [block!]
            init-size: [pair!]
        ]

        actors: [
            on-make: [
            ;    if block? drw: face/facets/drawing [
            ;       bind face/gob/draw: copy drw face/facets]

            ]
            ;-- JC
            on-draw: [face/facets/drawing]
        ]
    ]
]


Concerning the discussion of this morning on groups and panels, I 
would also prefer to have a default horizontal arrangement, and only 
precise when vertical: group, panel, vgroup, vpanel. A side effect 
is that it would remain compatible with Carl's doc.

By the way, it seems that tight is vtight. Logically, it should be 
htight.


That's all for the moment. When debugging the last demos, I may find 
other issues.

If I make a patch file that fixes the mezz problems, including the 
module-related ones, will that work? For now (when the module list 
isn't really protected yet) this is doable...

I load a patch file in %rebol.r right now, for my work use of R3. 
If I was doing my own host builds then I would put a reference to 
the patch file early on in the host-init code.

I have a list of fixes and improvements in mind, so I'll see if there's 
some time by the end of this week to put together a patch file. I'm 
sorry that I haven't documented the module system well enough to 
make it practical for anyone other than me to patch it at runtime. 
Improving its documentation is on my todo list, though I've been 
a bit busy at work lately.

Hopefully this patch file will serve as an example for others who 
want to do similar patching.

I succesfully 'overloaded' some mezz functions in R3 in the RMA hostkit. 
See the inclusion of %rma-patches.r file in src\tools\make-host-init.r 
in the RMA host-kit release. So it is possible to do some fixes that 
way.(of course not every part can be tweaked such way)

Yeah, I thought it was strange as well. Thought I read a note from 
Carl somewhere about a restore with a corrupt file... possibly a 
casualty?

what I'd recommend is for you to get to grips with the MS build of 
the host & extension.   just to get it compile and understand the 
file structure.

then, once carl or maybe henrik, gives you a link to a file with 
the Amiga stuff, you'll be in a much better position to port it.

ah.... just found out that I setup my merge app to store backups 
on all file saves  :-)   yay.

ok in the include file  "host-lib.h"

there is an entry at the begining that says:

#define HOST_LIB_SIZE 31

batch file with loop and make  ;-)

btw, andreas, I've almost finished re-working the CGR make file so 
that it organises the files just like the VC setup (and its already 
using the distro r2.exe)

when it gets to complex, its extracted and put into an isolated file, 
which is how its been evolving so far... quite straightforward.

I'd just rename the rebol BOOL to some other Identifier,and do a 
quick recursive file replace... I looked and its not used that much.

ssolie: the only file that needs to be reformatted so it supports 
other platforms than windows is agg_truetype_text.cpp + .h

Otherwise there is already available FreeType wrapper so the rest 
of code can work  even on OS4

But the current hostkit code needs some more work to extract the 
font/text rendering parts so they can be controlled by defs.

If you don't want to waste time on this I can have a look at it over 
the weekend and make the changes so you should be able compile without 
the text code for now. Just let me know.

no need to compile anything, there are example scripts and compiled 
versions  in the cgr-apps of that zip file.

if RDC_QUIT isn't working should I file a bug report?

I suppose I should go file a bug report right now so we don't forget...

If you don't have the ability to intercept the closing of the window, 
then you will cause data loss in apps, and not giving the program 
a chance to clean up (temp files, file locks, etc.) when quitting. 
Tthis deals with more than plain warnings of window closure. This 
is a UI and app specific behavior issue and should really not be 
controlled on a low level.

Easiest way to find all the posted results:
    http://www.rebol.org/aga-search.r?q=disk/file

I may be missing something fundamental, but


1) am I supposed to be able to build a A110 r3.exe from the sources 
at github.com/carls/R3A110 on Windows with MinGW and gcc? The gcc 
makefile differs in a lot of places from earlier versions (A109 and 
below) and even seems to generate some .so's instead of .dll's. It 
fails for me with 

gcc  -c -O1 -D_FILE_OFFSET_BITS=64 -Wno-pointer-sign -I ../src/include/ 
 -o obj/host-main.o ../src/os/host-main.c

cc1.exe: error: unrecognized command line option "-Wno-pointer-sign"
before doing anything.


2) given that I somehow manage to build it and include my own changes 
in a clone of that repo, what happens to them if once there's a A111 
repo? I don't see how a A110 repo could be turned into a A111 repo 
- I would have expected to have a R3 repo on github and to have commits 
tagged as constituting a alpha version like A110, A110 etc.

I did so ... first zip contained only one file, the second one contained 
2 exes. But the result seems like not being accelerated?

I tried to build R3 host kit (carls-R3A110-a660e4a) for Visual Studio 
2010 (make-vc10), I got the error  C1083: Cannot open include file: 
'netdb.h': No such file or directory	c:\users\awi\documents\rebol\hostkit\carls-r3a110-a660e4a\src\include\sys-net.h

Downloaded .zip file. Tried it now - it works. It just does not seem 
to copy dll to the place of the exe, or something like that:

Linking executable: bin\Release\r3.exe
Output size is 317,50 KB
Running project post-build steps
post-build-win.cmd bin\Release\

Execution of 'post-build-win.cmd bin\Release\' in 'C:\!rebol\!R3\r3-host-kit-A110\make-cbp' 
failed.
Nothing to be done.

yes, the .cmd file is missing from some reason

Aloysius - I already described the help, and Cyphre kind of confirmed 
- I noticed, that this hostkit is some linux version. When you look-up 
netdb.h, it seems its inclusion belongs to non-Windows #ifdef. So 
please go to /src/include/reb-to.h directory/file and rewrite the 
definition to: #define TO_WIN32

I think the file you're looking at is not really part of AGG, but 
written by Cyphre as a bridge between AGG and Windows

in other words..you are looking at  generated file..not the original 
source

I will polish the test file and attach it to the bug report.

Hm.. my mistake... probably commented the SHOW command when i was 
testing ... so I can confirm that for redraw on each mouse move I 
get same CPU usage.. pretty high. So the problem will be elsewhere.

Sorry for that.. I should take a break... here is my test file: https://github.com/Oldes/R3A110/blob/master/tests/text-test4.r3