[REBOL] Re: More REBOL IOS questions.
From: edanaii:cox at: 14-May-2002 18:23
Gregg Irwin wrote:
> Hi Ed,
>
> Two options OTTOMH. 1) the up-file utility that comes with IOS might be all
> you need. 2) write a custom reblet that works exactly how you want.
>
> I can't over-emphasize how important this (#2) kind of thinking has become
> to me. The bar is so low that it's almost always worth writing little
> scripts for tasks you might only do a few times. Anything beyond that is
> gravy. I find that many reblets have common traits of some kind and, while I
> had largely weaned myself away from cut-and-paste code reuse, I'm doing it
> again with REBOL and it's working really well so far. I know that just
> sounds wrong, and I haven't built a large system this way, but having a
> completely self-contained script is really nice. When I find that I'm using
> something more than twice, I start thinking about putting in my general
> purpose library. The other big difference with REBOL is the code/data
> duality. Lots of stuff I would have considered code before, is now data. For
> example, rather than coding directory names that might change into your
> scripts, build a data file that you just LOAD or DO, and your other scripts
> can use that.
>
Option #2 is definitely not lost on me, Gregg. :) In fact, it is one of
the main reasons why I'm focusing on it as a solution.
But I need to make the sale that REBOL will be able to everything
SourceSafe does for us, only better. At first glance, however, REBOL and
SourceSafe appear to be Apples and Oranges.
SourceSafe has a "check-in" "check-out" process. REBOL has a "publish"
process. SourceSafe allows me to check in multiple files and even whole
directories all at once, as long as REBOL allows me to do this, I can
use that to support the idea that it make the version control and
archiving processes even better.
I need it to do this out of the box. But as I said, the fact that I can extend its functionality
makes the that much better because I can use that process to build our master-scripts,
tie them to our change control process, and even use them to support our Meta-data database.
> Sorry for the confusion. Link is basically View with some extra pieces for
> talking to IOS servers. The CALL function and external library access are
> not enabled in the current releases of Link, and there's no easy way around
> that. Cal Dixon, I think, figured out a way to do it with some extra effort,
> but I'd have to look for it if you're interested. For me, I'll just keep
> asking RT to enable CALL in Link and I'll use View/Pro or Command for those
> pieces in the meantime.
>
That's pretty much what I expected about Link. That it disables this
functionality is not a big deal, but being able to use it, would be an
even bigger deal. :)
> OK, it's the 'can I *intercept* a change in a file' part that I'm not clear
> on.
>
> Let's say a file is changed, and saved back to disk. You can monitor
> timestamps, with a polling daemon of some kind with pure REBOL. If you want
> Windows to use the file change notification callback, that I don't know
> about. I'm not a *nix guy, so maybe there's a file-change-interception
> mechanism you're referring to that I'm not familiar with.
>
If it can be done through a daemon that is just as well, but it would be
nice that, when a file changes, a script fires up and executes a number
of processes.
Again, this is not required, but would be nice to have.
--
Sincerely, |
Ed Dana | Courage is fear holding on a minute longer.
Software Developer | -- General George S. Patton
1Ghz Athlon Amiga |
