World: r4wp

download.r is:

http://red.esperconsultancy.nl/Red-test/doc/trunk/download.r

Cool, then post that link in the future. First time it was posted 
here.

No need to interact with the Fossil web UI with that link.

I publish such links often when a single file is requested

Be sure to use them in the future, and the Fossil UI can be side-stepped 
completely.

Never saw such a link for download.r before (and don't find anything 
using AltME search either, but then ...).

It always could. I've explained many times that Fossil can do everything 
Git can

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. ;-)