tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: CFV TIP #340

[Jan N. <jan...@gm...>]

2008/11/27 Jan Nijtmans <jan...@gm...>:
> I will create a new patch this weekend.

The revised patch is available now, at:
<https://sourceforge.net/tracker/index.php?func=detail&aid=2315890&group_id=10894&atid=310894>

The CFV is open for voting again.
My vote follows:
   revised TIP #340: YES

The TIP text is not updated yet, but I hope that will happen soon. From
the previous mails, it should be clear what's the point.

One remark about the patch: The compatibility macro in the
TCL_NO_DEPRECATED section was put there to allow Tcl
and Tk to compile without warnings for now. I'm not sure it
is a good idea to keep it there, but that's an implementation
detail so it can be decided later. It is not meant as an excuse
not to replace the remaining Tcl_SetResult calls in the core.

I am a beleaver in the "eat your own dogfood" principle: If
we deprecate a function, it should be removed from the
core (except from the implementation and a legacy
test case!). I'm still planning to do that, but it would be
too big to put in the patch.

Regards,
            Jan Nijtmans

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Alexandre F. <ale...@gm...>]

Hello,

On Mon, Nov 24, 2008 at 2:19 AM, Alexandre Ferrieux
<ale...@gm...> wrote:
>
> Just uploaded a patch to
> https://sourceforge.net/tracker/index.php?func=detail&aid=1813597&group_id=12997&atid=112997
> Please review.

Just to let you know, in the absence of objections, and following
Donal's advice, I committed the patch to HEAD:

	* generic/tkCanvUtil.c	Millimeter patch. Fixes [1813597,2218964]
	* generic/tkInt.h	        by eliminating the functional redundancy
	* generic/tkObj.c       and unnecessary loss of precision of the
	* generic/tkText.c      {pixel,mm}ObjType tandem.

So, millimeters as an objtype can start decaying. Will be gone in 1e31
years, like protons.

Help appreciated for backports.

-Alex

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

[Pat T. <pat...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Nijtmans wrote:
> 2008/11/27 Jan Nijtmans <jan...@gm...>:
>> I will create a new patch this weekend, so the vote
>> can go on. But then, monday is a little short.
>> So, I would like to delay the vote until:
>>
>>    Monday dec 1st, 12:00 GMT (i.e. [clock format 1228478400]).
> 
> This clock format does not match the specified date. Of
> course I meant:
> 
>     Friday dec 5th, 12:00 GMT (i.e. [clock format 1228478400]).
> 
> Regards,
>         Jan Nijtmans

This kind of error seems to crop up regularly. How about everyone stops
being clever and just writes in the date so that people can just read
it. Use of seconds to describe a date in messages designed to be read by
humans is dumb.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSS8vMWB90JXwhOSJAQIVDQP/TMsMDZ6tEwCyIB2UiG+Mh4bOQfChgi9E
b2y4JXwv1k/usDgNLPObP+vegs6osLdnpIzWdFUyx1hzdJLVRhuiYUBdSZ9S1KeZ
F5+nxFBiNBzStaWe+VztPi113ivht6MUUYc6TEKWCuG0tRO9wAu4/mLM7Oh2cIpk
E1KF6wSa6+4=
=xgJQ
-----END PGP SIGNATURE-----

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

[Jan N. <nij...@us...>]

2008/11/27 Jan Nijtmans <jan...@gm...>:
> I will create a new patch this weekend, so the vote
> can go on. But then, monday is a little short.
> So, I would like to delay the vote until:
>
>    Monday dec 1st, 12:00 GMT (i.e. [clock format 1228478400]).

This clock format does not match the specified date. Of
course I meant:

    Friday dec 5th, 12:00 GMT (i.e. [clock format 1228478400]).

Regards,
        Jan Nijtmans

Re: [TCLCORE] a meta-TIP for "NOT YET"-votes ?

[Lars H. <Lar...@re...>]

Andreas Leitgeb skrev:
> Kevin Kenny <ke...@ac...> wrote:
>> Since we don't have a NOT YET vote, ...
> 
> I think, I read a line like this about every other CFV.
> 
> What would it take to add a "NOT YET" officially, to
> remove the need for this phrase?  just curious :-)

