World: r3wp

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

As far as I can tell, hardly any of the "basic" features work in 
A109.

Doing a plain import %module.r from the console only works as expected 
if the module is named and not private. Unnamed, private+named, private+unnamed 
modules seem to not work.

Here's what I tried:
https://gist.github.com/cd03af7ddacc2eb9a2e3

Well, looking forward to A110 :)

Despite what the blog says, unnamed modules are a bit of an advanced 
feature in the R3 module system. Normally modules should be named. 
But yes, the bug was in the criteria that determined that private 
import should be done, and all unnamed modules do the private import 
method (in alpha 110+ at least).

Carl really should stop pushing unnamed modules in those blogs of 
his. I know they look cleaner, but they are only for certain purposes.

Poor REBOL if DRY gets relegated to an "advanced feature".

DRY?

Don't repeat yourself.

Oh, you mean like what unnamed modules do when imported more than 
once.

No, I'm hinting at the most simple and straightforward use.