World: r4wp

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.

If there are parts of R2 or R3 that you like or don't like, don't 
assume that they are part of the design. There's a lot of stuff in 
there that doesn't match the design, is buggy or unfinished. Also, 
for R3, don't assume that only Carl knows the design. He worked with 
others, discussed his design with the other contributors. There's 
some stuff which only he can answer though, and some design decisions 
that weren't resolved, let alone implemented.

The concurrency model was not fully designed, for instance, and almost 
completely not implemented.

However, the part of the concurrency model that was designed so far 
affected the design and implementation of the system model and module 
system. You'd be surprised how much the module system was affected 
by the system, binding and interpretation model of R3; very little 
of its design and implementation was arbitrary. You might be able 
to get the syntax the same for Red's module system, but given the 
different system/binding/execution model there wouldn't be much of 
the implementation in common.

I am for sure no expert regarding unicode, but as red is a compiler 
and open source, why not not add flags that the user has to choose 
which unicode/string support he wants; either flexibility, but of 
cost of speed or no unicode support, then he  has to do the hard 
work by himself

One hypothetical advantage you have with Red is that you can make 
the logical behavior fairly high-level and have the compiler/optimizer 
get rid of that at runtime. REBOL, being interpreted, is effectively 
a lower-level language requiring hand optimization, the kind of hand 
optimization that you'd want to prohibit in Red because it would 
interfere with the machine optimization. This means that, for strings 
at least, it would make sense to have the logical model have a lot 
of the same constraints as that of R3 (because those constraints 
were inherent in the design of Unicode), but make the compiler aware 
of the model so it can translate things to a much lower level. If 
you break the logical model though, you remove the power the compiler 
has to optimize things.

sqlab, it would make sense to have the user choose the underlying 
model if you are doing Red on bare metal and implementing everything 
yourself, or running on a system with no Unicode support at all. 
If you are running a Red program on an existing system with Unicode 
support, the choice of which model is best has already been made 
for you. In those cases choosing the best underlying model would 
best be made by the Red porter, not the end developer.

but that means, that Red has to support all unicode models on all 
the systems, it can be compiled for.

That's not as hard as it sounds. There are only 3 API models in wide 
use: UTF-16, UTF-8, and no Unicode support at all. A given port of 
Red would only have to support one of those on a given platform.

Red user code would only need to support the codepoint-series model; 
Red would translate that into the system's preferred underlying model. 
More encodings would need to be supported for conversion during I/O, 
of course, but not for API or internal use.