World: r4wp

red>> function [] [()]
Segmentation fault

LOAD doesn't parse file! type:

red>> %/x

*** Script error: action 42 not defined for type: 2

If it would do that, the interpreter could execute the same scripts 
as the compiler unmodified, assuming that any #include files are 
already compiled into the interpreter

The error seems to have something to do with path interpretation 
again, as it happens when a / is present

Paul, I think I have found the sound problem on Windows

It seems I need to open a window before sound is initialised properly, 
no matter if you want a window or not. DirectSound is said to need 
to be associated with a window handle. So it wouldn't apply to other 
sound systems, which probably explains why it works on WINE

Sounds like a poor design choice on the part of the DirectSound team.

Yes, and it's not abstracted away in SDL

Ka, there's no file! type yet in Red, even if some parsing rules 
are already included in compiler's lexer. So the path error for %/x 
is currently correct.


However, adding file! is not a big deal and as you already have provided 
some file access functions, I think I'll add it for the 0.3.2 release.

Ka => Kaj.

FYI, the runtime lexer will parse #include as a word! currently, 
I could change that though, if it's a blocking issue for some scripts 
(but I don't want to spend too much energy in a tokenizer that will 
be replaced in the next weeks).

Multi-line strings: looking into it to see if it's easily doable.

BTW, the segfault above has been fixed.

Is it a known issue for console:
red>> print  4 * 4
16
red>> print 10 / 2
10
== / 2

*, +, - works, but / not.

Good catch!

That looks like a regression introduced when I added refinement support.

Working on it...

I guess so.

Another small thing:
red>> print x * 5

console window closed immediately, so I cannot see the error message 
(but there is a message!)
x is unset by the way.

I get here:

    red>> print x * 5

    *** Script error: action 13 not defined for type: 2

Translated in english: "you can't use * on unset! value"

I tried several times with the latest build. I open a fresh console 
window.
print x * y
** script error ... window closes..

On Windows or UNIX?

oh I got it. I run the console by double click, not from dos prompt.

:-)

sorry :)

np

/ issue fixed.

Kaj, I won't merge dyn-lib-emitter yet, I will work on it as soon 
as I make the new release to add PIC support and start Mach-O and 
ELF implementations. I want all of them working before merging. I 
would probably also make a new release and bump the revision number 
for the merge.

It's rather frustrating to have that functionality available for 
so long and yet not available

It is available, just from an alternative branch. Nothing stops anyone 
from using it.

It does, you don't get the functionality and fixes in master, and 
it's hard to install

It's fine that #include is parsed as a word! because that way it's 
skipped

You can easily keep your forked dyn-lib-emitter up-to-date with just 
a `git rebase`.

I know there is no file!; I don't need it now, I just need file literals 
to be skipped as well, so parsed as a word!, too, instead of bombing 
out

or rather `git merge origin:master`

I can't use Git

I've fixed the runtime lexer to parse #include as issue!, shouldn't 
change anything for you.

OK, that's even better

I've almost implemented file! completly this morning, but am now 
trying to get the multi-line strings literals recognized by both 
compiler and runtime lexers. A bit harder that it seems at first 
look, but should be ready for tonight anyway.

Great

That's great news Doc! File! is a huge part of what I do with REBOL, 
so this is a great step.

It is just file!, no port! nor port's actions support yet.

Though, you can use Kaj's READ and WRITE functions to access files 
from Red already.

Got multiline strings LOADing working, but now I need to find a way 
to efficiently (if possible) output the right delimiters:

    probe load {
        {
    	Hello
    	World!
        }
    }

    == ["
            Hello
            World!
    "]

Wait, " strings are multilined too? How do you help the developer 
when multiline strings are an error?

By "help the developer" I mean trigger a syntax error, or log an 
error in your compiler, whatever. Errors help the developer.

You missed the point, Red's MOLD is not yet able to correctly handle 
multiline strings, I'm right now working on adding that support, 
I'm just wondering how to do it the best (same discussion than in 
SO chat with Ladislav).