World: r4wp

I published three links in that form in the Announce channel, just 
not of download.r. There are many files, and people are already tired 
of my links

I'd suggest to use those links in the future.

I'll keep it in mind. And I'll remind of this request when people 
complain about my announcements again :-)

In any case, that's the difference between Oldes' link posted before 
and your previous "get download.r from http://red.esperconsultancy.nl/Red-test/dir?ci=tip".
Oldes' link doesn't require you to interact with Github's UI, your 
link requires one to interact with Fossil's UI.

Yes, because I want to supply some context and I don't want to spam 
with many links that can also be had on one web page

I am with Kaj on this. Supplying the download link when you update 
some project is not meaningful. If the corresponding link to the 
fossil rep is posted you can take a quick look at the  projectfiles 
and then decide if it is worth the troul]ble for you to update your 
own repo's with the dl script.

Besides that, the Github is not a nice solution imho just chosen 
because of free, and widely used (for exposure purposes) not for 
real ease iyam (if you ask me). So better appreciate the huge work 
Kaj has pulled of to make Red much more widely useable and accept 
his choice.

I would be interested in the demo video from Kaj where he shows how 
he uses fossil in his daily work.

I thought you were the video master? :-)

My use is quite simple. I just check in my work and seldomly need 
a branch. It can be seen in the timelines

The more sophisticated use is on Syllable Server, where I host our 
repositories

Continued in Fossil

Do you think

pick [1 2] yes

is faster or shorter than

either yes [1] [2]

Not sure it is faster, but it takes one less statically allocated 
block.

Aren't those EITHER block compiled away into code?

blocks

I have already thought, since Doc mentioned the small gains Red would 
see from compiler optimizations, that having a Red level optimizer 
might be even better.

I have understood it the other way around

Kaj: depends if it's in a function body or in global context, and 
if the bodies are stored or not.

Gregg: we'll add optimizations at all possible levels.

How does the compilation differ between global context and a function 
body (apart from storing)

?

The generated code for global and local variables is different.

I think I still like the EITHER better, then. It's more natural

I find the PICK version easier and faster to type, but that's just 
personal taste. :-)

I spend a very small part of my time typing

The PICK method seems more like an interpreter optimisation to me

I think it's good to have both from many perspectives, one being 
that EITHER reduces the values while PICK does not. I tend to use 
PICK for passive values and EITHER for evaluating expressions. You 
can also express a different intent using PICK than EITHER, think 
how a static code analysis tool (e.g. an IDE) would interpret it.

Agreed

Use them to express intent + 1

I have taken a look at XieQ's version of the Mersenne Twister and 
found that that too does not produce exactly the same results as 
'my' C version of the program. One of the issues is the shift result. 
I give this example:
int: 80000000h
print ["Value int: " int lf]
shi: int >> 31
print ["Value shi: " shi lf]
Result is Value int: -2147483648
Value shi: -1

afaict the C version using unsigned long integers this shift action 
results in +1

After that the xor with this different signed number get rid of the 
sign. 

Another little thing is the adding of the count/sequence number is 
different when added to a positive/negative number.

Getting the exact same result is important to me. While this version 
is good enough to use as random for throwing dice in a game of Yahtzee, 
distribution of randoms in longer term could be more predictable 
than with the "official" version, which would be a bad thing when 
used in encrypting.

(Because of the multiplication factor used a small difference in 
startvalue will result in completely incomparable resulting numbers)

Would like to see the hex representation of various inbetween results. 
Is that possible in Red/System?

The C library binding has form-hex, or you could use print-form

To shift as an unsigned number, you should use >>> instead of >>

Thnx Kaj!

If you want to print an integer in hex format in Red/System, you 
can also achieve it by a simple casting to a pointer type:

    print as byte-ptr! int

FYI, I've been mostly offline these last days as a friend of mine 
came to visit me from Paris. Also, that's the moment my Windows chose 
to die, not sure if it was triggered by a hardware issue or not. 
So, I'm now in the process of setting up a new system, moving to 
64-bit and bigger disks. I hope to be able to get all my tools back 
by tomorrow, so I'll be able to start committing changes again.

I can't wait to have a cross-platform Red IDE and forget about what 
"installation" means. :-) A Red OS would also help a lot. ;-)

Sorry for the hardware problem Doc. You can blame me. I sometimes 
think "How can I get Doc to write a Red OS...?"

Hehe :-)

We'll to that too at some point in the future.

We'll <come>...

What would be the difference in Red/System between
#define var value ;and 
var: value 
because both are valid? When to use either of them?

Ah read documentation again. Constant form, macro substitution. #define 
should be hardcoded, non variable so faster in executing.

How do we install support for Unicode when using a Windows console 
? When I open Hello.red with my MS Word, the unicode characters are 
visible but when I run it my "invite de Commande" I can't see them, 
they are replaced by ? Must we go the old way of page codes as when 
we were under DOS boxes ? I hope not ...

I'm trying this small Rebol 3 sample code under Red console and I 
get 3 load errors plus a real error at the end  - invalid char!. 
char ending delimiter " not found! unmatched ] closing bracket! word 
has no value.  Is it OK ?  Here is what I tried to enter : red>> 
 #"^(3B1)"     ; char as a hex encoded literal