World: r3wp

survives here.

font is smaller

Actually, I see quite the opposite. Using following code:

view layout [text "MIQXA" text "MIQXA"  font [size: "m"]]


the second line is bigger .I'm trying this on xubuntu 6.06 (using 
area has same results, but area is much bigger than text so it's 
harder to notice).
I'm rebooting to Win to see the difference.

so I tried on Win and the second line is so small so it's unreadable 
(font size 1 or something like that)

yes, I know. It segfaults on OSX so I wondered if it happened under 
Linux as well.

oh, you wrote about it. I didn't notice volkers input. sorry.

I will rambo it if there are no objections.

No objections on anything that causes a segfault (unless, of course, 
it's already in rambo somewhere.)

; Crash
write %test.r {rebol [] do %test2.r probe system/script/args}

write %test2.r {rebol [] system/script/parent: none} ; <-- naughty 
parenticide

do %test.r ; <-- DO file makes an error but doesn't really survive
do %test.r ; <-- so this second attempt shuts down console

DO probably needs to hang on to the original system/script object, 
and restore it after the child script has returned.  The child script 
could probably also modify attributes of the parent object and leave 
the parent script confused.

strange, I didn't even know about /parent !!

I like the idea from the R3 blogs about having SYSTEM be a function 
that generates objects, rather than an object. That way system/script 
would return an object that wouldn't mess up the infrastructure when 
it is changed.

its always safer to have hooks and apis, than direct data.

which is why I dearly hope R3 adds accessors.

many points in many r3 discussion would be moot with this simple 
concept added to a new class! or current object! engine.

I have been a big advocate of accessors here and in the blog comments, 
though mostly for interoperability with other object models that 
have them (all of the major platforms now). Safety is a good reason 
for them as well.

and invisible datatype... with accessors, I could code a liquid api 
which is completely hidden from users... totally non-aggressive to 
the way they currently code and yet still allow custom types of liquid, 
just by changing how the accessors are built.

I could do magic objects  ;-)

anyways... I'm getting OT... (rambo list)

Indeed.

what do you mean by "accessor" in rebol terms?

So, no objections to me creating a ticket for that ?

no objections from me

Petr, there were discussions in the R3 blog about accessors. It's 
quicker to just look there.

I think I understand - it is simply that some "variable" is not variable, 
but a function? In Visual Objects, we could define variable being 
an accessor, you then normally used oMyObject:myVar: 3 - which could 
mean - you either assign it to variable, or (if an accessor), the 
same syntax is being used, but it was passed as a parameter to function, 
which could do type checking, whatever ...

Yup, something like that. Accessors were introduced in Self, then 
ported to Delphi (as properties), then from there to ActiveX, Java 
(as a coding convention), C# (and the rest of .NET), and then many 
other modern languages and platforms (most of the major ones).

python is defined from ground up with accessors, you can replace 
the in-built datatypes!!!

I guess self is like that also.

Python is designed that way now, but it didn't start that way. That's 
something I like about Python - when they add new features in a new 
version, they are not afraid to redesign the whole system to take 
advantage of the new features.

Submitted the above crash code to RAMBO.

what do you think about these:

>> p: make port! http://
>> equal? reduce [p] reduce [p]
== true
>> equal? p p
** Access Error: Port none not open
** Near: equal? p p

or

>> a: tail [1]
== []
>> remove head a
== []
>> equal? reduce [a] reduce [a]
== true
>> equal? a a
** Script Error: Out of range or past end
** Near: equal? a a

it looks inconsistent to me and incompatible with FIND and SORT as 
well

It does look like a problem. Things like this are funny, because 
it seems like an obvious issue we would have hit long ago. :-\

ladislav, you aren't causing Carl any sleepless nights now, are you? 
:-)

no, he silently ignores my huge list

Except that I don't get the error you get on the second example.

you don't?

No. Let me try a fresh console.

Hmm. I got it this time.

it surprises me you didn't the first time

Me too. Let me check something.

ladislav, well it could be that he's incorporating fixes into R3.

Oh well, it happens every time now. Must have been something odd. 
Can't dupe it right now.

Can't dupe it working that is. :-)

that does not surprise me like the opposite did

That one comes back to the old issue of out of range indexes, which 
has been around for a long time, correct?

yes, it is an old issue, actually

but my point is, that you cannot state comparing A with A may be 
an error without asking for trouble

Agreed.

it is clearly more useful to allow comparisons as FIND or SORT demonstrate 
than to forbid them