tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP#234 Status

[Donal K. F. <don...@ma...>]

Michael Kirkham wrote:
> Clerical:
> 
> * Jeff and Pascal both indicated they prefer Tcl_Zlib as a prefix
> (with unnamed others preferring Zlib_).  [I don't care, but Tcl_Zlib
> makes more sense to me.  Maybe you can put that to vote.]

I'm similarly indifferent to this. Can run it as a subsidiary question.

> * 'compresseddata' in the Arguments section is not used anywhere and
>  should be removed.  'data' should be changed to in/out, or (maybe
> better) change Put() to 'srcPtr' and Get() to 'dstPtr', and replace
> 'data' in Arguments with these.

Good points.

> * I think the last time I read the TIP I was confused about Put/Get 
> thinking one was for compression and the other decompression, because
> one inflate() or deflate() call both feeds data in and gets data out,
> when using zlib directly.  If that's how Get/Put are intended to be
> used, it should be clarified.

I've been reading the TIP again and I think it is clear that isn't how
they are used. Instead, a stream is created as either a compressing or
decompressing stream and Get/Put are used to transfer data between the
stream's buffers and the rest of Tcl.

Will need careful documentation though.

> * Jeff mentioned in the previous thread something about consistency 
> between "-limit" and "-count" at the Tcl level and about multiple 
> compression method pairs versus one pair with options that don't look
> to have been addressed.  But I only bring them up because I was
> skimming the thread and looking at what was changed since, not
> because I have an opinion.  I'll just defer to Jeff et. al. regarding
> this stuff.  You can look to the tcl-core archives for Oct 23-25 '08
> for the thread in question.

As far as I can see, the two features are independent and you could
always get a short read.

I also noticed that the various options at the Tcl level can't be passed
to the stream creation function with the listed API...

> * I'm puzzled by the stream handle being an integer.  I'd think it'd
> be an opaque pointer, but maybe this is just an implementation issue
> and the int is actually a hash table key.  In any case, may be better
> as a typedef. (Only came up because I was wondering how to determine
> bytes consumed by Put(), and checking if TIP234 exposed the real zlib
> handle).

Ought to be an opaque token. Good catch.

> Underspecified:
> 
> * inflate() and deflate() may both return an error result.  It's 
> unspecified whether Zlib_StreamGet()/Put() are intended to return an
> error result (in which case, they should take an interp argument and
> handle error messages) or number of bytes read/written.

Good question.

> * Get() should indicate that data is appended to the Tcl_Obj, or else
> take a starting offset.  In the previous discussions, Pascal
> indicated he was leaning toward the former, and I can probably work
> with that (resetting Tcl_Obj length to 0 doesn't free memory, right?
> If so, it'd be a big performance hit to TkPNG; if not, should be
> fine).

Appending would be reasonable. When working with a bytearray object,
setting its length to zero doesn't deallocate the buffer. (I really hope
you're talking about setting the length of a bytearray Tcl_Obj! Doing it
for a "raw" one would be much scarier...)

> * A single call to inflate() or deflate() may, but will not
> necessarily, consume all provided input data or output buffer space.
> For Get(), if it always appends, this is fine.  For Put(), it's
> unspecified what happens with the leftovers.  I'm not certain you can
> simply keep calling inflate() or deflate() when the output buffer
> space is full and expect all input data to be consumed.

This is Tcl. We can expand our buffers. But I'm not sure whether we need
the streaming engine for PNG handling; can't we just use the "uncompress
a whole chunk at once" API? (Yes, I'm very ignorant!)

> So, does consumed input get trimmed from the Tcl_Obj so it can be
> passed again directly to consume more input?  Does TIP234 buffer the
> remaining input itself, so the next Put() call adds the new data to
> what it's buffered for input?  Or does it do neither, in which case
> Put() would need to provide the caller with info on how much was
> consumed, as well as take an additional offset argument.

