World: r4wp

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

I used relative paths ../../red-ownscripts/

./ is a relative path

On Windows 7 not on macosx

And my Red is a couple of weeks old.

./something paths work for me, on Linux.

From a separate working directory?

That's indeed still partially broken (completely in Red/System, for 
-o in Red). Thanks for reporting.

I'll push a fix shortly.

Thanks!

Pushed. If you give it a try, please let me know if it works for 
you as well.

I´ll have a go tomorrow

Did you run the tests before pushing the commit Andreas?  I now have 
a few failing Red/System tests. I'm in the middle of writing some 
tests and need to get those commitable before I can take a look.

From a quick look your commit has changed the default for red/system 
so that executablles are now built in the current working directory 
rather than the builds directory.

Quick-Test is built to handle the previous behaviour so is broken 
at the moment.

(@Kaj your apostrophe is a Yen sign in my AltME on Mac)

Being written in REBOL/View, ALTME encodes characters in the Windows 
codepage under Windows, MacRoman under OS X and UTF-8 (I think, it 
may be ISO-8859-1) under Linux. So if you use any character  other 
than standard ASCII characters, it will appear differently on differnet 
systems.

Andreas: watch out for regressions, this is a sensitive feature as 
it affects everything else: test suite, my own local tests scripts, 
Red compilation toolchain, documentation on github homepage, etc...

Such kind of change needs to be coordinated.

FYI, my plan is to get rid of %rsc.r and merge its features to %red.r 
(deciding on the compiler to use based on input script header). The 
%red.r  front-end is smarter and able to better handle relative paths.

Unintended regression, sorry.

Fix coming up in a second.

Pushed; sorry for the mess-up.

Test suite runs again, relative path handling for explicit output 
paths (-o) and sources passed to rsc.r should also work.

And w/o an explicit output path, builds are again stored in the builds/ 
directory.

watching pic-emitter Commits section - Doc, you are a coding hurricane 
:-) I can smell first shared library generated by Red coming over 
the weekend :-)

I hope it won't take me that much time. ;-)

Thanks Andreas

+1 for the merge of  %rsc.r into %red.r . Never liked the name %rsc.r