World: r3wp

that was such a stupid error.  :-)

Do you know the R2 SDK source well enough to know whether the Needs 
header is handled by mezzanine code in R2? And where?

no idea where the needs is managed.

but a file content search of the whole code doesn't return anything 
relevent to the needs block.

I'd like to backport the R3 module system, but the use of the Needs 
header might be awkward.

yeah... maybe carl can just add a hook for you in the loader.

At least the Core version need syntax is compatible...

yesss, I have the basic features of vprint working in R3... no code 
changes where needed  :-)

can now move ahead with liquid.

Cool. You should have enough rank to post files - tell me if you 
have difficulty.

there is one thing That I did not see documented... how can I get 
the modules to print errors from within?  I just get:
** access error: cannot open: %liquid.r3 reason: none

this is impossible to use for development.

in this case it was a mismatched "  character.

I can't imagine trying to corner that in a 50kb module!

Don't get what you are saying. Is the access error something that 
happens when you try to print from within, or what you want to print?

Or do you want line numbers in your syntax errors or something?

when the application script loaded the module, it printed above message. 
 but the real error was that the module had a mismatched " char...

the same error in the main script would have given a real error... 
 ** Syntax error: invalid "string" -- {"}

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.