Hi Harald,

thanks for your answer,

If you think, it would be so much easier, just make it with "fconfigure" :)

And for people like me (those are allergic to "throw with configure" too), here simple trick to use another "solution":

namespace ensemble configure ::chan -map [dict merge [namespace ensemble configure chan -map] {rethrow ::tcl::chan::rethrow}]
proc ::tcl::chan::rethrow {ch args} {fconfigure $ch -throwerror {*}$args}

so it will directly map to "fconfigure -throwerror", and if we test it (at the moment an error because not yet implemented):

% chan rethrow stdout
bad option "-throwerror": should be one of -blocking, -buffering, -buffersize, -encoding, -eofchar, or -translation
    while executing
"fconfigure $ch -throwerror {*}$args"
    (procedure "::tcl::chan::rethrow" line 1)
    invoked from within
"chan rethrow stdout"


Am 24.04.2014 22:26, schrieb Harald Oehlmann:

Hi Serg,

thank you for the ideas and the efforts to make it readable.

AFAIK, Andreas may correct me:
Unfortunately this is a channel driver dependent issue and solution and
thus we only have the fconfigure command to invoke abertrary functions.
Thus we should use "fconfigure -option ?value?".

Remark also that "fconfigure $h" directly maps to "chan configure".
So, we may also write: "chan configure $h -throwerror"

So, your ideas to make it more readable are nice, but AFAIK not
practical in the current framework.


