AltME groups: search

Henrik, the problem is that the server overwrites the client even 
when the server is wrong (corruption on the server side). It would 
be nice if it recognized the condition and recovered files from the 
clients.


The other problem is: can you think of a backup scheme to avoid this? 
(Note, we're speculating on the base of guesses, but still.)

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

This release contains:


-Windows: reworked keyboard events handling (key-up events support, 
ctrl+tab detection, base for ALT+key handling, etc.)
-text clipping bugfix


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

It depends of what is the objective. If the objective is to support 
an older code base then compatibility is a must.

But that's only the code base, Kaj. We are growing the language.

The 2.7 test release has been built. This is the base build for the 
next release. It contains SSL, ODBC, DES, etc., and no-license key 
is required.


In addition, I've added an install checkbox to the Prefs (User panel) 
and an Uninstall to the Help panel. These are just shortcuts to existing 
features.

The download is www.rebol.com/downloads/view277-test1.exe


Note that it's version # is 2.7.6, but it has a new system/build 
date. Don't mix it up with prior versions, as it's not at all tested.

Brian, for R2 can we make sure that a base component isn't doing 
any unnecessary reads or writes - such as registry values etc...

I hope core or base doesn't do it.  We need those as lean as possible.

I ohpe there is a base with ssl and all the stripped out view stuff.

adding a content-type header or content-disposition doesn't change 
anything. encoding base 64 either not.

We're trying to decide what should go into /Base 2.7.8, at least 
as it relates to the R2/Forward functions.

Yeah there is a Rebol/Core 2.5.0.5.2 and a Rebol/View 1.2.1.5.2 for 
BeOS R5. I tried the one with View on the latest nightly build of 
Haiku yesterday, didn't work though, some error message about the 
Media Server Addon IIRC. Could be because I used the GCC4 hybrid 
iso, don't know how far they are with that stuff yet, I haven't followed 
the mailing list for a few months. A R3 port in a few years would 
be good enough for me, Haiku is still in alpha so it's probably a 
good idea to wait a bit more. From what I heard they now have a few 
people working on it full time (paid) thanks to a lot of donations, 
so there is a lot of stuff going on with the Haiku code base right 
now :)

full ack BC, graham if you need (like) zfs try freebsd, it's already 
there. 
better perfomance, cleaner handling and much faster than linux. 

if you need a wm try xfce or lxde. feels like running win 3.11 on 
a quadcore.


for rdbms look also at monetdb, in nearly all cases 5-10 times faster 
than mysql.

very advanced designed dbserver and a nice abstracted query layer 
for sql and xquery. 

if you need a good allrounder/workhorse try postgresql (scales good 
on multicore)

free- or netbsd is a solid base for this. (but only until a real 
smp ready microkernel
os like minix is finished :-)

http://www.rebol.com/priorities.html


says 2.7.8 is "(Status: delayed, pending sufficient user-base response 
and contributions related to installation)"


Who can progress the installer?  That looks like it is holding this 
up ...

I have a technical re-distribution question relative to the R2/forward 
code-base.


I might be forced to use an older version of R2 but need to include 
"some" of the functions within r2/forward mezz files.   


since I don't want to have to include many files in this project, 
I would like to simply include the few functions directly within 
my own "reusable" stuff module which is already part of that project...


is it ok for me to include, as a comment within my own lib, the headers 
found in the source files I would pick specific functions from?

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.

On the other hand, if you are really trying to test the model to 
destruction as an example to base the next version's revisions on, 
then cool. I would like to see how your code integrates with devices, 
even if it has to be moved out of an extension and into the host 
for now, at least until we get device extensions. Code that works 
with the model won't need as much rearchitecting.

A single source base which automatically builds correctly for the 
platform the build tool is invoked on.

I will release our test-framework, which should be used as base or 
as resulting format.

+ lots of points for having a code base that's already done and tested!

Also, look at system/options/file-types. You can find the file extensions 
that are loaded as R3 extensions, and then go through them, adding 
them to your file's base name to find your file. Or you can add a 
one or two line platform-specific wrapper for your module code.

I'm not so much concerned about the ability of the base operating 
systems, but all the tools out there that expect conventions

Someone should write a software book called 'The Joy of Naming'. 


We're used to 'facets, and I don't have anything against it, but 
it's telling that description for it uses both 'attributes and 'properties. 
I don't expect it will change at this point. We all just need to 
help new users learn what it means. 


