World: r3wp

I think Carl should post that in his next Carl blog  :-)   being 
first with something as generic as R3 Alpha is no small feat....

I'll poke him with that when I get to enabling my R3 chat later on.

Sunanda, your "memory exhaustion" ticket (bug#920) was not a GC bug, 
in fact not a bug at all. Look at the comment for details :)

You are quick with the bug analysis!


Not entirely sure why you consider it not a bug. Recast this way, 
it looks a horrible problem....
   for n 1 10 1 [print n a: mold system]
....It gets slower and slower and then dies.

...And the I may need a new session as:
  b: mold system
now does not have enough memory.

devbase is a strange space.  its like: "altme in the twilight zone" 
 even the white letters on black of the dos shell  bg re-inforce 
this  ;-)

I've noticed that devbase has the same problem as altme at recognising 
the daylight saving time... I have a one hour offset in time postings.

is that a known issue?

also the "g" command of devbase doesn't seem to work when #xxxx is 
in messages, but it works for curecode and html.

yes, it's a very known issue

I suppose 'g for message numbers could be added.

hehe... you posted just after I reported it directly on devbase... 
like seconds appart  :-)

I actually like devbase.  the direct number navigation is quite possible. 
 I can just type 14   and go to R3 section directly wherever I am... 
that is very cool.

possible = powerfull...

are any plugin docs available yet?

no, not yet

try

f "chat.r"

to get the post where you can get the source for chat.r

cool.

what rank must I be to create headings?

there is a list in devbase help in the wiki

aaah ok... will look it up

If you feel like adding a feature, go ahead, and post it to curecode. 
Carl probably prefers 1-2 line fixes, though.

ok.

could someone either raise my rank so I can add a lib within Community/Libraries 
or add a heading called liquid there.  I'd post my R3 related comments 
for liquid there... I think Carl would like some feedback on my efforts/problems 
porting such an advanced tool into R3.  when it will work, I'll also 
be posting comparative benchmarks.

Sunanda, the reason it's not a bug is because for every iteration, 
'a is set to mold system, and mold system includes the previous value 
of 'a from the previous iteration, as a string. So that means that 
every iteration is the length of the rest of the system, plus the 
length of the previous 'a times the number of visible references 
to it. Since there are 4 visible references to the collection of 
global words, this means that the growth is exponential, and of a 
larger exponent than R2 (which has only one visible reference to 
the global words, so it just doubles).


The way to prevent the exponential growth is to assign none to 'a, 
or unset 'a, before you mold the system again.

The 4 visible references to the global words should be cut down to 
1 or 2 once the rest of the module system is done. The other 2 will 
refer to separate contexts than the current "global" context.

I've officially just created a new file on my system.... its called: 
   liquid.r3  
let the fun begin  ;-)

first step, convert vprint to r3

#4515: Community/Libraries/Liquid

thanks :-)

has anyone been able to properly link r3 in windows file extensions?

Raised your rank.

I do everything and its not in the extensions list, but strangely, 
it is working, since clicking on a liquid.r3 loads it properly.


what is even stranger is that I scanned the registry and its not 
there either!

Associating a file extension is easy enough, but for now it is better 
to make shortcuts or batch wrappers instead. R3 is alpha :(

but what I mean is that someting in the r3.exe isn't letting my XP 
properly associate it... is this to be expected?

thanks for the ranking.  I feel all special now  ;-)

Another gotcha to look out for is that if you use the module lookup 
list, the extension automatically added to the script is .r, not 
.r3.

good point.  that should be a configuration in the future IMHO.

I'm reading the official module docs right now  :-)

its funny its sooo close to slim ... and slim is over 5 years old 
;-)

Well, some of the module capabilities aren't done yet (as I mentioned 
above), mostly because most of the system hasn't been converted to 
modules yet. One of the current gotchas is that system/contexts/current, 
system/contexts/system, system/contexts/exports, and system/words 
are all the same object. In the final module system, the first three 
should be separate contexts and system/words should be gone (it is 
now an alias for system/contexts/current).

noted

The requirements for a module system in REBOL are pretty much defined 
by the task and the language semantics, and those haven't changed 
much in 5 years. It's not surprising there are similarities :)

but there is definitely one thing that needs to be added, unless 
its just not documented.   the ability for import to RESTRICT what 
is exported by the module. 

this is the most powerfull concept in slim and I'll never want to 
live without it.  


in slim, its the module USER that has control over the module.  when 
you load the module, by default it uses the module's expose list, 
but if you supply your own, then the module doesn't expose anything 
else than what you ask of it.  


this allows me to have a clean current context, and I can prevent 
my module from cluttering the context its loaded in.  especially 
if its loaded AFTER some code has been defined, or using common global 
words.

this would be:

import/only 'libname [funcname]


where funcname must also be in export, so there is two sided restriction 
... was is available, and what is needed.

the export renaming is something I also use often, here is how it 
could like in R3.

import/only 'libname [fill*: fill make*: make]


meaning, load the module's 'MAKE func as MAKE* in my current context.

as people will start building public modules, name clashing will 
become an increasing problem... there is already some of that on 
rebol.org... altough not much... but there aren't a lot of similar 
libs there either.

or using only one feature from a newer version of a library and all 
the rest from the older one, cause the update isn't compatible... 
that should be allowed.

the way I see it, currently its really complicated to achieve.

In theory the module import list could be more complex, including 
particular imported words (the relevant function is DO-NEEDS). The 
current model is focused on being enough to keep us going with our 
modularization of the system. We intend to refine the model after 
enough real-world use has given us ideas for refinement.