Comments on: Delayed init of built-in modules
As I start to use R3 more for real apps, specific needs pop up. For example, for writing R3 CGI, I'd really like CGI built-in, but unlike R2, I don't want them to init if I don't need it.
That is I want delayed loading of certain boot modules. This goes for various other useful functions.
The mechanism would work the same was as it does with import. I'd write:
and it would check first if it's built-in and load/init if so.
This way REBOL can have all the general features it needs, but not require boot time or memory when those modules are not needed. Because such modules are compressed, they don't take much memory when not used... and it let's us put quite a lot of what we need into the standard distribution: protocols, DB interfaces, toolboxes, etc.
this is exactly how slim modules work when libs are linked (less the compression) and its been working well for me for several years already (even before first devcon!).
there was a related discussion on R3 chat about command-line shortcuts (like the 'Q word for 'QUIT) which raised an interesting issue... should they be imported by default? we where split roughly 50/50 on the question.
adding above import statements to our rebol.r would allow us to integrate what default modules we want in our console without RT forcing them upon us.
maybe some modules could be part of rebol.r by default, but then we could remove them if we want.
this would also allow us to set up import scenarios where we could have meta packages - the ability to call all packages in a group (example protocols / gui / shortcuts) or specific packages like load 'ftp
Very good idea.
It means, more built-in modules while keeping a decent boot time.
Who can be against that ? Nobody i guess.
The further gui could be one of them.
So that, we wouldn't need of 2 standard versions of Rebol (core and view)
Definitely supported on my side. We could use words like 'invoke, 'init, but for the simplicity reasons, 'import is probably very right word to use.
I too want R3 for CGI, and was thinking about the speed of booting compared to R2 Core and especially Base. Help system is another candidate to not boot, unless 'help function is called for the first time. It needs to stay transparent = no need for user to import help - it would get imported by calling 'help.
Compression is interesting. I also wonder, what happened to Rebin concept, which woul allow binary "packaging". I think it is time to think about packaging concepts a bit too. We surely dont want components to be delivered in many files, but one ...
Max: don't remove 'q by default, or I am not going to buy you a beer at next Devcon :-)
I love this idea. It would give us some of the advantages of host building and library modules, while integrating with both of those if need be. It wouldn't be difficult to make IMPORT look for unloaded modules in an internal list before checking the filesystem. There would be no change to the binding and export process needed, and even mixins could work.
Pekr, HELP is not that large a function. Most of the help system is the doc strings that are loaded with their respective functions. Demand loading HELP won't help much.
What about Rebin? Compressed source has too much overhead, and series shared references are lost. We could speed things up quite a bit by using Rebin, afaict.
I like it too.
It seems very Rebolish: just 'do what is needed when it's needed... and it's simple (KIS!)
...we wouldn't need of 2 standard versions of Rebol (core and view)...
I agree. To many packages can be confusing. Very good idea. Can slim way down...load only what is needed.
Post a Comment:
You can post a comment here. Keep it on-topic.