'Template doesn't sound bad. It's funny, in OOP you have the concept 
of inheritance from a parent, but I don't know of a common term used 
for the view from the other direction. 'Attributes is probably the 
most common, but you don't hear it discussed as the base classing 
passing them on.

Maxim, I have hacked together(in fact it was lurking on my hdd for 
couple of weeks but I got to publish it here today) a test of one 
concept which IMO could solve part of your requests regarding 'access 
to DRAW elements' etc in R3. It can be also handy when you need to 
manipulate content of complex DRAW blocks...or even be a base for 
scalable vector graphics editor...or....I think there is relative 
big potential of usage :-)
Just try to run:
do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes.r
in your R3 console.

BTW The demo also features pixel precise object masking and optimized 
redrawing of DRAW objects just to prove we can do lot of things even 
at the higher level.

The file contains couple of predefined objects but the main code 
is very small like 4kB so it should be easy to see my point. Hope 
this could help a bit to someone.

Specifically:
	// Nothing, so wait for period of time
	delta = (REBCNT)OS_Delta_Time(base, 0)/1000 + res;
	if (delta >= millisec) return 0;
	millisec -= delta;  // account for time lost above
	req.length = millisec;

ok, we'll just have to see if this becomes necessary later. the model 
I base containers on is a little different.

Overall we start with the basic concepts we want to have in a GUI 
framework, as we think these needs to be taken into account very 
early. Building up a broad widget-set on a good base shouldn't be 
that hard than.

We take VID34 AS-IS and patch the code-base. So it's easy to find 
the differences. Most things we try to add non-intrusive. So you 
load an additional file and get new functionality.


The styles are all "self-contained". If Carl wants it can all be 
integrated into VID.

What is most important is, that we haven't hit a showstopper yet. 
Even with the current release we can move along. It might not be 
perfect in all aspects but good enough and comparted to R2 base not 
worse. That's enough to do it and get some apps done with R3.

Bitmask or alpha channal would only be used where non-rectangluar 
areas need to be clickable, so that, Maxim, means they are handled 
on a per GOB or per-Style base, giving 255 controls per GOB or Style, 
not in total, at least that's my understanding.

Wasn't the babylonian system base-60? Or was that someone else?

Babylonians had base-60 numbers, indeed, but the evidence exists, 
that they founded our positional system

base-url: http://rebol.hmkdesign.dk/files/r3/gui/
img-url: func [id] [rejoin [base-url id %.png]]
ids: [%220 %221 %222 %223 %224 %225]
imgs: copy []
foreach id ids [repend imgs [id load read/binary img-url id]]
cur-id: first ids
show-next-image: does [
    cur-id: select join ids first ids cur-id
    set-face f-img imgs/:cur-id
]
view layout [
    f-img: image (imgs/:cur-id)
    btn "Next" [show-next-image]
]

as I said and once again - I doubt that any such solution will be 
sufficient for all ppl, hence I am not sure it belongs to the base 
of theGUI framework ...

shadwolf, I suggest waiting with further comments until a release 
is made, so there is an actual base for commenting on.

what can be done to get more quality to the font display?

 I personally would make research about the technique McSeem(AGG author) 
 published in his well known font rendering related article and tried 
 to use the core idea of his demo application for making 'production 
 quality' version which can be then used in the HostKit code base.

host-kit was the first mandatory step so that we can now fix GUI 
bugs that we find while developing the base infrastructure code. 
This is now done.

think that agg can offert us really creazy effects motions shape 
changes solidity changes.... etc.... so for me the perfect gui Lib 
would play with those aspect in a clever way and maybe be the base 
for people to say ok .... and what if my next application would be 
a cloud ... a cloud have a non definited shape you can cut it in 
pieces than rearange those pieces you can make some part more dense 
some other part lighter   you can shrink it or completly change anytime 
it's shape .... the kind of interface that would be just  so fun 
to exploit use a multi touch screen ...

The current GUI style is just to see anything at all. Henrik has 
a concept how to decouple the decoration and look from the rest. 
We need to get this up & running in a way that it's not changing 
on a dayly base. Than we will release it and you can start doing 
all the nice GUI looks.

Ok, this is current material deffinition (not all of them).

