World: r3wp

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.

well, I'm giving you 5 years of daily real-world usage above  ;-) 
  a lot of the slim spec has not been used, by natural selection, 
but the above is in just about 95% of all of my code.

I've been giving the module system a lot of thought lately - but 
it needs a bit more...

and I'm like you and pekr... I won't stop whinning about it until 
I get it  ;-)

One thing to remember is that simplicity is a real value here. We 
need to make sure that any features we add integrate well with the 
rest, and don't create a burden on the programmer. Any setting that 
you can make is a setting that you will have to decide whether you 
need to make, so that adds to the development overhead.

brian I know all of that...   /only is a choice, not a burden.   


the way it is setup up now, we are imposed the decision of the module 
author.  its EXACTLY like people who currenly use:

set 'word func [][]


this is very bad design, even more if the module functions themselves 
require words to be global.


PITL requires control over modules.   in all languages which have 
modules, name clashing is always annoying.


python has a very nice module system, cause you import specific words 
or all of a module.   with a few hundred libs as standard they had 
to make it clean.  I think they did their homework.

We already have an /only for IMPORT, and wouldn't need it for this 
purpose - adding the words block to the Needs would be enough.

is the needs header supposed to support file names?  cause its not 
working in A56.  'IMPORT function works properly though.

didn't find any note about this in curecode.... posted new ticket.

Works for me: 

>> write %mod1.r to-binary "rebol [type: module] print 1" 
>> write %mod2.r to-binary "rebol [type: module] print 2" 

>> write %mod.r to-binary "rebol [needs: [%mod1.r]] import %mod2.r 
print 3" 
>> do %mod.r 
1 
Script: "Untitled" Version: none Date: none 
2 
3 


Note that if you specify your Needs in file form, system/options/module-paths 
won't be searched. Any relative filename will be resolved relative 
to the path of the importing script. Does this affect you?

all files are in the same directory.

Oh, I get it, you forgot to make Needs a set-word.,

Needs:

DOH!

to close to the tree to see the forest       ' :-/

Shall I delete the ticket, or dismiss it?

delete it...

Done.

that was such a stupid error.  :-)

Do you know the R2 SDK source well enough to know whether the Needs 
header is handled by mezzanine code in R2? And where?

no idea where the needs is managed.

but a file content search of the whole code doesn't return anything 
relevent to the needs block.

I'd like to backport the R3 module system, but the use of the Needs 
header might be awkward.

yeah... maybe carl can just add a hook for you in the loader.