World: r4wp

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?

To be understood, my question is whether you prefer

mold/all -0.0

to yield "0.0" or "-0.0"

As `false == same? 0.0 -0.0", I'd prefer mold/all to yield "-0.0".

OK, counted your vote. I assume that you do not object against

mold -0.0

yielding "-0.0" as well?

I have no opinion regarding mold, as I think mold/all should be the 
default.

But yes, if anything, I would prefer MOLD to yield "-0.0" as well.

(counting as "no objection for the two to behave the same in this 
case")

I would prefer MOLD/all -0.0 to generate "-0.0". As for MOLD, I'm 
on the fence: If the difference between 0.0 and -0.0 is significant 
enough semantically, but not too confusing to the regular programmers 
that MOLD is targeted at, then why not? We definitely don't want 
MOLD and MOLD/all to be the same though, because there are too many 
developers that want to keep the illusion that 0.1 exists. Having 
a display setting to have the interactive console print values with 
MOLD/all instead of MOLD makes sense though.

Sorry for starting this, let's not sidetrack this further into a 
discussion of MOLD vs MOLD/all.

(But to clarify a single bit: currently the plan is for MOLD/all 
0.1 to yield "0.1".)

That wouldn't be the whole value.

It is accurate enough, as Ladislav explained before.

That wouldn't be the whole value.

 - that is actually irrelevant. No software prints "the whole" 0.1000000000000000055511151231257827021181583404541015625, 
 neither I see it as practical

Right, because they print approximate values. If your proposal is 
to change MOLD to generate the smallest value that, while not actually 
being the value in memory, would generate that value in memory as 
a result of the loader trying to approximate what you wrote, then 
I might be OK with that if it can be done efficiently. If it can't 
be done efficiently, I'm OK with doing what all of the other non-scientific 
languages do and just use 15 digits.

That's precisely what Ladislav proposed: "Molding decimal numbers 
'precisely enough'".

R2 says 0.0 and -0.0 are the same, but R3 does not. I replied to 
Lad's googlegroup post that I would prefer "0.0", as evaluating -0.0 
returns 0.0. So, they are equal but not the same under R3. What would 
be a scenario where you would want to maintain the sign?

Evaluating -0.0 yields -0.0. But MOLD is used to format the evaluation 
result, that's what lead you to believe otherwise.

Ahhhh. So, is there every a case where we would want to maintain 
the sign (i.e. because we need the sign itself), or is "-0.0" preferred 
because it is more correct?

Anyone have a suggestion on how we can get trace/net functionality

R2 says 0.0 and -0.0 are the same

 - actually, in R2 it is possible to devise a test which would discern 
 -0.0 and 0.0, although SAME? can't discern them

, which means I can define my IDENTICAL? function so that

    identical? 0.0 -0.0 would yield FALSE

- if you want to see it, read

http://www.rebol.net/wiki/Identity

That clearly demonstrates that Rebol identity doesn't depend on the 
behaviour of the SAME? function as much as it seems...

It is possible to prove that Rebol identity does not depend on the 
SAME? function at all, in fact, and unsetting 'same? I obtain the 
same identity as when the SAME? function is defined.

(which is what the article demonstrates, in fact)

This actually demonstrates that there may be some level of "arbitrariness" 
in the implementation of the SAME? function, but if the SAME? function 
is arbitrary and differs from the IDENTICAL? function then we are 
able to prove that it is arbitrary and it is not the natural identity 
existing in Rebol regardless of the SAME? function.

The problem with writing a prot-send.r is that we have no guidance 
yet on where user variables such as name, email and passwords are 
to be stored.

I'll try to read the latest article soon Ladislav, though my scheule 
is packed right now. Thanks for posting it.

That is not "the latest article", it is quite old, to be honest.

You may have just forgotten you already read it