World: r4wp

Yes, works now. Thanks!

How am I supposed to cross-compile a Windows DLL from Linux? I'm 
getting an internal compiler error with any combination of -dlib, 
-t WinDLL and -t Windows

Oddly, -dlib does produce an .so

-dlib just activates the flag for generating a shared lib for the 
systems the compiler runs on.

From a non-Windows system, you have to use -t WinDLL target (and 
just that).

That's what I thought. It looks like the crash happens when there 
are no exports

May I suggest that -shared is a more common switch, usually on systems 
using GCC?

I guess we need an error message in such case.

It also crashes when there's executable code outside functions. I 
guess that's disallowed

There are short and long switches, -dlib is already a bit too long, 
so it might be reduced further in the future, the long version is: 
--dynamic-lib.

I prefer the dynamic/static naming scheme for libraries than shared/static.

Code outside: it shouldn't affect the library as it will never be 
run. I'm testing that...

The compiler seems to crash on it

Can't make it crash that way...what global code are you using?

A lot of stuff. Just my way of claying a new binding out of an old 
one. We'll see when I encounter some specific situation

Have you tried loading a Red/System DLL with Wine?

I've pushed a fix for the compiler crashing on missing #export.

Thanks. No, I don't have a meaningful DLL yet

Don't really have WINE, either. I'd have to dig out the laptop

I'm confused by

https://github.com/dockimbel/Red/commit/0443c4c4fe9bd7a2a86f9b62b566b80f310539e4

I thought the callback attribute was replaced?

The callback attribute is added automatically to a function when 
passed as get-word. But there are some cases where  it needs to be 
manually set, like for the ***-dll-entry-point function from the 
runtime.

The callback was never replaced, just inferred.

Doc, will you extract all the information string of Red source code 
into a file, so I can translate them into Chinese without modifying 
the source code.

You mean the docstring for functions (which we don't have yet), or 
all the code comments?

Doc, I mean the docstring, error messages ...

New Twitter message from Doc: "Making good progress on Red language 
layer, got a stable core compiler now and minimal datatypes set"

Go Doc, Go! :-)

Great.

sounds great

V5!!! ... Which means "Great! Wonderful!" in the Modern Chinese Cyber 
World.

There are still a lot of details to work on, but the core part is 
there. The bootstrapping does had several complications (like literal 
series handling) that will vanish once we get Red compiler rewritten 
in Red.

Thanks Jerry! :-)

*had => add

Doc, this is where we need that screenshot, like the one Linus Thorvalds 
took of the Linux kernel, when he showed it was able to switch tasks 
back in 1991. :-)

:-) Never seen that one, got an URL?

I was looking for it... but now I can't find it.

Maybe there is no original screenshot and I remember it wrong, but 
the kernel exists and you can test it. It's Linux 0.00 and the major 
feature is switching between two tasks that print A and B in the 
console:

http://gunkies.org/wiki/Linux_0.00

I should be able to make a "hello word" script in Red in a few days. 
I still have to make some design decision wrt Unicode internal handling, 
that's really a complex part.

I'm wondering if this is "easy"? Is the development path laid out 
or do you really carefully need to think about each step?

No easy way AFAICT, even if the big picture is there, you need to 
think and take decisions for a lot of details every day, even if 
you try to isolate parts, you always end up with some conflicts to 
solve both at the design and implementation levels.

ok

Thanks for the link...if I take Linus' code and add it to Red/System, 
I should be able to output a VM image directly from a Red/System 
program, no? ;-)

Doc - what I noticed (and please don't take it personally) is, that 
sometimes you miss on how R3 was designed and solved some areas. 
Maybe you could talk to BrianH, who knows lots of things about what 
was/is good about R3, so that you can take similar path? E.g. Unicode 
support took Carl 2-3 months ...

For Red, the bootstrap stage is really costly, I'm really impatient 
of getting rid of the REBOL part and only have Red code.

Pekr: thanks for the advice. :-) I haven't followed very closely 
the developpement of R3 nor I have ever wrote R3 code, so I'm not 
aware of all the reasons for some design decisions. That's why I 
ask when I need to. AFAIU, R3 was designed to solve R2 issues. I'm 
building Red from scratch, so I don't have legacy issues (so far) 
to deal with, I have more freedom than Carl with R3 and I intend 
to use it. They are some parts of R2/R3 design that fit well my plan, 
so I use them as inspiration, but there are other parts (especially 
in R3), that I am not fan of. Also, do I need to remind you that 
Red is compiled while R3 is interpreted? These are two different 
models which require different trade-offs.


The difficulties I have to deal with in Red (both design and construction 
process) are inherent part of any non-trivial work to build something 
new and that's my role to solve and overcome them. The best way others 
can help me are by pointing out errors or inconsistencies both in 
the design and implementation.


Wrt Unicode support, I should be able to say in a few days how long 
it will take to support it. I doubt I  need as much as 2-3 months, 
but anyway, nobody but Carl knows what he had put in, and exactly 
how long it took him. ;-)

Thanks for clarification :-D

I am glad that you are doing the Unicode part now. Better support 
it sooner than later. Back to 2008, I was one of the three Unicode 
testers for Carl, and I found many bugs and reported them back to 
Carl before he released it to the public.

There is a bit that is worth learning from R3's Unicode transition 
that would help Red.


First, make sure that strings are logically series of codepoints. 
Don't expose the internal structure of strings to code that uses 
them. Different underlying platforms do their Unicode APIs using 
different formats, so on different platforms you might need to implement 
strings differently. You don't want these differences affecting the 
Red code that uses these strings.


Don't have direct equivalence between binary! and string! - require 
conversion between them. No AS-STRING and AS-BINARY functions. Don't 
export the underlying binary data. If you do, the code that uses 
strings would come to depend on a particular underlying format, and 
would then break on platforms where the underlying format is different. 
Also, if you provide access to the underlying binary data to Red 
code, you have to assume that the format of that data can be corrupted 
at any moment, so you'll have to add a lot of verification code, 
and your compiler won't be able to get rid of it.


Work in codepoints, not characters. Unicode characters are complicated 
and can involve multiple codepoints, or not, but until you display 
it none of that matters.


R3 uses fixed-length encodings of strings internally in order to 
speed things up, but that can cause problems when running on underlying 
platforms that use variable-length encodings in their APIs, like 
Linux (UTF-8) and Windows/Java/.NET/OSX? (UTF-16). This makes sense 
for R3 because the underlying code is compiled, but the outer code 
is not, and there's no way to break that barrier. With Red the string 
API could be logical, with the optimizer making the distinction go 
away, so you might be able to get away with using variable-length 
encodings internally if that makes sense to you. Length and index 
would be slower, but there'd be less overhead when calling external 
API functions, so make the tradeoff that works best for you.