World: r3wp

A small gotcha for people who want to write scripts that run under 
both R2 and R3.

One of many, I fear. We should probably start an "Incompatible changes" 
page on the wiki and collect them.

I'm still not sure this specific stub should be removed.  it will 
invalidate *many* R2 scripts and its not such a big thing to leave... 
as long as it prints out a warning.

it could actually be part of a "compatibility" mode switch.... something 
like a delayed module which only need to import when running r2 code.

The other way round is an option as well.

We can collect all of those in an "r3-backward" module.

(Ignore that. Reading comprehension failed me :)

yes exactly.  an r2-compatibility module

That is a better plan than leaving these anachronisms in R3 by default 
:)

but we need to make sure we collect them all (I gather you've been 
a pack rat about this ;-)>

There are some things that we won't be able to replicate, like evaluation 
rules.

So it'll be more like an R3/Backward :)

I expect that with the R2/Forward additions to R2 there might be 
a useful middle ground.

is import expected for R2/forward?  even if its just for non dll 
stuff?

Yes, as an addon (not part of R2 by default). I wanted to wait for 
the model to be set first, and now (for a110) it will be.

cool.  that is the biggest issue I have now when trying to run simple 
R3 stuff in R2.

yes... I am using modules  :-)

I assumed so, but it's nice to hear that you are using R3 modules 
:)

(a classic case of.... if you can't convince them... use the stuff 
they put all those hours on... its probably better than yours  ;-)

hours -> weeks, months?

It feels like forever. But it is really cool now.

I really like how you've evolved the system and its doing all of 
what I wanted slim to do minus one or two little things, which I 
can easily graft over modules as they are .

The next step is to publish the test suite in DevBase, then finish 
it, then make it work with loadable module systems.

it
 being the test suite.

Look at bugs 1721, 1722 and 1723. They are all fixed in the new version 
that is done but not built yet.

I like 1722

in 1723... did you really have to rewrite stuff, or just use the 
newest code?

The boot exts loader does its own importing, for efficiency. As such, 
it wasn't much code to rewrite.

I posted the ticket after I did the work.

Just added this note to #1722: "Note: This ticket is not a dup of 
#1177. We made the same error again with a new module system. We 
have a better solution this time though."

it would be nice if the rename options supports none, to allow explicit 
reloading of modules going thru the whole motion.

And it was a two-word fix :)

since you are telling it none, its not a security hole you chose 
to ignore the name.

That won't work for IMPORT, but might work for sys/load-module with 
a little care. Not sure about that one though.

DO does the reloading already though.

why woudn't it work with import?

Import doesn't have a rename feature on purpose, as a simplification. 
IMPORT is supposed to be user-level automagic stuff. The real work 
is done by LOAD-MODULE.

ok then... rename to none should be supported by LOAD-MODULE  ;-0

For one thing, renaming something already imported is an error. And 
a lot of the time IMPORT is just giving you access to stuff you already 
imported earlier with Needs.

though the stated default reaction in your CC ticket is the best 
course of action

(for import)

If you want the reloading, use DO. DO works on scripts and modules 
both, and does them every time. It even tries to import the module 
after it is created. This is everything that you were requesting 
out of reloads. What it won't do is override a loaded module in the 
module list that is the same version or newer, but you can import 
those directly using IMPORT options.

The override rules in the system module list are sacrosanct though. 
You can load and use modules, but you can't override modules in the 
system list without following the rules.

You don't have to import to the system list for modules to be useful 
though. Look at IMPORT's /no-lib refinement. (After a110 comes out 
and it is fixed)

well the idea of supporting none is that they are not put into the 
system list to begin with, whatever their name or path.

so I guess that is what /no-lib does?

IMPORT/no-lib does that.

ok so I'll shut up now   ;-D

What /no-lib does is converts a module to a private module. It does 
a full import directly into the user context instead of importing 
through lib. It doesn't even go into the system modules list as a 
reusable prebuilt module, which named private modules otherwise do.

Which reminds me, I need to add that last bit to the tests.