tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Finalization vs. Exit

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

Hi,

As exhibited e.g. in
https://sourceforge.net/tracker/?func=detail&aid=486399&group_id=10894&atid=110894
, the Tcl finalization sequence is a complex thing.

In this specific bug, the problem involves avoiding bad interaction of
second-class threads with the main (first-class) one during the very
last steps of teardown, when the ground starts to dissolve under
everybody's feet.
In other instances, it can be argued that we're doing way too much
"administrative" cleanup (like freeing memory) just before exiting.

Now a simple approach seems to be viable: make a clear distinction
between the [exit] path and full finalization (eg in embedded
scenarios, since Donal dislikes scenarii ;-).

The idea, then, is to make clearer in the code the dichotomy between
the exit handlers that are "administrative" (meaning they have no
effect outside the dying process) and can thus be skipped in the
[exit] case, and those that are really compulsory in all cases because
they have side-effects on the outside world, these side-effects being
part of a documented or implicit contract that we simply cannot break.
Then, for the [exit] path, just do the compulsory ones, and call the
OS's exit() function.

Question: could you help me draw this dichotomy ?

Here is what I have spotted so far:

   - process-wide exit handlers registered with Tcl_CreateExitHandler,
aka "early exit handlers" --> compulsory

   - per-thread exit handlers (freeing memory) --> skippable for [exit]

Still in the gray zone, is FinalizeIOSubsystem. I know of cases where
not calling it might have long-ranging effects (like RST sent on all
non-closed sockets), but since it deals with per-thread/interp
structures (like channel lists), it should either be entirely skipped
or done for all threads... which is problematic at exit time if some
threads are blocked or in an uncontrolled state.

Thanks in advance for any insight on this,

-Alex

Re: [TCLCORE] Question about components of Tcl/Tk8.6

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

>
> BWidgets is a real mixed bag. How a package that is so comprehensively
> documented can nonetheless be so hard to learn is a bit of a mystery  
> to
> me. And parts of it are definitely long in tooth and have been
> superseded by other, more recent widgets (panedwindow, combobox in  
> ttk,
> etc.).
>
> Still, I find parts of BWidgets indispensible, in terms of their
> flexibility and relative. I make heavy use of the Tree widget in my
> apps, and the ListBox widget is also slated for inclusion in an app or
> two I'm developing. Once I "got" how these widgets worked, I found  
> them
> to be very powerful and perfect for my needs. Last I looked, the new
> tree/table widget in ttk wasn't as flexible. Also, BWidgets'
> drag-and-drop support remains the best script-level package for this
> kind of functionality (hard to grok, but more powerful than the basic
> drag-and-drop package I developed).
>
> Of couse, if there is a better, more comprehensive megawidget  
> framework
> than BWidgets out there, I'd be glad to see it.

You and Jeff are referring to two different things, and I agree with  
both of you. 0-]

You are referring to the BWdiget API, which I believe is quite good.   
It's very easy to learn, it's consistent, and I use it throughout all  
of my projects and plan to continue to do so.

Jeff is referring to the underlying framework on which BWidgets is  
built.  This is a total freaking mess, and it's horrible to code in.   
It does some of the bare basic things for you in creating new widgets,  
but (as the developer) you're still expected to do a lot of things by- 
hand.  This is what Jeff means when he says that it is unmaintainable.

The documentation of the widgets is pretty complete, and I like the  
API quite a lot, but what you don't have to see is the spaghetti mess  
underneath the widgets that is very hard to program in.  This is not  
something we want to continue to put time and effort into.  Especially  
when there seems to be so little of it going around these days.

The plan we have going forward is to have a new framework in place  
that megawidgets can be built off of, and then my plan is to port the  
usable BWidgets over to the new framework.  In all likelihood, these  
won't be EXACTLY like their counterparts in terms of how they look,  
but they will most likely be totally API compatible.  The reason they  
won't look exactly the same is because I hope to build the Tree and  
ListBox widgets on top of tktreectrl and not on top of the canvas  
widget.

I like BWidgets.  I plan to use the API going forward.  But, I don't  
plan to spend a lot of time fixing bugs in it and supporting it.  It's  
throwing my precious little time down a black hole.

D

Re: [TCLCORE] Question about components of Tcl/Tk8.6

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

On 29/04/2009 3:34 PM, Kevin Walzer wrote:
>> Note that BWidgets is not a core candidate for exactly the question 
>> you stated above.  Instead we are looking at alternative megawidget 
>> solutions that contain much better frameworks and will be much easier 
>> to maintain for years to come.
> 
> Out of curiosity, what frameworks are these?

*secret* frameworks.

> BWidgets is a real mixed bag. How a package that is so comprehensively 
> documented can nonetheless be so hard to learn is a bit of a mystery to 
> me. And parts of it are definitely long in tooth and have been 
> superseded by other, more recent widgets (panedwindow, combobox in ttk, 
> etc.).
> 
> Still, I find parts of BWidgets indispensible, in terms of their 
> flexibility and relative. I make heavy use of the Tree widget in my 
> apps, and the ListBox widget is also slated for inclusion in an app or 
> two I'm developing. Once I "got" how these widgets worked, I found them 
> to be very powerful and perfect for my needs. Last I looked, the new 
> tree/table widget in ttk wasn't as flexible. Also, BWidgets' 
> drag-and-drop support remains the best script-level package for this 
> kind of functionality (hard to grok, but more powerful than the basic 
> drag-and-drop package I developed).

