World: r3wp

still areas with automatic scrollers, styles as tab, groupbox, etc. 
are missing in default distro ... and we were supposed to know what's 
in the pipeline for VID refactoring "real-soon-now" (c) 2005 RT ;-)

values for highlighting is much quicker coding than translating to 
indexes. ANd for the other stuff, a selfmade list is not that much 
code. although complicated.

yes, list somehow scares novices :-)

I'd love to get LIST-VIEW into /view, if the quality can get high 
enough.

TEXT-LIST definitely has issues, but works well in many simple cases. 
I think we'd all love to have LIST-VIEW in there, though I have to 
spend some time with it to make suggestions, so it's good fit with 
other VID styles (client side, in VID). I think that's what has kept 
changes out of VID in general.

Ideally the Value and Text should be two different elements, like 
they can be in html selects.

Can anyone tell me if there are any efforts to embed core into a 
device or embedded controller. Given its light size, it would be 
perfect for routers, applicances, etc..

www.whywire.com runs Rebol in their routers.

I heard last night that there is a new linksys router that you can 
install linux software into. Of course, REBOL was the first thing 
to come to mind.

Most of the early linksys routers are linux based.

Do you know what type of controller Whywire is usting?

If an early links router was linux based, wouldnt you need the source 
code for rebol to compile it for that platform?

We use our own mother boards based on x86 cpu(s).

Linksys is planning to discontinue their linux products and move 
to VxWorks based ones.

I guess using x86 would simplify things quite a bit from a development 
standpoint. I would assume much more expensive over a rabbit2000 
or similar. Do you know what types of controllers the linksys utilized?

I believe they are MIPS based cpu(s).

what registry value 'browse refers to? Bobik has some screwed OS 
isntall, after removing FF from his PC, browse does not start IE. 
IE is checked as a default browser, but it still does not seem to 
work ...

ok, solved - there is a button to renew internet related settings 
in control panel/internet settings/programs ...

I think I found some errors on the tuple math with rebol. This results 
don't make any sense to me. Does anyone agree that these are bugs?

>> 1.2.3 or -253
== 0.0.0
>> 1.2.3 and -253
== 1.2.3
>> 1.2.3 xor -253
== 0.0.0
>> 1.2.3 xor 512
== 255.255.255
>> 1.2.3 or 512
== 255.255.255
>> 1.2.3 and 512
== 0.0.0

Well, each of the elements (numbers) in a tuple is an integer from 
0-255. Doing a binary operation with that restriction and an integer 
without that restriction should maybe return none or an error? I 
guess, REBOL is optimized for speed doing this, so the result is 
undefined. (You can probably guess some internal rules/side-effects.)

These operations can be defined correctly. The values returned are 
improper imo. And the speed optimization doesn't gain much.

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.