World: r4wp

why not to use native OS functions? At least on WIn there is: http://msdn.microsoft.com/en-us/library/windows/desktop/dd374085(v=vs.85).aspx

Kaj is working on Linux and Syllable only. Also that API provides 
UTF-16 to UTF-8 support, but we need also UCS-4 to UTF-8 (UCS-2 being 
a subset of UTF-16).

Some UCS related code for porting is here: http://public.googlecode.com/svn/trunk/UCSUTF.cpp

Endo: I have submitted a report for false positive to AVIRA, I hope 
Red binaries will be whitelisted soon. It seems to be the last AV 
vendor producing false alams, according to virustotal online testing 
tool.

Thank you, I'll check it later.

Kaj - You can find a rough and ready  red-string! to  c-string! function 
at:


https://github.com/PeterWAWood/Red-System-Libs/blob/master/UTF-8/string-c-string.reds


it #includes the UCS4 character to UTF8 convertor which you will 
need in the same directory as the string-c-string func.

The ucs4 -> utf8 char convertor:


https://github.com/PeterWAWood/Red-System-Libs/blob/master/UTF-8/ucs4-utf8.reds

I haven't really tested it as you can see from :


https://github.com/PeterWAWood/Red-System-Libs/blob/master/UTF-8/Tests/string-c-string-test.red

I'm not sure how it will cope with repeaated use as there is no way 
to release allocated c-strings under the Red memory manager.

Hope it helps.

who needs a GC/memory manager these days, just buy more RAM :-)

Peter, maybe you could user ALLOCATE function from Red/Sytem and 
let Kaj's code call FREE on UTF-8 buffers after usage?

I didn't think that it was possible to mix using the Red Memory Manager 
and C memory management in the same program. Is it safe to do so?

Yes, it is.

I have committed the change for the c-string to be allocated with 
Red/System ALLOCATE function.

FYI, Bruno is working on a Zlib binding for Red/System:
https://github.com/be-red/Red/commits/zlib

Much obliged, Peter. I can work that into my I/O routines

Really the thanks should go to Nenad. Without his help, I still be 
trying to work out how to do it.

I've add support for code points above the BMP.

add -> added

That is just called team work. :-)

Would be nice to be able to download the Red zip file and be able 
to compile scripts in another directory?

How do you mean? What you seem to ask is already possible

I was in the impression that Red and Red/System scripts should be 
in a directory within the Red dir. Where the other (test)scriots 
are too.

I am now hesitant to put a new zip over the old one and lose my scripts 
(but maybe even that fear is vain).

Nenad did a lot of work on making it location independent. A few 
issues remain, for example that Red/System always gets compiled into 
the builds/ subdirectory, but the source can be anywhere

If you just unzip, there´s no reason your scripts would be lost, 
but you can make it a lot easier by not putting them in the Red folders

Not sure what mode of compiling Red/System you are thinking about, 
but if you compile via rsc.r, you can tell it where to write the 
binary by passing a `-o` command-line option.

As in:
rebol2 -qsc rsc.r -o hello tests/hello.reds

I´m referring to the normal case of wanting to get the output in 
your working directory. Red does that now, but Red/System not without 
using that switch

You also need to give the full path to the source file

Actually, you also have to give the full path in the -o switch

I did some compiling today and found the resulting executable in 
the build directory.

Relative paths work for me.

Ishttps://github.com/dockimbel/Redthe official Github site?

Is https://github.com/dockimbel/Redthe official github site?

yes, it is ...

./ paths don´t work for me on rsc.r

Kaj: I think I've found a workaround for the semi-random compilation 
crash on Linux. It seems SELECT has some deep stability issues in 
R2.

At least in 2.7.6 and 2.7.8.

Good news and bad news at the same time...

Didn´t you already replace SELECT with FIND in other places?

Yes, in compiler.r, I did replace SELECT on most places where it 
was used on hash! series.

Don't tell Fork, or you will need R3 soon :-)

;-)

But just think what a great test this will be for Red's SELECT when 
it is self-hosting. :-)

Red codebase is the only place where I've encountered those SELECT 
internal instabilities, I don't remember even seeing them in Cheyenne.

Gregg: sure ;-)

BTW Kaj, you should be able to play with Red/System shared libs generation 
on Linux soon.

Actually, the SELECT expression where the compilation error occured 
was involving a word lookup in an object context, so those lookups 
are done, as far as we know, using internal hash tables, I wonder 
if the issue is not related to hash tables implementation bugs in 
R2. If I tried to put a PROBE between SELECT and the word lookup, 
the error was disappearing.

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?