Comments on: Boot Levels

Carl Sassenrath, CTO
REBOL Technologies
28-Sep-2010 18:05 GMT

Article #0337
Main page || Index || Prior Article [0336] || Next Article [0338] || 28 Comments || Send feedback

Updated 29-Sep-2010: no longer using integers

PROPOSED: Subject to Change

This feature is intended for advanced programmers developing new resident mezzanines or modules.

A new --boot command line option controls the boot level:

 baseinitialize only the lower levels. This option is for special purpose testing only because it provides no way to load external code. (No schemes, such as file access, nor load or do functions.) If your host-kit build is crashing on startup, you can use this option to confirm that the exe image is loadable and runable.
 sysinitialize up to and including the basic runtime lib and sys contexts. This option allows you to run a very "lean" system (minimal memory and boot time) where your code will be supplying all other run-time functions and modules. Provides a basic load function but with very limited special options (no import, needs, versions, or related features.)
 modsinitialize up to and including lower-level resident modules. In addition to boot-sys, this level adds high-priority resident modules, but not mezz plus (higher level mezzanines).

For example,

r3 --boot base mycode.r

When no option is specified, all resident features are enabled, including mezz plus and all other resident modules.



Gregg Irwin
28-Sep-2010 17:17:19
Is there a reason the boot levels are integers rather than words?
Carl Sassenrath
28-Sep-2010 19:24:55
Gregg, I was thinking that myself as I wrote it, and justified myself by pointing to Linux. The idea being that this is a level, so they are ordered as numbers.

I thought I'd see if someone mentioned it... and I can count on you. Yes, probably should be words. But, if so, do we lose the nice intuitive feeling of "level"?

Could just be flag-based I suppose.

BTW, according to your comment's timestamp, you mentioned this 45 mins before I posted. Hmmm.

Carl Sassenrath
28-Sep-2010 22:04:33
Ok, thought about it. Decided: it's an integer.

Reason: this is a special mode for gurus, used rarely. So, let's not add noise to the cmd line options. Also, it's easiest to deal with as ordered steps. Hence, integers.

29-Sep-2010 0:39:06
Well, this is very bad decision indeed, very non-rebolish. I noticed integer! type in the spec, but then my eye/brain got probably satisfied by looking into boot level description.

In fact, it is very easy - why do you bother with explaining boot-levels at all? Numbers are self-explanatory, aren't they? ;-)

So - what you in fact introduced, is another level of abstraction - you want user (whatever he is, novice or guru) to remember and map the integer number to its meaning. Nice look-up table, but I can guarantee you, that you either push user to look into docs each time, or introduce comment line in batch scripts.

OK, to be even more ironic, I suggest looking into 'usage function, and remap also other arguments - those are not any less guru level, than boot-level is :-), hence an example:

rebol.exe 151

... and if you wonder what does it mean, then maybe you will find somewhere in docs, that it refers to:

rebol.exe -cswq

And btw e.g. 'secure boot level options are words too, so? :-)

29-Sep-2010 3:22:09
I agree that integers are non-rebolish. I vote for words.
29-Sep-2010 3:51:24
I too find integer! not very rebolish. As Pekr point to, we will surely need to dig into the doc to remember what level 3 does exactly each time we need to use it.

Word! would be easier to remember and the perfect mix of the two would be even better:
- keep integer! level (easier for ie. automated tests),
- add word! levels with the integer value in it ('boot-core0, 'boot-sys1, 'boot-host2, ... or 'boot0-core, 'boot1-sys, boot2-host, ...),
Then, allow the two possibility in the command line parser (just a line or two of code).

And last, enjoy happy rebollers all around the world.

29-Sep-2010 3:52:35
+1 for words.
29-Sep-2010 4:02:37
+1 for Words too.

The Words map to integers anyway: Have both, use whichever whenever necessary.

All that is needed is a table for visual clarity.



29-Sep-2010 4:05:49
(at)Mr Sassenrath: 'Reason: this is a special mode for gurus, used rarely.'

Erm... Beginners become gurus if they're not excluded from the beginning.



29-Sep-2010 4:37:06
I absolute vote for words. What if you add another boot level in the future?
29-Sep-2010 5:14:15
Henrik, I think that Carl would simply add another integer, but I might not properly understand your argument. But, boot-level is just like secure:

--secure 'allow | 'ask | 'throw | 'quit

--boot-level 'core | 'sys | 'host | 'mods | 'mezz | 'all


1) use words, remove "boot-" from the word name