I'd expect it to put the whole contents of the Tcl_Obj without changing
that Tcl_Obj (assuming it's already a bytearray). But until we can get
access to the sources I can't tell. I don't know what the result of the
Put will be.

> I can work with either of these options, but buffering would be more
>  caller-friendly while offset input+count return would be most
> efficient. But it needs to be specified.

I'm tempted to say that the Get/Put methods ought to work with pointers
to arrays of unsigned chars. It still integrates with a bytearray object
easily enough, but also can work well with lower-level code.

> Nice to Have:
> 
> * It may be useful (particularly if, as I've suggested a couple times
> in the past, base64 decoding and images-as-strings are moved out of
> the GIF/PNG code into the generic photo code, turning both into
> channels and making it invisible to the format-specific handler)
> there were versions taking Tcl_Channels rather than Tcl_Objs.  But
> it's not a requirement for me.

Well, 8.6 now has native base64 handling (see [binary decode]) but apart
from that I think dealing with that stuff is a little out of scope, at
least of that TIP. (To be exact, it probably ought to be done but I
doubt there's the effort to do it in time.)

Donal.

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Will D. <wi...@wj...>]

BWidgets creates hidden widgets with "%" in their names, IIRC.

Will

On Nov 27, 2008, at 5:50 AM, Koen Danckaert wrote:

> Jeff Hobbs wrote:
>> Koen Danckaert wrote:
>>> Joe English wrote:
>>>> TIP#306: NO.
>>>>
>>>> This one does not play nicely with third-party widget sets or with
>>>> megawidget packages.  For the former, it places additional
>>>> constraints on widget constructors.  I have no idea how it will
>>>> interact with the latter, though I suspect the answer is "not very
>>>> well".
>>>
>>> The TIP describes how mega-widget packages can support the
>>> auto-naming scheme. It's really a minor effort.
>>>
>>> When the TIP was first discussed on this list, Will Duquette (the
>>> author of Snit) said he would like to see it happen.
>>>
>>> Note that the TIP doesn't break compatibility: any application that
>>> works today (which obviously doesn't use auto-naming), will continue
>>> to work in the future.
>>
>> This is so blatantly wrong with a 30 second glance at what's  
>> important
>> that anyone who voted yes deserves a right spanking.  This TIP would
>> break BWidgets, and I don't need to look any further.  The TIP  
>> blatantly
>> warns on this issue.  Stop the insanity and poor thinking - you break
>> something as basic as that, you will _not_ make a happy community.
>
> Well, the TIP will obviously not be accepted anymore, but the above  
> message is so insulting that I feel obliged to respond.
>
> The TIP does *not* break BWidgets. True, it doesn't support auto- 
> naming for BWidgets, but it does not break anything either (apart  
> from the fact that a single '%' sign could be too fragile - but that  
> seems not to be the problem people are talking about here). It  
> simply does not *apply* to BWidgets. People who do not understand  
> that difference, have the 'poor thinking' at their side. Heck, I  
> wrote the TIP, so I *know* what it warns about.
>
> In hindsight, maybe the TIP should have been called "Auto-naming  
> support for the core widgets", and the section about "Forward  
> compatibility" should have been titled "How mega-widgets can use it  
> too".
>
> But OK, it's too late now to turn the negative sentiments anyway. So  
> let's bury the TIP.
>
> --Koen
>
> -------------------------------------------------------------------------
> 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=/
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Koen D. <ko...@re...>]

Jeff Hobbs wrote:
> Koen Danckaert wrote:
>> Joe English wrote:
>>> TIP#306: NO.
>>>
>>> This one does not play nicely with third-party widget sets or with
>>> megawidget packages.  For the former, it places additional 
>>> constraints on widget constructors.  I have no idea how it will
>>> interact with the latter, though I suspect the answer is "not very
>>> well".
>>
>> The TIP describes how mega-widget packages can support the
>> auto-naming scheme. It's really a minor effort.
>>
>> When the TIP was first discussed on this list, Will Duquette (the
>> author of Snit) said he would like to see it happen.
>>
>> Note that the TIP doesn't break compatibility: any application that
>> works today (which obviously doesn't use auto-naming), will continue
>> to work in the future.
> 
> This is so blatantly wrong with a 30 second glance at what's important 
> that anyone who voted yes deserves a right spanking.  This TIP would 
> break BWidgets, and I don't need to look any further.  The TIP blatantly 
> warns on this issue.  Stop the insanity and poor thinking - you break 
> something as basic as that, you will _not_ make a happy community.

Well, the TIP will obviously not be accepted anymore, but the above message is so insulting that I feel obliged to respond.

The TIP does *not* break BWidgets. True, it doesn't support auto-naming for BWidgets, but it does not break anything either (apart from the fact that a single '%' sign could be too fragile - but that seems not to be the problem people are talking about here). It simply does not *apply* to BWidgets. People who do not understand that difference, have the 'poor thinking' at their side. Heck, I wrote the TIP, so I *know* what it warns about.

In hindsight, maybe the TIP should have been called "Auto-naming support for the core widgets", and the section about "Forward compatibility" should have been titled "How mega-widgets can use it too".

But OK, it's too late now to turn the negative sentiments anyway. So let's bury the TIP.

--Koen

Re: [TCLCORE] CFV on small high-prio TIPs (TIP#180)

[Eric B. <eri...@fr...>]

Damon Courtney a écrit :
>> The benefit of external tagging is that any widget can be tagged  
>> (even older ones).  This is why I like how tklib tooltip works.   
>> Should we add a -tooltip to widgets, or ?
>>     
>
>      Ok, then.  So, I've already got a package that does the external  
> tagging, and it does a pretty good job of it too.  Should we just push  
> that toward tklib and then work on pushing both the tooltip and tags  
> stuff into the ::tk namespace for core inclusion?
>
>      I do sort of like the process of vetting an extension through the  
> (tk|tcl)libs before core inclusion as it not only works the kinks out  
> but gets real-world use and some feedback.
>
>      My current package adds a tag and a configure command to the root  
> namespace, but they can just easily go into ::tk or whatever.
>
> ::tk::tag add foo .e1 .e2
>
> ::tk::tag configure foo -state disabled
>
> etc...
>
>   

Hello,

I use another package which abstracts even more things:
To invoke do_something whenever file_open changes:

   appstate bind file_open do_something

To toggle state of .e1 and .e2 according to file_open and readonly:

   appstate bindstate {file_open && !readonly} .e1 .e2


Just change the variable, and the GUI is updated, like -textvariable:

  appstate set file_open 1

 ...

-- 
Eric

Re: [TCLCORE] TIP #339: Case-Insensitive Package Names (fwd)

[Andreas K. <and...@ac...>]

> > As written, [package require tk $requirement] will pass along
> > arguments "tk" and $requirement (if any) to the [package unknown]
> > handler.  The contract is that the [package unknown] handler should
> > find packages that match what it was told to look for.  If it wants,
> > it can look for other things too and the default one does, but that
> > has not been required.
> 
> Yes. And a big thank you for reminding me of this, as I am currently
> not adressing this in the TIP at all, and will have to.

The TIP has been updated for this.
 
> > So, either we would need to change the contract so that [package
> > unknown] handlers are expected to search for matching packages of
> > all cases variations, causing some existing [package unknown]
> > handlers to become "broken" according to the new standard,
> 
> I believe I am prefering this over the proposal below.

And a reference implementation can be found on SourceForge, at

	http://sourceforge.net/support/tracker.php?aid=2316115

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122
 

Re: [TCLCORE] TIP#234 Status

[Donal K. F. <don...@ma...>]

Twylite wrote:
> You're the one who said he wouldn't accept the [try] proposal hammered 
> out by the community ;p

You mean the one where you don't listen to the voices in the community
saying to keep it simple?

> fwiw I am working on it (please give me some feedback on the last 
> DKF-friendly version), and do hope to have something, soon.

Any vote has to be started by the end of this week (given that this is a
fairly large new feature) in order that we can get the vote through
before the deadline. Well, by start-of-business on Monday. I don't think
it is worth delaying 8.6b1 for [try], even for one that is all I dream
of. :-)

Donal.

Re: [TCLCORE] TIP#234 Status

[Twylite <tw...@cr...>]

Hi,
> You mean to say that out of all the high-importance TIPs I identified,
> the Tcl community is unable to bring even *one* of them to a fit state?!
> First there was the "let's support every kind of network ever invented"
> contribution to the one on IPv6. Then we have the blasted [try] debacle.
> TIP#180 just isn't going to be ready. Now we're going to slip up on
> zlib/png support as well?
>   
You're the one who said he wouldn't accept the [try] proposal hammered 
out by the community ;p

fwiw I am working on it (please give me some feedback on the last 
DKF-friendly version), and do hope to have something, soon.

Twylite

Re: [TCLCORE] TIP#234 Status

[Michael K. <mi...@mu...>]

On Wed, 26 Nov 2008, Donal K. Fellows wrote:

> [Michael, please note that I'm not ranting at you specifically. But I'm
> very very cross...]

Aw, well I've been committed to TkPNG being good enough for a long time, 
but it's been out of my hands. :)

> What's missing from the zlib API? If I know what to add/change, I can
> fix the TIP today and we go to the vote.

Clerical:

* Jeff and Pascal both indicated they prefer Tcl_Zlib as a prefix (with 
unnamed others preferring Zlib_).  [I don't care, but Tcl_Zlib makes more 
sense to me.  Maybe you can put that to vote.]

* 'compresseddata' in the Arguments section is not used anywhere and 
should be removed.  'data' should be changed to in/out, or (maybe better) 
change Put() to 'srcPtr' and Get() to 'dstPtr', and replace 'data' in 
Arguments with these.

* I think the last time I read the TIP I was confused about Put/Get 
thinking one was for compression and the other decompression, because one 
inflate() or deflate() call both feeds data in and gets data out, when 
using zlib directly.  If that's how Get/Put are intended to be used, it 
should be clarified.

* Jeff mentioned in the previous thread something about consistency 
between "-limit" and "-count" at the Tcl level and about multiple 
compression method pairs versus one pair with options that don't look to 
have been addressed.  But I only bring them up because I was skimming the 
thread and looking at what was changed since, not because I have an 
opinion.  I'll just defer to Jeff et. al. regarding this stuff.  You can 
look to the tcl-core archives for Oct 23-25 '08 for the thread in 
question.

* I'm puzzled by the stream handle being an integer.  I'd think it'd be an 
opaque pointer, but maybe this is just an implementation issue and the int 
is actually a hash table key.  In any case, may be better as a typedef. 
(Only came up because I was wondering how to determine bytes consumed by 
Put(), and checking if TIP234 exposed the real zlib handle).

Underspecified:

* inflate() and deflate() may both return an error result.  It's 
unspecified whether Zlib_StreamGet()/Put() are intended to return an error 
result (in which case, they should take an interp argument and handle 
error messages) or number of bytes read/written.

* Get() should indicate that data is appended to the Tcl_Obj, or else take 
a starting offset.  In the previous discussions, Pascal indicated he was 
leaning toward the former, and I can probably work with that (resetting 
Tcl_Obj length to 0 doesn't free memory, right?  If so, it'd be a big 
performance hit to TkPNG; if not, should be fine).

* A single call to inflate() or deflate() may, but will not necessarily, 
consume all provided input data or output buffer space.  For Get(), if it 
always appends, this is fine.  For Put(), it's unspecified what happens 
with the leftovers.  I'm not certain you can simply keep calling inflate() 
or deflate() when the output buffer space is full and expect all input 
data to be consumed.

So, does consumed input get trimmed from the Tcl_Obj so it can be passed 
again directly to consume more input?  Does TIP234 buffer the remaining 
input itself, so the next Put() call adds the new data to what it's 
buffered for input?  Or does it do neither, in which case Put() would need 
to provide the caller with info on how much was consumed, as well as take 
an additional offset argument.

I can work with either of these options, but buffering would be more 
caller-friendly while offset input+count return would be most efficient. 
But it needs to be specified.

Nice to Have:

* It may be useful (particularly if, as I've suggested a couple times in 
the past, base64 decoding and images-as-strings are moved out of the 
GIF/PNG code into the generic photo code, turning both into channels and 
making it invisible to the format-specific handler) there were versions 
taking Tcl_Channels rather than Tcl_Objs.  But it's not a requirement for 
me.

If the underspecified things are specified, then I think I can make TkPNG 
work with it with minimal re-engineering.  Currently, I can't tell enough 
from the TIP how it's used from C to say.

--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/

Re: [TCLCORE] TIP#234 Status

[Donal K. F. <don...@ma...>]

Michael Kirkham wrote:
> I'd say no.  Doesn't look like anything's changed in the TIP with regards 
> to the C API since I'd last commented.

[Michael, please note that I'm not ranting at you specifically. But I'm
very very cross...]

You mean to say that out of all the high-importance TIPs I identified,
the Tcl community is unable to bring even *one* of them to a fit state?!
First there was the "let's support every kind of network ever invented"
contribution to the one on IPv6. Then we have the blasted [try] debacle.
TIP#180 just isn't going to be ready. Now we're going to slip up on
zlib/png support as well?

I can understand why a few things might slip, but I'm deeply
disappointed that so much is getting messed up by people failing to
*commit* to getting something good enough done!

[rant over]

What's missing from the zlib API? If I know what to add/change, I can
fix the TIP today and we go to the vote.

Donal.

Re: [TCLCORE] TIP#234 Status

[Michael K. <mi...@mu...>]

On Wed, 26 Nov 2008, Donal K. Fellows wrote:

> Date: Wed, 26 Nov 2008 16:22:11 +0000
> From: Donal K. Fellows <don...@ma...>
> To: Michael Kirkham <mi...@mu...>
> Cc: Adrian Robert <adr...@gm...>,
>     Tcl Core List <tcl...@li...>
> Subject: Re: [TCLCORE] TIP#234 Status
> 
> Michael Kirkham wrote:
>> Unfortunately, Pascal's site is inaccessible currently and I don't have a 
>> copy (recent or otherwise) of the 234 reference implementation.  So if 
>> someone has recent sources they can send them to me, or ping me when 
>> Pascal's site is back up, and I'll try to take a look.  I'm not certain 
>> what the 8.6 deadline is, though.
>
> Deadline for the *specification* is really soon (Dec. 10 IIRC, which
> means it's really got to go to a vote this week) but deadline for the
> implementation could be put off slightly (we want 8.6.0 to ship in the
> spring). The main thing I want a check on is whether what is in the TIP
> is Good Enough; I don't know enough about png loaders to be sure. :-)

I'd say no.  Doesn't look like anything's changed in the TIP with regards 
to the C API since I'd last commented.

--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/

Re: [TCLCORE] TIP#234 Status

[Donal K. F. <don...@ma...>]

Michael Kirkham wrote:
> Unfortunately, Pascal's site is inaccessible currently and I don't have a 
> copy (recent or otherwise) of the 234 reference implementation.  So if 
> someone has recent sources they can send them to me, or ping me when 
> Pascal's site is back up, and I'll try to take a look.  I'm not certain 
> what the 8.6 deadline is, though.

Deadline for the *specification* is really soon (Dec. 10 IIRC, which
means it's really got to go to a vote this week) but deadline for the
implementation could be put off slightly (we want 8.6.0 to ship in the
spring). The main thing I want a check on is whether what is in the TIP
is Good Enough; I don't know enough about png loaders to be sure. :-)

Donal.

Re: [TCLCORE] TIP#234 Status

[Michael K. <mi...@mu...>]

On Wed, 26 Nov 2008, Adrian Robert wrote:

> Date: Wed, 26 Nov 2008 10:28:12 -0500
> From: Adrian Robert <adr...@gm...>
> To: Tcl Core List <tcl...@li...>
> Subject: Re: [TCLCORE] TIP#234 Status
>
> On Nov 26, 2008, at 7:35 AM, Torsten Berg wrote:
>
>> I really, really would like to see 234 and 244 in Tcl 8.6 finally.
>
> I share in this hope.  I've used tkpng on Mac and Windows for some
> time and find it useful (indispensable, actually) and stable.

FWIW, the majority of the work required for 244 (png) to be ready is in 
234 (zlib), provided the C API is pretty close to using the zlib API 
directly, only stubbed.  Last this came up a month or two ago it wasn't 
fully defined, but Pascal was open to whatever's needed for TkPNG.  I 
didn't bother to look into it because, well, lets just say I'm focused on 
the economy like everyone else.  But I suppose if it's going to get done 
I'll have to volunteer to pick it up.

Unfortunately, Pascal's site is inaccessible currently and I don't have a 
copy (recent or otherwise) of the 234 reference implementation.  So if 
someone has recent sources they can send them to me, or ping me when 
Pascal's site is back up, and I'll try to take a look.  I'm not certain 
what the 8.6 deadline is, though.

--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/

Re: [TCLCORE] TIP#234 Status

[Donal K. F. <don...@ma...>]

Torsten Berg wrote:
> I really, really would like to see 234 and 244 in Tcl 8.6 finally. I  
> have been using the reference implementations for a longer period now  
> and they work for me (on MacOS X and Linux). Just one thing. It has  
> been said before, that handling of zip files like reading entries or  
> writing them is a simpe task of some Tcl scripting. It would be nice  
> if such a tcl script/wrapper could be included in the distribution. I  
> don't have it myself but always felt it was missing.

I'd look for that in tcllib once the core has the compression engine.

Donal.

Re: [TCLCORE] TIP#234 Status

[Adrian R. <adr...@gm...>]

On Nov 26, 2008, at 7:35 AM, Torsten Berg wrote:

>> Is TIP#234 ready to roll (and the implementation acceptably close)?  
>> It
>> doesn't look far off it to me, but I'm not close enough to the
>> detail to
>> be sure.
>>
>> The primary remaining question is whether the C API is sufficient for
>> implementing a PNG reader on top of it in short order. My guess is
>> that
>> it is (i.e. we can also do TIP#244) but it'd be nice to have a  
>> reality
>> check. :-)
>
> I really, really would like to see 234 and 244 in Tcl 8.6 finally.

I share in this hope.  I've used tkpng on Mac and Windows for some  
time and find it useful (indispensable, actually) and stable.

Re: [TCLCORE] TIP Roundup

[Harald O. <Har...@El...>]

Donal K. Fellows wrote:

> Medium Priority and in search of a champion
> ———————————————————————————————————————————
>    TIP #106	Add Encoding Abilities to the [dde] Command

I have written this TIP in 2002.
If DDE will not be dropped from the core soon I may care about an
implementation of the TIP.
IMHO this will not be ready for 8.6.

Harald

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Colin M. <co...@ch...>]

Magentus wrote:
> - And for cleaning up those messes of switch and other statements
> presently needed to support all kinds of error and result handling.
> If done right, it'll be fast and efficient for the simple case.  And
> a heck of a lot easier to read and work with in the complex case.
>
> Especially when it's so damn simple trivial to do so much better.
>   
I don't see 'trivial', and I don't see 'better', in what's been proposed 
here at various times.

I presume you're talking about [switch] being messy when it's used to 
decode error conditions.  I see nothing messy about [switch]ing on 
conditions to discriminate different cases of error and take appropriate 
actions.  Error conditions aren't somehow special, they're just more 
data to be processed, and if [switch] isn't an appropriate way to 
represent discrimination between cases, then that's a problem with 
[switch] which should be analysed.  I see no problem with [switch], and 
I've seen no reports of any discomfort with [switch] in the role of case 
discriminator.

The proposals I've seen would not be 'easier to read or work with', they 
obfuscate the processing required to properly handle errors by wrapping 
it in a gigantic command with so many options and internal argument 
syntax it may as well be another language.  I can't name another such 
complex command in tcl core.

About the only valid complaint I've seen about [catch] which doesn't 
rely upon the questionable premise of error data being somehow 
privileged is that it requires the use of temporary variables.  I think 
this would be handled by a variant of [catch] which returned a dict 
whose values could then feed a [switch].  You can use string 
concatenation to test for error code, combine that with whatever you 
want to handle the error data returned in dict form.

Arguments that error processing is complex and that it therefore 
requires a special kind of processing are specious.  Any argument you 
can make that an error dict requires special processing should properly 
apply to absolutely any dict - the fact that the dict happened to be 
derived from an exception is immaterial.  If someone made an argument 
that there needs to be a special tcl core command to handle (for 
example) processing a database record qua dict because 'handling 
database records is hard, and there's some messy code out there to do 
it' I doubt it'd even get to TIP.

Colin.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Magentus <mag...@gm...>]

On Tue, 25 Nov 2008 17:56:54 +0200, 
Twylite <tw...@cr...> wrote:

> Sadly it will be some time before I can gain value from this function 
> myself. Not until the third-party libraries I am tied to - which
> require me to parse the (non-localised) result - are updated to
> produce an errorcode. Not until I find enough time on or between
> projects to refactor legacy code (core libraries that I depend on and
> use in pretty much all new utilities and applications) to use
> errorcode rather than (or, for backwards compatibility, in addition
> to) a list structure in the result. Not in places where I need to
> maintain code that allocates & frees more than 2 resources, which can
> be done cleanly using finally callbacks, but otherwise sends you to
> the depths of nested try/finally blocks and you can't see the wood for
> the error-and-cleanup-handling trees.

THIS is the part I've been trying to deal with.

- Support for all current return values, not just one limited view of
reality, so that it's useful NOW, not some time in an unknown future
that may or may not happen.  (That's what happened to errorcode, it was
created before the mechanisms existed to make good use of it, and
it's floundered in obscurity ever since.)

- And for cleaning up those messes of switch and other statements
presently needed to support all kinds of error and result handling.
If done right, it'll be fast and efficient for the simple case.  And
a heck of a lot easier to read and work with in the complex case.

Especially when it's so damn simple trivial to do so much better.


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 49 days,  6:43)

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Magentus <mag...@gm...>]

On Tue, 25 Nov 2008 20:23:35 +0000, 
"Donal K. Fellows" <don...@ma...> wrote:

> Andreas Leitgeb wrote:
>> Even  {CHILDKILLED * SIGSEGV *} may have its use. The errorCodes
>> thrown from core appear to have been carefully crafted to be
>> reasonably glob-able.  At this point in time, glob appears like
>> the perfect hammer for the nail, but nails are likely going to
>> change when programmers get more into the habit of creating new
>> errorCodes for their applications, and introducing ambiguities,
>> that could have been avoided by list patterns in the first place.
> So... you're rejecting an admittedly perfect solution for a much more
> complex one because of a possible theoretical problem in the future?
> Words fail me.

I don't think it's been admitted to be perfect.  I believe one of the
the key phrases was "reasonably glob-able", and the other key concept
was that just because it ALMOST fits the present carefully crafted
nails, doesn't mean it will fit the less carefully crafted nails that
will start to appear once the idea of using errorcodes catches on.

Glob on a list is flawed.  It's as simple as that.  And it astounds me
that you can defend the idea of matching a list with at least one piece
of arbitrary text, with glob matching that has no regard for word
boundaries.


Andreas Leitgeb:
> Anyway, all my arguments have been said. Seems like I just failed to
> prevent what I consider a bad thing from happening to Tcl. Alas. <EOD>

While sometimes I go off on a tangent that even I don't expect to be
followed on, and I freely admit that, a good useful implementation of
this will be immediately practical and useful.  We're ALL doing the
kinds of things this command is designed to make easier.  We ALL want
to see good error handling.  We ALL want to be able to get rid of those
annoying and hard to follow if..elseif and catch+switch blocks.  And
[try] has the opportunity to do that in a clean way.

But the way it's being dumbed down to mere triviality, I can't agree
more on this particular sentiment.


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 49 days,  7:01)

