World: r4wp

Same in Red.

Jerry: symbol! datatype is not reachable for Red users, it's an internal 
feature. I might also add series! and context! datatypes, it will 
be for internal use only too. You can see the types hierarchy at 
page 22 of this presentation: 

http://static.red-lang.org/Red-SFD2011-45mn.pdf

(the types in italic are internal types, not accessible for Red programming).

You don't have typesets?

Not yet, but I will add them.

That can deal with the series! type, unless you have an internal 
reason to have it be a real type.

Also, the ipv6! type might not be derivated from binary! if it can 
fit in a value slot.

I don't see how it could fit in a 128bit value slot, but maybe in 
a larger one.

Internal reason: type inheritance mainly.

I don't remember how long was an IPv6 address?

128bit.

Can't fit a value slot, so it needs it's own buffer.

*its

If you have support for unboxed intermediate values or unboxed series 
types (like vector) then you can make sure you can do IPv6 types 
that way too.

What do you call "unboxed intermediate values"?

Side effect of compilation. The compiled code retrieves a value from 
a value slot or other indirect type, manipulates the values in typed 
stack or register variables, then puts the results back in the value 
slot or wherever.

You'd likely need to use two 64bit registers unless you use SSA or 
something.

Sorry, SSE.

Ok, I wasn't sure what you meant by "intermediate". Red compiler 
will heavily rely on unboxing for all the optimizations.

Right, otherwise there's no point to going through the trouble of 
compiling (aside from the challenge) :)

in R3, Date! is not scalar!. In Red, Date! is scalar!. Why?

Also, in R3, Issue! is any-word!, not any-string!. But in Red, Issue! 
is any-string!

Hope I can keep learning Red while your are developing it. So I can 
help in book writing or something like that in the future. :-)

In R3, date! isn't in scalar! because scalars need to be able to 
support +, -, * and /, and two of those don't make sense for dates.

The issue! type was changed from a string-like type in R2 to a word-like 
type in R3, but the R3 behavior isn't completely final. It will continue 
to be a word-like type, but the syntax might get some tweaking and 
some string-like operations might be added back where possible, perhaps 
in a similar way to how tuples are series/like at times but actually 
immutable.

Jerry: I haven't decided yet for issue! datatype. By default, I stick 
to R2 model. For scalar!, Red definition might differ a bit from 
R3 one, we'll adjust that if required when the work on date! will 
begin.

I have pushed a commit yesterday night that reimplements almost fully 
namespaces support in Red/System. It is now cleaner, fixes a lot 
of issues and it is allows faster compilation of apps that heavily 
rely on namespaces like Red's runtime code. For example, the demo 
Red script now compiles 20% faster.


Please test well your current scripts to spot eventual regressions 
caused by this change.

james_nak: When you run the Red tests, their output is logged to 
Red/quick-test/quick-test.log. Would you mind taking a look to see 
if any error message was logged.

I haven't seen any regressions yet in building the bindings with 
the new CONTEXT implementation

Good! Thanks for reporting it.

Oddly, the Windows (and MSDOS) builds are changed, but I can't see 
where that's coming from

Changed how? Size or content?

Content, I suppose. Probably not size, as Windows works with pages. 
I checked them in, so they can be retested

I am studying Red/System. For me, it's good enough, so I am curious: 
What can C do and Res/System cannot do?

From top of my head: C has unions and can pass struct by value. Both 
those concerns should be addressed in future Red/System versions.

s/concerns/features

Another missing feature in Red/System that C has: 64-bit integers.

Yeah, I thought about the lack of union.

You can address bits in C but not the current version of Red/System

Right, no bitfields in Red/System (yet).

Stack allocation of local structs

16 bit integers

If I use a foreach on a c-string, how can I tell when I am at the 
last character?

tail? stringname doesn't seem to work. Maybe I need to use length 
to keep track of where I am!?

As I understand, there is no foreach in the current version of Red/System 
and no c-strings in the current version of Red.

The best loop to use in Red/System is until:

str: "1234567"
until [
  print str/1
  str: str + 1
   str/1 = null-byte
]

Will print the characters in a c-string ( as would print str).

Hmm, OK, I was using Red so probably it is a string! , but there 
seems to be a foreach.

Thanks for the suggestion about until. Will try it.

MagnussonC, you're mixing Red and Red/System. The above suggestion 
from Peter is for Red/System, not Red. What you are looking for in 
Red is FORALL or REPEAT iterators.

Though, you can also use UNTIL in Red, but string! is not c-string!, 
the + 1 part and final test are not valid in Red.

I realize I mixed string and c-string, but it was possible to use 
foreach on the string. The problem was to find the find the last 
char.

In such case, you should not use FOREACH, but an alternative. FOREACH 
doesn't handle a series offset, so you can't test for a position 
in the series.

Thnx :)