World: r3wp

aha, so, a kind of "general graph"

copying making a new instance of the master class cannot imply duplicating 
all of the internals which have to be unique... it makes no sense.

graphs of graphs.

just the series copying makes countless duplication of data already... 
at least if there was an option but there isn't... that is my problem.

right now I depend on inner objects being shared in every single 
serious application I write.

so, is this a simle example of the behaviour you dislike?

>> o: make object! []
== make object! [
]
>> p: make object! [x: o]
== make object! [
    x: make object! [
    ]
]
>> q: make p []
== make object! [
    x: make object! [
    ]
]
>> same? q/x p/x
== false

yep.

I don't even understand why you'd want to do so... its exactly like 
forcing a reduce everytime you copied a block.

I mean.. it being the default in make.... I can see where copy/deep 
on objects can be usefull, but not as the only way to create new 
instances of objects.

yes, I preferred the R2 behaviour too

I prefered the R1 even more.

I don't remember how R1 handled objects

it didn't copy anything.

they where identical clones, within only binding switched to new 
context.

all series data was shared... 
but its easy to copy on demand... its impossible to "uncopy"


the reason for the change was essentially that it made VID easier 
to use.

people didn't understand why changing one string would affect many 
faces.


to some degree, that side-effect is still there though...  fonts, 
para, edge, are now still shared accross all face of the same style, 
which makes a lot of sense.

I also vote for the module system to support the ability to restrict 
what you import, and SLiM's ability to rename words on import (and 
prefix them) is very nice.

Maxim, when I suggested isolate: true I didn't understand what you 
were asking for. Based on your bug ticket it doesn't apply.

it should be documented though.

It is documented - it just does the opposite of what you thought 
it does.,

where ...  its not here: http://rebol.com/r3/docs/concepts/modules-defining.html

It is exactly the same as IMPORT/isolate.

I reviewed and put comments in your vprint tickets. In both cases 
the bug is caused by code *in* %vprint.r3, not the code calling it.

I would love to fix the bugs, or figure ouut what they are if they 
are caused by native code, but without the source to vprint.r3 I 
can't.

I don't understand what this means... "Wrong errors get the severity 
"text" unless the specific error implies a potential security hole. 
"

brian... if I do vprint in the main app, the functions work.

actually, when I do the script in the module, they work in the main 
app but not in the module.

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?