Re: [TCLCORE] TIP#234 Status

[Torsten B. <re...@ma...>]

> Is TIP#234 ready to roll (and the implementation acceptably close)? It
> doesn't look far off it to me, but I'm not close enough to the  
> detail to
> be sure.
>
> The primary remaining question is whether the C API is sufficient for
> implementing a PNG reader on top of it in short order. My guess is  
> that
> it is (i.e. we can also do TIP#244) but it'd be nice to have a reality
> check. :-)

I really, really would like to see 234 and 244 in Tcl 8.6 finally. I  
have been using the reference implementations for a longer period now  
and they work for me (on MacOS X and Linux). Just one thing. It has  
been said before, that handling of zip files like reading entries or  
writing them is a simpe task of some Tcl scripting. It would be nice  
if such a tcl script/wrapper could be included in the distribution. I  
don't have it myself but always felt it was missing.

The opinion of a user,

Torsten

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Donal K. F. <don...@ma...>]

Jeff Hobbs wrote:
> Shall I take the opportunity to push TIP#180 again?  ;)

Thinking about it, I suspect that what we get out of #180 isn't going to
be in 8.6 as we just haven't got the time to finish cooking it before
beta. On the other hand we should push on and get it into tklib (well,
assuming we can now do it in pure Tcl). Like that it can get the public
exposure it needs to get its feature set finalized, and we can see what
*actually* is too slow for Tcl...

