World: r3wp

We already have an /only for IMPORT, and wouldn't need it for this 
purpose - adding the words block to the Needs would be enough.

is the needs header supposed to support file names?  cause its not 
working in A56.  'IMPORT function works properly though.

didn't find any note about this in curecode.... posted new ticket.

Works for me: 

>> write %mod1.r to-binary "rebol [type: module] print 1" 
>> write %mod2.r to-binary "rebol [type: module] print 2" 

>> write %mod.r to-binary "rebol [needs: [%mod1.r]] import %mod2.r 
print 3" 
>> do %mod.r 
1 
Script: "Untitled" Version: none Date: none 
2 
3 


Note that if you specify your Needs in file form, system/options/module-paths 
won't be searched. Any relative filename will be resolved relative 
to the path of the importing script. Does this affect you?

all files are in the same directory.

Oh, I get it, you forgot to make Needs a set-word.,

Needs:

DOH!

to close to the tree to see the forest       ' :-/

Shall I delete the ticket, or dismiss it?

delete it...

Done.

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.