Does that mean you are stepping up to maintain it for the next 3 years? 
  Because nobody else is doing so, and I'd be happy to reassign all the 
open bugs.

> Of couse, if there is a better, more comprehensive megawidget framework 
> than BWidgets out there, I'd be glad to see it.

better != more comprehensive IMO.  Iwidgets is more comprehensive than 
BWidgets, but while some still use it, more would be advised to stay far 
away.  I want a framework that espouses the current nature of Tcl, using 
the latest features, and that is _very_ easy to develop for and maintain.

Jeff

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Kevin W. <kw...@co...>]

> 
> Note that BWidgets is not a core candidate for exactly the question you 
> stated above.  Instead we are looking at alternative megawidget 
> solutions that contain much better frameworks and will be much easier to 
> maintain for years to come.

Out of curiosity, what frameworks are these?

BWidgets is a real mixed bag. How a package that is so comprehensively 
documented can nonetheless be so hard to learn is a bit of a mystery to 
me. And parts of it are definitely long in tooth and have been 
superseded by other, more recent widgets (panedwindow, combobox in ttk, 
etc.).

Still, I find parts of BWidgets indispensible, in terms of their 
flexibility and relative. I make heavy use of the Tree widget in my 
apps, and the ListBox widget is also slated for inclusion in an app or 
two I'm developing. Once I "got" how these widgets worked, I found them 
to be very powerful and perfect for my needs. Last I looked, the new 
tree/table widget in ttk wasn't as flexible. Also, BWidgets' 
drag-and-drop support remains the best script-level package for this 
kind of functionality (hard to grok, but more powerful than the basic 
drag-and-drop package I developed).

Of couse, if there is a better, more comprehensive megawidget framework 
than BWidgets out there, I'd be glad to see it.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Jordan H. <jor...@ya...>]

On Wednesday 29 April 2009, Paul Alfille wrote:
> You could get the best of both worlds if the bells and whistles were
> packaged with the core distribution but only loaded on demand
> (transparently would be best). The rare case where are truly small system
> on disk is needed would be easy to create by deleting the loadable parts.
My 2 cents, as a long time user of TCL/TK, would be to include everything in the standard as it is 
done today.  Most people will want, unknowingly, the distribution to be like this.  However, people 
who work on embedded systems, can download the source, albeit large, and configure it to something 
smaller.

I work, on a regular basis, on embedded systems where I need only the minimal core, as well as 
server and end-user applications where the full suite is needed.  I like the idea, like Active 
State's configuration, of just installing the full suite on the servers and end-users 
configuration.

For the embedded systems configuration, I have to compile and configure many other parts, only one 
of which is TCL/TK.  For me, this is not a problem and rather expected. Many of the tools I use on 
the embedded platforms need configuration.

Thanks,
Jordan Henderson


>
> On Wed, Apr 29, 2009 at 9:34 AM, Robert Seeger <rhs...@gm...> wrote:
> > I think that's the key point to keep in mind:
> >
> >    - A large number of people that want all the bells and whistles ("it
> >    just works") don't have the knowledge or experience to go get all the
> >    individual pieces.
> >    - A large number of people that want the stripped down version are
> >    perfectly comfortable stripping out the parts they don't need, as long
> > as how to do it is relatively well documented and "built into the system"
> > (ie, make/configure options).

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Paul A. <pau...@gm...>]

You could get the best of both worlds if the bells and whistles were
packaged with the core distribution but only loaded on demand (transparently
would be best). The rare case where are truly small system on disk is needed
would be easy to create by deleting the loadable parts.

On Wed, Apr 29, 2009 at 9:34 AM, Robert Seeger <rhs...@gm...> wrote:

>
> I think that's the key point to keep in mind:
>
>    - A large number of people that want all the bells and whistles ("it
>    just works") don't have the knowledge or experience to go get all the
>    individual pieces.
>    - A large number of people that want the stripped down version are
>    perfectly comfortable stripping out the parts they don't need, as long as
>    how to do it is relatively well documented and "built into the system" (ie,
>    make/configure options).
>
>

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Robert S. <rhs...@gm...>]

On Wed, Apr 29, 2009 at 12:10 AM, Donal K. Fellows <
don...@ma...> wrote:

> Larry McVoy wrote:
> > Personally, I would love to see more stuff in the core.  Instead of
> putting
> > the burden on end users to drag stuff in they need, put the burden on the
> > people who want small to toss stuff out.
>
> I largely agree with that (modulo engineering standards being high for
> things that go in). The key point here is that most of the people who
> want minimality also have the skills to read the documentation and pass
> suitable arguments at the right places to get that minimality.
>
> Donal.
>

