World: r3wp

Andreas, the (dis)advantage to private modules is that they need 
to be explicitly imported into your module for you to get their exports 
(selective import). For regular modules, you import into the runtime 
library once and it is just there to share. Regular modules can take 
advantage of this to support upgrading themselves in place, for instance, 
or more easily managing word overrides on a global basis; private 
modules can't be upgraded. Each approach has advantages and disadvantages 
in different situations. This is why we support both export models.

The differences between the two are less if you are importing to 
user scripts. Since scripts share a context, subsequent scripts can 
benefit from the effects of modules imported by previous scripts, 
whether they were private or not.

For me that's purely an advantage. Explicitly importing the modules/functions 
you need is how it should be.

There are real downsides to explicit import. Choose what works for 
your situation.

I'm also pretty sure that upgrading "private" modules is possible.

For instance, with explicit import you can't upgrade a running process. 
That can be a disadvantage for some apps.

But that doesn't worry me at all, at the moment. If R3 ever reaches 
the stability and maturity that such long-running become realistic, 
then I'll start to worry about in-place upgrades.

such long-running processes*

Part of exporting is copying the values to another context, where 
it is used. You don't normally get any references to the original 
module words. And part of importing is copying those words again 
to your own context (for isolated modules and for scripts), or binding 
to the runtime library. So in practice, the only known contexts that 
you can update the values in are your own, the runtime library, and 
the current task's user context. To upgrade other contexts they would 
need to register with you, and you would have to do them one at a 
time.

REBOL processes tend to run for years, if they don't have bugs and 
don't use a buggy REBOL. Do you remember the first mailing list outage?

Luckily, we can change allmost all of that.

But this copying you mention should actually make the updates I have 
in mind easier.

If you meant my last long message by "we can change allmost all of 
that" then no, not in the base system. You can work around it in 
your own code though.

As far as I understood the boot levels allow us to get rid of most 
of the default module system alltogether.

Yup. That is one of the workarounds I mentioned.

Too good a feature to call it a workaround.

What about the mailing list outage?

You say that having not worked with the module system, but yes, if 
you say so :)

I say that having followed the discussion around it and read the 
documentation and posts about it.

And I really appreciate the work you put into it.

The first REBOL mailing list outage happened because the server rebooted. 
The REBOL process that was running the mailing list had been started 
manually, and just kept running. They forgot to add the startup code 
for the mailing list to the init code for the server. But noone knew 
this because the process just kept running for more than 3 years. 
It took a UPS failure to stop the list.

That is the kind of runtime that REBOL is designed to support :)

Ah yes, the legendary REBOL mailing list script.

Times long gone :)

OK, most of the discussion of the new module system so far has been 
in a private world. And the final working system hasn't been released 
yet. And the documentation is outdated. So pardon me if I say that 
you should reserve judgement. But still, being to remove the module 
system with a boot level is a pretty cool feature :)

One which I haven't tested yet :(

Because it doesn't work.

At least I couldn't figure out how to call R3 so that it respects 
the boot-level flag.

I don't know, I haven't tested it yet.

My first priority was to get the module system working, and fix the 
slight design flaws that the previous system had (mostly the API 
of IMPORT). Boot levels are next.

You'd be shocked at how many significant subtleties are tested for 
in the test code. And that code isn't even complete yet.

It made sense though: It's easier to deliberately not load something 
when you know what you're not loading.

I'd probably not :)

Be shocked, I guess. Actually, I was just shocked: The mod-test.r 
file only has 696 lines in it at the moment. I guess this is a testament 
to how compact we can make REBOL scripts with the new system :)

Later! :)

Andreas: boot level info is found here:
>> usage

Example:
r3 -b sys


But, this is magic guru stuff because the boot is stopped early, 
which means that most of the nice funcs you depend on are not yet 
alive.

on boot-level sys, you'll also find that the user context does not 
exist, it is the same as the lib context

core
>> print stats
856824

core -b sys
>> print stats
793984

core -b base
>> print stats
573336

Note that -b base is not useful for you (it's for me) because schemes 
are not yet init'd.  It's a bit like booting an OS without the file 
system.

Also, -b sys is somewhat useful, because there is a very minimal 
LOAD that should work.

USAGE says:
	--boot-level L   Where L can be: base sys mods

Reported as #1713.

And from the hostkit: the long option name actually is "--boot".

I like that better. Nice catch.

Quick Q: are modules supposed to actually work with A109?

Because it seems I can't even get http://www.rebol.net/r3blogs/0344.html
to work.

No, they don't quite work in 109. All of the problems with modules 
have been fixed for alpha 110.

But in theory the stuff in that blog should have worked even in a109.

Next week, as time allows, I will be reformatting the module system 
into a loadable script that can work at lower boot levels. This will 
both be good documentation and allow better testing, for the module 
system and the boot levels too.

See here for the bug announcement, in the comments to the release 
announcement: http://www.rebol.net/cgi-bin/r3blog.r?view=0343#comments