It's a shame, as I'd identified #180 as important. Ho hum.

Donal.

Re: [TCLCORE] CFV on small high-prio TIPs (TIP#180)

[Damon C. <da...@tc...>]

> The benefit of external tagging is that any widget can be tagged  
> (even older ones).  This is why I like how tklib tooltip works.   
> Should we add a -tooltip to widgets, or ?

     Ok, then.  So, I've already got a package that does the external  
tagging, and it does a pretty good job of it too.  Should we just push  
that toward tklib and then work on pushing both the tooltip and tags  
stuff into the ::tk namespace for core inclusion?

     I do sort of like the process of vetting an extension through the  
(tk|tcl)libs before core inclusion as it not only works the kinks out  
but gets real-world use and some feedback.

     My current package adds a tag and a configure command to the root  
namespace, but they can just easily go into ::tk or whatever.

::tk::tag add foo .e1 .e2

::tk::tag configure foo -state disabled

etc...

D

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Michael K. <mi...@mu...>]

On the auto-naming of widgets, I've long felt that it's a bit silly we 
have to name them ourselves at all.  I don't care what the widget names 
are, only that I know what they are so I can interact with them.  If I'm 
caring what the actual name is, it probably means I've hardcoded it in 
several places, which is going to make it a hassle to modify the code 
later to restructure/extend the GUI.