2) I hope it is just question of one's getting used to, but I am very uncomfort with the naming of 'lib and 'sys lately :-( We use REBOL own naming conventions all around, whereas lib/sys sound like we try to adhere to the external world.

'exports was much better name than 'lib, if you ask me, because the word maps to the meaning.

As for the boot-level, I would prefer 'base instead of 'sys anyday (of course if the meaning is not shifted, but I have 'base mapped to my brain from the old R2 days :-) ). We describe "functionality packages" during the boot, and hence imo no need to refer to 'sys context here ...

Now note - it is really not a big deal, just the question of pleasure of use.

Maxim Olivier-Adlhoch
29-Sep-2010 10:30:12
+ one for words (didn't use an integer for my vote ;-)

though keeping integers also is pretty easy... in the host, its just a question for two argument values to map to the same level.

also... REBOL gurus like words ;-)

In the host C source, once the arguments are parsed, it can obviously be stored as an integer level, but a mezz function to map the level to its meaning would be very appreciated too.

29-Sep-2010 10:53:56
Pekr, a new boot level could perhaps occur between level 2 and 3 or 5 and 6. Since they are integers, you would have to move the other boot levels, potentially breaking a lot of code. Using words would prevent that.
Brian Hawley
29-Sep-2010 11:10:48
Not sure I buy the "not REBOL-like" argument, but Henrik makes a good point: Using integers makes later changes to the list a little tricky. That's enough to make me vote for words.
Carl Sassenrath
29-Sep-2010 12:27:42
Ok... IHY! (I hear ya)

Above decision is reversed. Will change to words.

BTW, you'll be happy to know I concluded that same thing this morning when I had to move one of the levels, and I realized that the entire "levels" idea wasn't going to work as I had intended.

Once again... we cannot take "guru" shortcuts in place of good design. I will update the above blog content.

Gregg Irwin
29-Sep-2010 12:37:37
"BTW, according to your comment's timestamp, you mentioned this 45 mins before I posted. Hmmm."

I can see into the future, just not very far.

I know *nix uses levels, as many of us have in the past, but I don't care for them (beyond things like low/med/high). Syslog is the main thing that comes to mind. The levels are named, but have never created a clear "order" in my mind. More and more I try to use a tagging model. Yes, it means you may have to list multiple tags at times, but it provides clarity and fine-grained control.

And I'm glad you had a good reason to change it. :)

29-Sep-2010 14:03:08
Words are better, but now it's somewhat the other way round: three "levels" hardcoded as three flags. Why can't we do what Pekr suggested, one flag taking multiple options:

--boot 'core | 'sys | 'host | 'mods | 'mezz | 'all

That would be readable all the while not introducing a mess of multiple flags. And it is still nicely extensible.

29-Sep-2010 14:10:34
Seems the post was updated while I wrote above comment, which is now obsolete.
29-Sep-2010 14:15:21
Uh, the article completly changed. Now what's that? Carl, you probably forgot, that we also need simple -b representation. So how do you refer with single -b to all 'boot-base, 'boot-sys, and 'boot-mod?

Why not simply:

--boot 'core | 'sys | 'host | 'mods | 'mezz | 'all

And also - you seem to be in a hurry? :-) You are usually very picky about the names, and generally against abbreviations. For me all following names introduced lately, feel non-rebolish and they don't sound accurate - 'sys (should be 'base imo) 'lib (should be 'exports) :-) All IMO ...

29-Sep-2010 14:17:15
eh, ditto Andreas ;-) The blog changed once again, and now it seems OK :-) It seems blog is not good instant messaging platform, suited for fluid discussions :-)
Gregg Irwin
29-Sep-2010 17:06
What about [kernel base standard|default plus ...] as words?
Carl Sassenrath
29-Sep-2010 17:51:17
Yes, the blog is updated as things change.