materials: make object! [
	; base material - normal color
	base: make object! [
		up: down: over: make object! [
			specular: 'high
			intensity: 1
			diffusion: [1 1]
			opacity: 1
			texture: none
		]
	]
	chrome: make base [
		up: over: down: make up [

   diffusion: [1.00 0% 0.78 49% 0.76 50% 0.7 51% 0.76 97% 1.00 100%]
		]
	]
	aluminum: make base [
		up: make up [
			diffusion: [1.00 0% 0.74 7% 0.70 70% 0.71 97% 1.00 100%]
		]
		down: make up [
			diffusion: [0.67 0% 0.78 7% 0.71 70% 0.72 97% 1.00 100%]
		]
		over: make up [
			intensity: 1.03
		]
	]
	; for use in container in various box styles
	container-groove: make base [
		up: down: over: make up [

   diffusion: [0.0.0.200 0% 0.0.0.255 50% 255.255.255.255 50% 255.255.255.220 
   100%]
		]
	]
]

I would regard such design being - fundamental. I like that RebGUI 
because of that - one widget, one file, easy as that. There is too 
much fuss about inheritance, having some base, upon which other styles 
are based - that is an utopia, and I don't know, while we still keep 
to that. That does not save any signicant memory, and I doubt that 
by changing one parameter to some base style, you want to have all 
childs influenced. That is nice example of inheritance, but completly 
misses practical usability imo :-)

then can a recusiv process be the base of the tool creation/collection 
can then those basic bricks be assembled on more sofisticated tools 
 those sofisticated tools being then short cuts to create your own 
software

It would be good to have somethink like GUI/base which could be used 
to make micro guis - as a platform for own guis.

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.

The host kit should be synced at reasonably stable checkpoints. That 
way the GUI people are free to experiment, and people who are working 
on hosts that don't need a GUI or are using a different one can have 
a base that doesn't change as often and is a little more reliable.

Carl is the one to release host-kits. He has full access to our code-base. 
As Brain said, from time-to-time RMA changes are merged.


IMO it doesn't make sense that we fork the host-kit and have two 
release in the wild.

and since i'm considere as a pain in the ass and you all try your 
best to not have this discussion with me  or with the others in the 
community then you go to what Carl did without any second thoughts 
in the end we will end with a strong win32 API based R3/GUI and no 
linux or macOS X ports. That' s the the projection I can make base 
on the actual work.

If WINDOW would be just a panel there won't be need for that WINDOW 
style no? :) Anyway, the WINDOW is the base style which controls 
all the content.
The structure looks like:
WINDOW [	; this is the main container GOB
	BACKDROP [ ;renders solid background under the content
		<your layout>
	]
]

What materials do (apart frome some cute functions to calculate gradients, 
etc.), is that it basically adds block of following objects into 
face/materials:

	base: make object! [
		up: down: over: make object! [
			specular: 'high
			intensity: 1
			diffusion: [1 1]
			opacity: 1
			texture: none
		]
	]

But look at material 'base style. It does not contain any field to 
hold colors?

	base: make object! [
		up: down: over: make object! [
			specular: 'high
			intensity: 1
			diffusion: [1 1]
			opacity: 1
			texture: none
		]
	]

Ladislav - let's not just take it personally :-) For me, and as you 
can see, it is a good experience to experiment with the GUI, as I 
am gaining some internals knowledge. I published the tickets for 
RMA team to consider the consequences, and it is up to you, to react 
accordingly. So - if you guys feel that it is ok, then just dismiss 
the ticket, ad the comment there, and it will server for future GUI 
users as a knowledge base, that's all ...

It's one of the base rules of software engineering to keep complex 
systems in a working state

And, we don't have any secret versions, code base or so. So it's 
mostly the same for us as for you. At least the result is the same.

I think you will clutter the base style with things it's not supposed 
to do. This will be dragged along inherited styles.

Ladislav, I discussed it a few days ago, but not to worry. Rebolek 
disagrees too, so it probably won't be done. My worry is that the 
act of creating a border or frame around a style will be an obscure 
part of a base style.

#[[Henrik

My worry is that the act of creating a border or frame around a style 
will be an obscure part of a base style.
Henrik]] - you need not worry, it already works for all styles

1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?


To me, a layout is a specification, not an instance. I don't know 
that using a different word (container or compound) helps. You just 
need to be explicit about whether you're talking about a panel face 
or the panel style (which has a layout specification).


2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?


My view was based on there always being a base 'panel style, with 
'hpanel and 'vpanel being shortcut styles to set the layout mode.

The base is now matured enough that all can help.

Must be very frustrating ... and dangerous to base a business on 
such a situation

The binaries are not built from the same code base. Simple as that.

The base language for the naming of REBOL functions is English. But 
REBOL adds naming conventions that English doesn't have.

That is what I was saying about ? in REBOL before. EQUAL? is short 
for EQUIVALENT, and DIVERGE? would be short fot DIVERGENCE. It's 
nonsense in English, but English is just the base language for REBOL 
function names.