I'd prefer to let the parent in the hierarchy do the naming.  Perhaps this 
would largely be a matter just of convention, or perhaps there would be a 
wrapper around Tcl_CreateObjCommand to create widget commands that handle 
this automatically, but I would suggest:

1. A widget creation command (e.g. "frame"), when given no arguments or 
the first argument doesn't start with ".", gets a fully automatic name 
assignment that's a child of "." (or a child of nothing if a toplevel).

e.g.,

set top [toplevel]    ;# -> .toplevel1
set frame [frame]     ;# -> .frame1
set frame [frame]     ;# -> .frame2
set frame [frame .f]  ;# -> .f

2. The parent should be capable of creating widgets and assigning names to 
them in its hierarchy itself.  Maybe this would be done with a subcommand 
specified to that Tcl_CreateObjCommand wrapper 
(Tk_CreateWindowObjCommand?), or maybe something like "." as a subcommand 
is suitably unique and (pardon the pun) on point:

set top [toplevel]           ;# -> .toplevel1
set frame [$top . frame]     ;# -> .toplevel1.frame1
set button [$frame . button] ;# -> .toplevel1.frame1.button1

The wrapper would see that "." is the first argument and treat the second 
argument as a widget creation command (no matter what it is), inserting a 
unique name as its first argument (or, I guess, treat the first two as 
ensembles).

