World: r3wp

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?

what is the drawback of fallback?  security risk?

no, it's just not esmtp anymore :)

i mean, if noone in the world will ever need the fallback, there's 
no point in adding it. in weird cases when you have to work with 
some 15 years old server, you may just use the old smtp:// protocol.

as long as you make the error obvious, I guess its better to be strict 
about it.

fall back.

if you write a simple smtp server in rebol you might just want to 
support helo only

graham - did you stumble on any servers not liking EHLO? if you did, 
then I guess we need to fallback

no, actually, you can support EHLO and have no extensions.

not supporting ehlo in a server makes your server not rfc compliant

let me check if my own smtp server supports ehlo :)

http://www.compkarori.com/vanilla/display/Smtpd.r

suports EHLO .. so I guess you're okay!

i think you're the person that better knows how smtp servers behave 
out there. :)

there are some pretty ancient smtp servers out there ...

if an ordinary user would stumble into the problem, then it's probably 
better to fallback.

that way we only need one protocol ..

Gabriele, why don't we run without the fallback for a while to see 
if it will affect anyone. I don't see the reason to add code "just 
in case" when there might in fact be no case like that.

You could keep the fallback code in there ready to be uncommented 
when someone complains.

anton, it might only be a couple of lines to fall back.

and I would think most email clients would fall back ...