World: r4wp

For one aspect.

The module system could be a deciding feature pro R3. But we really 
need to get started on docs for that to become true.

The module system was almost complete in implementation with the 
last closed-source release, needing only the fixes we (and I mean 
me and you, Andreas) did in the first week of the open source release. 
We have only been waiting for Carl to add that pull request to get 
the current design working as intended, though that request doesn't 
only apply to modules in particular, but to scripts in general. Once 
it is accepted, I need to do another round of optimization, but the 
external effects are set already.

So we are at the stage of writing docs and tests.

The only reason the user-level docs aren't yet written is because 
I am really bad at writing user-level docs of any kind. I was hoping 
that I could write some guru-level docs and then let someone read 
them and write something user-level.

As for that blog, the behavior described there has some practical 
problems. There is nothing in the code itself (I mean the example 
code in the blog, not the implementation code) to indicate that 'last-stock 
is a free variable, but 'if and 'not are not - they are all words 
not declared at the top level of the module (by using them as set-words, 
like in an object) or elsewhere in the code. This means that if you 
want it to have 'last-stock be made local to a module, you would 
have to make 'if and 'not local as well. That works if lib words 
can only be set once, but not if they can be reset, since changes 
wouldn't propagate to the other modules or user scripts (since those 
values are copied to words in other contexts).


We determined that the behavior described in that blog could be useful 
enough to be worth supporting, but had some nasty side effects that 
made it not be what we wanted to do by default. That is why we made 
it an option, in particular the isolate option. If you specify the 
isolate option, your module acts like it does in the blog, and this 
has the effect of isolating your module from all external changes 
to the lib context.

what isolate option?

rebol [type: module options: [isolate]] your script

Carl decided that the best way to make extensible options was to 
put the flag-like ones in an options block. That makes them extensible 
without bloating your header.

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)