World: r3wp

try/recover - that is how Carl wanted it to be. (he didn't want to 
define a new function)

Pity about that.

my note is, that it should be native

(because only a native can discern a "live" error and a "computed" 
one)

pity about that - I understand it, that you are already using Default 
and this will make your code incompatible?

you can still define the mezzanine in your %user.r if you want to

No, I was looking forward to using it. I've been avoiding the overhead 
of maintaining another patch script by using
	if error? set/any 'err try [...]
over and over...

usage:

    try/recover [...] 'error [print disarm error]

The pity is more from the "richness of human expression" point of 
view. I can understand the more conservative "don't fill up the default 
namespace with too many functions" point of view too..

(i.e. the usage will be the same as the usage of the Default function)

Ok, that's not bad. It does cut down 9 characters.

Oh I think I remember the discussion now.

The advantage of "reusing" TRY is, that the code will be easier to 
maintain this way (TRY and DEFAULT would have a lot of common code 
otherwise)

(I am speaking about interpreter code above)

Yes, that is good reasoning.

I am satisfied once again.

#4124 "set-modes doesn't work on file directories" - maybe add a 
note to Paul here that "the filesystem may not support setting all 
of the modes that are gettable by get-modes. For instance you can't 
set modification-date, but you can set the owner-write flag." Maybe 
there should be a more informative access error type, not just "Cannot 
open ...".

but it should work in windows

will you be online for a few minutes?

Anton, error #4124 is not a filesystem problem. I replicated it here, 
on NTFS, in a directory that I have permission to do anything. NTFS 
supports changing the modification date of directories - I have an 
Explorer shell extension that does just that, as well as a command 
line touch utility. REBOL can change that attribute on files, but 
not directories. REBOL is probably hust using the wrong API.

hust -> just (typo)

different API - maybe the same goes with TimeZone info .... Ladislav 
found new pointer .... currently under investigation ...

Ok Brian, thanks for the clarification. Maybe that info should be 
added to the ticket "NTFS supports changing the modification date 
of directories..."

I accidentally put a string in the font size, like this:

view layout [area font [size: "m"]]


Windows gives me a small font, which seems right. On OSX I either 
get screen trashing inside the text area, hanging or a segmentation 
fault.

Is there any simple way to add a screenshot upload function to the 
RAMBO script? Or has anyone done it already?

No, and the RAMBO source is not open, as far as I know.

can anyone make the layout code I wrote above crash in Linux? I don't 
have Linux handy...

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