hm.. so debase/base next to-string  #ff 16

We are working on it every day. And the speed is raising as a lot 
of base code has been done now...

So why are not Steven's changes included in the source-base?

>> x: [16#ffffff] 
== [#6#ffffff]

how can i specify an integer! in hex format?

debase/base "ffffff" 16  returns a binary! which i mostly can smear 
on my hair, since most operators just doesn't play nicely w it...

same problem again... i tried to use rebol for byte level processing 
and it's just not suitable for it.. :/

here is my ObjectID routine a'la mongodb.

wondering how much simpler could it be in r3?...  not that i could 
use r3 any time soon for production stuff, but i would love to, of 
course

  rejoin probe reduce [
    to-hex date-to-epoch now

    enbase/base copy/part checksum/method system/network/host 'md5 3 
    16
    skip to-hex access-os 'pid 4
    skip to-hex random/secure to-integer #ffffff 2
  ]

(And if you diff A107 Linux against the Win32 version, you'll see 
the base for my "Lazyness" comment.)

We just really need to get Carl to the point where the hostkit is 
kept as a single source base.

Andreas: the code base is a mix of both single source and multi-source 
tree.


I will not allow source files to become unreadable with every other 
line being #ifdef for a different OS. Those are not maintainable.

And whatever you want to call it, the process is simple: you have 
a single code base, version controlled. Upon every change to this 
code base, you automatically build and test on all supported platforms.

Using the Cygwin compilers turned out to be unnecessary, so I can 
get away with just the Cygwin base install plus make for the NDK, 
TDD-GCC for the host kit, and Git for Windows for the Git support. 
Only one set of compilers per target platform, but 3 mostly duplicated 
sets of general command line tools.

For the sake of completeness, here are the highlights of the alpha 
108 changes:

- Script headers can have an options block, a simple block of flag 
words. User extensible.

- The standard script header now has a lot fewer words in it. More 
stuff is optional or in the options block.

- Script compression, either binary and base 64 binary! encoded. 
Automatic, transparent.

- Script checksums, both to verify the script and for IMPORT to compare 
with. Applies to decompressed source.

- An optional script length header field (like http's Content-Length). 
This allows binary script embedding.

- Internal support for getting the end of an embedded script, so 
a multi-loader is possible.

- The 'content and 'isolate header fields are changed to option words. 
The content is still saved to a 'content header field.

- The 'content field, if set, is set to the start position of the 
script proper, even if there is stuff before it.

- The whole system/contexts/system concept is gone, as part of the 
system restructuring. Now we have SYS.

- The system/contexts/exports concept is gone too, replaced by a 
not-module-specific runtime library called LIB.

- The old type: 'extension is now the 'extension header option word. 
The only module type is 'module. And it's optional for most code.

- Mixins are now called "private modules", and are flagged by the 
'private option word. And they can have names.

- Private modules can be added to the system modules list (because 
of the names). This lets them be reused without being reloaded.

- Unnamed modules are now prohibited (until alpha 109, where they 
become private modules that reload every time).

- Delayed modules, which can be partially loaded and then not fully 
made until they are imported. Use the 'delay option word.

- A HIDDEN module source keyword, which applies PROTECT/hide to a 
word or words. Acts like the EXPORT keyword.

- Better errors are triggered when the bad things happen. Including 
new error codes.

- DO and MAKE--MODULE intrinsics are now in sys, as DO* and MAKE-MODULE*. 
No more system/intrinsics.

- DO-NEEDS is no longer exported (it's in sys). IMPORT block is a 
public alias for DO-NEEDS anyways.

- MODULE now makes modules that act more like those in script files. 
And has /mixin support too.

- A whole bunch of changes and fixes to native functions to support 
the above stuff.

If you meant my last long message by "we can change allmost all of 
that" then no, not in the base system. You can work around it in 
your own code though.

core
>> print stats
856824

core -b sys
>> print stats
793984

core -b base
>> print stats
573336

Note that -b base is not useful for you (it's for me) because schemes 
are not yet init'd.  It's a bit like booting an OS without the file 
system.

USAGE says:
	--boot-level L   Where L can be: base sys mods

Well, enbase.base 2 is easy:
     string: enbase/base "cffdf" 2
     "01" = sort unique join "10" string
And that is easily extendable to the other bases

But you might get some false positives -- say a base 16 number happened 
to be all 0s and 1s.

Henrik, i suspect that debasing may be faster than checking eg. with 
parse. are we talking base64 here or just base 2 and 16?

Sorry, missed that. Yes, qsort takes a callback used for comparison. 
Here's the decl:


void qsort(void *base, size_t nitems, size_t size, int (*compar)(const 
void *, const void*));

Rebol []

make-obj: func [
	"Créé un objet en sauvant son nom dedans."
	'name "Nom de l'objet à créer."
	obj "Objet de base à instancier."
	spec "extension de l'objet de base."
] [

 set name make obj append reduce [to-set-word 'obj-name to-string 
 name] spec
]


save-obj: func [
	"Sauvegarde un objet selon son propre nom."
	'obj "Objet à sauvegarder."
	/local name
] [

 name: any [all [word? obj  object? get obj  get in get obj 'obj-name] 
 join "objet" random 10000]
	save/all to-file join name ".r" get obj
]

load-obj: func [

 "Recharge un objet et l'intancie selon son propre nom s'il en a un."
	file "Nom du fichier à charger."
	/local obj
] [
	if exists? file [
		obj: load file
		probe bind next first obj obj
		probe get in obj 'list
		all [in obj 'obj-name  set to-word get in obj 'obj-name obj]
	]
	obj
]

task: make object! [
  list: copy []
  add: funct [t [block!]] [
    append list t
  ]
  save: does [
    save-obj self
  ]
  run: does [
    do list
  ]  
]

make-obj task1 task []
task1/add [a: 0 a: a + 1]
task1/add [print a]
task1/run
task1/save

task1: none

load-obj %task1.r
task1/run

>> to integer! binary: debase/base to-hex integer: 11 16
== 11

>> zen: func [arg [integer!] /local /private base] [add any [base 
0] arg]
>> zen 1
== 1
>> help zen
USAGE:
    ZEN arg

DESCRIPTION:
    (undocumented)
     ZEN is a function value.

ARGUMENTS:
     arg -- (Type: integer)
>> zen/private 1 10
== 11

This would mean that you would replace this code:
    saved: system/options/binary-base
    system/options/binary-base: 64  ; or 16, whatever
    output: mold data
    system/options/binary-base: saved
with this:
    output: mold/with data [binary-base: 64]


This saves code since you can't trust that any global option will 
remain even its default value without data flow analysis unless it's 
protected.

this who "binary" talk is quite fucked, btw. as if carl never worked 
w low-level stuff... but after seeing a whole nation (singaporeans) 
calling the desktop machine CPU, im not surprised... just disappointed..
wtf does binary-base mean? binary already means number-base 2...

But, as said, I am not afraid of such "stangenesses", since they 
do not exist in the actual code base

Clarity: That depends, because the example is contrieved as a "trap": 
I have little base for judging it.

Some basic ASLR (stack randomisation and mmap-base randomisation) 
was added to the mainline Linux kernel in 2.6.12:
http://lwn.net/Articles/121845/

Doc, by multibyte chars I wasn't talking about variable-size, I was 
talking about fixed-size with Unicode support. A char! would have 
a single size, but that size would either be 1, 2 or 4 bytes depending 
on whether the base plarform supports ASCII, Unicode2 or full Unicode.

Could you try changing the base address in ELF.r? It is a the top 
of the file:
context [
	defs: [
		image [
			base-address	134512640	; #{08048000}
		]

hm, kaj, could you try setting
base-address:  -2147483648
and see if that generates binaries which work?

Wow, base-address	-2147483648 compiles

Base address, really, and address alignment

Ah, yes, base address, not entry point. Thanks.

Base address for Syllable Desktop is 80000000h which currently needs 
to be coded as -2147483648

So the compatibilty base seems to be FreeBSD 6

It sort of pulls the base out from under my efforts to wrap all external 
functions to return logic!

The next step will be working on Red memory manager, then Red compiler 
(including reimplementing all the base natives). Alpha should be 
available around September, 1st.

I said "base natives", so not a whole REBOL reimplementation.

I never planned to base the Red string! type on the Red/System c-string! 
type. All Red datatypes will have their own specific implementation. 
In some cases, for the sake of optimization, we should be able to 
substitute some Red scalar values to Red/System scalar values (mainly 
integer! in fact).

Just because it looked good to me when I had to pick one. But since 
then, Andreas made me realize that it can be problematic for derivated 
works because of the "prior written permission" part. That is why 
the current Red runtime source code is licensed under the Boost License. 
I think I'll just re-license the whole source base under BSD 2-clause 
when I'll find some time for that.