AltME: SDK

Messages

DocKimbel
Both cases, when run and encapped.
Ladislav
yes, it is always both
DocKimbel
I mean, when encapped, such data file should be encapped too.
Ladislav
I can use either #include-binary or #include-string, etc. directives, or even the #do directive for something different
DocKimbel
When run with DO, it should be just read from disk.
Ladislav
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
DocKimbel
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. :-)
Ladislav
that is not a problem, why there is any problem in using rebol -s %incl instead of rebol -s?
DocKimbel
I guess I shouldn't be able to use %do on any such script from console anymore?
sorry: do instead of %do
Ladislav
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
DocKimbel
How does it avoid collisions between similar script names in different include folders?
Gregg
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.
Ladislav
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

Last message posted 49 weeks ago.