Am 24.04.2014 22:11, schrieb Dipl. Ing. Sergey G. Brester:
Hi, I have no problem with "-throwerror", I think the "fconfigure" would not be right for the error throwing. What I with "condthrow" suggested, was a "conditional error throwing". And I think it would be clearer and better for general use. If you compare: *fconfigure $chan -throwerror* and *condthrow [fconfigure $chan -error]* But to say about channel functionality only, I think there is a standard ensemble "chan" better. Then, extending the ensemble would be better, something like: *chan rethrow $channelid* what you propose would be: *chan configure -throwerror $channelid* for me it looks not so good. Unfortunately, I can't recommend here "*chan throw*", because I did it "misused": I extended standard ensemble, so in my world "*chan throw $channelid $opt $msg*" sends an error through socket to another site (own RPC-solution) and then I would have to rewrite it. Thanks, Serg. Am 24.04.2014 21:06, schrieb Harald Oehlmann:
Hi Serg, thanks for the fruitful discussion. Indeed, "fconfigure -lasterror" is another sister function, working again different. "fconfigure -error" is already used to get the error message text for sockets. To resume: fconfigure -lasterror: serial, win only: returns something like the second component of an errorCode list: lindex $::errorCode 1 -> channel must not be closed, serial errors may be temporary. fconfigure -error: socket, all platforms: returns an error message -> channel must be closed, no way to recover (with tcp). fconfigure -throwerror: throw a full error containing errorCode and errorMessage if {[catch {fconfigure $h -throwerror} e d]} { catch {close $h} puts "$h:$d" # -> returns "connection refused:-code 1 -level 0 -errorcode {POSIX ECONNREFUSED {connection refused}} -errorinfo {couldn't open socket: connection refused" # fail with the error unset d -level return -options $d $e } In future, the serial port may get a "-throwerror" option too. I don't stick to the name "-throwerror", better propositions welcome. What do you think ? Regards, Harald Am 24.04.2014 19:31, schrieb Dipl. Ing. Sergey G. Brester:
Hi Harald, Agree, I thought "-throwerror" would be a flag, and you want to automatically throw the error by channel access (cause I was confused using "fconfigure" to throw an error). If I understand correctly now, you will use it comparable to serial "-lasterror", so quote from documentation
fconfigure -lasterror can be called to get a list of error details
but for throwing of the last error (if error occurred). Then I think that "fconfigure -error" or "fconfigure -lasterror" are much understandable and the following code would be not much more complex to write as "fconfigure -throwerror": *condthrow [fconfigure $chan -error]* But it would be more undestandable and has more benefits as "fconfigure -throwerror" (command "condthrow" could be used with another cases). I have C and pureTcl implemetation of "conditional throw" command, if it can be interesting, I will commit it as a Tip. Tcl implementation is attached now; Thanks, Serg Am 24.04.2014 17:33, schrieb Harald Oehlmann:
Hi Serg, thank you for the proposal. I don't like not supporting new ideas, which are always good. Nevertheless, here is my answer. The proposition is to: - stock the error if it arises - throw it if "fconfigure -throwerror" is executed. The functionality you require is more appropriately covered by "fileevent". For instance, fileevent (readable,writable) fires in success and fail cases. If you want an error fileevent only, this should be extended. Your proposed change is IMHO quite heavy in implementation. The proposed "fconfigure -throwerror" is 5 lines in C code, as the whole functionality is already awaylable by "fconfigure -error". Ok ? Thank you, Harald Am 24.04.2014 17:14, schrieb Dipl. Ing. Sergey G. Brester:
Am 24.04.2014 15:59, schrieb Harald Oehlmann: Hello Harald, everyone. Do I understand correctly, did you mean boolean switch, something like "fconfigure -throwerror *yes|no*"? If yes, it'll be good solution imho (source code maintenance, backwards compatibility etc.). But imho, better solution would be something like example below: *fconfigure $chan1 -onerror on_chan_error fconfigure $chan2 -onerror on_chan_error_throw* proc *on_chan_error* {chan opt msg} { # log error message: tclLog ... $msg # rethrow an error: return {*}$opt $msg } proc *on_chan_error_throw* {chan args} { # simple rethrow an error: return {*}$args } So we can define a callback, that just rethrows an error (return) or does additionaly anything else (tcLog). For example, it make possible to (re)connect, if we have a connection problems or still much more other cases... I think, the cost of implementation of this would be comparable with throwing of error, because the error message+options you should buffers nevertheless up to the channel access. Regards, Serg
Am 22.04.2014 14:26, schrieb Donal K. Fellows:
Hi everyone As you can see, TIPs 427 and 428 are now up. The delay in publishing them was due to me having a total crunch on at work (since Christmas it's been a neverending round of too many things to do, not nearly enough time, and *far* too much stress!) for which I completely and unreservedly apologise.
Donal, TCL-community, thank you bringing the TIPs up and caring well about language and form. Complementary information is on the wiki page http://wiki.tcl.tk/39687 Some information to the community and possible ways how things may be done: - TIP#427: "Introspection of Asynchronous Socket Connection" This TIP proposes "fconfigure -connecting" which allow to fully use async connect without the event queue. Async connect without event queue worked well on TCL8.5 and was used (info by windows bug reports). How this may proceed: - Reinhard wants to review the TIP - After discussion, this small change may be voted and integrated in tcl 8.6.2 - eventually backport to tcl 8.5 (open for discussion) - TIP#428: Produce Error Dictionary from 'fconfigure -error' This second tip has a more general form and question. I want to rewrite it totally as something like: "fconfigure -throwerror" : if an error arised in a non-blocking operation (e.g. "fconfigure -error" would report an error), throw this error. If there is no error, do nothing. This would allow to treat a background error like a normal error and do a catch or a try on it and get errorCode etc. It has a more general scope, as other channel drivers also implement the option "fconfigure -error" and thus should also support this. Please feel free to comment. Harald ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Tcl-Core mailing list Tcl-Core@lists.sourceforge.net <mailto:Tcl-Core@lists.sourceforge.net> <mailto:Tcl-Core@lists.sourceforge.net <mailto:Tcl-Core@lists.sourceforge.net>> <mailto:Tcl-Core@lists.sourceforge.net <mailto:Tcl-Core@lists.sourceforge.net> <mailto:Tcl-Core@lists.sourceforge.net <mailto:Tcl-Core@lists.sourceforge.net>>> https://lists.sourceforge.net/lists/listinfo/tcl-core