World: r3wp

The severity "text" is just an indication of the type of bug. Severity 
is not priority. Generating the wrong error is marked as text throughout.

In some cases the particular bug generated indicates a lack of bounds 
checking, and that is considered bad. However, it is the lack of 
bounds checking that makes it bad, not generating the wrong error.

why does DOing the exact same script, generate the proper error in 
the main app and generate a bogus error when DOne from a module... 
that is the problem.

About bug#928, couuld you at least post the header of %vprint.r3? 
We can't diagnose the problem without at least that.

I can't write a module if every syntax error becomes a bogus undefined 
error when I try to use it.

posted on curecode... vprint isn't a module anymore... its just a 
normal script defining words, not even within a context... just simple 
 vprint: func [args][body]

I'm not saying that bug#923 isn't important (that's a priority thing), 
just that it isn't severe. Severity is defined by how dificult it 
is to fix, not by how much trouble it causes.

And I still can't diagnose bug#928 without at least the header of 
%vprint.r3 - we have to have something testable.

Sorry, it was bug#924 that was the wrong error bug, not bug#923.

ah ok... now it makes sense.

Bug#923 requires the whole source of %vprint.r3 that causes the crash, 
not just the header.

ok, I'll provide one line examples which cause both crashes.... the 
bugs occur with ANY script I tried.

the import twice crashed with a file containing only a print statement.

There may be a pattern in the scripts you would try.,

Importing a module twice when specified with a filename instead of 
a word is almost always an error, but shouldn't crash.

what do you mean "is almost always an error"?

There is an error in the import process, but modules loaded by filename 
are actually loaded each time. If the module has a name header then 
only the first import works properly. Every subsequent import by 
filename will be a logic error. However, you can import a named module 
the first time with a filename and then use the name for all subsequent 
imports with no difficulty.


If the module is not named and specifically designed to be loaded 
multiple times, then cool, you can do so.

Naming a module enables its reuse, but all subsequent uses should 
be specified by name, not by filename.

If the module isn't already loaded then specifying it by name generates 
the filename by adding .r to the end and checking import-paths.

ok, so far it seems strickly related to file based import... specifically, 
when it tries to load the file a second time.  it raises the assertion 
crash.


reloading a module can be needed... it was changed, for example, 
and you want to allow run-time updates, cause your ip ports must 
not be closed.

the module re-use works correctly.

In theory, runtime updates should be version-triggered. The init 
code could in theory check for a prior version and migratee the data.

what init code?

The code in the code block of the module.

I agree, that is the point of reloading it runtime.

but right now it crashes at the second load.

I could use a minimal header and code block of a module that triggers 
the assertion crash on reimport by filename (bug#923).

Justt something to trace and test with.

Those assertion crashes are caused in the native code, but we need 
to narrow down *which* native code.

I just uploaded an VERY minimal module and application with 3 imports... 
the 2 initial are by name and are fine, the third is by file and 
it crashes.

is that ok for testing?

for (bug#923)

That's what I thought - it's named. You are only supposed to import 
named modules once per version - subsequent imports are to be by 
name. New versions are supposed to displace the old, and that might 
be where the crash is. This will be interesting to trace.

have fun  ;-)

currently building example scripts for bug#924

Cool, thanks.

posted 3 file example.

re bug#924 in one test, I even had the print word not bount to any 
context !

OK, I just looked at bug#924 and now get what you want to do. It's 
not a bug, it's by design. The code block of a module is bound before 
the block starts executing. You can't define new words in the module's 
context unless those new words are defined in imported modules or 
in the code itself at the top level, or anywhere in the code if the 
module is isolated.

Sorry, bug#928, not 924.

why is that?  this means we can't create new words in a module at 
run-time?

Right. Even if you did you wouldn't be able to use them because the 
code would already have been bound.

aren't module contexts auto-expanding?

but in the script (previously global) context... every word is bound 
to the script context when loaded, why not providing the same for 
modules.  if it hasn't been set when its encountered then you raise 
the proper unset error.

Not really. They are (using a hack), but the binding of the code 
block is done after the imports are processed and before the code 
block starts executing. Once the code block starts executing the 
module context has already been defined. REBOL's evaluation and binding 
rules preclude any automatic rebinding.

but the word exists in the module before the script is done.... its 
just not set yet... so it should be bound in the module and the script 
sets the value, since its running in the context of the module.

what you are saying is that for modules, we need to start declaring 
words?  not very rebolish. 


 I have to do so in slim to keep words local to the calling context, 
 but I would have tought that modules would do so automatically since 
 they replace the global context.

 any new word in the root of the spec block of the module should be 
 added to the module's context and set to unset! just like R2's global 
 context does.

Um, no, a DOne script is running in its own context if it is a module, 
or the current context if not. The current context is not the context 
of the calling code - it exists independently.

Modules have their own context, but they don';t replace the "global" 
context.

Any set-word in the top-level of the module's code block is added 
to the module's context before the module code runs, just like an 
object. If you isolate the module, every word in the module's code 
block and all nested blocks, parens and paths are added to the module's 
context. The only words you need to "declare" are the exported words.