World: r3wp

if I say "pretty please", can we have such a mezz? :-)

see r3 chat #4447 for discussion there.

It would be expensive. And aren't we trying to make things optional 
now? It would complement DEDUPLICATE well though.

yes, I'm not sure there is a way to make it in-expensive, but I've 
stumbled onto several situations where I would like not having to 
write and test it.

These would make good library functions. Give me a moment.

Would it be alright to skip the /skip option? Then we can use a map! 
to do the work without too much overhead.

I'm fine with that, but it would perhaps lose a bit of consistency.

The problem with the /skip is that we would have to write our own 
hash function, or copy/part every record at least once, or go n^2.

The problem with the map! method is that we would have limits on 
what could be in the block.

ok

There's the 2-block method, which would only top out at n^2 performance. 
Or we could hybrid, using map! for non-structures.

Or we can do the remove-each copy [not find ...]  method, which tends 
towards n^2.

I'm not sure if I can make a decision here.

If you've imported a module and then updated the module and incremented 
the version of it and then call import again this time requesting 
a newer version than has been loaded shouldn't the module be reloaded?

One would think so .. can you even reload a module?

The answer is yes!  However I'm not sure this is a good idea...

remove/part find system/modules 'module 2
import 'module

anyone know if R3 RENAME will allow moving files and dirs now?

ammon, that doesn't look like an approved reload method!

Ammon, the answer is yes, without changing system/modules. The new 
module is added (and used for all new references), and the old module 
is still referenced in system/modules so the new version can migrate 
data from the old.

system/modules is a block. New modules are just added to the beginning 
of the block. Old versions are not removed by the module system. 
Security issues might prevent them from being removed at all in the 
future - this is an unresolved issue.

The actual module doesn't have much directly in it, just two objects, 
one for the spec, one for the local context. If you empty out the 
local context then there shouldn't be much memory referenced.

Then I've found a bug...  And some unexpected behaviour...

>> t: import 'test-module
>> test
0.0.1
>> t/test
0.0.1
>> t2: import/version 'test-module 0.0.2
** access error: cannot open: %test-module.r reason: none

>> t2: import/version 'test-module 0.0.2
>> test
0.0.1
>> t2/test
0.0.2



Apparently if you don't have the version available in your module 
search path then it errors out without telling you why it failed.

Yeah. The bug is that we need better errors. I am rewriting the module 
system now (more or less, I took a break for a bit). The last stage 
is reviewing the errors and getting more informative ones added to 
the error catalog.

For now, a lot of the possible errors are just asserts.

And those asserts are incredibly confusing...


Glad to know you are working on it.  Does this mean that I don't 
need to enter any of this in CureCode?

Yes. When the rewrite is done, I hope to see all of its errors reported 
though :)

The new code is specificly designed to be less confusing. The old 
code failed the hit-by-a-bus test.

Excellent.  I'll be anxiously awaiting your update.

Look in the !REBOL3 Modules group for details. I've already given 
a lot of status updates.

LOL!  That's pretty much what it felt like when I first started playing 
with Modules but I seem to be making some progress.

The requested delayed modules feature ended up creating a lot of 
other features as a side effect. The new module system is much more 
powerful. And by default just as easy to use (I hope).

The (incomplete) design docs (for the incomplete design) are here: 
http://www.rebol.net/wiki/Module_Design_Details

ok, looks like RENAME under OSX R3-A97 is broken

and windows too

seems to work on a104

only tried using a file!, though

please try a directory

I get "** Script error: cannot use rename on port! value"

ok, still broken

are you going to log the issue?

it's already in curecode.

Finished the first round of RM Asset's build system. There will surely 
be some revisions required, but I've put the manual out for public 
study:

http://rebol.hmkdesign.dk/files/r3/build/build-manual.html

nice work

Where is the latest 104 release?

DTC

DTC?

is there any related anounce ?

The blog talks about a 104 version.  My last one is 100.x.x.x

The blog talks about a 104 version.  My last one is 100.x.x.x

It's a guru only release and very unstable, but there is a link in 
the REBOL3 Host Kit group.