World: r4wp

Robert, Nenad's intial plan was for the Red compiler to directly 
generate machine code. So his first presentation reflects that. It 
was a few months after the launch that he decided to generate Red/System 
code from the Red compiler.

Ok, IMO it just needs to be made more clear. I'm confusig it after 
not tracking this here for a time. Just make things as simple as 
possible.

Robert: C++ is a superset of C. Red is not a superset of Red/System, 
they are two different languages that share the same syntax and superficially, 
some semantic rules. Red/System is a low-level dialect of Red than 
enables system & hardware programming with C-level performances. 
Additionally, Red/System is used to build Red runtime (memory manager, 
lexer, natives,...).

Merged namespaces branch with master branch.

Kaj: I'll give tonight a quick try to add namespaces support to aliases, 
then I'll make the 0.2.6 release.

Cool :-)

Kaj: aliases are now namespace-aware! ;-)

But I'm not 100% confident that my changes cover all possible use-cases, 
so I'll delay the 0.2.6 release until tomorrow night to give us time 
to test it better.

In the meantime, I'll also have a look at the compilation target 
folder issue you've raised.

By the way, it's also about compilation source. If your source is 
in your working directory, you still have to provide the full path

Kaj, for compilation or for including?

I think rsc.r should work fine with relative paths.

Compiling; relative paths do work for including

The GTK binding doesn't work anymore

Compiling with rsc.r works fine with relative paths; where do you 
encounter problems?

It doesn't work for me, on Linux

Or for me on OS X :

Schulz:Red peter$ rebol -qs red-system/rsc.r red-system/tests/hello.reds

Cannot access source file: red-system/tests/hello.reds

If you login to red-system dir compiling tests/hello.reds will work.

I presume Kaj's issue is having to cd to the red-system dir before 
compiling (it is a bit of a pain).

The GTK binding doesn't work anymore
 Was it working before my changes on aliases?

Yes, I reported it in the tracker

Peter, I had automated switching directories in a wrapper script, 
but I don't seem to have to do that anymore in the current version

I can start rsc.r from any directory, but then it fails to find the 
source file in that directory

Kaj: the issue has been fixed.

For some odd reason, it does indeed work if I switch manually to 
the directory holding rsc.r

Thanks!

Kaj: I've tried compiling from different folders (out of Red/ tree), 
with both absolute and relative paths to %rsc.r, the compilation 
goes well. The only issue I see is that the final binary is in Red's 
%builds/ instead of local folder. I guess I should change that to, 
by default, output the binary to same folder as program source code.

Why not simply the working directory? That's the common way compilers 
work

That also means you don't want to change into the Red tree to start 
the compiler

Working directory: sure we can do that.


DO is automatically doing a CD to the argument script's folder, it's 
not the %rsc.r script.

I wonder if we shouldn't start providing binary (encapped) versionsof 
the Red/System compiler?

Ok, I've reproduced the issue with a Red/System program not located 
in Red's tree.

Encapped: perhaps for most people. But it's also good to be able 
to browse the source, especially the runtime at this early stage

R2 has always been rather nasty with the working directory, fiddling 
with it. I think R3 is better

I think it will definitely bring in more people if they don't have 
to install REBOL as well as Red. One less barrier, and REBOL has 
lots of problems with installation

The GTK binding works again

Browse the runtime: agreed, but we could ease that by adding support 
for docstrings in functions and use them to auto-generate a reference 
doc for the runtime functions. I remember Peter suggesting me that 
months ago, maybe we could also start working on it now. I think 
that some minor modifications to functions spec block parsing rules 
should suffice. For other elements like namespaces, enums, aliases, 
we could allow an optional docstring somewhere to document them too. 
I can do the required modifications on the compiler quickly if someone 
is willing to write the docstrings?

I'll willingly help with the doc strings but am a bit short for time 
this week.

Docstrings would be great

I already write the bindings as if they were there, with some REBOL 
style documentation in comments

I went through my bindings and simplified several by using SWITCH 
and CASE

SWITCH and CASE not only simplify the source code, but they also 
significantly reduce the emitted code size.

Have you already enhanced your GTK dialect with namespaces and WITH?

Peter: thanks, then I'll add that to my todo-list.

SWITCH and CASE: ehm, no. Each one makes the binary 16 to 24 bytes 
larger

Namespaces: not yet, I'm planning to do that after the release

Peter: the lib-test file is crashing here on my OS X 10.6.2 image 
with following error:

dyld: lazy symbol binding failed: Symbol not found: _strnlen

  Referenced from: /Users/dk/Desktop/Red/red-system/tests/runnable/lib-test
  Expected in: flat namespace


After researching a bit about it, it seems that strnlen() is (was?) 
not supported by OS X.

SWITCH and CASE: I had a ~20% code reduction on Red/System runtime 
when I used them instead of tons of IFs. I guess your use-case is 
different.

It seems that strnlen() is defined for versions >= 10.7.0...unfortunately, 
I can't upgrade my image (virtual image), so I will replace strnlen() 
by strlen() in the tests.

The constructions in the runtime you replaced were very inefficient. 
Normal EITHER constructions seem to have less overhead than SWITCH 
and CASE. It's more or less independent from the number of clauses. 
It may be the default clause, especially when one is needed in CASE