World: r4wp

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

Arnold, I´m on a new Linux installation set to dead keys, so it´s 
manipulating quotes and such. I guess I can´t keep up that experiment

So, what's the prospect for getting Red/System running on a Parallella?

Pekr: %rsc.r, like it or not, the naming scheme was following the 
usual conventions for naming compiler launchers, maybe you would 
have preferred %red-system-compiler.r?

I would prefer it would not exist. I find "do/args %rsc.r "-v 5 %tests/hello.reds"" 
still being rather cryptic and I hope everything gets replaced, once 
we get red.exe?

Parallella: Red should be able to run on it from day one as we already 
support their system (Ubuntu/ARM). For the risc chips cluster (Epiphany), 
simply making a Red/System backend for them would not be enough to 
leverage the computing power. We would probably need some new abstractions 
at Red level, specific new natives in Red or even dialects to take 
real avantage of it. For example, we could have a MapReduce native 
support in Red that would   delegate execution to such kind of cluster 
(there are other competing hardware products in that area).

Pekr: you understand that building Red is not going from 0.0 to 1.0 
in one step? So, like in any other long ang complex building processes, 
you have intermediary building steps and states that are not necessarily 
representative of the final product. Think of a house in construction 
with scaffoldings, you don't point at the scaffoldings saying that 
the house will look horrible.

I've found a nice keyboard configuration that seems to do everything 
I want