World: r4wp

But - sort your priorities yourself, no reason to get distracted 
....

I admit git is not an intuitive tool and it can be a PIA sometimes...but 
Github is the place to be and it's an invaluable tool for collaborative 
coding.

https://github.com/dockimbel/Red/downloads

https://github.com/dockimbel/Red/tags

I'm just glad I wasn't the only one who thought it was confusing. 
:-) Program on.  Thanks Kaj.

In my Syllable build recipe you can see that you can download the 
current state of a branch the same way:

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/Red--current/

I'm sure it's confusing by design, so that Doc can make a living 
selling single downloads ;-)

Kaj: I might make macros context-sensitive, but I don't see what 
more I can do. The point of #system is to write Red/System code within 
the 'red context, so naming should be done carefully to avoid conflicts. 
But with a few context wrappers, you should be able to solve that, 
no?

As I said, wrapping a binding in a context isn't enough, in the first 
place because #define's remain global. Making them context sensitive 
would help a lot, because they're currently the most primitive construct 
in Red/System

The other big part of the problem is that we have two languages now, 
Red built on top of Red/System, while they're so similar that they 
will often use the same names for slightly different concepts. With 
the bindings, one builds a world on top of Red/System, but the biggest 
parts of them should also be usable in the world one builds on Red, 
without making them look butchered when programming in Red/System

It's fair enough that #system code runs within the RED context, to 
be able to extend it and write the application code - although as 
I said, it's hard to know which names from Red's internal implementation 
will conflict. However, I need another place to import the core part 
of the bindings, outside the RED context so they won't conflict

I should be able to find a solution for that need tonight.

That would be great. Otherwise I don't have a presentation :-(

I know...

You fixed the cast arithmetic in master. Thanks, but I need it in 
dyn-lib-emitter

Ah, you should have said that in the ticket, I copied the fix in 
v0.3.0 thinking that's where you needed it. :-)

Done.

I referred to it in our private chat on our secret project, but thanks 
:-)

Actually, I don't need it, you need it :-)

hehe :)

Ok, I've added (not pushed yet) a new directive for including Red/System 
libs outside of 'red context. Example:

	#system-include [%tests/hello.reds]


will load and compile the hello.reds script. Notice that relative 
include paths are resolved from Red/System root folder (%Red/red-system/).

Does that cover your need Kaj?

It should solve one big part of the problem. The other big part are 
the context sensitive #define's

I also need #include's to work the same as in Red/System: relative 
to the source the path is in

The only #include right now are Red/System includes.

Yes, those I mean

#system-include just inserts them outside of 'red context.

Or do you mean paths in #system-include?

The included file paths are left unchanged.

They are just inserted at beginning of intermediary script passed 
to Red/System.

I meant the ticket I have open

The path of the source file they came from is lost

Does such include work fine with %rsc.r?

Yes, I use them everywhere

(I mean just #include %../C-library.reds)

By the way, I think we should eventually have a search path for includes, 
but that's for the future

Yes, I use relative include paths of that form in all my bindings 
and examples

I need them to be able to install my Fossil repositories side by 
side in one main directory and then #include between them without 
changing paths

I've pushed #system-include addition, but there's probably more path-related 
patches to apply I'm afraid.

context-sensitive #define: seems to be a complicated change as it 
is the heart of the preprocessor...but context are created only during 
compilation (so after preprocessing).

It would be easer if #system-include would be like #system so that 
you could wrap an extra context around Red/Sytsem code, without introducing 
an extra wrapper file. Would that be hard?

No, trivial, I would then just remove #system-include and add an 
option to #system to have the code loaded outside of 'red context...but 
semantically, it will be a bit inconsistent with barebone #system, 
as it means "inline the Red/System code here"...Maybe I should just 
rename #system-include to solve that.

It works as it is now, but then I run into the #define problem

This form of #system-include is probably still handy

Why does it require a block?

I've changed it to #system-global, work exactly as #system but loads 
outside and before 'red context, should I push it?

Please

Done.

Works with #include with an absolute path

There's an extra problem when I wrap the C binding in a context, 
but that seems unrelated