World: r4wp

If you're thinking about OS bindings, they should go in %platform/ 
folder. Can't you add CALL to natives? If you need help I can give 
you a check-list of things to add to support a new native, it's pretty 
simple.

I'll have a try

I'd like to keep it simple and quick for now, so I've done the CALL 
implementation externally in the C library binding, where the Red/System 
counterpart is

Kaj: could you please test if the fix for #277 solves also #381 for 
you?

Will do

It fixes 381 but not 252

Ok, thanks! I will see if I can add a fix for 251/252 too...

I've done a complete build run and I see no regressions in the examples

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

With the implementation of a random function on Red/System I have 
some questions:

#DEFINE seems to become obsolete towards version 2, no preprocessor 
anymore, so any progress on a decision? https://github.com/dockimbel/Red/wiki/Alternatives-to-Red-System-pre-processor-%23define


How are you supposed to implement an array, I can figure out some 
things about using a pointer, but I cannot believe it will work with 
the example value of 40000000h 

http://static.red-lang.org/red-system-specs.html#section-4.8(.3)

I do not have a clue if this is a realistic value as a memory-address, 
that is why a simple array could come in handy.


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.

Time is another fine thing. The OS should support one or another 
timestamp that can be picked up and molded into a preferred representation?

#DEFINE seems to become obsolete towards version 2, no preprocessor 
anymore, so any progress on a decision?


It is not the time for taking decision about Red/System v2. For the 
preprocessor replacement, we are for now just gathering ideas in 
the wiki.

The fourth alternative suggested for defining a constant looks best 
to me, but personally I would just use caps for the name, assign 
a value and not even think about changing it ever again.

The fourth alternative introduces a new datatype, so it has a high 
cost.

Ah, message crossed, I like to be prepared for the future :)

Then I like my method of using a variable and keep it a constant 
myself (but hey I still am a COBOL programmer!)

How are you supposed to implement an array, I can figure out some 
things about using a pointer, but I cannot believe it will work with 
the example value of 40000000h

What are you missing from using pointers?


I do not have a clue if this is a realistic value as a memory-address, 
that is why a simple array could come in handy.


The example is just showing how to do a dereferencing. It will probably 
crash on most systems if you use it with that value (reading should 
be safe on Windows, but writing not, as it is the default read-only 
memory starting page for PE executables). If you have a better alternative 
example that can work for real on all OS, feel free to submit a pull 
request. For example, retrieving the pointer value from an OS or 
C lib call would maybe be better (but much longer). My intention 
in this example was just to show how to dereference a pointer, how 
the pointer is initialized is a lesser concern.

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