Another thing that could similarly do with a revision is the 
interpretation of "two thirds" in the "Two YESes And No NOs Or Two 
Thirds" rule. According to the interpretation used on at least one vote 
(TIP accepted with 4 YES, 2 NO, and 2 PRESENT if memory serves), those 
two thirds refer to YESes among YESes and NOs, which implies a PRESENT 
is the same as "not present". This could be what the voters expected, 
but I rather suspect it wasn't.

Lars Hellström

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

[Joe E. <jen...@fl...>]

Jan Nijtmans wrote:
>
> [ Revised specification for TIP#340, of which I approve ]

Just a few notes:

> It will still be a lot of
> work to check all Tcl_SetResult() calls, because
> a simple change to Tcl_SetStringResult() is not
> always the best solution. (I hope that Joe will
> help me with this.....)

To clarify: this is not a mechanical change, but
the whole point of enabling additional compiler warnings --
to improve the code -- involves a certain degree of code
review in the first place.

Tcl_SetResult(interp, s, TCL_STATIC|TCL_VOLATILE);
can generally be shortened to Tcl_SetStringResult(interp, s);
without further thought.

In the case of Tcl_SetResult(interp, (char*)s, TCL_STATIC|TCL_VOLATILE);
where "s" is a const char *, you can also remove the cast-away-const cast.

Calls that use TCL_DYNAMIC or a general freeProc need to be
examined on a case-by-case basis.

Also: this is not a forced change; it requires no changes
to extensions or (strictly speaking) even to the core itself.
The idea is to provide a convenient, const-correct alternative
to Tcl_SetResult() for the benefit of code that wishes to become
const- and -Wwrite-strings safe.


> The disadvantage is that it might break extensions
> compiled against Tcl 8.6 which still use interp->result,
> but since TIP #330 is accepted, who cares!

To clarify: such extensions are already broken and
have been in danger of the brokenness being exposed
at any time anyway.  Extensions that look directly
at interp->result may be affected simply because there
will be even fewer places in the core that set interp->result;
this sort of thing has been going on since Tcl 8.0,
so there's nothing new here.


--Joe English

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

[Joe E. <jen...@fl...>]

Koen Danckaert wrote:

> I can understand that people prefer a solution that works for all existing wi
> dgets at once, but that will be difficult.

	variable % 0
	proc % {} {
	    global %
	    return "autonamed[incr %]"
	}

Then you can write:

	set l [label .f.[%]]

Works for any widget class.


> For example, if TIP180 is done, BWidget will also
> have to be adapted to make use of it.

Why?  That might be a good test case for TIP#180,
but I don't see that it's mandatory.


--Joe English

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

[Kevin K. <ke...@ac...>]

Jan Nijtmans wrote:
> Understandably (is that good english?...) there were no
> other votes on this, and after Joe's response Joe and I
> have been working to resolve our 'conflict'. Therefore I
> decided to modify the TIP along the following lines.
> 
> - The Tcl_SetResult signature will not change, but this
>   function will be deprecated in full. It will be replaced
>   by a macro:
>       #define Tcl_SetStringResult(interp, s) \
>       Tcl_SetObjResult(interp, Tcl_NewStringObj(s, -1))

This is nice.

I don't think there's any controversy that
we want to kill Tcl_SetResult -- eventually. It isn't const-
correct, and can't be made const-correct. But, aside from
spewing compiler warnings, it's Mostly Harmless. The chief
reason for wanting to kill it is that it's all tied up in
the manipulations of interp->result, and we have to wait at
least another release cycle before we can put paid to them.

Unfortunately, there is a lot of Tcl_SetResult out there,
chiefly because it was a good deal less typing than
Tcl_SetObjResult(interp, Tcl_NewStringObj(..., -1).
Tcl_SetStringResult would be a cleaner alternative.

--
73 de ke9tv/2, Kevin

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

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

On Nov 27, 2008, at 7:30 AM, Koen Danckaert wrote:

> Will Duquette wrote:
>> BWidgets create hidden widgets with "%" in their names, IIRC.
>
> No, they use a "#" (not at the last position of their name), just  
> like menus do.
>
> I've been using TIP306 in applications, together with BWidgets, for  
> 1.5 years already... (of course without auto-naming the BWidgets,  
> that simply does not work yet.)
>
> FWIW, I had a quick glance at the BWidget source code. I adapted  
> some of the widgets to be able to use auto-naming, in just 5  
> minutes. I think it would not take more than 20 minutes to adapt all  
> of them.
>
> I can understand that people prefer a solution that works for all  
> existing widgets at once, but that will be difficult. For example,  
> if TIP180 is done, BWidget will also have to be adapted to make use  
> of it.


OK.  I stand corrected. :-)


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

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

[Jan N. <jan...@gm...>]

2008/11/23 Joe English <jen...@fl...>:
>
> Jan Nijtmans wrote:
>> This is a Call For Votes on TIP #340.
>>
>>  TIP #340: CONST Qualification of Tcl_SetResult's argument and -Wwrite-string
>
> TIP#340: NO.
>
> I support the goals of this TIP, but not the specific
> proposed refactoring.  It leaves Tcl_SetResult() in a
> broken state: with an incorrect const qualifier on the
> second argument and a worthless vestigial third argument.

Understandably (is that good english?...) there were no
other votes on this, and after Joe's response Joe and I
have been working to resolve our 'conflict'. Therefore I
decided to modify the TIP along the following lines.

- The Tcl_SetResult signature will not change, but this
  function will be deprecated in full. It will be replaced
  by a macro:
      #define Tcl_SetStringResult(interp, s) \
      Tcl_SetObjResult(interp, Tcl_NewStringObj(s, -1))

This allows to modify almost all Tcl_SetResult() calls
in the core to Tcl_SetStringResult(), except for the
ones in tclResult.c and tclTest.c. All tests pass,
and all extensions compiled against Tcl 8.5 still
run unmodified with Tcl 8.6. It will still be a lot of
work to check all Tcl_SetResult() calls, because
a simple change to Tcl_SetStringResult() is not
always the best solution. (I hope that Joe will
help me with this.....)

The disadvantage is that it might break extensions
compiled against Tcl 8.6 which still use interp->result,
but since TIP #330 is accepted, who cares!

I will create a new patch this weekend, so the vote
can go on. But then, monday is a little short.
So, I would like to delay the vote until:

    Monday dec 1st, 12:00 GMT (i.e. [clock format 1228478400]).

Regards,
       Jan Nijtmans

Re: [TCLCORE] TIP#234 Status

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

On Thu, 27 Nov 2008, Michael Kirkham wrote:

> On Thu, 27 Nov 2008, Michael Kirkham wrote:
>
>> Of course, anything other than giving an offset to Put() and getting back a
>> count of bytes consumed will add memcpy overhead to decoding PNG images that
>> doesn't exist now.
>
> Actually, there's going to be memcpy overhead using using split Put/Get
> functions anyway, since there's no guarantee that caller data will still
> be valid between calls to Put() and Get().  So Put() will have to copy all
> of the provided data, then wait for the call to Get() before invoking
> zlib.

Not to belabor the point, and sorry for repeatedly replying to myself, but 
perhaps (for this reason) Put() and Get() really ought to be combined into 
one IO() call.

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

Re: [TCLCORE] TIP#234 Status

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

On Thu, 27 Nov 2008, Michael Kirkham wrote:

> Of course, anything other than giving an offset to Put() and getting back a 
> count of bytes consumed will add memcpy overhead to decoding PNG images that 
> doesn't exist now.

Actually, there's going to be memcpy overhead using using split Put/Get 
functions anyway, since there's no guarantee that caller data will still 
be valid between calls to Put() and Get().  So Put() will have to copy all 
of the provided data, then wait for the call to Get() before invoking 
zlib.

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

Re: [TCLCORE] TIP#234 Status

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

On Thu, 27 Nov 2008, Donal K. Fellows wrote:

>> * 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.

Oops, looks like I was deleted a sentence in what I sent due to 
reformatting.  I meant to say that on the latest reading I came to the 
same conclusion as you (feed data in with Put, get data out with Get, 
regardless of whether you're inflating or deflating), and "If that's 
how...".

>> * 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.

Not sure if you mean "expand" as in "lengthen" or as in "add another 
buffer".  Just to be clear, the issue isn't with buffer length.  The issue 
is I could feed Put() 1K bytes and its call to in/deflate() could consume 
only 512 bytes, for example.  I need to know what happens with that other 
512 bytes.  Maybe Put() holds onto them for the next call to Put() and, as 
a caller, as far as I can tell the whole 1K was consumed.  Or maybe it 
doesn't, in which case I need to know to re-feed the remaining 512 bytes.

Of course, anything other than giving an offset to Put() and getting back 
a count of bytes consumed will add memcpy overhead to decoding PNG images 
that doesn't exist now.

> 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!)

I talked about this before, but it's a matter of mainly of memory usage 
and maybe a bit of efficiency, both of which will affect its usefulness 
for large PNG images (i.e., not icons), as well as simplicity.

1. By feeding data into zlib in chunks, only a fixed amount of memory 
(currently #defined to 1K) of the file needs to be in memory at a time. 
If you instead feed the whole file at once, you've got load the whole file 
into memory at once: ~1X image size of memory usage, versus 1 Kb.

2. By reading data out of zlib in chunks, only a fraction of the 
uncompressed data needs to be held in limbo between "PNG format" and "Tk 
internal image format".  If instead you read the whole uncompressed image 
out at once, you've got to hold enough memory for essentially two copies 
of the whole image: another ~2X image size of memory usage, versus 1X plus 
a small fraction (noted below, ~2X the size of one *line* of the image).

3. Each PNG image line specifies a filter, which is an algorithmic 
combination of that line's bytes and the line above, which affects the 
image's compressability (and here a "line" is only certain pixels in an 
interlaced image).  By reading, filtering, and converting (to Tk format) 
one line at a time, I can simply have two line buffers that are swapped 
each time a line is processed.

It's simpler algorithmically to swap buffers than deal with line-start 
offsets having to do with image dimensions, color depth, and interlacing 
(at least on the Tk image block side, only dimensions matter).  If I 
wanted to keep that simplicity despite reading the whole uncompressed data 
at once, I'd have to resort to extra copying (which would impact 
efficiency).