I think that's the key point to keep in mind:

   - A large number of people that want all the bells and whistles ("it just
   works") don't have the knowledge or experience to go get all the individual
   pieces.
   - A large number of people that want the stripped down version are
   perfectly comfortable stripping out the parts they don't need, as long as
   how to do it is relatively well documented and "built into the system" (ie,
   make/configure options).


Robert Seeger

Re: [TCLCORE] Question about components of Tcl/Tk8.6

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

Jeff Hobbs wrote:
>> where currently there are only two.  "tcl-only" would contain Tcl
>> only.  This would acknowledge there is some subset of Tcl users
>> whose use patterns truly require only the language itself, and
>> this download option spares them the burden of stripping down the
>> standard release for themselves.
>>     
> I believe that is antiproductive to where Tcl needs to move.  The core 
> download can be 50MB in size - very few people really care.  What may be 
> important is that you can build the core runtime without all the 
> components if you so choose, but that certainly shouldn't be the default.
>   
I think Jeff is right on the mark here.  I would like the option of a 
minimal Tcl (e.g. for embedding) but I don't really care if I have to 
download a bunch of extra stuff, so long as I can use appropriate 
compile-time options to produce a minimal build.  I think the bigger 
question is whether such compile-time options exist, and how they are 
managed with respect to future additions to the core.

Regards,
Twylite

Re: [TCLCORE] Question about components of Tcl/Tk8.6

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

Larry McVoy wrote:
> Personally, I would love to see more stuff in the core.  Instead of putting
> the burden on end users to drag stuff in they need, put the burden on the
> people who want small to toss stuff out.

I largely agree with that (modulo engineering standards being high for
things that go in). The key point here is that most of the people who
want minimality also have the skills to read the documentation and pass
suitable arguments at the right places to get that minimality.

Donal.

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[<lm...@bi...>]

> >> Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.
> > 
> > That comment made me laugh.  Every Tcl'er has the same prescription.
> > Tcl/Tk should come with the goodies I need, and none of that other crap.
> 
> Yes, and someone else will say "I don't need Tk, just give me OO 
> finally!", or similar.  The final line contradicts the argument of the 
> entire email.

Personally, I would love to see more stuff in the core.  Instead of putting
the burden on end users to drag stuff in they need, put the burden on the
people who want small to toss stuff out.

The hard part is getting agreement on what should go in.  zlib and png
are great examples of stuff that finally made it but should have made
it long ago.  Bwidgets is a great example of something that should not
be in the core, it's essentially dead from what I can tell, which is a
bummer but putting dead code into the core seems bad.  Perhaps one of 
the tests for inclusion is "are you willing, or do you have someone who
is willing, to maintain this for at least the next 3 years?"  If the
answer is no, well, I guess you don't care enough.

I'd be willing to dedicate some of our resources on trying to shepard 
stuff into tk if that helps.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] Question about components of Tcl/Tk8.6

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

On 28/04/2009 8:19 AM, Larry McVoy wrote:
>>>> Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.
>>> That comment made me laugh.  Every Tcl'er has the same prescription.
>>> Tcl/Tk should come with the goodies I need, and none of that other crap.
>> Yes, and someone else will say "I don't need Tk, just give me OO 
>> finally!", or similar.  The final line contradicts the argument of the 
>> entire email.
> 
> Personally, I would love to see more stuff in the core.  Instead of putting
> the burden on end users to drag stuff in they need, put the burden on the
> people who want small to toss stuff out.
> 
> The hard part is getting agreement on what should go in.  zlib and png
> are great examples of stuff that finally made it but should have made
> it long ago.  Bwidgets is a great example of something that should not
> be in the core, it's essentially dead from what I can tell, which is a
> bummer but putting dead code into the core seems bad.  Perhaps one of 
> the tests for inclusion is "are you willing, or do you have someone who
> is willing, to maintain this for at least the next 3 years?"  If the
> answer is no, well, I guess you don't care enough.

Note that BWidgets is not a core candidate for exactly the question you 
stated above.  Instead we are looking at alternative megawidget 
solutions that contain much better frameworks and will be much easier to 
maintain for years to come.

> I'd be willing to dedicate some of our resources on trying to shepherd 
> stuff into tk if that helps.

That's always welcome.  My laundry list for Tk isn't getting shorter, 
and it's all good stuff.

Jeff

Re: [TCLCORE] Question about components of Tcl/Tk8.6

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

On 28/04/2009 6:40 AM, Donald G Porter wrote:
> ??????? ????? wrote:
>> First, excuse me about my vary bad language.
> 
> I'll take that as a reason to ignore the inflammatory tone I read
> in your questions.
> 
> Rather than respond point by point, let me ask you.  Would it
> adequately address your concerns if we simply added another download
> option for "tcl-only" ?  There could be three tarballs:
> 
> tcl-only8.6-src.tar.gz
> tcl8.6-src.tar.gz
> tk8.6-src.tar.gz
> 
> where currently there are only two.  "tcl-only" would contain Tcl
> only.  This would acknowledge there is some subset of Tcl users
> whose use patterns truly require only the language itself, and
> this download option spares them the burden of stripping down the
> standard release for themselves.

I believe that is antiproductive to where Tcl needs to move.  The core 
download can be 50MB in size - very few people really care.  What may be 
important is that you can build the core runtime without all the 
components if you so choose, but that certainly shouldn't be the default.

>> Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.
> 
> That comment made me laugh.  Every Tcl'er has the same prescription.
> Tcl/Tk should come with the goodies I need, and none of that other crap.

Yes, and someone else will say "I don't need Tk, just give me OO 
finally!", or similar.  The final line contradicts the argument of the 
entire email.