3. Maybe, for cases where you actually do care what the name is, extend 
(1) and (2) a little bit such that if the first argument doesn't start 
with "-" and doesn't contain any dots, then it's a parent-relative name:

set bob [frame bob]         ;# -> .bob
set top [toplevel]          ;# -> .toplevel1
set bob [$top . frame bob]  ;# -> .toplevel1.bob
set ok [$bob . button ok]   ;# -> .toplevel1.bob.ok

--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Will D. <wi...@wj...>]

On Nov 25, 2008, at 12:22 PM, Jeff Hobbs wrote:

> Koen Danckaert wrote:
>> Joe English wrote:
>>> TIP#306: NO.
>>>
>>> This one does not play nicely with third-party widget sets or with
>>> megawidget packages.  For the former, it places additional
>>> constraints on widget constructors.  I have no idea how it will
>>> interact with the latter, though I suspect the answer is "not very
>>> well".
>>
>> When the TIP was first discussed on this list, Will Duquette (the
>> author of Snit) said he would like to see it happen.

I vaguely recall that; and Snit does indeed support autonaming of
widgets using the %AUTO% syntax, e.g., [label $win.%AUTO%].  I
don't recall ever looking at the syntax shown in the TIP, though;
and using a single "%" character as the string to be replaced
strikes me as asking for trouble.

