r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[RAMBO] The REBOL bug and enhancement database

btiffin
19-Nov-2006
[2031x2]
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.
Anton
19-Nov-2006
[2033]
Graham is talking about crashes which take down the interpreter :)
btiffin
19-Nov-2006
[2034]
Sorry for the interruption.
Maxim
19-Nov-2006
[2035x3]
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.
Graham
20-Nov-2006
[2038]
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.
Gabriele
20-Nov-2006
[2039x2]
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.
Anton
20-Nov-2006
[2041]
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
	]
Graham
20-Nov-2006
[2042x2]
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?
Cyphre
20-Nov-2006
[2044]
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).
Graham
20-Nov-2006
[2045]
and .. wrong channel ...
Gabriele
20-Nov-2006
[2046]
I have a question for you guys.
Maxim
20-Nov-2006
[2047]
go!
Gabriele
20-Nov-2006
[2048x3]
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?
Maxim
20-Nov-2006
[2051]
what is the drawback of fallback?  security risk?
Gabriele
20-Nov-2006
[2052x2]
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.
Maxim
20-Nov-2006
[2054]
as long as you make the error obvious, I guess its better to be strict 
about it.
Graham
20-Nov-2006
[2055x2]
fall back.
if you write a simple smtp server in rebol you might just want to 
support helo only
Gabriele
20-Nov-2006
[2057x3]
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
Graham
20-Nov-2006
[2060x3]
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!
Gabriele
20-Nov-2006
[2063]
i think you're the person that better knows how smtp servers behave 
out there. :)
Graham
20-Nov-2006
[2064]
there are some pretty ancient smtp servers out there ...
Gabriele
20-Nov-2006
[2065]
if an ordinary user would stumble into the problem, then it's probably 
better to fallback.
Graham
20-Nov-2006
[2066]
that way we only need one protocol ..
Anton
20-Nov-2006
[2067x2]
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.
Graham
20-Nov-2006
[2069x2]
anton, it might only be a couple of lines to fall back.
and I would think most email clients would fall back ...
Gabriele
20-Nov-2006
[2071]
it's not a big deal indeed, it just means disabling the rest of the 
code - that's why it seems quite weird to me :)
Graham
20-Nov-2006
[2072]
It's not worth the hassle of not putting it in.
Anton
20-Nov-2006
[2073]
How about net-logging a prominent message when falling back ? That 
way, it should eventually turn up in someone's log, and we'll see 
it that way.
Maxim
20-Nov-2006
[2074]
good idea... that way any techie does not miss it, if its at all 
important.  and any average user, gets improved mileage without the 
hassle.
Graham
20-Nov-2006
[2075]
Anton, it will be in the build ... do you really want to update all 
builds once someone reports a problem
Gabriele
20-Nov-2006
[2076]
ok, i guess i will add the fall back.
Anton
20-Nov-2006
[2077]
I'm just always trying to find "the correct thing to do".
Gabriele
20-Nov-2006
[2078x3]
I am accepting #4143. note, that although i think it is unlikely, 
this change could break old code that made assumptions about switch. 
so please do test this one when released (i assume 2.7.2), and if 
it breaks code, we can revert to the old switch, and maybe add a 
refinement or something like that.
anyone has the original contents of #3056?
can anyone check if #3666 still applies?