World: r3wp

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.

hmm, since it is about the deep copy, you can always replace it by 
doing it on your own

(but it may be "expensive", i.e. time-consuming)

Why is it deep copying an object within an object?  it shouldn't.

it should only deep copy series... no?

that is a change in R3: copy/deep now copies objects too. I am not 
sure, what was the reason for it, though, maybe we should ask in 
R3 chat?

WHAT THE FUCK!

If that doesn't change, unfortunately, I'll never use R3.

...or, you could raise that question in CureCode

...or in both places (Carthaginem esse delendam)

I definitely will, I didn't realize the /deep until you posted your 
first comment above.

I'll restate the above... 

if make object doesn't switch or allow copy not being deep , I'll 
never be able to use R3.  I already hated (but understood the reason 
behind) the series copy, but this is ridiculous.

objects aren't payload, they are contexts.

can you show a simple example of the behaviour you dislike? - just 
to make sure it cannot be circumvented easily

ladislav, I have object which contain 150 interconnected objects.

and multiple depths