gmane.comp.lang.tcl.core

Re: Yet more voting. (TIP 339 - Case-Insensitive Package Names)

Jeff Hobbs — 2008-12-04T18:06:59

TIP#339: YES In the long term view, where I hope Tcl modules become more common and we still have to deal with case insensitive OSes, this just makes sense. Jeff ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: TIP #329 [try] updated

Andreas Leitgeb — 2008-12-04T16:07:47

I now feel guilty for having stepped this loose :-) Would it be feasible to sanity-check the errorCode just once (and independent of actual handlers), and in the BAD-case replace it with something else? Another ugly workaround could be to make the match check like this: Canonify the pattern (i.e. lrange 0 end) and see if it's entirely equal to the errorCode or if "$canonifiedpattern *" glob-matches the errorCode. Wow, did I just suggest to use glob on a list??? *gasp* It's ok, it's a fundamentally different thing. I believe that for two canonical lists, this type of check is equivalent to a sublist check (they differ only for bad lists). If I'm wrong here, then forget this second paragraph altogether. intercepting bad errorCodes at the respective commands is surely not safe enough. Assuming that [try] makes use of the [catch]-infra- structure, catch would be the appropriate place to spot bad errorCodes and perhaps repair them like regexp {\S+} ... I am quite sure that bad errorCodes shall never

Re: TIP #329 [try] updated

Donal K. Fellows — 2008-12-04T14:37:27

I'll think about how to implement the correction. We'll make sure that 'finally' always runs. It's not a handler, and the 'finally' semantics are important. More of a concern is what happens when you hit a resource limit or the interpreter is unwound or deleted but there the issue is that the interpreter is just unable to execute commands; a finally clause could run, but would have to do nothing that involves commands... ;-) The bytecode engine is rather more complex than that. IIRC, each instruction is in the context of an error handler; the default one just makes the current "script evaluation" exit, but [catch] (and [try]) puts a different one in place around its protected code. (Or maybe there's no handler by default, but that's dealt with the same as if there was a default handler that does what I described. Whatever.) What that means is that if you have a fairly complex structural piece of Tcl inside a [catch], Tcl can handle any errors inside it very quickly. Or it could except for generation of

Re: TIP #329 [try] updated

Donal K. Fellows — 2008-12-04T12:26:21

I don't think they make letters that large except in books by Douglas Adams... While I know how to fix such things through stub-table rearrangement (and I've done such in parts of Tk) they're pretty ugly to do. What we *can* do is make sure that Tcl code doesn't mess this up through [error], [return] (and [throw]). I don't think anyone is actually generating bad error codes anyway; at the C level, the convenient API produces proper lists. [...] Things are fairly messy in this area. Donal. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Yet more voting. (TIP 339 - Case-InsensitivePackageNames)

Donald Arseneau — 2008-12-04T11:10:57

Mine doesn't either. Although I will not suffer from the package name collisions this may cause, I am sensitive to the claims raised here that such cases do exist. What does has caught me often is the current case-sensitive matching when the capitalization of package names follows no rules. (I remember there being rules for core vs non-core packages, but I don't see them being followed.) However, I would be quite happy with a change to the error message, suggesting a corresponding existing package can't find package Blt (perhaps you meant BLT) What I don't know is if dynamic error messages break any contract; maybe constant strings are needed for translators and parsers. I was pleasantly surprised tonight when "mount" suggested I meant to type iso9660 when I typed iso9669.

Re: TIP #329 [try] updated

Twylite — 2008-12-04T10:54:26

Never mind. But there need to be bigger health warnings on tclExecute.c and tclCompile.c. Of course this is easier said than done. Everything calls down to "void Tcl_SetObjErrorCode(Tcl_Interp *interp, Tcl_Obj *errorObjPtr)" which makes for one convenient place to fix the problem, but the function is published in the stubs table and returns (void) ... which makes it tricky to fix. One could fix TclProcessReturn() to check valuePtr just before calling Tcl_SetObjErrorCode (context below) ... if (valuePtr != NULL) { Tcl_SetObjErrorCode(interp, valuePtr); } ... which would at least make this safe at a script level, so that only C code calling Tcl_SetObjErrorCode directly can mess things up. Regards, Twylite ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source ev

Re: TIP #329 [try] updated

Twylite — 2008-12-04T10:15:52

Hi, Right - can you please flex your admin muscles and clarify that in the TIP. It's not merely that "trap can't process it", it is that a TCL_ERROR with "-errorcode not a list" is an exception that will be raised if a trap handler is checked. Also please clarify for my understanding (and to answer Joe's question/statement) whether "finally" will run if this happens (your answer implies not: if you don't have a special catch context for listRangeImm then you can't stop the exception from propagating so that you can do the finally, depending on how the entire function is being written). Side question: if you're working in C code there is no "catch context"

Re: TIP 324 (font chooser dialog in tk)

Donal K. Fellows — 2008-12-04T10:12:49

My advice? Stop vacillating. Go with the current proposal. Not because it is inherently vastly superior, but because *nothing* is vastly superior here and the current proposal is, well, current. :-) Donal. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Yet more voting. (TIP 339 - Case-Insensitive Package Names)

Donal K. Fellows — 2008-12-04T10:08:13

I don't know, but I'd tend towards sub-packages or *Impl packages in my own code. Case tricks have always made me a bit uneasy, and life is much easier on Win if you don't play them. (OTOH, I have to ask what locale the case-insensitivity is going to be applied in... :-)) Donal. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: TIP #329 [try] updated

