World: r3wp

my guess is that it was supposed to increas a paren't size based 
on children offset and size...

so if you position your face far off, the pane ends up larger... 
but for the top level pane this does not work, since all it does 
is move the window... this is all pretty strange.

(again, just thinking out loud.. I am deep in my head resolving a 
get_username OS call, to get proper logon user on windows) hehe

Most styles have not much to do with pane-size, but there's a whole 
branch hanging off BASE-TEXT which deal with pane-size in exactly 
the same way.

BACKDROP and BACKTILE are in a separate category, they just set their 
size to pane-size at the end of their INIT.

continuing from View: Since you can opt not to install Rebol/View 
in Windows, how about a no-file-pollution option, where REBOL itself 
will never create dirs or files, like the public dir?

I like the way you're thinking.

rambo'ed

I'd like there to be a no install version of rebol view.

a version which doesn't even ask, does not store any registry to 
remember anything and which actually looks in the directory from 
which rebol.exe is launched to find any config files... without actually 
creating them itself...

I guess the SDK versions are like this.. but they should be made 
available at large.

Maxim - that is a lost battle! Just google some of my maillist rants 
- I was faiting for reverse scenario for years, back then, when Holger 
was still with RT. View's dependency on registry, and install process, 
is what I find obtrusive

RT's opinion, and probably valid though, was, that majority of users 
do want system friendly install process ...

yes... but any developper or techie hates this.  especially for a 
development platform where you have to deploy...

if you have to deploy, use the sdk :)

(continuing from View) Funny, Anton I got the standard Windows crash 
requester the first time, but the new one the second time.

actually:

>> to-vector "1"

old style crash

>> to-vector "x"

new style crash! :-)

My console just disappears with the first one.

This one worked before:

REBOL/View 2.7.0.3.1 18-Nov-2006 Core 2.6.3
Copyright 2000-2005 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> make list! 0
** Script Error: Cannot use make on datatype! value
** Where: halt-view
** Near: make list! 0
>

looks like list! and hash! don't work.

were there so deep changes to kernel, that those already working 
things don't work?

Beginning of the corresponding blog raised question, if it is worth 
to do so for "old" branch. I really see it as unneded, if the emphasis 
on the future is clear - R3.

Petr, we need updates to the current releases. Until R3 has stabilized 
etc. it takes quite some time. I need a matured product.

pekr, R3 stable is probably a year away at best. we need something 
to play with in the meantime :-)

yes, I do understand. But I am not sure, if those updates should 
not be mainly bugfixes only. I don't agree about 1 year maturity. 
R2 was developed by Carl alone in 3 months?

OK, at least I hope that new introduced functionality to R2 is on 
pair with what is planned for R3

I would hope that crashes can be vectored to our own handling system 
rather than having to trap every error

petr, the deep changes are, i guess, to make Carl's life easier. 
(i.e. compiler and string)

graham, i'm still not sure what you mean.

I would like a way to handle all untrapped errors.

Dropping to the console in an encapped program is not very pretty 
... :(

Graham: I might not quite be getting it but this style works for 
me.  Wrap your code in a "go" function and then ; Loop forever
forever [
    if error? result: try [go] [
        errobj: disarm result
        errorlog [mold errobj]
        either noask [
            alert reform ["There has been an error logged"
                  newline copy/part mold errobj 200

                  newline "See File/Configure/View Error File/ for more info"]
        ][

            unless question/title reform ["There has been an error logged."

                                  newline copy/part mold errobj 200] "Continue?" [
                print ["Type Q to quit, GO to restart FirM"]
                halt
            ]
        ]
    ]
    ; halt
    recycle
]

The whole noask part is support for me while developing.  If something 
is wonky before the gui gets up and exposes the Exit button there 
would be no way out of my app, so noask starts out false.

Graham is talking about crashes which take down the interpreter :)

Sorry for the interruption.

REBOL is very old.  although R1 code might have been finished quickly, 
it tool many months to get view, draw, and other goodies.  and AFAIK 
Carl was not alone.  getting R3 at the level of R2 will definitely 
take time.  especially to a level where it is stable enough to be 
commercially viable.

just getting 1.2 -> 1.3 took ages (for many reasons.. but still)

and R3 is such a big shift in philosophy, just adapting our code 
to it will take some time.

btiffin ... I guess it's good to wrap an error handler around the 
whole program, and too often I don't. I just trap suspect areas, 
and then get caught when something happens in a region where I was 
not expecting the possibility of an error.

Anton, if a crash takes down the interpreter then you cannot trap 
it with interpreted code.

Graham, what I don't understand is the difference between the code 
that btiffin showed and what you ask.

Oh, you're right.
Graham, just do this in your programs:

	view/new window: layout [...]
	if error? set/any 'reserr try [ do-events ][
		print mold disarm reserr
	]

Is this a one fire mechanism?  When I do this, and get an error, 
and print it .. or whatever, and if I generate the same error again, 
it then drops to the standard error handler ignoring my error handler.

Do, I need to reset the trap somehow?

Also it is good to add some protection against infinite error cycling.(for 
example if an error occurs in some loop/timer/port etc. executed 
code).

and .. wrong channel ...

I have a question for you guys.

go!

I want to improve the esmtp:// protocol to fix a few bugs reported 
to RAMBO... and make it more conformant to the RFC

so... it needs to send out EHLO instead of HELO

should it fall back to HELO if EHLO fails, or should we tell users 
to use the old smtp:// protocol if they are dealing with an old server?