World: r3wp

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.

Max: I am especially curious, if you are able to add a point to the 
"Needs list"

yes, was discussing that with brianH last night.

extending the /only concept to support a block of words to import.

and only those from the available export list can be chosen...  so 
you have a double restriction.

what can be exported AND what you need imported.

yes, I even consider the "what you need imported" as more important 
- since the original writer cannot know that

and that is the core reason for the existence of SLIM.

its the basic PITL building block missing in REBOL.  (for me anyways)

well, that may depend on granularity. If the original module contains 
even the kitchen sink, then it is absolutely necessary ;-)

in R3, modules can enforce the invisibility, where as in R2 it can 
only be obfuscated.

hehehe

(but even that does not protect you against bloat, since you don't 
import the words, but the code still takes space)

slim also allows you to rename the words AS you are importing them, 
solving the name clashing cleanly and obviously.  This is very usefull 
when you are using frequently updated libs.  and is even more usefull 
when those libs aren't readily editable. (encrypted, compressed, 
etc)

yes... bloat is something that accords bragging rights.  when you 
build a graphic packages... a single window takes up 3-4 times more 
space than ALL of loaded code.  so in any serious app, growing to 
30-100MB of data... 20 kb of code is meaningless.

hum... there are two words missing in the above...

yes... BUT bloat is ONLY something ...

in an app I tried to build using R2 a single picture took 40MB.  
I need to edit 10000 of them and output them in a picture that take 
about 1GB of space.  saving 10kb... really I could care less.

right you are

now I'm not downsizing the philosophy of less is more, just that 
in many PITL apps, the data becomes the beast.

that's usually the case, especially with REBOL

liquid is a 40kb library when comments are removed.... I've seen 
similar packages for other platforms take up 1MB for download.

well , so much for R3fying liquid.  just stumbled upon a bug in make 
object that prevents liquid from working in R3.
I am not using the 'self attribute but its the same bug.

http://curecode.org/rebol3/ticket.rsp?id=802&cursor=35

I was finally able to work around the bug.  :-)
so convertion can continue for now


but the workaround will become impossible to apply at some point. 
its too low-level a problem to be properly addressed in every single 
opportunity... and its an ugly fix.