World: r4wp

Another of the already-implemented options is private. The isolate 
option affects importing, the private option affects exporting.

You can do both of course.

There is also a content option (it acts like content: true from R2), 
and a compress option (for scripts that are stored compressed, and 
automatically decompress on load).

The content and compress options don't require type: module - they 
work on regular scripts too.

Scripts can also be checked against checksums, and can be limited 
to a length, but those aren't flags so they need their own header 
words.

Great to know who the caretakers of R3 source are.  Thanks for your 
work all six of you.  :)

The six people named are caretakers of the R3 bug reporting system. 
At the moment, Carl is the only code caretaker.

Close, but not exact, I would say. Other people take care of r3 code 
as well.

A picture is worth a thousand words:

https://github.com/rebol/r3/network

Btw, "Reviewed" has generally meant that someone has gone over the 
ticket and not immediately found a good reason to dismiss it, and 
that we haven't found a problem yet. It is not an indication that 
the ticket should be implemented - we frequently have competing contradictory 
tickets. So it sometimes means that more debate is needed before 
we can accept or reject it. On the other hand, it sometimes means 
that we haven't gotten around to it yet. Nonetheless, some reviewed 
tickets will eventually be rejected. Carl and I were the reviewers 
for the most part, except in the case of bugs that needed some domain-specific 
knowledge, like the math bugs we referred to Ladislav.

In general, when there are competing proposals and we finally pick 
and implement one, we dismiss the competing ones, even if they were 
"reviewed" before.

do we have a state, awaiting implementation?

Basically, "reviewed" with a consensus. No specific marker. We need 
to have the people who are familiar with the arguments go through 
the tickets that aren't still under debate and implement them.

Just that I had a proposal which was accepted and marked as built 
and then you reviewed and found it wasn't built

So, how many of those are hanging around?

We might want to rethink that now that Carl and I aren't the only 
ones implementing things :)

I haven't had a chance to go over the remaining tickets yet. And 
there are some that weren't implemented yet because Carl didn't want 
to, but hadn't yet convinced the rest of us as to why. Those might 
be dismissed if we get a good argument against them, which we can 
do in some cases ourselves now that we can see the native source.

so we need a state of confirmed built

That was the "tested" state.

And we need to go through the old previously implemented but now 
invalid tickets, to mark them as such so we don't have bad tests 
added for them.

For some of the early tickets, more thought and experience caused 
us to change our minds later on.

We used the "tested" state for confirmed built. The "complete" state 
was supposed to be for when we added a test for it to the standard 
test suite, but we were not as consistent about that.

Graham, was that proposal state change recent? Was it changed to 
"pending"? We've had a bit of a definitional problem with the "built" 
state lately. Until we actually get official builds, with version 
numbers, we don't really have a defined "built" state. We need a 
state for "implemented and accepted as a pull request into Carl's 
repo, but not in an official build yet", but we've just been callung 
that "pending" for short.

I think using "built" to mark things once they get accepted is fine 
(much better than "pending"), but we then lack a state to describe 
things which have been submitted as pull request but have not yet 
been declined or accepted.

I updated

http://www.rebol.net/wiki/Decimals-64


to reflect the current state of knowledge about molding and loading

Yeah, we've been using comments for that.

Andreas, maybe we can use "built" for accepted into the official 
repo, but have one of the "Fixed in" states for that, not giving 
it an actual version number in that field until it's in an official 
build.

yes, that's fine. but it won't give us a "waiting to be accepted" 
state :)

And then we can use "pending" for waiting to be accepted.

If you like, I can implement this policy this weekend.

We have only 8 "pending" tickets at the moment.

It wouldn't take much :) And there might be miore tickets that should 
be in that state than are currently marked as such.

So yes, I think using "pending" to mark "waiting to be accepted" 
is fine.

No, I mean we have 8 tickets marked pending according to the "old" 
meaning.

So the policy change would not be very invasive.

Ah, those are seem to already be "accepted but not yet released" 
markes. So then that's an even stronger "yes" from me :)

For tickets with implementations that have been accepted into Carl's 
r3 master branch, mark the ticket with a Status of "built" and a 
Fixed in of "r3 master".

For stuff that has a pull request that hasn't been accepted yet, 
we can use the "pending" status. Watch out though, since with that 
meaning of "pending" the ticket can now be dismissed at this stage 
(that didn't use to be the case with the old meaning of "pending").

Any insights on establishing .r3 file associations on Windows 7? 
 Am I in the correct group for this?

You may want to have a look at


http://www.rebol.net/wiki/INCLUDE_documentation#How_to_add_a_new_association_for_.r_files_in_Windows_Vista.2C_Windows_7_or_Windows_8

(more complicated than for the older Win versions, I admit)

Not exactly answering your question, you would need to check the 
r3_auto_file key in regedit, but the procedure is the same

Close, but not exact, I would say. Other people take care of r3 code 
as well.

 - As I understand others can only submit pull requests for Carl to 
 accept or reject, at the moment only Carl can commit changes to the 
 github rebol/r3 repository.

Yes, that is correct, but that does not mean everything has to stop 
if Carl stops.

I updated


http://www.rebol.net/wiki/INCLUDE_documentation#How_to_add_a_new_association_for_.r_files_in_Windows_Vista.2C_Windows_7_or_Windows_8

The beauty of using a distributed version control system is that 
we can still work on stuff without really being blocked by Carl stopping.

Citing from the source of LOAD:

next [
    print "LOAD/next removed. Use TRANSCODE."
    cause-error 'script 'no-refine [load next]
]


As far as I am concerned I find that print annoying (I find the error 
more than sufficient). Are there some people preferring to keep the 
print?

That error is exactly the same one that would be returned if there 
were no /next refinement. The print is only there to help people 
with the transition. If we don't feel that is necessary anymore, 
we should remove the /next option altogether and that entire code 
segment as well.

Correct, I am trying to perfom something like poll. Will duplicate 
the question to the ML for people to be able to let us know what 
their opinion is.

A poll question:


-  I am adjusting Rebol core-tests suite and doing MOLD and MOLD/ALL 
tests for decimals. There is one case I want to mention separately. 
At present it seems that for almost every decimal X the expression

same? x load mold/all x


yields true. The only exception being the "negative zero" case, because 
MOLD currently yields "0.0" when molding "negative zero".

What are your preferences in this respect?