World: r3wp

INCLUDE/PATH: you are using an old version, I suggest you to switch 
to this one: http://www.fm.tul.cz/~ladislav/rebol/include.r, which 
does not use the /PATH refinement any more. Instead, a special variable 
called INCLUDE-PATH is used

aha, regarding INCLUDE-PATH: maybe I did not understand your proposition

so, you propose a new refinement? (I think I had such a refinement 
once, but removed it...)

what does BrianH think about this? How it should be done to make 
it the most comfortable for the users?

I prefer an issue! keyword dialect, the changing the issue! type 
to be word-like withot the binding. I don't like INCULDE as a function 
name because that would preclude its use as a set operation the opposite 
of EXCLUDE (but that's just me) - using #include and such as issue 
keywords is fine.


An extended prebol dialect like Ladislav's include would work, if 
renamed and made module-aware. When you have modules most of the 
keyword directives go away in practice, since the module scripts 
can be converted to MODULE calls.

how does the module path interface look, Brian?

Just a block of file! and url! paths for now. The file paths of the 
original files can be used at preprocessor time, but would be unnecessary 
at runtime since MODULE doesn't use them. Once the module is loaded 
its load path is irrelevant, and doesn't even have to exist anymore.

The default:
>> system/options/module-paths
== [%./]

yes, that is OK, sure

The preprocessor would need a directive to set module import paths 
that would be used during the preprocess - it probably shouldn't 
use the standard paths in the preprocessor's running process, since 
that would get the modules the preprocessor is using mixed up with 
the ones it is processing, which would prrevent cross-platform processing.

you mean something like (currently used): #do [append include-path 
%this]

Yeah, but with its own official directive. Preprocessor directives 
are friendly - code patterns requiring #do are not. Adding module 
support to the preprocessor means doing it for real.

yes, sure

I'll be back this afternoon (It's still morning here).

Yes, want I wanted to say that I prefered the old INCLUDE/PATH over 
INCLUDE-PATH because it's one word less to "pollute" the global namespace 
(is there such a notion in R3? I'm not so sure now) and it's one 
word less to remember - the refinement will always be easy to learn 
about with HELP INCLUDE.

Re: "INCLUDE as a word" - isn't IMPORT an option, too? We have no 
EXPORT to conflict with, have we?

IMPORT is used in R3 for module management, which (according to Carl) 
is "not usable for building distributions using..."

then there is the system/options/module-paths variable

(in R3)

PREBOL set aside, I really think IMPORT/CHECK is the common case 
and one of the main advantages over a simple DO - preventing circular 
imports and such. I would be deeply surprised if Carl opts for INCLUDE 
(or #INCLUDE or whatever it will be) not having that check functionality 
in the standard case, switched off by a refinement. But that's just 
me and I certainly don't have any extensive build scripts ...

IMPORT - ah, o.k., I didn't know about that.

we may ask him, you can contribute to the discussion article: http://www.rebol.net/wiki/Inclusion_Methods
, ideas welcome

even the notes you mentioned now are good to keep in there

include should be /check by default   and we should add an  /ALWAYS 
refinement to force reload.

@BH - would changing issue! to a word! sub class rule out some of 
its current capabilities?

Yes. We've made many such changes in R3, removing some functionality 
to replace it with better functionality. It wouldn't have to be as 
bad as you might think - we could change it to copy-on-modify and 
most uses of issue! would still be viable. Keep in mind that use 
of issue! for binary conversions will be going away anyways, replaced 
by better methods. We have strings and tuples for most of the rest. 
The only real difference is just a datatype and/or syntax difference.

Chrisitian, R3's module system handles circular imports without need 
for any /check option.,

Ladislav, R3's IMPORT is not suitable for building distributions, 
but the syntax of modules was designed to be so.

qwikitxt - Nice Janko!

Gregg and amacleod : Thanks :)

Oles: I still can't fully get this.. are you building this flash 
game in REBOL? or is there AS3 code + REBOL to for example generate 
some data for game, etc... ?

I'm building it using REBOL (writing code in old but still my favourite 
Crimson editor). Which means I'm producing AS2 bytecode and also 
modify (resize, join...) various swf files with graphic ( on bit-level 
:) I'm using various caching so for example don't have to republish 
the graphic all the time when I just need to change simple logic 
in my code.

are you the only coder in the team?

I mean at this project

yes

all I can say is "Mega WOW"  :)

I made some flash games (in HaXe mostly).. I have no idea how to 
make a game with so many details, animations, sound, things that 
need to work together...what else to do is in REBOL using some dialect

Oldes: the demo is fabulous... congrats!

you should try and market your engine as an alternative to the other 
flash game building tools.

Max - pity Cyphre is overloaded with work. He did some library for 
R2, where he mapped it to HW acceleration, so that you could have 
general face rendering accelerated IIRC.

about www.reboltutorial.com , its one of the best rebol specific 
pages out there... There is a lot of very cool & unknown work on 
that page.... too bad the author hasn't put any of his stuff on rebol.org.... 
we would have more knowledge of it.   strange is that the author's 
name isn't anywhere on the site... even though we have a good clue 
as to who it is IIRC...

pages = sites

What are the prerequisites?

>> do http://www.hmkdesign.dk/rebol/vid/src/vid-ext-kit.r

Script: "VID Extension Kit" Version: 0.0.1 Date: 29-Aug-2009/14:02:19+2:00
** Script error: insert-event-func has no value
** Where: catch either either applier do
** Near: catch/quit either var [[do/next data var]] [data]

ok, let's see...

it's not for R3

ah, yes. :-) it's for R2.

sorry.(

but, I should probably make a message in the script about that..

You did already. My fault not to read.

it's in the announce, sqlab just missed it