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

World: r3wp

[!REBOL3]

BrianH
24-Aug-2010
[4638]
Strangely enough, the only thing about tasks that works so far is 
tasks themselves, as long as you don't trigger any errors.
Pekr
24-Aug-2010
[4639]
AdrianS: for what have been discussed so far - http://www.rebol.net/wiki/IPC_-_Inter-process_communication
Graham
25-Aug-2010
[4640x2]
http://blog.sitescraper.net/2010/06/scraping-javascript-webpages-in-python.html
http://blog.sitescraper.net/2010/06/scraping-javascript-webpages-in-python.html
Henrik
25-Aug-2010
[4642]
is the SDK prebol available for R3?
Henrik
26-Aug-2010
[4643x2]
BrianH, was there ever talk about a function that returns only duplicates 
in a series?
(prebol question has been answered)
BrianH
26-Aug-2010
[4645]
I remember there being such a discussion, but it never really went 
anywhere.
Henrik
26-Aug-2010
[4646x2]
if I say "pretty please", can we have such a mezz? :-)
see r3 chat #4447 for discussion there.
BrianH
26-Aug-2010
[4648]
It would be expensive. And aren't we trying to make things optional 
now? It would complement DEDUPLICATE well though.
Henrik
26-Aug-2010
[4649]
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.
BrianH
26-Aug-2010
[4650x2]
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.
Henrik
26-Aug-2010
[4652]
I'm fine with that, but it would perhaps lose a bit of consistency.
BrianH
26-Aug-2010
[4653x2]
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.
Henrik
26-Aug-2010
[4655]
ok
BrianH
26-Aug-2010
[4656x2]
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.
Henrik
26-Aug-2010
[4658]
I'm not sure if I can make a decision here.
Ammon
26-Aug-2010
[4659]
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?
Graham
26-Aug-2010
[4660]
One would think so .. can you even reload a module?
Ammon
26-Aug-2010
[4661]
The answer is yes!  However I'm not sure this is a good idea...

remove/part find system/modules 'module 2
import 'module
Henrik
26-Aug-2010
[4662]
anyone know if R3 RENAME will allow moving files and dirs now?
Graham
26-Aug-2010
[4663]
ammon, that doesn't look like an approved reload method!
BrianH
26-Aug-2010
[4664x3]
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.
Ammon
26-Aug-2010
[4667]
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.
BrianH
26-Aug-2010
[4668x2]
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.
Ammon
26-Aug-2010
[4670]
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?
BrianH
26-Aug-2010
[4671x2]
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.
Ammon
26-Aug-2010
[4673]
Excellent.  I'll be anxiously awaiting your update.
BrianH
26-Aug-2010
[4674]
Look in the !REBOL3 Modules group for details. I've already given 
a lot of status updates.
Ammon
26-Aug-2010
[4675]
LOL!  That's pretty much what it felt like when I first started playing 
with Modules but I seem to be making some progress.
BrianH
26-Aug-2010
[4676x2]
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
Henrik
27-Aug-2010
[4678x2]
ok, looks like RENAME under OSX R3-A97 is broken
and windows too
AdrianS
27-Aug-2010
[4680x2]
seems to work on a104
only tried using a file!, though
Henrik
27-Aug-2010
[4682]
please try a directory
AdrianS
27-Aug-2010
[4683]
I get "** Script error: cannot use rename on port! value"
Henrik
27-Aug-2010
[4684]
ok, still broken
AdrianS
27-Aug-2010
[4685]
are you going to log the issue?
Henrik
27-Aug-2010
[4686]
it's already in curecode.
Henrik
28-Aug-2010
[4687]
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