World: r4wp

At this moment I will not worry about support of a L(ong) or 64 bit 
type, I'll work with 32 bits for now.

We will add an integer64! datatype in v2 ("long long" in C IIRC).

What I am missing, is the background about the memory-management 
in certain OS'es, so where is it safe to place/store the data in 
memory. That is why I expect the example value to fail in a general 
situation. When array is supported, this will be taken care of by 
the compiler is my simple thought.

For constants, #1 seems most the the annotation/decoration model 
that is used in other languages.


I like #3, because it looks like an dialect to me. Feels REBOLish.

Arnold: if you use DECLARE on pointer! or struct!, you already get 
an automatic memory allocation done by the compiler for you. Such 
memory will be statically allocated from the data segment (defined 
by the executable). 


Alternatively, you can use ALLOCATE to get a memory buffer for your 
array during the execution of your program (just don't forget to 
release it with a FREE call at some point).

Gregg: so far, I also think #3 is the best as it is the most compact 
form (when defining a lot of constants, all can fit in one PROTECT 
block). I would probably use set-words instead of words though.

Yes, that sounds good to me Doc.

Arnold, I've said it before, but there are time and random functions 
for Red/System in my C library binding:

http://red.esperconsultancy.nl/Red-C-library/dir?ci=tip

Kaj: I've made fixes for #251 and #252, does it work fine for you 
now?

No, it strips any ../ prefixes from relative include paths and then 
looks for them in the compiler tree, instead of just using them relative 
to the location of the source file

I'm working on a new fix for that...

Thank you Kaj and Doc!

Kaj: I have a problem with #381. I have reconstructed a similar directory 
structure relative to Red/System root folder (on Linux). My issue 
is that #include directives specified from Red or specified from 
embedded Red/System should have the same base folder from the user 
perspective, but that's not the case currently. So, my question is: 
do you see any drawback in fixing this inconsistency? (Also from 
the implementation perspective, it is a nightmare to handle otherwise)

https://github.com/dockimbel/Red/issues/381

Think of it in the context of Red being encapped and used a single 
binary, having a reference to a Red/System base folder would make 
no sense.

I don't understand. #381 is already fixed by your new code

The Red directory in my example has nothing to do with the compiler 
tree. It's just the parent directory in which I keep my projects. 
I want include paths to be relative to the source file, not the compiler, 
be it Red or Red/System

Hmm...let me see, I might have introduced a regression in my uncommited 
code...

It would be very useful to have a search path for includes that could 
include directories elsewhere, possibly in the compiler tree, but 
it should start by checking relative to the source file

What command line are you using for testing #381?

(I still can't make it work here)

Wait, it seems I'm not at the head of the branch...

r2 -sw ~/Desktop/Red/Red/red.r ~/Red/common/examples/test.red

Thanks!

~/Desktop/Red/ is a symlink to ~/Red/. Not sure if that complicates 
anything

Arnold, I've said it before, but there are time and random functions 
for Red/System in my C library binding:
 

I must have missed that remark before. But then again, I like to 
try this using Red or Red/System as an exercise or for fun or to 
not be dependent of using C (Why not do it all in C? Because we have 
Red/System.)

Arnold - binding just means, that Kaj have created a library of some 
functions in Red/System.

just look here - http://red.esperconsultancy.nl/Red-C-library/dir?ci=b67c4b9a38dbfed9

I have completed the set of fixes for various path issues for Red. 
They are available from the `fix-issue-277` branch and they should 
cover the following issues:

#251 (Red doesn't find source in working directory)
#252 (#system cannot find #include)

#277 (Include system doesn't handle well files with same name in 
different directories)

#366 (Compilation of code outside of the Red/ path fails under Windows)
#381 (#system-global doesn't detect equal #include paths)


Please let me know if there are remaining path issues to fix before 
merging this branch with master.

Just want to briefly describe that in my expectation a C-level language 
means you can do things like you would when using C. So it is not 
that you would have to call functions/programs/libraries with C programs 
to do those things. So for speed issues or fast prototyping purposes 
or to do things not yet possible in another way you use the bindings. 
In my case I wanted to try to program a relative simple algorithm 
of which I have an example in C and I want to do that using Red or 
Red/System. I can accept it is too early at this stage.. at least 
for me but this kind of thing is what others will be doing in the 
near future and they discover you can do literally anything using 
Red and Red/System, as long as you make a C program to do it and 
call that. That is a bit of a black and white view, but that is how 
I see it.

Thanks, Doc. That's a major devil driven out of the details

The hardest part was to tell apart REBOL path issues from Red and 
Red/System own path issues.

They look too much alike ;-)

Arnold: I can only encourage you to do so, implementing more algorithms 
in Red/System is the best way to help it grow and improve it.

Arnold, Red/System has been ready for writing code for at least a 
year. Red is only getting to that stage now, so that's why I have 
been working in Red/System. My 6502 emulator is a major self-contained 
work in Red/System, but there's also the issue of communicating with 
the outside world. Unless you write your own operating system, the 
way to do that is by binding to the existing operating system

#252 is finally fixed

More great progress Doc. Thanks for the update.

I've tested a number of complex scenarios, including one I hadn't 
reported yet, and they work now

We are still struggling to make #366 pass in all use-cases (Windows/Linux/OSX, 
run from console vs from shell,...): https://github.com/dockimbel/Red/issues/366

Fortunately, I can skip the Windows discussion :-)

Actually, my last issue in on non-Windows systems, with the run from 
"console vs shell". Hard to fix one without breaking the other...

With the help of Andreas and Peter, we've fixed the last remaining 
non-passing cases. I will merge the fixes in the master branch tonight, 
in the meantime, if you notice any regression or issue with paths 
handling, please report them here before the merge.

It's great to hear you're making continuted progress!

Thanks Nick.

Just donated 50 EUR so that Red project does not feel bad by my move 
to donate also to R3/Android/GUI :-)

Thanks Petr! :-)

I've done a full build run with the path fixes, without regressions

Merged branch `fix-issue-277`. Thanks to all contributors and testers 
for helping clean up those issues.

http://www.rebol.com/cgi-bin/blog.r?view=0527#comments


Fork: "I am porting Red to R3--and while I won't claim I'm "almost 
done", I will say I've made significant progress. Red/System now 
builds a working hello.reds under both R3 and R2."


Great! Like Nick says, hard to keep track of everything happening 
these days. :-)

surprised by Fork even looking into Red, he seemed to be interested 
mainly in R3 itself ...

Well, in fact I don't understand, what he actually did. What I would 
expect is someone writing R3 in R/S, so that it would got all backends 
R/S supports?