World: r3wp

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?

Max: you should add your part to the http://www.rebol.net/wiki/Inclusion_Methods

Sunanda: I think, that it is necessary to *discourage* everyone from 
using (xor 1 2) in R2. It is not officially supported anyway.

...exactly like (+ 3 4), which is not officially supported too, AFAIK. 
the supported way is (add 3 4) and always has been

I know R3 will have threading ... this is some video that digs into 
pythons implementation .. and shows how not to do threading mostly 
... http://blip.tv/file/2232410

the guy tried to run a long-running-cpu-intensive-func 2 times one 
after another, and in two native threads (on 2core cpu) that python 
supports and running it in threads took 1.8 more time than running 
it one after another

(I woud be more interested in rebol having green cooperative threads 
anyway, and if you need real multi-cpu concurrency there can be normal 
processes and message passing between (which can be made on top of 
ordinary rebol anway)

Janko - you mean so called Erlang concurency model?

I think erlang concurrency model is higher level model and could 
be build on top of cooperative threading + os process (or thread) 
communication. Specific for erlangs model is that you can have 1000s 
of these processes that communicate with message passing. There each 
"object" is a process.. etc..  I don't know if I want exactly that 
(although I would love it also) but maybe more low level concurrency 
"enabler" where different such models can be build upon. There are 
many ways of doing actors (like native erlang (with one way messages/mailboxes), 
python's lib Kamaelia (with channels), java's lib Kilim..) and other 
things for concurreny..

but I am not an expert in any of these concurrency "models" .. more 
like an interested observer .. so if someone wants to correct me 
no problem

Thanks.Ladislav....I don't particularly mind _why_ R3 is incompatible 
with _R2_. Forward compatibility would have been nice, but that discussion 
ended long ago with the decision not to be.


What I think we need now is to start work on a  migration guide, 
so we do not all need to stumble across the gotchas.....It may also 
help debug R3 [some reported changes may turn out to be accidental 
and fixable].


Hence my question about where would be a good place for us to start 
sharing migration hints and tips.

Ladislav, good idea, I'll add a section on slim at the end.

janko, I have been using multi CPUs machines for 15 years In 3D applications 
and you'll be surprised to know that none of them have yet to use 
two cpus for anything else than image rendering.  its because management 
of the cores generally takes as much resources than the processing 
itself.


in general, if the same processing algorythm, running multi-threaded 
is less than 1.5 times slower than two concurrent, independent tasks, 
you can start to say that the implementation is well designed, it 
rarely is better than 1.25x slower.


some algorythms and datastructures are much better suited at being 
parralelized though, and software built from scratch to support it 
will always be better at it then when its converted to multi-threading.

brianH, the isolate: true isn't documented in docbase, and its not 
working in my script, which leaves me to think that it was left out 
in public releases.