World: r3wp

python give you the file name and the normal error after... so you 
know where that happened.

So it was a load error then? Interesting that it would return that 
error - I've never seen the like, and modules and scripts are loaded 
the same, with the same code even.

yes error on load... it seems that other errors report the error 
correctly.

Well, LOAD loads scripts and modules alike. Where was the mismatched 
", header or code?

code.

loading a module twice crashes rebol.  :-(

even if its being loaded from different contexts.   

I tried importing vprint in main app and within liquid module... 
I get an "assertation failed" error.

You need to post example code when you find these things out - otherwise 
we can't fix things.

sure! like I did with the needs header   ;-)   hehehe

ok, so I'll add a CC ticket for the load error.

At least post the exact assertion failed error message.

I guess I'm going to give R3 modules a run for their money  ;-)

Speaking of which, I'm trying to backport a subset of the ASSERT 
function to R2. It's kicking my ass so far :(

created two new tickets.

If you import files rather than names, the file gets imported twice. 
Clearly there is something in your %vprint.r3 that causes an assertion 
when reloaded. Have you tried DOing the file twice?

doing is ok... just tested that

was about to post my workaround.

Have you tried renaming the file to %vprint.r, giving it a Name: 
'vprint header, and importing it lilke Needs: [vprint] or IMPORT 
'vprint ?

note, I had to remove the type: 'module in the header for it to work

haven't used the word based module handling, but the vprint module 
already has a name: vprint in the header.

Name: 'vprint  

to be precise

If you want the module to be referenced in the module registry so 
it doesn't get reloaded you need to do the word-based module style.

I think - let me trace the code.

I actually WANT the module to be loaded twice cause I want each context 
to have its own verbosity control to be independent...  but my current 
attempt at using files was not in that goal, it was really just to 
support  .r3 extensions.

although its possible that import copies and rebinds each import 
to the current context, so that its

.... so that its unessary to perform the disk I/O twice.

Think I found an error in IMPORT - a <= where it should be a <, and 
a >= where it should be a >. I think the file thing shouldn't affect 
it.

using word based import or needs still cause the bug.

(still crashes rebol)

You want the module to be loaded and done once, but imported twice. 
Doing the module code more than once wouldd usually be bad.

shared and distinct/copied modules should both be supported.  right 
now I am not sure which one R3 does but, it doesn't provide the capabilities 
to do both, AFAICT.

It's shared if you give the module a name header.

Not shared if not.

ok. that should be more explicit in the docs... its sort of mentionned 
(implied?) but not as obvious as the above sentence.

I think you have to import it by word too to share, but I'm still 
tracing.

strange bug... If I only
 do %vprint.r3

in the module and try to use a function from vprint, I get an error:

vprint loaded
** Script error: von word is not bound to a context

** Where: do applier make if import catch if either either do begin 
do
** Near: do body obj

vprint loaded
 is a probe statement executed within the vprint.r3 file

I'm going to get a power nap... I'm practically sleeping on my keyboard 
(2:45 AM here)... continue my testing tomorrow.

ok... traced what happened... it actually loaded the vprint.r in 
the main application's context, even though the file was DOne in 
the module.. that is a bit strange... no?

OK, got it. If you import a module the first time and it has a name 
header it gets added to the registry - it doesn't matter whether 
it is imported by word or file.  However, any subsequent import of 
the same module by word will reuse the module - if you reimport by 
file it is reloaded (there is a bug in IMPORT too, so the new displaces 
the old even if they are the same version). I'm going to have to 
rethink the flow here.

Modules don't get isolated contexts unless they have the isolate: 
true header or are IMPORTed with /isolate.

so you mean that a module which loads a module, will expose the sub-module 
into the global context too, by default?

The current context, not really the global context.

ok.

If I get this, it means that  DO is always global, and the only way 
to trap it, is for the module to isolate the global context from 
any code it executes.

No, DO is always relative to the current context and there is no 
global context. And you can switch current contexts, though that 
mechanism isn't fully implemented yet.

Must sleep now - I'm getting to dumb to keep up :(

will reflect about this a bit... will re-read the above tomorrow... 
for the same reason  ;-)

night!

And well into it it is :)

I have been playing with converting some R2 scripts to R3.

And I am buiding a perhaps useful list of the things that need to 
change....eg:
      r2  allows: xor 1 2
      r3  either: 1 xor 2
              or: xor~ 1 2
Where would be a good place to start a list like that?