yes, it is always both
I mean, when encapped, such data file should be encapped too.
I can use either #include-binary or #include-string, etc. directives, or even the #do directive for something different
When run with DO, it should be just read from disk.
it works using something like
# rebol -s %incl.r "%cheyenne.r"
actually, I do not write these #rebol -s %incl.r "...", I just click on the file
and to encap it, I use right-click
...and it does not work just in Windows, the same holds for Linux
I run all my REBOL scripts using F10 key from my code editor (which launches "rebol -s" on the script), having to use a wrapper script won't fit well my way of working. F11 encaps the current script directly with /Pro, F12 encaps it with /CommandView. :-)
that is not a problem, why there is any problem in using rebol -s %incl instead of rebol -s?
I guess I shouldn't be able to use %do on any such script from console anymore?
sorry: do instead of %do
just use INCLUDE
(it actually even finds the script for you, as opposed to DO which does not have a search capability)
for example, I write:
include %timblk.r
and do not care where the script is, since INCLUDE finds it for me
How does it avoid collisions between similar script names in different include folders?
It does mean relying on INCLUDE as a normal part of your workflow and approach, but I would have a hard time giving it up now.
You can use the #include-check directive to catch multiple includes, so your include-path gives you control.
it uses the INCLUDE-CTX/PATH search path variable, where the first found first served approach is used. Also, you can adjust your path at any time, which is being done by some scripts to "shrink" the search area
...and you can alway just write: INCLUDE-CTX/PATH: [%.] which uses only the current directory for search

Last message posted 49 weeks ago.