Donal K. Fellows — 2008-12-04T10:02:04

I can *deny* this. :-) Apart from everything else, it is significantly more awkward to implement since you'd have to push a special catch context just when doing the listRangeImm. And anyway... The errorcode is documented to be a list on the [return] manpage and has been for many years, though according to DGP it is a bug that this is not currently enforced. Probably because nobody tried to do it. Donal. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: TIP #329 [try] updated

Twylite — 2008-12-04T07:47:58

Hi, Thanks Joe - I didn't get a chance to response to Donal yesterday. What I said (or intended to say) in the TIP was that the [try] itself must not die horrible if it encounters an errorcode that is not a list. This would imo be a bug in [try] unless error/return/throw force their errorcode argument to be a list (which they don't). And it would be a Bad Thing because then someone doing something stupid lower down the stack can blow up your anti-blowup control structure. Two ways of handling this: (1) If errorcode is not a list, then trap handlers must determine that there is no match, and let the error fall through to the next handlers and be processed or propagated as normal. I _think_ that's what Donal's rewrite is saying, but I'm not certain? DKF - can you confirm this? (2) Update the implementations of error & return so that a non-list error code raises an appropriate error at that point, rather than allowing arbitrary strings that can blow up the [try] later. Regards, Trevor -------

Re: Yet more voting. (TIP 339 - Case-Insensitive Package Names)

Twylite — 2008-12-04T07:39:16

Just wondering how "rare" these incidents of case conflict will be ... I have at least two in my libraries source tree, possibly more in my applications. Regards, Twylite Andreas Kupries wrote: ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Yet more voting. (TIP 339 - Case-Insensitive PackageNames)

Larry McVoy — 2008-12-03T23:59:15

Not that my opinion matters, but count me in the YES camp.

Yet more voting. (TIP 339 - Case-Insensitive PackageNames)

Andreas Kupries — 2008-12-03T23:27:28

Let us see who screams. Calling the vote on TIP #339:Case-Insensitive Package Names One week voting period, close at 12:00 GMT on 9 December. My vote: TIP#339YES -- Andreas Kupries public.gmane.org> Developer < at > http://www.ActiveState.com Tel: +1 778-786-1122 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: TIP 324 (font chooser dialog in tk)

Adrian Robert — 2008-12-03T23:18:18

On Dec 1, 2008, at 2:10 PM, Daniel A. Steffen wrote: I'm still uneasy about the prefixing for the command, though I hope this can be decided independently of the voting on the TIP. The main proposals have been: (1) tk_chooseFont [original] (2) ::tk::chooseFont [June-November] (3) tk chooseFont [current] (1) is consistent with other temporary dialogs (tk_getOpenFile, tk_messageBox, tk_chooseColor, etc.) in its naming style, however the font chooser dialog operates differently in that it may be non-modal on Mac OS X and perhaps other platforms. Therefore (2) was proposed, however it would introduce a practice of dividing the tk core cross-platform commands into multiple namespaces. This seems too drastic a move to deal with the inconsistency in (1). Perhaps partly in reaction to this, (3) was brought into the most recent version of the TIP. However the 'tk' command is described in its man page as "Manipulate Tk internal state". The other subcommands under it include "appname", "

Re: Delaying CVF#340 until dec 5 (Re: CFV TIP #340)

Jan Nijtmans — 2008-12-03T21:50:33

2008/11/27 Joe English public.gmane.org>: First remark: This looks like a YES, but still isn't. I'm wondering why still no other votes then mine came out. Was it because the TIP was still not updated to include the results of the agreement? If that's the case, I have good news: the TIP text is updated now! Second remark: I agree with all of Joe's remarks below. Especially the last remark is important. Although the risk is not zero, it is small enough in my opinion to justify a YES. My "who cares!" remark was intended to trigger everyone's attention, not to make people afraid of voting. :-) Joe was the only one who reacted, and he reacted exactly the way I hoped for..... Regards, Jan Nijtmans ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Sourc

Re: CFV: My final round for 8.6...

Joe English — 2008-12-03T19:48:04

Donal K. Fellows wrote: TIP#329 r1.7: YES (enthusiastically) I'd like to thank Twylite for shepherding this one through the TIP process. The discussion looked like it was going to go completely off the rails, but in the end the process worked: the final version is a *good* spec. Between the conflicting requirements of functionality on the one hand and simplicity on the other, it hits a local optimum. TIP#343: PRESENT. --Joe English jenglish-BD/dr091N2xF6kxbq+BtvQ< at >public.gmane.org ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: CFV: My final round for 8.6...

Andreas Kupries — 2008-12-03T19:33:51

At this moment TIP#329:PRESENT Have to read the TIP first, now that the heat of discussion has subsided. TIP#343:YES Agreeing with Donal. This is low-hanging fruit and sensible. -- Andreas Kupries public.gmane.org> Developer < at > http://www.ActiveState.com Tel: +1 778-786-1122 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: TIP #329 [try] updated

Joe English — 2008-12-03T19:31:46

[I wrote] Oh, that *was* the revised text. Please ignore previous message. --JE ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: More voting...

Andreas Kupries — 2008-12-03T19:25:46

Amending, now that I have read the TIP: TIP#341: YES A generalization of the existing filter sub-command which looks innocent enough. -- Andreas Kupries public.gmane.org> Developer < at > http://www.ActiveState.com Tel: +1 778-786-1122 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: TIP #342: Dict Get With Default

Jeff Hobbs — 2008-12-03T19:16:46

+1 on new verb altogether. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/