hmm, I did not need to do it, INCLUDE %timblk.r is still much shorter than DO %/e/Ladislav/REBOL/timblk.r
DocKimbel
Gregg: did you find it annoying when working on small script that do not need INCLUDE features, or it is not a problem at all?
Gregg
There are a number of things I don't do in R2 simply to make it easier for others to use code I may post. Making it clear that INCLUDE is used is easier than "overload DO, and if you've changed DO yourself...)". I just say "Use INCLUDE. If you have a problem, tell Ladislav". :-)
It is a mental shift, and I still have some very small scripts that don't use it. Those are almost gone, because I almost always want library functions at some point, and I don't care about loading extra stuff locally.
Ladislav
"Gregg: did you find it annoying when working on small script that do not need INCLUDE features, or it is not a problem at all?" - let me answer your question as well: not a problem at all
Gregg
Even my small scripts just start with "do %paths.r" (or a variation for specific projects), which does all the setup.
Ladislav
If I do not need INCLUDE features I am still able to use INCLUDE to run the script (INCLUDE is able to run scripts not needing it)
Gregg
I also have a project generator that automatically creates all the build scripts and such for a new project.
DocKimbel
Thanks to both of you for the answers. I guess I will need to give it a deeper look and try it on some projects to see how it works for me.
Gregg
That's the best way. The hardest part was getting over the "no external dependencies" mindset for me.
Ladislav
My suggestion is: "always define standalone functions, etc. as standalone files, not cumulate things in one file" that way you are able to use everything as a building block for any new project
DocKimbel
That makes sense wrt features INCLUDE offers.
Ladislav
BTW, Gregg, did you consider to add some simple usage examples to
I haven't, but I may. May not happen soon as I have a number of things going on in the next few days.
Andreas
"I wonder why nobody did it yet then (overloading DO in R2 to add INCLUDE capabilities)."
I think because the more obvious solution is to actually bundle INCLUDE with the standard R2/R3 binaries.
I think Gregg has hit the nail on the head: one of the main reasons for _not_ using INCLUDE is a "no external dependencies" mindset. With INCLUDE being part of e.g. a standard R3 build, this mindset would be at ease.
BrianH
The "no external dependencies" thing isn't really as big a deal for R3, as long as they're optional, only used by people who need them. But still, the only reason that include wasn't part of the community library is because we haven't set one of those up yet.
BrianH
Ladislav's include has been the best candidate to be the new prebol for R3. It does basically the same thing without the bugs :)
BrianH
And more :)
Gabriele
"Why is everyone trying to tell me I'm not having these issues." - You're misunderstanding there, we're telling you WE never had those issues.
If you use Encap, you cannot use #[...] notation, that simply doesn't work. In the same way, if you evaluate stuff in your preprocessor, so that you expect to end up with real NONE! values in your blocks (for eg.), that won't work.
MarcS
Does anyone know whether there are plans to lower the SDK price?