4. I could envision a time in the far-off future when Tk supports 
asynchronous image decoding so you can get that "partially visible as it's 
downloading" effect you see in some web browsers with some formats 
(particularly with interlaced images).  To do that, you have to operate on 
partial data (which means you have to use streaming).

At any rate, it's a trade off.  It would probably be more efficient to 
take the all-at-once approach, but I don't think the memory hit is worth 
it, nor closing off forever the possibility of (4).

> 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.

Either should be fine for me (as long as, if it uses Tcl_Objs rather than 
uchar ptrs, Get() appends rather than overwrites; if it overwrites 
Tcl_Objs, I have to add copying overhead).

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

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

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

Will Duquette wrote:
> BWidgets create hidden widgets with "%" in their names, IIRC.

No, they use a "#" (not at the last position of their name), just like menus do.

I've been using TIP306 in applications, together with BWidgets, for 1.5 years already... (of course without auto-naming the BWidgets, that simply does not work yet.)

FWIW, I had a quick glance at the BWidget source code. I adapted some of the widgets to be able to use auto-naming, in just 5 minutes. I think it would not take more than 20 minutes to adapt all of them.

I can understand that people prefer a solution that works for all existing widgets at once, but that will be difficult. For example, if TIP180 is done, BWidget will also have to be adapted to make use of it.

--Koen

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.