The -b is still there as an option, followed by the same word args. The naming is PRELIMINARY and may change over the next couple days, but the code needs to be written and debugged, so things are happening in parallel.

Regarding sys vs base: neither one is a great name. I picked sys because it sounds more "restricted", which is the main point of the context. It's really kind of a mix of special functions that should not generally be imported into user code. It could be called "misc" or "priv" or ??? (Suggest it.)

Regarding lib vs exports: you need to try it first, and spend some time with lib... This definitely behaves more like a lib with the new binding changes. And, new users will understand it better too.

Regarding blog vs IM. Because we need to preserve the main article as well as the discussion... somewhere it can be referenced later if necessary.

Brian Hawley
30-Sep-2010 2:51:10
Note: The new lib context doesn't necessarily (or yet) contain any exports.

As you can tell from a careful reading of the boot level descriptions above, the module system is optional, and not installed at the lowest boot level. The module system, once installed, will be referenced by the sys and lib contexts, will export stuff from regular modules (not mixins) to the lib context, and will use the lib context as an import library. But the sys and lib contexts exist independently of the module system and any concept of "exports".

For that matter (at time of the posting of this message) the boot code doesn't include the module system at all, yet.

14-Oct-2010 8:21:49
-pekr- "Well, this is very bad decision indeed, very non-rebolish"

perhaps you think there might be several unknown software failures that are hard to track down ? #aabbcccc.dddddddd

perhaps you should buy him a new but it doesn't seem to have a Rom button you can wack.

14-Oct-2010 8:50:42
"Regarding sys vs base: neither one is a great name. I picked sys because it sounds more "restricted", which is the main point of the context. It's really kind of a mix of special functions that should not generally be imported into user code. It could be called "misc" or "priv" or ??? (Suggest it.)"

i dont get it, especially coming from you carl, why not just do the simple

set start= assign[] assign "somename"= 1, "misc"=2,priv"=3,"Suggest it"=4,"the begin and the end"=0

assign "heres a good name"=4 if exists RAD:start do assign

oc to make it work properly , you need each rebol to make a tiny local RAD that you can store these env in and set your sequence of events , and you need a way to make them read only after you finished setting them up and cover corner cases etc, but its been done before remember ;)

15-Oct-2010 10:23:59
hmmm, in effect from inside a software client (rebol core) you want to emulate the slax layout and its liveCD/USB modules type use

have a core base, a trusted 3rd party modules, extension modules in the inner circle of the modules livecd/rebol core and finally unknown 3rd parys modules that can be loaded on live demand as wanted...

but from a rebol extended app perspective, with some form of build page to customize the whole as you wish ?, it kind of works UK actually but not very inventive, or what some might call innovative, as it takes a core set of people to always be around to make and check these build's for compliance and that they actually work for a given base.

much like the many old scripts on in fact , where you cant simply do them as they break now, just the same as tomas's old slax modules and his great Linux Live scripts that revolutionized the liveCD but others keep messing up ;)

Louis Vuitton bags outle
7-Jul-2012 21:42:41
Visit buyIf want to know where you want to buy Louis Vuitton bags outlet sale, you can use online resources Designer Louis Vuitton bags outlet sale visit descriptions of the Louis Vuitton bags and the big guy for the different costs and other accessories. You can find the online destination and Overstock Handbagcrew reduced price handbags and designer handbags. Check out other great creators of these pages that have the same quality and you will be able to see, how much to save - prices really have to pay a department store shopping at this site is much more normal. Have fun while you shop Louis Vuitton bags outlet sale!
Supra shoes for girls
9-Jul-2012 22:05:40
The Supra shoes for girls Asia this training camp lineup,More than 50 players from China, Hong Kong, China, Chinese Taipei, Japan, Korea, Australia and other countries and regions,Players in the Supra shoes for girls list, we are familiar with the noble, Supra shoes for girls and consultant in the lineup, not only have Yi Jianlian, Gay and DeRozan and the other two NBA players, as well as the former coach of the United Arab O'Connor, and Chinese star Du Feng and so on.

Post a Comment:

You can post a comment here. Keep it on-topic.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 24-Mar-2017 - Edit - Copyright REBOL Technologies -