World: r4wp

Agreed. My bindings already use that structure among each other

They mirror the situation in the open source world, where work is 
divided in independent projects. Even if you would heap the bindings 
together, you would still have to manage the libraries separately

A distributed source control database is essential to my operations, 
so I can't just use anything that others happen to use

What's wrong with Git for your purposes?

Kaj, downloaded the Zip file from Fossil and re-ran (after sorting 
paths to files) and get the same problem as already posted. The problem 
is not file locations as that results in a different compiler error 
which is easily sorted. It seems to me in the problem I have posted, 
the compiler thinks there is already an alias called str-array! - 
however I have searched every reds file and there is no other with 
that name! Anyway, it is not urgent but I just wanted to feed back 
my findings to you.

Git is bloated, to the point that in the past we haven't been able 
to port it to Syllable. Maybe the core would be portable now, but 
we don't want it, because it's huge and complex and confusing to 
users. Fossil is much simpler

Ken, I'm not sure what revision of 0.2.6 you used. When downloading 
from Git, the "master" branch should be used. I'm also working with 
the v0.3.0 development branch, so I'll reinstall that later today 
to test

There have been many bugs in the development branches lately, so 
if you're not using the latest, all bets are off

ok - I will download v0.3.0 and try it on that too

What do you mean by sorting paths to files? If you unpack the repositories 
in the right places, no files need to be edited

Under windows there is no common folder where the common.reds file 
resides - on windows common.reds resides in the runtime folder, so 
the #include file in the c-library.reds file needs to point to where 
that file resides. Likewise on fib and mand - they point to the c-library 
which I put into the library folder  that exists in the Red/System 
folder on the windows version.

But the file locations are not the issue - the compiler complains 
accurately when the files are not in the locations specified by the 
#include directive.

Ah, see, you're mixing up files. The common.reds file in Red has 
nothing to do with my bindings. It also has nothing to do with Windows. 
You should leave that alone and put my bindings in the subdirectories 
I mentioned in a parent directory of your choice

It's better not to put the bindings in Red's directories at all. 
They are isolated from each other and should be handled that way

But in the c-libraray.reds file that is in the zip file with the 
examples I downloaded from Fosil there is this: #include %../common/common.reds 
- but there is no common folder or common.reds folder in that download 
from Fosil - so where does it find this common.reds file that it 
is trying to access if it is not the one that is part of Red/System?

Yes, that's why I asked you if you had installed the extra Red-common 
repository, from the Announce channel

Ah! Sorry Kaj - I missed that vital bit of info - I will go and find 
it  now

Welcome to dependency hell ;-)

Sounds like DLL hell - and I thought that was only a windows registry 
problem - grins!!!

Yes, it's the sequel

Yay! Success!

Congrats

Thanks for the help :)

Wow! the Mandelbrot is fast - elapsed time 0, process time 0.22

There's reward at the end of the tunnel :-)

Rebol 2 elapsed time: 17.473 seconds - yawn!

Sorry - I tell a lie - that last elapsed time for R2 was for the 
fib - the mandelbrot is 4.436 seconds - still very slow comapared 
to Red/System - this is cool!

20 times faster ? I would expect more :-)

Timing on Windows is inaccurate. For the Mandelbrot, it probably 
includes a significant share of printing the result, instead of computing 
it

Elapsed time for fib on Reds is 0, process time is 0.103 - so fib 
is hundreds of times faster on Reds compared to R2 - so I guess it 
depends on the program as to the speed difference

That's consistent with my laptop that I used for this month's recordings, 
about a factor hundred

It's impressive - Reds will open a whole new world for us C haters 
:)

Yep

What is really exciting is the concept of creating an OS which is 
completely red/red/system - the control, power and speed of that 
woulod be phenomenal

Red/System v2 will be faster, it will benefit from a lot of optimization 
stages that do not exist in the current version. I expect a raw speed 
improvement of between x2 and x4. Maybe more if we can use some SIMD 
to speed up some processing (but that will probably require new datatypes, 
and/or new looping functions).

Ken: full Red stack, yep, that's the long term goal. ;-)

Carl though about it (Lava/MagmaOS), we will make it real! ;-)

Yes - it could truly revolutionise computing - a single high level 
language which enables you to program everything - fantastic concept!

it used to be called  language  C   ;-)

Well, one day, Carl sees the light at the end of the tunnel, and 
joins Red ;-)

Doc - will we have something like Rebin?

I hope that a lot more Rebol coders get on-board with Red to help 
Doc and speed development - Red is the future I think, not interpreted 
Rebol, as brilliant as that has been in the past.

For me the difference is elsewhere - Red has a momentum, which Carl 
almost/mostly killed by the 18 months of information embargo. Red 
has a lead - DocKimbel, who is dedicated to the matter, whereas R3 
looses its main lead - Carl.

it would be nice to formalise, e.g. to have /bindings subdir, where 
partricular systems would be represented by subdirs, etc.


We already have some place for that since many months (it's the /library 
folder): https://github.com/dockimbel/Red/tree/master/red-system/library

Got my raspi board! :-) Any advice on the type of SD card that works 
the best with it?

Haven't got power for mine yet

SD card: a slow and not too big one :)

Have a look at http://elinux.org/RPi_VerifiedPeripherals#SD_cards

64GB SDXC Class 10 Extreme (45 MB/s UHS-I) (SDSDX-064G-X46) - works 
with 2012-07-15-wheezy-raspbian

:-)

SanDisk cards seems the most tested ones.