World: r4wp

I have committed the change for the c-string to be allocated with 
Red/System ALLOCATE function.

FYI, Bruno is working on a Zlib binding for Red/System:
https://github.com/be-red/Red/commits/zlib

Much obliged, Peter. I can work that into my I/O routines

Really the thanks should go to Nenad. Without his help, I still be 
trying to work out how to do it.

I've add support for code points above the BMP.

add -> added

That is just called team work. :-)

Would be nice to be able to download the Red zip file and be able 
to compile scripts in another directory?

How do you mean? What you seem to ask is already possible

I was in the impression that Red and Red/System scripts should be 
in a directory within the Red dir. Where the other (test)scriots 
are too.

I am now hesitant to put a new zip over the old one and lose my scripts 
(but maybe even that fear is vain).

Nenad did a lot of work on making it location independent. A few 
issues remain, for example that Red/System always gets compiled into 
the builds/ subdirectory, but the source can be anywhere

If you just unzip, there´s no reason your scripts would be lost, 
but you can make it a lot easier by not putting them in the Red folders

Not sure what mode of compiling Red/System you are thinking about, 
but if you compile via rsc.r, you can tell it where to write the 
binary by passing a `-o` command-line option.

As in:
rebol2 -qsc rsc.r -o hello tests/hello.reds

I´m referring to the normal case of wanting to get the output in 
your working directory. Red does that now, but Red/System not without 
using that switch

You also need to give the full path to the source file

Actually, you also have to give the full path in the -o switch

I did some compiling today and found the resulting executable in 
the build directory.

Relative paths work for me.

Ishttps://github.com/dockimbel/Redthe official Github site?

Is https://github.com/dockimbel/Redthe official github site?

yes, it is ...

./ paths don´t work for me on rsc.r

Kaj: I think I've found a workaround for the semi-random compilation 
crash on Linux. It seems SELECT has some deep stability issues in 
R2.

At least in 2.7.6 and 2.7.8.

Good news and bad news at the same time...

Didn´t you already replace SELECT with FIND in other places?

Yes, in compiler.r, I did replace SELECT on most places where it 
was used on hash! series.

Don't tell Fork, or you will need R3 soon :-)

;-)

But just think what a great test this will be for Red's SELECT when 
it is self-hosting. :-)

Red codebase is the only place where I've encountered those SELECT 
internal instabilities, I don't remember even seeing them in Cheyenne.

Gregg: sure ;-)

BTW Kaj, you should be able to play with Red/System shared libs generation 
on Linux soon.

Actually, the SELECT expression where the compilation error occured 
was involving a word lookup in an object context, so those lookups 
are done, as far as we know, using internal hash tables, I wonder 
if the issue is not related to hash tables implementation bugs in 
R2. If I tried to put a PROBE between SELECT and the word lookup, 
the error was disappearing.

btw - would there be any benefit with the Red's ability to create 
shared libs, for R3 guys? R3 can already use Red to generate extensions, 
right? And R3 lacks the interface for DLLs. Maybe for R2 guys?

Doc, great; that will open up many more possibilities

Petr, it will make the R3 bridge available for other platforms than 
Windows

It will also allow writing shared libraries for R2 for other platforms 
than Windows

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

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

Nope, a lib must not this.

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

Good!

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

About the relative path, that was possible. Indeed. The Rebol console 
changed the path a few times so i needed to change it accordingly, 
but after that it was reusable.

Are you talking about compiling Red or Red/System?

I posted "my" "random" program via the Red mailinglist. It seems 
to work, but I really wonder how this is possible, maybe because 
the same or other memory is allocated.

Red/System

Odd, I can´t use ./ paths from the working directory