Jeff

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Donald G P. <dg...@ni...>]

??????? ????? wrote:
> First, excuse me about my vary bad language.

I'll take that as a reason to ignore the inflammatory tone I read
in your questions.

Rather than respond point by point, let me ask you.  Would it
adequately address your concerns if we simply added another download
option for "tcl-only" ?  There could be three tarballs:

tcl-only8.6-src.tar.gz
tcl8.6-src.tar.gz
tk8.6-src.tar.gz

where currently there are only two.  "tcl-only" would contain Tcl
only.  This would acknowledge there is some subset of Tcl users
whose use patterns truly require only the language itself, and
this download option spares them the burden of stripping down the
standard release for themselves.

> Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.

That comment made me laugh.  Every Tcl'er has the same prescription.
Tcl/Tk should come with the goodies I need, and none of that other crap.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Question about components of Tcl/Tk8.6

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

Воронов Роман wrote:
> Hello! Tell me please, why are you trying to add so many unnecessary
> components in the standard package of Tcl 8.6? For example, is in
> necessary the Itcl, if you already have TclOO? Why add TDBC in
> standard package, if it is possible to install it manually. There are
> several extensions of questionable need.

The actual size of those packages is pretty small, and the only one that
we're thinking of adding but where we haven't yet done so is Thread
(because that's important functionality that is very useful for taking
advantage of modern computer architectures).

> TCL's charm lies in its size. But I fear that soon Tcl's size will be
> equal to Java's size.

Don't worry about that. Java's got a massive head start...

> The Great extension - Tk is not installed by default with Tcl and it
> may be installed on the user's request. To my mind, user have to
> choose which extension to install and which are not.

Minimalism is all very well, but Tcl's not really all that minimal
anyway. (Compare with Lua here for real minimality.) The extensions that
have been gained are exactly these: TDBC (database access *core* lib;
drivers are external, and will remain so) and Itcl (it's been sought by
a large part of the community for many years). TclOO and zlib are
quasi-packages; they've got names and versions, but are really just part
of Tcl.

> Thus please don't add any extensions (except PNG in Tk) in standard
> Tcl package.

Tk now has PNG support; that'll be part of 8.6.0 (it only just slipped
8.6b1 due to shortage of developer effort).

Donal.

[TCLCORE] Question about components of Tcl/Tk8.6

[Воронов Р. <rv...@ya...>]

First, excuse me about my vary bad language.