Will

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] CFV on small high-prio TIPs (TIP#180)

[Jeff H. <je...@ac...>]

Damon Courtney wrote:
>> Skip -alias, consider -tags (would any known widget conflict at the  
>> widget creation level?).
>>
>> button .b -tags toolbar
>> button .c -tags {toolbar edge}
>> configure toolbar -state disabled
>> ...
>>
>> I simulate this at the higher level now.  It may be asking too much  
>> for 8.6, but possibly worth considering.
> 
>      Yes.  My brain was moving too fast when I posted, but this is  
> exactly what I recommend.  In fact, I use a system I wrote called  
> Tktags that does just this sort of thing.  In fact, it does exactly  
> what you describe here except for the fact that you have to tag the  
> widgets yourself since they don't support a -tags option.

The benefit of external tagging is that any widget can be tagged (even 
older ones).  This is why I like how tklib tooltip works.  Should we add 
a -tooltip to widgets, or ?

Jeff

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Damon C. <da...@tc...>]

> Skip -alias, consider -tags (would any known widget conflict at the  
> widget creation level?).
>
> button .b -tags toolbar
> button .c -tags {toolbar edge}
> configure toolbar -state disabled
> ...
>
> I simulate this at the higher level now.  It may be asking too much  
> for 8.6, but possibly worth considering.

     Yes.  My brain was moving too fast when I posted, but this is  
exactly what I recommend.  In fact, I use a system I wrote called  
Tktags that does just this sort of thing.  In fact, it does exactly  
what you describe here except for the fact that you have to tag the  
widgets yourself since they don't support a -tags option.

Damon