World: r3wp

None: We haven't been talking about it yet. There has been some speculation 
that PROTECTed data could be shared, and the "user context" is supposed 
to be task-specific (designed that way, not task-specific yet). But 
the PROTECT security model isn't finished yet (there are tickets 
yet to implement), and nothing has yet been done to make it tasking-friendly.

Strangely enough, the only thing about tasks that works so far is 
tasks themselves, as long as you don't trigger any errors.

AdrianS: for what have been discussed so far - http://www.rebol.net/wiki/IPC_-_Inter-process_communication

http://blog.sitescraper.net/2010/06/scraping-javascript-webpages-in-python.html

http://blog.sitescraper.net/2010/06/scraping-javascript-webpages-in-python.html

is the SDK prebol available for R3?

BrianH, was there ever talk about a function that returns only duplicates 
in a series?

(prebol question has been answered)

I remember there being such a discussion, but it never really went 
anywhere.

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.