World: r4wp

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.)

script/path & options/path: yes

What we want is ability to call %rsc.r from anywhere, compiling a 
program from working dir (or relative to working dir) and producing 
the binary in the working dir.

(Kaj correct me if I'm wrong)

Yes, that's what we want.

Yes

A minor question re the output binary remains: do we want to keep 
up the automatic executable name guessing we do at the moment (foo.reds 
-> foo || foo.exe), or do we want to use non-descript default name.

And if we want to keep the "nice" exe names (which would be my guess), 
what to do if the target file already exists?

Most developer friendly (imo): just overwrite it.

Automatic name guessing: yes, we want to keep that and overwrite 
it if exists already.

Ok, should be an easy change, but I guess the test runners will need 
adapting (if we want the new behaviour to be the default).

Yes, we'll need to adapt all our tests scripts. That's why I've tagged 
the last commit for the release, to avoid further delays.

Added floating point support to the SQLite binding

Nice!

It was mostly uncommenting some prepared lines :-)

Andreas: if you know how to improve working dir handling in %rsc.r, 
feel free to do so when you want. We'll adapt the test scripts accordingly.

I'm trying to move the SQLite binding into a CONTEXT, but I've hit 
a bug

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


Did you install Xcode including the Unix libs?  I wrote the tests 
under OS X 10.6 but am now running on 10.7.

What we want is ability to call %rsc.r from anywhere, compiling a 
program from working dir (or relative to working dir) and producing 
the binary in the working dir.


Please can we also supply a second argument to rsc.r for the output 
dir/file name (the gcc -o option with improvements).


If the second argument is a dir then the executable is written to 
that dir instead of the current working dir.


If the second argument is a file then the executable is saved with 
that name.

(That would really help with quick-test).