You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(3) |
Feb
(35) |
Mar
|
Apr
(10) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(13) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(7) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(26) |
2013 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(10) |
Jul
(1) |
Aug
|
Sep
(11) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Donal K. F. <don...@ma...> - 2012-12-07 11:01:28
|
On 07/12/2012 10:55, Trevor Davel (Twylite) wrote: > We would be quite happy with (1), although it is a fairly myopic change > that may not address future problems with drivers needing literal > characters where the tokenizer gives them special meaning. That would indeed be problematic with SQLite, as that uses @foo to mean a bound variable that is treated as binary instead of as text. Donal. |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 10:55:16
|
Hi, This is a follow up on bug http://core.tcl.tk/tdbc/tktview?name=751477d142 "Problem with MS SQL SERVER (via tdbcodbc) stored procedures" (closed in the TDBC repo and moved to http://core.tcl.tk/tdbcodbc/tkthistory/751477d142). This is a TDBC bug, not an ODBC one; and we're very keen to see it resolved before 8.6.0 is released (if possible). The problem is that the TDBC tokenizer (Tdbc_TokenizeSql() in tdbcTokenize.c) give special meaning to '@', and doesn't have an escape syntax to allow '@' to be passed uninterpreted to the underlying driver. In MS SQL Server the character '@' is required in the DDL, in particular for defining stored procedures. The current behaviour of TDBC (not tdbcodbc) prevents stored procedures from being created from Tcl code (via TDBC). There are several possible solutions: (1) Remove the special handling of '@'. See diff http://core.tcl.tk/tdbc/fdiff?v1=f602a0664f456f9b&v2=fbe1b103c15ccd17 for the necessary change (minus documentation fixes). We are currently working with a special build that includes this change. KBK has previously indicated that this option may have a problematic interaction with Sqlite, but I don't know the details. (2) Add specific escaping syntax to Tdbc_TokenizeSql(). For example, a specific escape may be that '@@' is a literal '@'. (3) Add generic escaping syntax to Tdbc_TokenizeSql(). A general escape may be that '\x' is a literal char x for x in '@', '$', ':', ... (4) Provide a way to bypass host parameter substitution in the tokenizer. This is a wider-reaching change that would allow a flag to be conveyed down to Tdbc_TokenizeSql() to bypass substitution. (5) Provide a way to bypass the tokenizer. As for (4), except the tokenizer is bypassed entirely. Since the tokenizer also handles comments this may have unintended consequences. We would be quite happy with (1), although it is a fairly myopic change that may not address future problems with drivers needing literal characters where the tokenizer gives them special meaning. If an approach can be agreed upon we have time now (before things get busy again in January) to do the implementation. Regards, Twylite |
From: Harald O. <har...@el...> - 2012-12-07 09:38:19
|
Am 07.12.2012 10:24, schrieb Trevor Davel (Twylite): > Hi, > > On 2012/12/07 11:07 AM, Harald Oehlmann wrote: >> I personally whant to help to get tcl8.6.0 released. >> >> Thats why I work on the test in the build environment. >> The IMHO function for the build people is, that a "make test" on tcl >> just runs all tests of all bundled packages. >> >> I will not try CMake, as it will not bring us further to the aim. > I agree with that approach, which is why I contributed the attempt at a > makefile.vc for tdbcodbc. I would like to see a move to CMake in the > longer term, but it won't help towards an 8.6.0 release. > >> There should be a general decision like: >> 1) we use CMAKE and MSVC++ 6,7,8,9,10 (any set of them) > Yes. In fact the CMake team made specific changes to support the path > quoting needed for pkgConfig defines passed in from the build file, > which require some really weird quoting in MSVC 6 and 8 project files. > >> 2) we use NMAKE and MSVC++ 6,7,8,9,10 (any set of them) > What we have now. Painful to maintain, and doesn't allow Windows users > to work in the MSVC IDE, use interactive debugging, use third-party > memory checking tools, etc. > >> 3) we use cygwin/msys make and MSVC++ 6,7,8,9,10 (any set of them) > Over the past couple of years the msys installer has been broken on and > off for months. It is not acceptable to rely on a technology that is > not itself reliable. Using msys also means requiring Windows developers > to learn how to use a *nix shell prompt, maintain builds using autoconf > (which is itself a black art), and not use the MSVC IDE and its > facilities (as mentioned above). In short it's just keeps Windows as a > second-class environment for Tcl development. Thank you for the valueable summary. I agree and have put it on http://wiki.tcl.tk/20966 Harald |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 09:37:59
|
Hi, On 2012/12/07 11:23 AM, Jos Decoster wrote: > I can see your point now about the cmake. I'll give it a try. You are > right the nmake build is a hard to fight monster, any replacement > making that simpler is a good thing. > > Would building static tclsh and libs be possible in the cmake you're > planning? Yes. I think it works right now if you build with BUILD_SHARED_LIBS=OFF, although I haven't tested that recently. e.g. cmake .. -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=%CD%\..\INSTALL Regards, Twylite |
From: Harald O. <har...@el...> - 2012-12-07 09:30:37
|
Am 07.12.2012 10:14, schrieb Trevor Davel (Twylite): > TL;DR: replace NMake with CMake, then we have the same number of > supported build methods, but the build is easier to maintain on Windows > and supports more compliers. I am not at all against CMake. I just want: - have a 100% relyable windows build - get tcl 8.6.0 out (help mainly Donald) If I can contribute to any of those aims, and if CMake would help, I am ready. Trevor, if you could refine my nmake test target I would be happy. As you see, Donald was not so satisfyed by my work here and I am at my end... Sometimes, the hard way must be gone, sorry... Thank you, Harald |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 09:25:20
|
Hi, On 2012/12/07 11:07 AM, Harald Oehlmann wrote: > I personally whant to help to get tcl8.6.0 released. > > Thats why I work on the test in the build environment. > The IMHO function for the build people is, that a "make test" on tcl > just runs all tests of all bundled packages. > > I will not try CMake, as it will not bring us further to the aim. I agree with that approach, which is why I contributed the attempt at a makefile.vc for tdbcodbc. I would like to see a move to CMake in the longer term, but it won't help towards an 8.6.0 release. > There should be a general decision like: > 1) we use CMAKE and MSVC++ 6,7,8,9,10 (any set of them) Yes. In fact the CMake team made specific changes to support the path quoting needed for pkgConfig defines passed in from the build file, which require some really weird quoting in MSVC 6 and 8 project files. > 2) we use NMAKE and MSVC++ 6,7,8,9,10 (any set of them) What we have now. Painful to maintain, and doesn't allow Windows users to work in the MSVC IDE, use interactive debugging, use third-party memory checking tools, etc. > 3) we use cygwin/msys make and MSVC++ 6,7,8,9,10 (any set of them) Over the past couple of years the msys installer has been broken on and off for months. It is not acceptable to rely on a technology that is not itself reliable. Using msys also means requiring Windows developers to learn how to use a *nix shell prompt, maintain builds using autoconf (which is itself a black art), and not use the MSVC IDE and its facilities (as mentioned above). In short it's just keeps Windows as a second-class environment for Tcl development. Regards, Twylite |
From: Jos D. <jos...@gm...> - 2012-12-07 09:23:43
|
Hi Trevor, I can see your point now about the cmake. I'll give it a try. You are right the nmake build is a hard to fight monster, any replacement making that simpler is a good thing. Would building static tclsh and libs be possible in the cmake you're planning? Jos. On Fri, Dec 7, 2012 at 10:14 AM, Trevor Davel (Twylite) <tw...@cr... > wrote: > Hi, > > > On 2012/12/07 10:37 AM, Jos Decoster wrote: > > On Fri, Dec 7, 2012 at 9:23 AM, Harald Oehlmann < > har...@el...> wrote: > >> >> How does the CMAKE build work ? >> Should we pass from nmake to cmake ? >> >> If Tcl would build on all platforms with cmake, I'd agree to let the > nmake build go. Otherwise cmake would be yet another build method. > > I'd really like to convince you that CMake should replace NMake for > Windows only (thus not 'another'). > > A cross-platform cmake build by comparison would be 'another' build method > to maintain, because I can't see everyone agreeing to drop autoconf. > > I've looked at the work that Clifford Yapp has done on a cross-platform > CMake build ( > http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/CliffordYapp/tcltk_cmake_paper.pdf) > and it's really good, but it tries to shoehorn the Windows build into a > Unix model, and in doing so it reproduces a bunch of the complexity and > problems of the current (autoconf + NMake) approach. > > The build - and particularly the install - needs of Windows are different > from *nix. You _can_ support both in one build system, but when you do you > end up complicating the *nix build and getting an un-Windowsy result on > Windows. You also end up with frequent breaks of the Windows build when > developers on a *nix platform make non-trivial updates to the build files > (and that's a problem in Tcl where there are relatively few developers > building on Windows). > > The main reason why I started work on a CMake build was to be able to > build Tcl extensions. Tcl went through about a four-year period of chronic > build failures on Windows (from 2007 to 2011 I could not once check out > HEAD/trunk from Tcl, Tk, Itcl, Thread and get a successful build+install > using NMake), and many other extensions had woefully out of date NMake > support (or none at all). I'm no stranger to NMake, but getting an > extension building and installing with it is not a task for the faint of > heart. Even maintaining an NMake build over time is tricky. > > I wanted something that I could easily use to get extensions building, and > that would be easy for a non-Windows developer to set up (with a high > chance of success). That is why Coffee (my CMake builds) focuses on > _really simply_ CMakefiles and targets Windows only. The CMakefile feels > more like a config.in than a Makefile.in. You can't achieve that level > of simplicity in a cross-platform build. > > TL;DR: replace NMake with CMake, then we have the same number of supported > build methods, but the build is easier to maintain on Windows and supports > more compliers. > > Regards, > Twylite > > |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 09:15:20
|
Hi, On 2012/12/07 10:37 AM, Jos Decoster wrote: > On Fri, Dec 7, 2012 at 9:23 AM, Harald Oehlmann > <har...@el... <mailto:har...@el...>> wrote: > > > How does the CMAKE build work ? > Should we pass from nmake to cmake ? > > If Tcl would build on all platforms with cmake, I'd agree to let the > nmake build go. Otherwise cmake would be yet another build method. I'd really like to convince you that CMake should replace NMake for Windows only (thus not 'another'). A cross-platform cmake build by comparison would be 'another' build method to maintain, because I can't see everyone agreeing to drop autoconf. I've looked at the work that Clifford Yapp has done on a cross-platform CMake build (http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/CliffordYapp/tcltk_cmake_paper.pdf) and it's really good, but it tries to shoehorn the Windows build into a Unix model, and in doing so it reproduces a bunch of the complexity and problems of the current (autoconf + NMake) approach. The build - and particularly the install - needs of Windows are different from *nix. You _can_ support both in one build system, but when you do you end up complicating the *nix build and getting an un-Windowsy result on Windows. You also end up with frequent breaks of the Windows build when developers on a *nix platform make non-trivial updates to the build files (and that's a problem in Tcl where there are relatively few developers building on Windows). The main reason why I started work on a CMake build was to be able to build Tcl extensions. Tcl went through about a four-year period of chronic build failures on Windows (from 2007 to 2011 I could not once check out HEAD/trunk from Tcl, Tk, Itcl, Thread and get a successful build+install using NMake), and many other extensions had woefully out of date NMake support (or none at all). I'm no stranger to NMake, but getting an extension building and installing with it is not a task for the faint of heart. Even maintaining an NMake build over time is tricky. I wanted something that I could easily use to get extensions building, and that would be easy for a non-Windows developer to set up (with a high chance of success). That is why Coffee (my CMake builds) focuses on _really simply_ CMakefiles and targets Windows only. The CMakefile feels more like a config.in than a Makefile.in. You can't achieve that level of simplicity in a cross-platform build. TL;DR: replace NMake with CMake, then we have the same number of supported build methods, but the build is easier to maintain on Windows and supports more compliers. Regards, Twylite |
From: Harald O. <har...@el...> - 2012-12-07 09:07:15
|
Am 07.12.2012 09:52, schrieb Trevor Davel (Twylite): > Hi, > > On 2012/12/07 10:23 AM, Harald Oehlmann wrote: >> Am 07.12.2012 08:47, schrieb Trevor Davel (Twylite):> Hi, >>> Yep, me too ;) But to be honest I'd rather be building with CMake, and >>> I don't care much about the ability to build extensions against an >>> installed runtime (rather than against sources and binaries in a build >>> environment), because that's mostly broken with MSVC anyway. >> How does the CMAKE build work ? >> Should we pass from nmake to cmake ? > I'd love to use CMake rather than NMake for Windows builds. There has > been some support and resistance to the idea when I've raised it before, > and there has been other work on a cross-platform CMake build. > > The CMake build (as I have implemented it) uses CMake variables to > communicate between the CMakefiles. So once you've built Tcl every > subsequent CMakefile in the build knows where to find the Tcl include > paths and what libraries or stubs to link against. Once you've build > Tdbc every subsequence CMakefile (like the drivers) knows where to find > the Tdbc includes and libs. > > I've set up my CMakefiles to be simple to maintain (even with limited > knowledge of CMake), and they have proven remarkably robust in the face > of changes to both the Tcl build and the build environment (e.g. the > NMake rules.vc must be updated every time a new MSVC is released, and > this change must be propagated to all extensions). > > If you're interested you can find my CMakefiles at > http://dev.crypt.co.za/coffee/index (last updated around September, and > expecting the old TDBC repository layout). The latest CMakefile for Tcl > is here: > http://dev.crypt.co.za/coffee/artifact/4fd7782a8d6412a7ef5cb5a1548d501e1b67bbc6 > if you want to take a quick look. > > Oversell warning: don't let anything I've said above lead you to believe > that this is a mature solution ;) There is currently no support for > testing, there should be more knobs for build configuration, and the > 'protocol' for communicating information between CMakefiles needs to be > explicitly defined (it's rather ad hoc at the moment). > > In theory saving parts of the CMake cache into a build configuration > file (like tclConfig.sh, but specific to CMake builds) will allow > building against an installed Tcl rather than sources+build, but I've > never implemented this. > >>>> If the nmake crowd can live with fragile warnings not to build/test >>>> in paths with spaces, I'm not going to more effort to overrule that. >> Yes, but this is another purpose. >> The test suite will tell you, if you have done something wrong in your >> code. Both tests are helpful. > I agree, although my work process tends to be different (I directly run > 'Debug_VC10\tclsh86t.exe ..\tests\mytest.test' from the command line, > rather than 'nmake test'), so I don't miss the functionality; but I > understand how other people find it useful. > >> At least, I tried to get the test suite work in the installation folder, >> which tells you, if the build is correct (and stresses your nerves to >> make this work). > Trick: copy the tcltest.exe to the install folder and run with that ;) > To my knowledge all of the problems with testing in the install > environment have been ironed out recently. Trevor, thank you for the information and the work. I personally whant to help to get tcl8.6.0 released. Thats why I work on the test in the build environment. The IMHO function for the build people is, that a "make test" on tcl just runs all tests of all bundled packages. I will not try CMake, as it will not bring us further to the aim. I thought, CMake will use anything existant and there is no additional work needed... There should be a general decision like: 1) we use CMAKE and MSVC++ 6,7,8,9,10 (any set of them) 2) we use NMAKE and MSVC++ 6,7,8,9,10 (any set of them) 3) we use cygwin/msys make and MSVC++ 6,7,8,9,10 (any set of them) 4) we don't use MSVC and only gcc My personal experience is, that the msvc and Makefile.vc results are just good, specially in result size (factor 3 compared to mingw). This might be due to the fact, that the c runtime dll is not linked statically as it is always present. This is a +MSVC reason for me. If we don't have any active experts with Makefile.vc left, we should perhaps go to solution 3 (which I never tried). Thank you, Harald |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 08:53:22
|
Hi, On 2012/12/07 10:23 AM, Harald Oehlmann wrote: > Am 07.12.2012 08:47, schrieb Trevor Davel (Twylite):> Hi, >> Yep, me too ;) But to be honest I'd rather be building with CMake, and >> I don't care much about the ability to build extensions against an >> installed runtime (rather than against sources and binaries in a build >> environment), because that's mostly broken with MSVC anyway. > How does the CMAKE build work ? > Should we pass from nmake to cmake ? I'd love to use CMake rather than NMake for Windows builds. There has been some support and resistance to the idea when I've raised it before, and there has been other work on a cross-platform CMake build. The CMake build (as I have implemented it) uses CMake variables to communicate between the CMakefiles. So once you've built Tcl every subsequent CMakefile in the build knows where to find the Tcl include paths and what libraries or stubs to link against. Once you've build Tdbc every subsequence CMakefile (like the drivers) knows where to find the Tdbc includes and libs. I've set up my CMakefiles to be simple to maintain (even with limited knowledge of CMake), and they have proven remarkably robust in the face of changes to both the Tcl build and the build environment (e.g. the NMake rules.vc must be updated every time a new MSVC is released, and this change must be propagated to all extensions). If you're interested you can find my CMakefiles at http://dev.crypt.co.za/coffee/index (last updated around September, and expecting the old TDBC repository layout). The latest CMakefile for Tcl is here: http://dev.crypt.co.za/coffee/artifact/4fd7782a8d6412a7ef5cb5a1548d501e1b67bbc6 if you want to take a quick look. Oversell warning: don't let anything I've said above lead you to believe that this is a mature solution ;) There is currently no support for testing, there should be more knobs for build configuration, and the 'protocol' for communicating information between CMakefiles needs to be explicitly defined (it's rather ad hoc at the moment). In theory saving parts of the CMake cache into a build configuration file (like tclConfig.sh, but specific to CMake builds) will allow building against an installed Tcl rather than sources+build, but I've never implemented this. >>> If the nmake crowd can live with fragile warnings not to build/test >>> in paths with spaces, I'm not going to more effort to overrule that. > Yes, but this is another purpose. > The test suite will tell you, if you have done something wrong in your > code. Both tests are helpful. I agree, although my work process tends to be different (I directly run 'Debug_VC10\tclsh86t.exe ..\tests\mytest.test' from the command line, rather than 'nmake test'), so I don't miss the functionality; but I understand how other people find it useful. > At least, I tried to get the test suite work in the installation folder, > which tells you, if the build is correct (and stresses your nerves to > make this work). Trick: copy the tcltest.exe to the install folder and run with that ;) To my knowledge all of the problems with testing in the install environment have been ironed out recently. Regards, Twylite |
From: Jos D. <jos...@gm...> - 2012-12-07 08:37:44
|
On Fri, Dec 7, 2012 at 9:23 AM, Harald Oehlmann <har...@el... > wrote: > > How does the CMAKE build work ? > Should we pass from nmake to cmake ? > > If Tcl would build on all platforms with cmake, I'd agree to let the nmake build go. Otherwise cmake would be yet another build method. |
From: Harald O. <har...@el...> - 2012-12-07 08:22:48
|
Am 07.12.2012 08:47, schrieb Trevor Davel (Twylite):> Hi, > > On 2012/12/06 07:29 PM, Donald G Porter wrote: >> Empirically you and Jos Decoster are the only folks who complain about >> ability to build using MSVC (maybe Twylite too?). I imagine your >> voices represent multitudes, but still those are the only folks I have >> evidence for caring about nmake builds. > Yep, me too ;) But to be honest I'd rather be building with CMake, and > I don't care much about the ability to build extensions against an > installed runtime (rather than against sources and binaries in a build > environment), because that's mostly broken with MSVC anyway. How does the CMAKE build work ? Should we pass from nmake to cmake ? > >> If the nmake crowd can live with fragile warnings not to build/test >> in paths with spaces, I'm not going to more effort to overrule that. > I can live with this. I don't test in the build/test environment > anyway, because it gives a false sense of security. Tests need to be > executed using the final installed configuration, and preferably on a > system without MSVC installed. This way you get to confirm that you > included the correct C runtime in your install, that DLLs and packages > can be located correctly, and that core functionality can be reasonable > expected to work in a production environment. Yes, but this is another purpose. The test suite will tell you, if you have done something wrong in your code. Both tests are helpful. At least, I tried to get the test suite work in the installation folder, which tells you, if the build is correct (and stresses your nerves to make this work). Harald |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 07:47:39
|
Hi, On 2012/12/06 07:29 PM, Donald G Porter wrote: > Empirically you and Jos Decoster are the only folks who complain about > ability to build using MSVC (maybe Twylite too?). I imagine your > voices represent multitudes, but still those are the only folks I have > evidence for caring about nmake builds. Yep, me too ;) But to be honest I'd rather be building with CMake, and I don't care much about the ability to build extensions against an installed runtime (rather than against sources and binaries in a build environment), because that's mostly broken with MSVC anyway. > If the nmake crowd can live with fragile warnings not to build/test > in paths with spaces, I'm not going to more effort to overrule that. I can live with this. I don't test in the build/test environment anyway, because it gives a false sense of security. Tests need to be executed using the final installed configuration, and preferably on a system without MSVC installed. This way you get to confirm that you included the correct C runtime in your install, that DLLs and packages can be located correctly, and that core functionality can be reasonable expected to work in a production environment. Regards, Twylite |
From: Donald G P. <don...@ni...> - 2012-12-06 17:30:35
|
On 12/06/2012 12:03 PM, Harald Oehlmann wrote: > Am 06.12.2012 17:52, schrieb Donald G Porter: >> It appears to me that your `make test` targets are not robust to paths >> that contain spaces. You'll want to make use of [list ...] quoting when >> constructing the [package ifneeded] scripts. Another possibility is >> copying what tdbcsqlite3 MSVC support has done, which apparently doesn't >> need the -load option support to get `make test` to work? > > Thank you. I am aware of this as I have thrown out the list commands. > I took the code in "Makefile.in" and the existing code and fiddled until > it worked. > I have replaced the list commands by hardcoded curly braces which should > lead to the same result. Dear God no. If that worked, you'd see Tcl scripts using it, instead of [list ...]. Non-broken ones I mean. > I have tried it without the load command and I failed. > Are you shure, the SQLite tests work with MSVC ? > >> I'm going to copy/modify what you have now. When you fix tdbcodbc, >> please copy your fix over to the other drivers too. > > The current state is the best I could give. > It is far away from good but, at least, it works in some cases... > I hope, someone else could care... Empirically you and Jos Decoster are the only folks who complain about ability to build using MSVC (maybe Twylite too?). I imagine your voices represent multitudes, but still those are the only folks I have evidence for caring about nmake builds. FWIW, I have "negative" care for them. They cause a whole lot of trouble for me getting releases done. I have no reasonable way to test them. Their presence always adds at least an additional RC round if not two or three. I'd be overjoyed to see them tossed overboard. If the nmake crowd can live with fragile warnings not to build/test in paths with spaces, I'm not going to more effort to overrule that. Perhaps with 8.6.0 made real by a release, the other crowds who care about nmake builds may show up. We'll see. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Harald O. <har...@el...> - 2012-12-06 17:03:14
|
Am 06.12.2012 17:52, schrieb Donald G Porter: > It appears to me that your `make test` targets are not robust to paths > that contain spaces. You'll want to make use of [list ...] quoting when > constructing the [package ifneeded] scripts. Another possibility is > copying what tdbcsqlite3 MSVC support has done, which apparently doesn't > need the -load option support to get `make test` to work? Thank you. I am aware of this as I have thrown out the list commands. I took the code in "Makefile.in" and the existing code and fiddled until it worked. I have replaced the list commands by hardcoded curly braces which should lead to the same result. I have tried it without the load command and I failed. Are you shure, the SQLite tests work with MSVC ? > I'm going to copy/modify what you have now. When you fix tdbcodbc, > please copy your fix over to the other drivers too. The current state is the best I could give. It is far away from good but, at least, it works in some cases... I hope, someone else could care... Harald |
From: Donald G P. <don...@ni...> - 2012-12-06 16:52:35
|
On 12/05/2012 11:08 AM, Harald Oehlmann wrote: > I suppose, the tdbc::odbc makefile may be used as a starting point for > mysql and postgresql It appears to me that your `make test` targets are not robust to paths that contain spaces. You'll want to make use of [list ...] quoting when constructing the [package ifneeded] scripts. Another possibility is copying what tdbcsqlite3 MSVC support has done, which apparently doesn't need the -load option support to get `make test` to work? I'm going to copy/modify what you have now. When you fix tdbcodbc, please copy your fix over to the other drivers too. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Harald O. <har...@el...> - 2012-12-06 16:30:41
|
Am 06.12.2012 17:07, schrieb Donald G Porter: > I merged these patches into the trunks of tdbc and tdbcodbc. Thank you ! > I'm working on that. Thank you very much for that. There is much room for improvement... > As I go I notice that tdbcodbc/win/makefile.vc > is using the directory names under tcl/pkgs/ to find things. We want > to avoid that. Maybe how the Makefile.in handles things can be copied? The makefile tests the two different positions for TDBC (bundled/standalone). As I understood, tdbc and drivers will be separated (and will propably have different versions). There are separated repos now... I suppose, the best would be to access the tdbcConfig.sh file. The tdbcConfig.sh has two remaining issues: TDBC_BUILD_LIBRARY_PATH : slash/backslash issue (hardcoded in template) TDBC_BUILD_STUB_LIB_SPEC, TDBC_BUILD_STUB_LIB_PATH : relative paths A current tdbcConfig.sh is attached. I have no idea how Makefile.in works at this point. I only found some variables which come from tdbcConfig.sh. I suppose, it relies on the fact that tdbc is installed and thus the include files and stub is in the tcl place (which is not the case in the bundled build). > I'm going ahead with what you've given, since fragile support is better > than no support at all. At least I think so for now. I agree. Lets start... Harald |
From: Donald G P. <don...@ni...> - 2012-12-06 16:07:52
|
On 12/05/2012 11:08 AM, Harald Oehlmann wrote: > This checkin: > > http://core.tcl.tk/tdbc/info/7f5817340f > > of branch td-win-tea of tdbc on core.tcl.tk > does the following steps for tcl8.6.0 bundling using the msvc++ compiler > and Makefile.vc: > > - tdbc: > - Install development files > - tdbc::odbc > - Builds standalone and when bundled > - Test invokation works. > For me, only sqlite worked due to missing odbc drivers. > There are some test errors which might be addressed later. > > I tested both on a total checkout and when I copied both Makefiles into > the tcl8.6.0rc2 tree. I merged these patches into the trunks of tdbc and tdbcodbc. > I suppose, the tdbc::odbc makefile may be used as a starting point for > mysql and postgresql I'm working on that. As I go I notice that tdbcodbc/win/makefile.vc is using the directory names under tcl/pkgs/ to find things. We want to avoid that. Maybe how the Makefile.in handles things can be copied? I'm going ahead with what you've given, since fragile support is better than no support at all. At least I think so for now. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Harald O. <har...@el...> - 2012-12-05 16:07:57
|
This checkin: http://core.tcl.tk/tdbc/info/7f5817340f of branch td-win-tea of tdbc on core.tcl.tk does the following steps for tcl8.6.0 bundling using the msvc++ compiler and Makefile.vc: - tdbc: - Install development files - tdbc::odbc - Builds standalone and when bundled - Test invokation works. For me, only sqlite worked due to missing odbc drivers. There are some test errors which might be addressed later. I tested both on a total checkout and when I copied both Makefiles into the tcl8.6.0rc2 tree. I suppose, the tdbc::odbc makefile may be used as a starting point for mysql and postgresql Harald |
From: Harald O. <har...@el...> - 2012-11-29 16:09:46
|
Thank you, Kevin, for the detailed answer. I used the wiki as primary information source. I tried to update it to reflect all this information... Am 29.11.2012 15:31, schrieb Kevin Kenny: > On 11/29/2012 08:11 AM, Harald Oehlmann wrote: >> I wondered about the odbc implementation and the metadata query commands. >> I understood, that each driver may return different dict keys. > So you will see additional columns in the results returned from the > introspection commands. TIP 308's list is the minimal set. Thank you, now, as I found the docs and tip350, the image is clearer. It might be helpful, if there would also be a minimal set for the tables subcommand. At least the tableSchma might be standardised. >> Why is the ODBC driver not usable with tcl8.5 but the other drivers are? > I'd be willing to help guide a programmer who wants to rework a version > 0.18 of the drivers to build and execute against 8.5 (point out what in > the code has to change, and so on...) but at present I don't have the > bandwidth to take it on myself. This is one of several ODBC projects in > need of an implementor. (I'd like to see the Oracle driver finished, > have a driver for the SQL Server native API, and have a C version of > the SQLite3 driver - the Tcl version that we have is pretty slow and > has a couple of unfixable bugs.) Thank you for the clarification. As I tried many times to compile tdbc for tcl8.5, I have at least an explanation why it does not work. I don't want to work on the drivers, enough building sites already (as you) and only little know-how... But I have put your answer on the wiki to eventually inform others. Thank you, Harald |
From: Kevin K. <kk...@ny...> - 2012-11-29 14:31:49
|
Redirecting replies to the tcl-tdbc list. On 11/29/2012 08:11 AM, Harald Oehlmann wrote: > On http://wiki.tcl.tk/tdbc, Kevin Kenny stated that TDBC issues should > be reported by tickets on http://tdbc.tcl.tk/ (which seams to be linked > to http://core.tcl.tk/tdbc , at least my ticket there appeared on the > first (they are only ordered differently)). > > Now, both Ticket systems show issues: > > http://tdbc.tcl.tk/index.cgi/info/e226dbc23c > and > http://core.tcl.tk/tdbc/tktview?name=e226dbc23c > show an error message: > "ERROR: SQL error: no such table: ticketchng" > > When pressing on "New Ticket": > http://core.tcl.tk/tdbc/tktnew > there is an error message: > "ERROR: no such variable: icomment" > > My login "oehhar" is only valid on "core.tcl.tk/tdbc", not on > "tdbc.tcl.tk". That is why I prefer core.tcl.tk/tdbc The two are indeed mirrored. The tdbc tracking system on core.tcl.tk appears to be down at the moment. I've sent email to Richard, since he made recent changes there, and I'm sure things will get sorted. > ---------------------------- > Here are some implementation remarks. > > I don't want to blame anybody (specially not Kevin Kenny how feels quite > allone with tdbc) but I want to understand why things are how they are. > ---------------------------- > I wondered about the odbc implementation and the metadata query commands. > See the summary at: > http://wiki.tcl.tk/tdbc -> button "Return dictionaries of the metadata > query commands" > > I understood, that each driver may return different dict keys. > But why does the same driver gives the same thing many different key names. > For example, the dict key for the table name: > "TABLE_NAME": ODBC, tables subcommand > "tbl_name": SQLite3, table subcommand > "table_name": ODBC, columns subcommand > "tableName": ODBC, primarykeys subcommand Generally speaking, the underlying code for each driver that handles commands like 'tables,' 'columns,' and 'primarykeys' returns the result as a SQL result set, as if it were any other statement (In fact, in several of the databases, the commands are implemented as SQL statements querying the INFORMATION_SCHEMA.) No column is deleted from this result set, by design. This allows for inspecting driver-specific results when the underlying database is known; various databases have additional information about tables, columns and constraints that is not represented in the standard set of results. Nevertheless, portable applications want a standard set of column names that they can depend on. TIP 308 describes, and all the drivers provide, a standard set of column names that will be returned from [db tables], [db columns], [db primarykeys] and so on. These result columns should be present on all databases: if one or another is missing, that's a bug. (Note that the last remark has to be taken with a grain of salt. It's not uncommon, for instance, for the key to be missing in the returned dictionary because the associated value is NULL.) So you will see additional columns in the results returned from the introspection commands. TIP 308's list is the minimal set. > ---------------------------- > Method starttransaction is begintransaction > > In TIP 308, the method "starttransaction" is described. > With odbc, it is implemented as "begintransaction". TIP 308 included several editorial errors. TIP 350 contains this and other corrections. I recommend using the man pages instead of the TIPs for reference. > ---------------------------- > Why is the ODBC driver not usable with tcl8.5 but the other drivers are? As far as I know, only the SQLite3 driver remains usable with 8.5, and even that is something of an accident: it happens not to depend on any 8.6 features. The MySQL, ODBC and PostgreSQL drivers were all rewritten to depend on the functionality described in TIP #357 (Export Tcl_LoadFile). This change turns out to be important for distributors. A distributor can build tdbc::odbc, tdbc::mysql and tdbc::postgres without needing to have the client libraries for the respective databases on the build system. The library references, and the functions therein, are resolved at runtime, when the package is required. Unfortunately, the change was a fairly major fork to the code. The TEA build system is quite complex, and TDBC stresses it some. Figuring out the correct incantations needed to make an 8.5 version link directly to the database client libraries while having an 8.6 version use Tcl_LoadLibrary simply was more than I could handle at the time, and so those drivers - which were in beta state to begin with, targeted to ship together with 8.6 - were shifted to an explicit 8.6 dependency. The intent is not to run TDBC's release cycle in lock-step with Tcl's, but in this specific case, there was a strong dependency on a new feature of 8.6. I'd be willing to help guide a programmer who wants to rework a version 0.18 of the drivers to build and execute against 8.5 (point out what in the code has to change, and so on...) but at present I don't have the bandwidth to take it on myself. This is one of several ODBC projects in need of an implementor. (I'd like to see the Oracle driver finished, have a driver for the SQL Server native API, and have a C version of the SQLite3 driver - the Tcl version that we have is pretty slow and has a couple of unfixable bugs.) -- 73 de ke9tv/2, Kevin |
From: Andreas K. <and...@ac...> - 2012-10-15 17:47:44
|
19th Annual Tcl/Tk Conference (Tcl'2012) http://www.tcl.tk/community/tcl2012/ November 12 - 16, 2012 Sessions: National Museum of Health and Medicine Chicago 175 W. Washington Chicago, IL 60602 Rooms: Holiday Inn Chicago Mart Plaza 350 West Mart Center Drive Chicago, Illinois, USA Map/Transport: https://maps.google.com/maps/ms?msid=204739899073144451536.0004c144222a9036c99f6&msa=0&ll=41.885266,-87.633734&spn=0.008443,0.018818 http://wiki.tcl.tk/28843#pagetoca7e55932 Hello all. This is a reminder that the offer of reduced rates for rooms at the conference hotel expires on October 20, i.e. at the end of this week. Book Now! (if you haven't already). And talk to us should you run into trouble with the Hotel claiming to be sold out already before the deadline. Of course registration for the Conference is still open at http://www.tcl.tk/community/tcl2012/reg.html To book a room at the conference hotel at reduced rates please follow the instructions on that page. Our schedule can be found at http://www.tcl.tk/community/tcl2012/schedule.html Conference Committee Clif Flynt Noumena Corp General Chair, Website Admin Andreas Kupries ActiveState Software Inc. Program Chair Cyndy Lilagan Nat. Museum of Health & Medicine, Chicago Site/Facilities Chair Arjen Markus Deltares Brian Griffin Mentor Graphics Donal Fellows University of Manchester Gerald Lester KnG Consulting, LLC Jeffrey Hobbs ActiveState Software Inc. Kevin Kenny GE Global Research Center Larry Virden Mike Doyle National Museum of Health & Medicine, Chicago Ron Fox NSCL/FRIB Michigan State University Steve Landers Digital Smarties Contact Information tcl...@go... Tcl'2012 would like to thank those who are sponsoring the conference: ActiveState Software Inc. Buonacorsi Foundation Mentor Graphics Noumena Corp. SR Technology Tcl Community Association |
From: Andreas K. <and...@ac...> - 2012-09-10 18:55:38
|
19th Annual Tcl/Tk Conference (Tcl'2012) http://www.tcl.tk/community/tcl2012/ November 12 - 16, 2012 Sessions: National Museum of Health and Medicine Chicago 175 W. Washington Chicago, IL 60602 Rooms: Holiday Inn Chicago Mart Plaza 350 West Mart Center Drive Chicago, Illinois, USA Map/Transport: https://maps.google.com/maps/ms?msid=204739899073144451536.0004c144222a9036c99f6&msa=0&ll=41.885266,-87.633734&spn=0.008443,0.018818 http://wiki.tcl.tk/28843#pagetoca7e55932 I am pleased to announce that registration for the Conference is now open at http://www.tcl.tk/community/tcl2012/reg.html To book a room at the conference hotel at reduced rates please follow the instructions on that page. Note that the offer of reduced rates expires on October 20. Book early. Our schedule can be found at http://www.tcl.tk/community/tcl2012/schedule.html Conference Committee Clif Flynt Noumena Corp General Chair, Website Admin Andreas Kupries ActiveState Software Inc. Program Chair Cyndy Lilagan Nat. Museum of Health & Medicine, Chicago Site/Facilities Chair Arjen Markus Deltares Brian Griffin Mentor Graphics Donal Fellows University of Manchester Gerald Lester KnG Consulting, LLC Jeffrey Hobbs ActiveState Software Inc. Kevin Kenny GE Global Research Center Larry Virden Mike Doyle National Museum of Health & Medicine, Chicago Ron Fox NSCL/FRIB Michigan State University Steve Landers Digital Smarties Contact Information tcl...@go... Tcl'2012 would like to thank those who are sponsoring the conference: ActiveState Software Inc. Buonacorsi Foundation Mentor Graphics Noumena Corp. SR Technology Tcl Community Association |
From: Douglas P. <dou...@gm...> - 2012-08-31 15:16:04
|
Hi, I am using tdbc's odbc driver to work with an MS SQL Server (2008) database. I have run into a problem when writing code to create a stored procedure, specifically w.r.t. the syntax for a procedure's parameters. SQL Server's "CREATE PROCEDURE" syntax ( http://msdn.microsoft.com/en-us/library/ms187926%28v=sql.100%29.aspx) requires that a procedure's parameters be declared using the @ symbol preceding the name, e.g. @myvar Just doing this results in the connection's prepare method returning a statement whose params method returns a dict that has all of the stored procedure's parameters as bound variables. If I precede the parameter specifications with an underscore then the params dict does not contain the parameters, they are not seen as bound variables (b.t.w. this is undocumented) but when executing the statement fails due to the sql command still having the underscore. See examples below. Thanks Douglas (tools) 5 % set con_str {Driver=SQL Server Native Client 10.0;Server=127.0.0.1\SQLEXPRESS;DATABASE=TDBC;UID=builder;PWD=bob;} Driver=SQL Server Native Client 10.0;Server=127.0.0.1\SQLEXPRESS;DATABASE=TDBC;UID=builder;PWD=bob; (tools) 6 % tdbc::odbc::connection create my_mssql_con $con_str ::my_mssql_con (tools) 7 % set sql_stmt { > CREATE PROCEDURE [ESS].[sp_commitsinsert] > @commitRef nchar(64), > @streamId int, > @lastCommitId int, > @events nchar(64), > @metadata nchar(64) = NULL, > @snapshot nchar(64) = NULL > AS > IF EXISTS (SELECT 1 FROM [ESS].[t_streams_myStore] s WHERE s.streamId = @streamId AND s.lastCommitId != @lastCommitId) > RAISERROR('Concurrency exception', 0, 0) > ELSE > INSERT INTO [ESS].[t_commits_myStore] (commitRef, streamId, lastCommitId, events, metadata, snapshot) > VALUES (@commitRef, @streamId, @lastCommitId, @events, @metadata, @snapshot) > } CREATE PROCEDURE [ESS].[sp_commitsinsert] @commitRef nchar(64), @streamId int, @lastCommitId int, @events nchar(64), @metadata nchar(64) = NULL, @snapshot nchar(64) = NULL AS IF EXISTS (SELECT 1 FROM [ESS].[t_streams_myStore] s WHERE s.streamId = @streamId AND s.lastCommitId != @lastCommitId) RAISERROR('Concurrency exception', 0, 0) ELSE INSERT INTO [ESS].[t_commits_myStore] (commitRef, streamId, lastCommitId, events, metadata, snapshot) VALUES (@commitRef, @streamId, @lastCommitId, @events, @metadata, @snapshot) (tools) 8 % set stmt [my_mssql_con prepare $sql_stmt] ::oo::Obj22::Stmt::1 (tools) 9 % set param_dict {} (tools) 10 % set param_dict [$stmt params] commitRef {name commitRef direction in type wvarchar precision 255 scale 0} streamId {name streamId direction in type wvarchar precision 255 scale 0} lastCommitId {name lastCommitId direction in type wvarchar precision 255 scale 0} events {name events direction in type wvarchar precision 255 scale 0} metadata {name metadata direction in type wvarchar precision 255 scale 0} snapshot {name snapshot direction in type wvarchar precision 255 scale 0} (tools) 11 % set args {} (tools) 12 % foreach v_name [dict keys $param_dict] arg $args { > if { ($v_name ne {}) && ([dict get $param_dict $v_name direction] ne "out") } { > dict set param_dict $v_name $arg > } > } (tools) 13 % puts $param_dict commitRef {} streamId {} lastCommitId {} events {} metadata {} snapshot {} (tools) 14 % set resultset [$stmt execute $param_dict] [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword 'PROCEDURE'. [Microsoft][SQL Server Native Client 10.0][SQL Server]Statement(s) could not be prepared. (executing the statement) (tools) 15 % (tools) 15 % (tools) 15 % set sql_stmt { > CREATE PROCEDURE [ESS].[sp_commitsinsert] > _@commitRef nchar(64), > _@streamId int, > _@lastCommitId int, > _@events nchar(64), > _@metadata nchar(64) = NULL, > _@snapshot nchar(64) = NULL > AS > IF EXISTS (SELECT 1 FROM [ESS].[t_streams_myStore] s WHERE s.streamId = _@streamId AND s.lastCommitId != _@lastCommitId) > RAISERROR('Concurrency exception', 0, 0) > ELSE > INSERT INTO [ESS].[t_commits_myStore] (commitRef, streamId, lastCommitId, events, metadata, snapshot) > VALUES (_@commitRef, _@streamId, _@lastCommitId, _@events, _@metadata, _@snapshot) > } CREATE PROCEDURE [ESS].[sp_commitsinsert] _@commitRef nchar(64), _@streamId int, _@lastCommitId int, _@events nchar(64), _@metadata nchar(64) = NULL, _@snapshot nchar(64) = NULL AS IF EXISTS (SELECT 1 FROM [ESS].[t_streams_myStore] s WHERE s.streamId = _@streamId AND s.lastCommitId != _@lastCommitId) RAISERROR('Concurrency exception', 0, 0) ELSE INSERT INTO [ESS].[t_commits_myStore] (commitRef, streamId, lastCommitId, events, metadata, snapshot) VALUES (_@commitRef, _@streamId, _@lastCommitId, _@events, _@metadata, _@snapshot) (tools) 16 % set stmt [my_mssql_con prepare $sql_stmt] ::oo::Obj22::Stmt::2 (tools) 17 % set param_dict {} (tools) 18 % set param_dict [$stmt params] (tools) 19 % set args {} (tools) 20 % foreach v_name [dict keys $param_dict] arg $args { > if { ($v_name ne {}) && ([dict get $param_dict $v_name direction] ne "out") } { > dict set param_dict $v_name $arg > } > } (tools) 21 % puts $param_dict (tools) 22 % set resultset [$stmt execute $param_dict] [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near '_@commitRef'. [Microsoft][SQL Server Native Client 10.0][SQL Server]Statement(s) could not be prepared. (executing the statement) (tools) 23 % |
From: Andreas K. <and...@ac...> - 2012-08-07 18:28:02
|
[[ Get your papers, WIPs and posters in. (We have an exhibition hall with 25 gesture-controlled screens to show the latter two on). The deadline for abstracts and proposals is three weeks away. ]] [[ Notes: Colin Walker of F5 is confirmed as our Keynote speaker. http://www.f5.com ]] 19th Annual Tcl/Tk Conference (Tcl'2012) http://www.tcl.tk/community/tcl2012/ November 12 - 16, 2012 Sessions: National Museum of Health and Medicine Chicago 175 W. Washington Chicago, IL 60602 Rooms: Holiday Inn Chicago Mart Plaza 350 West Mart Center Drive Chicago, Illinois, USA Map: https://maps.google.com/maps/ms?msid=204739899073144451536.0004c144222a9036c99f6&msa=0&ll=41.885266,-87.633734&spn=0.008443,0.018818 Important Dates: Abstracts and proposals due August 27, 2012 Notification to authors September 10, 2012 WIP and BOF reservations open August 6, 2012 Author materials due October 29, 2012 Tutorials Start November 12, 2012 Conference starts November 14, 2012 Email Contact: tcl...@go... Submission of Summaries Tcl/Tk 2012 will be held in Chicago, Illinois, USA from November 12 - 16, 2012. The program committee is asking for papers and presentation proposals from anyone using or developing with Tcl/Tk (and extensions). Past conferences have seen submissions covering a wide variety of topics including: * Scientific and engineering applications * Industrial controls * Distributed applications and Network Managment * Object oriented extensions to Tcl/Tk * New widgets for Tk * Simulation and application steering with Tcl/Tk * Tcl/Tk-centric operating environments * Tcl/Tk on small and embedded devices * Medical applications and visualization * Use of different programming paradigms in Tcl/Tk and proposals for new directions. * New areas of exploration for the Tcl/Tk language Submissions should consist of an abstract of about 100 words and a summary of not more than two pages, and should be sent as plain text to <tclconference AT googlegroups DOT com> no later than August 27, 2012. Authors of accepted abstracts will have until October 29, 2012 to submit their final paper for the inclusion in the conference proceedings. The proceedings will be made available on digital media, so extra materials such as presentation slides, code examples, code for extensions etc. are encouraged. Printed proceedings will be produced as an on-demand book at lulu.com The authors will have 25 minutes to present their paper at the conference. The program committee will review and evaluate papers according to the following criteria: * Quantity and quality of novel content * Relevance and interest to the Tcl/Tk community * Suitability of content for presentation at the conference Proposals may report on commercial or non-commercial systems, but those with only blatant marketing content will not be accepted. Application and experience papers need to strike a balance between background on the application domain and the relevance of Tcl/Tk to the application. Application and experience papers should clearly explain how the application or experience illustrates a novel use of Tcl/Tk, and what lessons the Tcl/Tk community can derive from the application or experience to apply to their own development efforts. Papers accompanied by non-disclosure agreements will be returned to the author(s) unread. All submissions are held in the highest confidentiality prior to publication in the Proceedings, both as a matter of policy and in accord with the U. S. Copyright Act of 1976. The primary author for each accepted paper will receive registration to the Technical Sessions portion of the conference at a reduced rate. Other Forms of Participation The program committee also welcomes proposals for panel discussions of up to 90 minutes. Proposals should include a list of confirmed panelists, a title and format, and a panel description with position statements from each panelist. Panels should have no more than four speakers, including the panel moderator, and should allow time for substantial interaction with attendees. Panels are not presentations of related research papers. Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather sessions (BOFs) are available on a first-come, first-served basis starting in August 6, 2012. Specific instructions for reserving WIP and BOF time slots will be provided in the registration information available in June 2012. Some WIP and BOF time slots will be held open for on-site reservation. All attendees with an interesting work in progress should consider reserving a WIP slot. Registration Information More information on the conference is available the conference Web site (http://www.tcl.tk/community/tcl2012/) and will be published on various Tcl/Tk-related information channels. To keep in touch with news regarding the conference and Tcl events in general, subscribe to the tcl-announce list. See: http://code.activestate.com/lists/tcl-announce to subscribe to the tcl-announce mailing list. Conference Committee Clif Flynt Noumena Corp General Chair, Website Admin Andreas Kupries ActiveState Software Inc. Program Chair Cyndy Lilagan Nat. Museum of Health & Medicine, Chicago Site/Facilities Chair Arjen Markus Deltares Brian Griffin Mentor Graphics Donal Fellows University of Manchester Gerald Lester KnG Consulting, LLC Jeffrey Hobbs ActiveState Software Inc. Kevin Kenny GE Global Research Center Larry Virden Mike Doyle National Museum of Health & Medicine, Chicago Ron Fox NSCL/FRIB Michigan State University Steve Landers Digital Smarties Contact Information tcl...@go... Tcl'2012 would like to thank those who are sponsoring the conference: ActiveState Software Inc. Buonacorsi Foundation Mentor Graphics Noumena Corp. SR Technology Tcl Community Association |