This question for developers of Tcl/Tk (may be, for Tcl Core Team's developers)

Hello! Tell me please, why are you trying to add so many unnecessary components in the standard package of Tcl 8.6? For example, is in necessary the Itcl, if you already have TclOO? Why add TDBC in standard package, if it is possible to install it manually. There are several extensions of questionable need.

TCL's charm lies in its size. But I fear that soon Tcl's size will be equal to Java's size.

The Great extension - Tk is not installed by default with Tcl and it may be installed on the user's request. To my mind, user have to choose which extension to install and which are not.

Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.

Re: [TCLCORE] TDBC and read trace failures

[Neil M. <ne...@Cs...>]

Thanks Kevin,

You raise some interesting points. For 8.7 do you think it is worthing  
plugging this apparent API gap with Tcl_VarExists and Tcl_ArrayExists  
calls? Possibly even some form of Tcl_GetVar2IfExists that returns a  
boolean (either directly, or via an int* arg) and also, in the TRUE  
case, retrieves the value of the var/array entry (in case this offers  
a performance/usage advantage)? Obviously, this doesn't address your  
concerns for the 8.5/8.6 series, so I accept your rationale for the  
current design.

-- Neil

On 21 Apr 2009, at 18:28, Kenny, Kevin B (GE, Research) wrote:
> Neil Madden asks an entirely reasonable question about why it is
> that read trace failures and inappropriate array usages are silently
> converted to NULLS.
>
> The answer: It's quite hard NOT to do so on the C side.  Tcl's
> C API does not provide any equivalent to [info exists] and
> [array exists], and (in 8.5 at least) the cases are distinguished
> in Tcl_GetVar2 only by the error message. In 8.6, 'errorCode'
> at least discriminates between "variable does not exist",
> {TCL LOOKUP VARNAME} and "variable exists but the read failed
> for another reason" {TCL READ VARNAME}. But I'm still trying
> to keep tdbc 8.5-compatible, and the errorCode there is NONE.
>
> So the check turns into either: Tcl_GetVar2, and then parse
> the error message to try to make the distinction (and hope a
> read trace doesn't simulate variable nonexistence), or else
> Tcl_Eval a generated script to execute [info exists $varname]
> and [array exists $varname], and only then attempt to get the
> value.  In either case, it's also necessary to bracket the
> call with Tcl_SaveInterpState and Tcl_RestoreInterpState
> (and put Tcl_DiscardInterpState in the error path), so that
> errorInfo and errorCode are preserved in the case
> where a NULL *is* what's wanted.  It turns into a nightmare,
> particularly since there's then also no protection against
> user code that has overridden [info] or [array].
>
> The SQLite3 driver at the Tcl level has similar issues,
> with the additional complication of doing everything [uplevel]
> (This in turn mandates inline code to do it, or else the
> weird step of encapsulating it in a proc that takes the
> level number as argument.)
>
> After several months, I haven't managed to get it right,
> and I didn't think there was much hope of a driver writer
> managing to do so if I couldn't. So I punted.
>
> -- 
> 73 de ke9tv/2, Kevin
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

[TCLCORE] TDBC and read trace failures

[Kenny, K. B (G. Research) <ke...@cr...>]

Neil Madden asks an entirely reasonable question about why it is
that read trace failures and inappropriate array usages are silently
converted to NULLS.

The answer: It's quite hard NOT to do so on the C side.  Tcl's
C API does not provide any equivalent to [info exists] and
[array exists], and (in 8.5 at least) the cases are distinguished
in Tcl_GetVar2 only by the error message. In 8.6, 'errorCode'
at least discriminates between "variable does not exist",
{TCL LOOKUP VARNAME} and "variable exists but the read failed
for another reason" {TCL READ VARNAME}. But I'm still trying
to keep tdbc 8.5-compatible, and the errorCode there is NONE.

So the check turns into either: Tcl_GetVar2, and then parse
the error message to try to make the distinction (and hope a
read trace doesn't simulate variable nonexistence), or else
Tcl_Eval a generated script to execute [info exists $varname]
and [array exists $varname], and only then attempt to get the
value.  In either case, it's also necessary to bracket the
call with Tcl_SaveInterpState and Tcl_RestoreInterpState 
(and put Tcl_DiscardInterpState in the error path), so that 
errorInfo and errorCode are preserved in the case
where a NULL *is* what's wanted.  It turns into a nightmare,
particularly since there's then also no protection against
user code that has overridden [info] or [array].  

The SQLite3 driver at the Tcl level has similar issues,
with the additional complication of doing everything [uplevel]
(This in turn mandates inline code to do it, or else the
weird step of encapsulating it in a proc that takes the
level number as argument.)

After several months, I haven't managed to get it right,
and I didn't think there was much hope of a driver writer
managing to do so if I couldn't. So I punted.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] TIP #350: Tcl Database Connectivity - Corrigenda

[Neil M. <ne...@Cs...>]

Hi Kevin,

The changes all look good to me, with the exception of the point  
below, which I'm not sure I fully grasp:

On 19 Apr 2009, at 20:55, Kevin B. Kenny wrote:
> TIP #350: TCL DATABASE CONNECTIVITY - CORRIGENDA
> ==================================================
> [...]
>
> THE '''EXECUTE''' METHOD OF A STATEMENT - VARIABLE SUBSTITUTION
> -----------------------------------------------------------------
>
> The rule that an array variable provided as a bound value to a
> substituent in a SQL statement MUST result in an error has proven to  
> be
> awkward to implement in practice. Moreover, the original specification
> [TIP #308] fails to indicate what happens if a read trace on one of a
> statement's bound variables throws an error.
>
> The sentence,
>
>       An array variable provided to a substituent MUST result in an
>       error.
>
> is therefore to be replaced with:
>
>       An array variable provided to a substituent, or a variable in
>       which substitution results in an error being reported by a read
>       trace, MUST result in a NULL value being provided.
>
> This change is expected to have minimal impact on existing code; the
> behaviour being described is simply providing a NULL value for a case
> that was an error before (an array where a scalar is expected) and a
> case that was unspecified before (an error within a variable trace).

This seems a little odd. Can you expand on the rationale for this  
change? I would expect a read trace or access error to be an error:  
does TDBC now catch that error and convert it silently into a NULL?

On an unrelated and very minor note, would it be possible to make the  
tdbc namespace into an ensemble? I.e., [tdbc connection], [tdbc  
mapSqlState] etc.

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

[TCLCORE] TDBC 1.0b10 RELEASED

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

I am happy to announce release 1.0b10 of TDBC.  This is the most
recent of ten frequent betas of the TDBC core and driver code.

Source code of TDBC, and all the drivers, can be obtained by the
following steps:

(1) Open a browser and go to http://tdbc.tcl.tk/index.cgi/login

(2) Log in as 'anonymous' - the password is shown on that page.

(3) Once you are logged in, go to the page for the 1.0b10 release:
     http://tdbc.tcl.tk/index.cgi/ci/44c5b4a87b

(4) Download the source code by clicking on the [ZIP Archive] link
     in the 'Commands:' line at the bottom of the first paragraph.

Win32 binaries and HTML documentation for the 1.0b10 release are
available from SourceForge at:

https://sourceforge.net/project/showfiles.php?group_id=10894&package_id=305160

The files to be found there are:

tdbc1.0b10-win32.zip:

This file contains Win32 binaries of the database drivers for TDBC. To
install it, unzip the file, and then run 'wish86.exe' passing it the
INSTALL.TCL file in the resulting directory. Thereafter, tclsh and
wish should be able to do

     [package require tdbc::mysql]

     [package require tdbc::odbc]

and

     [package require tdbc::sqlite3]

tdbc1.0b10-doc.zip:

This file contains HTML documentation for the TDBC drivers. The
'contents.html' file in its root directory is the entry point to the
documentation and contains the links to everything else.



Summary of user visible changes to TDBC since 1.0b9:

2009-04-18:

Man pages added for Tdbc_Init(3), Tdbc_MapSqlState(3),
Tdbc_Tokenize(3) and tdbc::mapSqlState(n).

Manual pages for tdbc::statement(n) and tdbc::resultset(n) now show
the correct syntax for the 'foreach' method.

Manual pages for all the drivers now document that the 'new' method as
well as the 'create' method may be used to make new connection
instances.

Changes made to all the drivers so that :x substitution of an array
variable, or a variable where a read trace fails, yields a NULL rather
than failing.

2009-04-16:

Reworked the allocation of result bindings in tdbc::mysql. The revised
allocation pattern makes many fewer calls to ckalloc/ckfree, and
avoids a crash in the case where a same statement handle is used for
one result set, the result set is closed, and the same statement
handle is used for a second result set. Thanks to Alan Grunwald for
reporting this bug.

2009-03-03:

The constructor pattern for TDBC connections and statements is now
changed.  Rather than setting a variable called 'statementClass' or
'resultSetClass', classes that inherit from these two classes are
expected to impement methods called 'statementCreate' or
'resultSetCreate' respectively.  These methods normally should be
forwarded the 'create' method on the appropriate statement or result
set class.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] small web site fix

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

On 17/04/2009 11:01 PM, David Welton wrote:
> http://www.tcl.tk/software/plugin/safetcl.html
> 
> "The safe.tcl file in the tcl7.7 script library" 7.7!
> 
> Doesn't look like the page has been updated in a while... "Netscape
> plugin".  I'd ditch that, and add some of the more recent developments
> with safe Tcl.

I removed the tcl7 stuff.  If anyone wants to contribute a more full 
rewrite, I'd be happy to update it.

Jeff

Re: [TCLCORE] TIP#198: Image Command XPM Extension

[<geo...@in...>]

Hi Tim,
My name is George Sterling and I am finishing my fourth year of studying Engineering physics (Electrical engineering specialization) at UBC. I had been dreaming for the past few months of dedicating my summer to making a type of programmable analog computer using a a fuse array intended for performing complex mathematics operations until I bumped into your site about FPAA's. I don't think I will be following my original ambitions to carry through making a prototype for a programmable analog chip out of external components as it appears much development already exists. However, I would still like to carve a project out of my initial ideas or from something similar to it. Do you know how can I get involved with research and development with regards to FPAA's. I have clean-room experience as well as experience with the space-science community from my involvement at the Canadian Space Agency. I am more than willing to volunteer my efforts towards your team's goals if that is a p!
 ossibility. Please let me know more.
 
 
George Sterling  
Ugrad Engineering physics
geo...@in...
Phone: 778-240-1311
 
Mailing Address:
2205 Lower Mall 1463
University of British Columbia
Vancouver, BC, Canada
V6T-1Z4

[TCLCORE] TIP #350: Tcl Database Connectivity - Corrigenda

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

 TIP #350: TCL DATABASE CONNECTIVITY - CORRIGENDA 
==================================================
 Version:      $Revision: 1.1 $
 Author:       Kevin B. Kenny <kennykb_at_acm.org>
 State:        Draft
 Type:         Informative
 Vote:         Pending
 Created:      Saturday, 18 April 2009
 URL:          http://purl.org/tcl/tip/350.html
 WebEdit:      http://purl.org/tcl/tip/edit/350
 Post-History: 
 Obsoletes:    TIP #308

-------------------------------------------------------------------------

 ABSTRACT 
==========

 This TIP defines a common database access interface for Tcl scripts. It 
 is an update to [TIP #308] to take into account experience gained since 
 that TIP was written. Note that this TIP does /not/ repeat the contents 
 of that one, which is mostly correct apart from the changes described 
 in this document. 

 SUMMARY OF CHANGES 
====================

 Implementation experience on Tcl Database Connectivity [TIP #308] has 
 exposed several issues with its specification that require editorial 
 corrections. In brief: 

    1. The error codes returned from TDBC drivers are detailed in such a 
       way as to make them more usable in the *try* command. 

    2. The *starttransaction* method on a database connection is 
       renamed, *begintransaction* 

    3. The *execute* method on a statement, and all of the methods that 
       invoke it (*allrows* and *foreach* on database connections) 
       changes its behaviour in the case where a bound variable in its 
       SQL code refers to a Tcl variable that is an array, or a read 
       trace on the associated variable fails. 

    4. The order of arguments on the *foreach* methods on database 
       connections, statements and result sets is changed. 

    5. The /statementClass/ and /resultSetClass/ instance variables, and 
       the /init/ method of connections, statements and result sets, are 
       deprecated; a new initialization API is provided. 

    6. A Tcl command, *tdbc::mapSqlState*, and a C function, 
       *Tdbc_MapSqlState* are provided for the convenience of driver 
       writers. 

 INTRODUCTION 
==============

 The actual implementation of TDBC and three database drivers for it has 
 revealed a handful of mistakes in the TDBC specification [TIP #308]. 
 The purpose of this TIP is to correct those errors and promulgate a 
 specification that matches TDBC as implemented. 

 SPECIFICATION 
===============

 ERROR CODES 
-------------

 Whenever a TDBC driver reports an error in interacting with an 
 underlying database, it SHOULD set the interpreter error code to a list 
 of at least four elements. The first element should be the constant 
 string *TDBC*. The second should be an 'error class' chosen from the 
 list below. The third should be the (usually five-character) SQL state 
 that the database reported, or the constant string *HY000* if the SQL 
 state cannot be determined. (In the latter case, the error class should 
 be *GENERAL_ERROR*.) The fourth element should be the name of the TDBC 
 driver that reported the error. Any elements beyond the fourth SHOULD 
 give further details (for example an error code returned by a native 
 API), and are driver dependent. 

 The permissible values for the error class are as follows. Note that 
 each one corresponds to the first two characters of a five-character 
 'SQL state' that is common to most SQL database API's; the SQL state 
 corresponding to the class is also given. 

    SQL State
    Prefix     Error Class
    --------------------------------------------------------
       00      UNQUALIFIED_SUCCESSFUL_COMPLETION
       01      WARNING
       02      NO_DATA
       07      DYNAMIC_SQL_ERROR
       08      CONNECTION_EXCEPTION
       09      TRIGGERED_ACTION_EXCEPTION
       0A      FEATURE_NOT_SUPPORTED
       0B      INVALID_TRANSACTION_INITIATION
       0D      INVALID_TARGET_TYPE_SPECIFICATION
       0F      LOCATOR_EXCEPTION
       0K      INVALID_RESIGNAL_STATEMENT
       0L      INVALID_GRANTOR
       0P      INVALID_ROLE_SPECIFICATION
       0W      INVALID_STATEMENT_UN_TRIGGER
       20      CASE_NOT_FOUND_FOR_CASE_STATEMENT
       21      CARDINALITY_VIOLATION
       22      DATA_EXCEPTION
       23      CONSTRAINT_VIOLATION
       24      INVALID_CURSOR_STATE
       25      INVALID_TRANSACTION_STATE
       26      INVALID_SQL_STATEMENT_IDENTIFIER
       27      TRIGGERED_DATA_CHANGE_VIOLATION
       28      INVALID_AUTHORIZATION_SPECIFICATION
       2B      DEPENDENT_PRIVILEGE_DESCRIPTORS_STILL_EXIST
       2C      INVALID_CHARACTER_SET_NAME
       2D      INVALID_TRANSACTION_TERMINATION
       2E      INVALID_CONNECTION_NAME
       2F      SQL_ROUTINE_EXCEPTION
       33      INVALID_SQL_DESCRIPTOR_NAME
       34      INVALID_CURSOR_NAME
       35      INVALID_CONDITION_NUMBER
       36      CURSOR_SENSITIVITY_EXCEPTION
       37      SYNTAX_ERROR_OR_ACCESS_VIOLATION
       38      EXTERNAL_ROUTINE_EXCEPTION
       39      EXTERNAL_ROUTINE_INVOCATION_EXCEPTION
       3B      SAVEPOINT_EXCEPTION
       3C      AMBIGUOUS_CURSOR_NAME
       3D      INVALID_CATALOG_NAME
       3F      INVALID_SCHEMA_NAME
       40      TRANSACTION_ROLLBACK
       42      SYNTAX_ERROR_OR_ACCESS_RULE_VIOLATION
       44      WITH_CHECK_OPTION_VIOLATION
       45      UNHANDLED_USER_DEFINED_EXCEPTION
       46      JAVA_DDL
       51      INVALID_APPLICATION_STATE
       53      INSUFFICIENT_RESOURCES
       54      PROGRAM_LIMIT_EXCEEDED
       55      OBJECT_NOT_IN_PREREQUISITE_STATE
       56      MISCELLANEOUS_SQL_OR_PRODUCT_ERROR
       57      RESOURCE_NOT_AVAILABLE_OR_OPERATOR_INTERVENTION
       58      SYSTEM_ERROR
       70      INTERRUPTED
       F0      CONFIGURATION_FILE_ERROR
       HY      GENERAL_ERROR
       HZ      REMOTE_DATABASE_ACCESS_ERROR
       IM      DRIVER_ERROR
       P0      PGSQL_PLSQL_ERROR
       S0      ODBC_2_0_DML_ERROR
       S1      ODBC_2_0_GENERAL_ERROR
       XA      TRANSACTION_ERROR
       XX      INTERNAL_ERROR
     anything
      else     UNKNOWN_SQLSTATE

 The reason for structuring the error codes in this way is to make 
 errors more accessible to the *try* command [TIP #329]. For instance, a 
 Tcl script that wishes to detect and handle division by zero in a SQL 
 statement might look like: 

     try {
         $statement foreach row {
             # ... process the row
         }
    } trap {TDBC DATA_EXCEPTION 22012} {
         puts "Division by zero!"
    }

 Since the previous specification [TIP #308] left the error code 
 unspecified, this change is not expected to impact any client code. 

 TRANSACTION CONTROL 
---------------------

 The *begintransaction* method was inadvertently called, 
 *starttransaction* in the TDBC specification. Therefore, the word 
 *starttransaction* should be replaced with *begintransaction* wherever 
 it appears. 

 This change will break no existing code; no *starttransaction* method 
 has been defined for any TDBC driver. 

 THE '''EXECUTE''' METHOD OF A STATEMENT - VARIABLE SUBSTITUTION 
-----------------------------------------------------------------

 The rule that an array variable provided as a bound value to a 
 substituent in a SQL statement MUST result in an error has proven to be 
 awkward to implement in practice. Moreover, the original specification 
 [TIP #308] fails to indicate what happens if a read trace on one of a 
 statement's bound variables throws an error. 

 The sentence, 

       An array variable provided to a substituent MUST result in an 
       error. 

 is therefore to be replaced with: 

       An array variable provided to a substituent, or a variable in 
       which substitution results in an error being reported by a read 
       trace, MUST result in a NULL value being provided. 

 This change is expected to have minimal impact on existing code; the 
 behaviour being described is simply providing a NULL value for a case 
 that was an error before (an array where a scalar is expected) and a 
 case that was unspecified before (an error within a variable trace). 

 THE ''FOREACH'' METHODS 
-------------------------

 The syntax of the /foreach/ method of connections, statements, and 
 result sets in the original specification contains editorial errors. 
 The correct syntax is: 

       /dbHandle/ *foreach* ?*-as* *lists*|*dicts*? ?*-columnsvariable* 
       /varName/? ?--? /varName/ /sql/ ?/dictionary/? /script/ 

       /statement/ *foreach* ?*-as* *lists*|*dicts*? ?*-columnsvariable* 
       /varName/? ?--? /varName/ ?/dictionary/? /script/ 

       /resultset/ *foreach* ?*-as* *lists*|*dicts*? ?*-columnsvariable* 
       /varName/? ?--? /varName/ /script/ 

 This change represents an editorial correction; the reference 
 implementation functioned in this way even prior to the acceptance of 
 the original specification [TIP #308]. 

 THE CONSTRUCTOR PATTERNS 
--------------------------

 The /statementClass/ variable, and the *init* method, are no longer 
 recommended for use in the constructors of connection classes. Instead, 
 the recommended pattern is that a connection class SHOULD implement a 
 *statementCreate* method that accepts the fully qualified name of the 
 command that is to represent the statement, the connection handle and 
 the SQL statement, and returns a handle to the statement object. The 
 usual way to do so is with a forwarded method: 

     forward statementCreate ::driver::statement create

 If the *statementCreate* method is not present, the default one looks 
 for a variable named /statementClass/ in the connection object, and 
 invokes its *create* command. 

 In this way, drivers that are written to the original specification 
 continue to operate. 

 Similarly, the /resultSetClass/ variable, and the *init* method, are no 
 longer recommended for use in the constructors of statement classes. 
 Instead, the statement class SHOULD implement a *resultSetCreate* 
 method that accepts the fully qualified name of the command that will 
 represent the result set, the statement handle, and the parameters to 
 the *prepare* method. Once again, this method will usually simply be 
 forwarded to the appropriate constructor: 

     forward resultSetCreate ::driver::resultSet create

 Once again, backward compatibility is provided by a *resultSetCreate* 
 method in the base class. This method looks for a /resultSetClass/ 
 variable in the statement instance, and interprets it as a class name, 
 invoking the /create/ method in that class. 

 /Rationale:/ These changes eliminate several jumps among methods with 
 *uplevel* calls, and yield both simpler code and improved performance. 

 SQL STATE MAPPING 
-------------------

 For the convenience of drivers that deal with database APIs that 
 provide a standard SQL dtate in the event of errors, a Tcl command, 
 *tdbc::mapSqlState* is provided. This command accepts a (usually five 
 character) SQL state, and returns the error class that should go in the 
 second element of the error code. The mapping is described in the table 
 in the *Error Codes* section above. 

 Similarly, A C function is provided: 

       const char * *Tdbc_MapSqlState*(const char */sqlstate/); 

 This call looks up the given /sqlstate/ and returns its error class 
 according to the table. 

 LICENSE 
=========

 This file is explicitly released to the public domain and the author 
 explicitly disclaims all rights under copyright law. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] small web site fix

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

David Welton wrote:
> http://www.tcl.tk/software/plugin/safetcl.html
> 
> "The safe.tcl file in the tcl7.7 script library" 7.7!
> 
> Doesn't look like the page has been updated in a while... "Netscape
> plugin".  I'd ditch that, and add some of the more recent developments
> with safe Tcl.
> 

Wow.  There never *was* a 7.7 released.

-- 
73 de ke9tv/2, Kevin

[TCLCORE] small web site fix

[David W. <da...@de...>]

http://www.tcl.tk/software/plugin/safetcl.html

"The safe.tcl file in the tcl7.7 script library" 7.7!

Doesn't look like the page has been updated in a while... "Netscape
plugin".  I'd ditch that, and add some of the more recent developments
with safe Tcl.

-- 
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

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

Zbigniew Baniewski wrote:
> There are people - like myself - who prefer the option, because this will
> make the field contents "strictly bound" to a widget.

The problem is that the data model of such an option (given the general
models of Tcl and Tk) is such that it's only convenient if reserved
strictly for use by application code, and is left entirely alone by
libraries. If we go to something more general capable of supporting use
by both libraries and an application at the same time, you've got to
make the syntax different. (Damon's suggestion would do that exactly.)

Or you can use an array with a <Destroy> callback or command-delete
trace for cleanup, and get your functionality today. In case you've got
this idea that being an option is holy, realize that this is pretty much
what Tk does internally when working out when to clean up structures.
Wrapping that with fancy syntax is an exercise for the reader.

Donal.