World: r3wp

Jaime, were you expecting each value of the tuple to be compared 
with the first 8 bits of a 32-bit integer ?

Yes. I do to use as many bits as possible.

It also seems the operator have inconsitent behaviour like this.

>> 1.2.3 and -1
== 1.2.3
>> 1.2.3 and -2
== 0.2.2
>> 1.2.3 and -3
== 1.0.1
>> 1.2.3 or -1
== 0.0.0
>> 1.2.3 or -2
== 0.0.0
>> 1.2.3 or -3
== 0.0.0
>> 1.2.3 xor -1
== 0.0.0
>> 1.2.3 xor -2
== 0.0.0
>> 1.2.3 xor -3
== 0.0.0

AND behaves differently than OR and XOR regarding on how they treat 
negative numbers. AND is taking into account as many bits as possible, 
while OR and XOR are just returning a tuple of zeros.

My conclusions is that these operators have bugs.

Yes, looks inconsistent.

Probably better to fix to support 32-bits.

So. You agree that it needs to be posted to RAMBO ?

Yes.

If there is some explanation for the behaviour, we will find out 
this way.

BTW. Orca is using all the bits possible, and its behaviour is consistent 
across the board.

I agree. If it works with 'and', one would expect it to work with 
'or' and 'xor' too.

Isn't it incredible with REBOL. Here are some basic bugs or misbehaviour, 
and it takes us 8 years or so to discover them. :-)

What about, if we started a project to closely investigate the behaviour 
of REBOL native!, action! and op! in relation to the defined datatypes? 
I did something like that in the IOS regarding minimum and maximum 
values for the different datatypes at some time. The idea would be 
to nail down bugs and misbehaviour and lead to a more robust language 
definition. After the initial investigation, the mezzanines could 
be looked at.

The amount of work can be judged by:
>> ? native!
>> ? action!
>> ? op!

Regression tests!

... and:
>> ? datatype!

Maybe the amount of work will be too big compared with the number 
of bugs and misbehaviour, we might find. REBOL is rather stable, 
as it is. And: 1) we have RAMBO and 2) the power-users already know 
most of the misbehaviour (, if you can call it that).

An example of a peculiar thing:
>> negate 2 ** 31
== -2147483648.0
>> a: negate to-integer 2 ** 31    
** Math Error: Math or number overflow
** Where: to-integer
** Near: to integer! :value
>> a: negate to-integer 2 ** 31 - 1
== -2147483647
>> a: a - 1
== -2147483648
>> type? a
== integer!

Ah, I just found the explanation!
>> a: to-integer negate 2 ** 31
== -2147483648

It's correct behaviour. Silly me.

Personally, I think it would be worth it to make the tests. There 
have been several times that I have been tripped up by a former bug 
getting fixed, sometimes years prior, and a set of unit tests would 
have kept me informed. Still, I would prefer if any misbehavior found 
would be fixed, not just documented and left to rot.

I often thought it would be nice to see the history of a function. 
That is, which version of rebol it first appeared in, if there were 
any changes in any subsequent versions etc.

Plus, the unit tests would serve as documentation of a function's 
behavior, intended or not.

There used to be calls for "the function diffs" when new versions 
of rebol would come out. The script to produce the diffs compared 
argument spec blocks and function body code where available.

Anton, your function history sounds like a great idea, although I 
would add parse behaviors to that list.

Fixes to parse bugs (somewhere in the /View 1.2 betas) were what 
tripped me up :)

Yes, well that's where the unit tests will help you.

Unit tests will have to be rebol version dependant. Eg. A set of 
unit tests developed on Core 2.6 for the PRINT function may all pass 
on Core 2.6, but not on Core 2.5.  Recording the rebol version also 
captures the date and platform where the tests were developed.

Uhh yes, testing a vocabulary huge and multi-platform language as 
REBOL is a big task. But interesting aspects (like the history), 
as you point out.

I'm thinking more like keeping track of a few things:
- Proper behavior, and version when such behavior was achieved
- Changes in expected behavior

So there would be two sets of versions, the versions of REBOL and 
the versions of the tests. Over time, both REBOL will be fixed and 
the tests will be fixed, refined or altered. This could get pretty 
big pretty quickly I suppose - it could use a database to store the 
tests or some such.

Encyclopedia REBOLae
:-)

Don't tell me this is another thing that would have to wait for the 
REBOL/Services infrastructure...

I think we all have to wait for Rebol 3.0 :-)

It would be good to be able to answer a question like this: "Do the 
functions: [print parse encloak] exist and behave the same on Rebol/Core 
2.5 and 2.6, and Rebol/View 1.2.1 and 1.3.1?"

Brian, I think the results can be stored hierarchically, so a filesystem 
storage can be enough, although I'm not sure.

I'm wondering if everything can be automated so that there are no 
stored results (because results are in fact derived), so when the 
user asks a question, that's when the tests are run and the answer 
obtained.

(The results could be stored after this, mayb, so that only popular 
questions have web pages generated with the results in them.)

I've got a text file going with these notes in it, but I think it 
might be better to make a new project in Qtask. Anyone disagree ?

For the resulst of the use of a word, you may need to save the wanted 
output, and the actual output from different platforms (if they differ).

*results*

Absolutely, but if we have a rebol unit test server constantly running, 
able to answer arbitrary questions, why would we need to store results 
?

right, only the wanted result need to be tested, if you have access 
to all platforms to test. Maybe result from one reference platform 
should be saved, to test other platforms up against?

We could set up a server with as many versions of rebol as possible, 
so it can help as many people as possible, but each of us could also 
run the same system with a more limited set of rebol versions (ie. 
just the ones we bother keeping).

*only the wanted result need to be SAVED, if ...*

(I'm not too sharp today.) :-)

Geomol, every one has a different idea, as time progresses, as to 
what is the "reference" platform. Since it will be a collaborative 
effort everyone will be adding input from various sources. Some functions 
are only available on Rebol/Link etc..

Well for one thing, this would preclude platform-specific tests, 
as your server would only be able to be one platform (probably).

Anton, to make it perfect (total), you need acces to all the OSs, 
REBOL is supported on.

That's right, the server will get as many rebol versions from everyone 
as possible; Core, View, SDK whatever..

So the request to a certain server would be something like: run this 
little test and tell me the result (also if it lead to an error!). 
Could be done easily with REBOL.