r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Maxim
13-Jun-2009
[15421]
created two new tickets.
BrianH
13-Jun-2009
[15422]
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?
Maxim
13-Jun-2009
[15423x2]
doing is ok... just tested that
was about to post my workaround.
BrianH
13-Jun-2009
[15425]
Have you tried renaming the file to %vprint.r, giving it a Name: 
'vprint header, and importing it lilke Needs: [vprint] or IMPORT 
'vprint ?
Maxim
13-Jun-2009
[15426x3]
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
BrianH
13-Jun-2009
[15429x2]
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.
Maxim
13-Jun-2009
[15431x3]
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.
BrianH
13-Jun-2009
[15434]
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.
Maxim
13-Jun-2009
[15435x2]
using word based import or needs still cause the bug.
(still crashes rebol)
BrianH
13-Jun-2009
[15437]
You want the module to be loaded and done once, but imported twice. 
Doing the module code more than once wouldd usually be bad.
Maxim
13-Jun-2009
[15438]
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.
BrianH
13-Jun-2009
[15439x2]
It's shared if you give the module a name header.
Not shared if not.
Maxim
13-Jun-2009
[15441]
ok. that should be more explicit in the docs... its sort of mentionned 
(implied?) but not as obvious as the above sentence.
BrianH
13-Jun-2009
[15442]
I think you have to import it by word too to share, but I'm still 
tracing.
Maxim
13-Jun-2009
[15443x3]
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?
BrianH
13-Jun-2009
[15446x2]
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.
Maxim
13-Jun-2009
[15448]
so you mean that a module which loads a module, will expose the sub-module 
into the global context too, by default?
BrianH
13-Jun-2009
[15449]
The current context, not really the global context.
Maxim
13-Jun-2009
[15450x2]
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.
BrianH
13-Jun-2009
[15452x2]
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 :(
Maxim
13-Jun-2009
[15454x2]
will reflect about this a bit... will re-read the above tomorrow... 
for the same reason  ;-)
night!
BrianH
13-Jun-2009
[15456]
And well into it it is :)
Sunanda
13-Jun-2009
[15457]
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?
Ladislav
13-Jun-2009
[15458x3]
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
Janko
13-Jun-2009
[15461x3]
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)
Pekr
13-Jun-2009
[15464]
Janko - you mean so called Erlang concurency model?
Janko
13-Jun-2009
[15465x2]
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
Sunanda
13-Jun-2009
[15467]
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.
Maxim
13-Jun-2009
[15468x3]
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.