World: r4wp

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

After looking at the diff-ed code, I think that replacing all the 
assignment in IFs bodies, by a single one before the SWITCHs is what 
produced the code size gain.

Yes, I did manage to make small gains where SWITCH could be used, 
but only when it makes other constructs obsolete. First you have 
to make good on the overhead of SWITCH itself

strnlen only available in last year's OS X? Oh man...

I suspect you could optimise SWITCH and CASE by detecting constant 
expressions, like C does, especially when TRUE is used as a default 
clause for CASE

Probably, but we'll leave that for the final version of the compiler.

I think
--assert 12 = strlen s 32
should be
--assert 12 = strlen s
in your last commit

Thanks, forgot to commit that modification.

Ah, so calling rsc.r from someplace else was the trouble.


Isn't that a fundamental problem with the current R2 interpreters? 
I seem to remember that when a script is running the interpreter 
already change-dir'ed to the directory containing the script, thereby 
losing the original working directory.

Anyone has an easy workaround for that handy?

It's not lost, it should be stored in system/options/path.

Reliably?

I'm unsure about that.

Time to try again, I guess :)

So far, testing with a modified %rsc.r on Linux, it seems to be reliable.

Do you use rsc.r from the REBOL console as well?

Well, seems to even properly work with DO.

(Testing with R2.7.8 on Linux.)

Yes, from REBOL console.

So `change-dir system/options/path` at the top of rsc.r it is :) 
?

Not sure this would covers all cases.

We need two paths: one for locating red-system/ root directory and 
another one for the working directory.
So:
- system/script/path should give us red-system/ root
- system/options/path should give us working directory

`do load %rsc.r` and DO-ing rsc.r from an URL are the two only cases 
I can think of right away where it might make not much sense (it 
would then use the workdir the REBOL interpreter was started.)