tcl-tdbc — Discussion of TDBC - Tcl DataBase Connectivity - TIP #308

Re: [Tcl-tdbc] [TCLCORE] CALL FOR DISCUSSION: TDBC introspection

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

On Mon, May 17, 2010 at 11:09:50PM -0400, Kevin Kenny wrote:
> Larry McVoy wrote:
>> I am _so_ not an expert in all this stuff.
>>
>> The only question I have is has anyone looked at what perl/python/etc
>> do in this area?
>
> Yes.

And?  What was learned?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [Tcl-tdbc] [TCLCORE] CALL FOR DISCUSSION: TDBC introspection

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

Larry McVoy wrote:
> I am _so_ not an expert in all this stuff.
> 
> The only question I have is has anyone looked at what perl/python/etc
> do in this area?

Yes.

-- 
73 de ke9tv/2, Kevin

Re: [Tcl-tdbc] [TCLCORE] CALL FOR DISCUSSION: TDBC introspection

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

I am _so_ not an expert in all this stuff.

The only question I have is has anyone looked at what perl/python/etc
do in this area?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[Tcl-tdbc] CALL FOR DISCUSSION: TDBC introspection

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

CALL FOR DISCUSSION: TDBC introspection of referential integrity
constraints, and of database indices.

Purpose and scope:
==================

Donal Fellows has been experimenting with an extremely
simple object-relational mapping engine for TclOO and TDBC, which he's
begun to discuss at http://wiki.tcl.tk/26254. In a conversation on the
Tcl'ers Chat, he and I have discussed characteristics of TDBC's
introspection of the database - or rather, its lack thereof - that get
in the way. The purpose of this message is to open up discussion of
how best to add the needed functionality to TDBC.

Donal's need, as I understand it, consists of:

(a) Identifying the primary key of a table; the primary key becomes an
object's identity.

(b) Identifying foreign keys: for a table, identifying what other
tables have foreign key constraints that refer to it. Conversely, for
a table, identifying its foreign keys and the tables to which they
refer.  The columns of a table that are foreign keys can be replaced
with object identities in the object-relational mapping.

(c) Identifying the indices that apply to table columns. This
identification has the side effect of identifying unique key
constraints (which again are candidates for replacement with object
IDs). Even nonunique indices can assist developers of general
query software to suggest appropriate query designs.

Tentative proposal:
===================

This proposal is very much partly-baked and is going out primarily to
get comment. In particular, the names of methods and dictionary keys
are subject to negotiation, as are the parameters of methods.

(1) Determining primary keys.

    Each TDBC connection shall provide a method of the form:

        $connection primarykeys $table

    where $table is the name of a table in the underlying database.
    The return type of the 'primarykeys' call is a list of
    dictionaries. The list will be empty if the table lacks a primary
    key; a singleton is the table has a simple primary key, and of
    length two or more if the table has a compound primary key.
    The list elements shall have at least the keys

        columnName - Name of the column participating in the key

   and may have

        columnSequence - Ordinal position of the column in the key.
        constraintName - Name of the constraint defining the primary
                         key, if known.

   and other columns as defined by the underlying database engine.

For example, if a table has the schema

    CREATE TABLE mytable (
        id1 INT NOT NULL,
        id2 INT NOT NULL,
        moredata VARCHAR(40),
        CONSTRAINT pk_mytable PRIMARY KEY (id1, id2)
    )

then '$connection primarykeys mytable' would be expected to return
a list of two dictionaries:

    columnName id1 columnSequence 1 constraintName pk_mytable
    columnName id2 columnSequence 2 constraintName pk_mytable

(Some databases might omit the 'columnSequence' and 'constraintName'
columns; in any case, the key components are expected to be returned
in left-to-right order.)

(2) Determining foreign keys.

Each TDBC connection shall provide a method of the form:

        $connection foreignkeys \
            ?-primary tableName? ?-foreign tableName?

If neither the '-primary' nor '-foreign' option is supplied, the
results are unspecified.

If '-primary' is supplied, the set of results is restricted to
foreign keys that reference columns of the given table.  If
'-foreign' is supplied, the set or results is specified to
foreign keys that appear in the given table. It is meaningful to
specify both, to restrict results to a (usually unique) foreign
key relationship between a given pair of tables.

The result of the method is a list of dictionaries giving the
columns participating in the foreign key relationship. The
dictionaries will have at least the following keys:

        primaryTable - Table referenced by the foreign key
        primaryColumn - Column referenced by the foreign key
        foreignTable - Table in which the foreign key appears
        foreignColumn - Column name of the foreign key
        keySequence - Ordinal position of the column in the foreign
                      constraint.

It may contain the following keys, if they are meaningful to the
underlying database and specified:

        primaryConstraintName - Name of the constraint as applied to
                                the primary table
        foreignConstraintName - Name of the constraint as applied to
                                the foreign table
        updateAction - Action to take if an UPDATE operation violates
                       the constraint. May be one of
                       'cascade', 'setNull' or 'setDefault', or
                       'omitted (in which case an UPDATE that violates
                       the constraint is an error).
        deleteAction - Action to take if a DELETE operation violates
                       the constraint. May be one of 'cascade',
                       'setNull', or 'setDefault', or omitted 
        defer - Time at which the referential integrity constraint
                is validated. May be one of 'deferred', 'immediate',
                or 'nondeferrable', or omitted.

Example: If a schema contains two tables, 'department' and 'employee',
with the following definitions:

    CREATE TABLE department(
        id INT PRIMARY KEY NOT NULL,
        name VARCHAR(40)
    )
    CREATE TABLE employee(
        id INT PRIMARY KEY NOT NULL,
        departmentId INT,
        surname VARCHAR(40),
        givenname VARCHAR(40),
        CONSTRAINT fk_employee 
            FOREIGN KEY departmentId REFERENCES department(id)
            ON DELETE SET NULL
    )

then any of the three commands

    $db foreignkeys -primary department
    $db foreignkeys -foreign employee
    $db foreignkeys -primary department -foreign employee

will return a list of dicts that includes the value:

    primaryTable department primaryColumn id
        foreignTable employee foreignColumn departmentId
        foreignConstraintName fk_employee keySequence 1
        updateAction setNull

(3) Characterizing indices

Each TDBC connection shall support a method

        $db indices tableName

where tableName is the name of a table in the database.  (The
'connection' base class will also provide a synonym, 'indexes', that
forwards to 'indices'.)

If the given table is found, the method returns a list of dictionaries
describing the table columns that participate in index definitions.
Each dictionary shall include the keys,

        tableName - Name of the table (which should be the same
                    name that was passed to the 'indices' method).
        indexName - Name of the index (suitable for passing to a
                    DROP INDEX statement)
        unique - 1 if duplicate values are forbidden, 0 if duplicates
                 are allowed.
        columnName - Name of a column that participates in the index
        keySequence - Ordinal position of the column in the index
                      key.
        direction - 'asc' or 'desc' specifying the collation order.

The dictionaries may also contain the following keys if they
are meaningful in context:

        type - The type of index (one of 'btree', 'clustered',
              'content', 'hashed', or another implementation-dependent 
              type)
        cardinality - The number of rows in the index if known.
        pages - The number of pages in the index if known.
        filterCondition - If the index is a filtered index, gives the
                          filter condition (e.g., SALARY>100000) as
                          a SQL expression. Omitted if the index is
                          not a filtered index or the filter condition
                          cannot be determined.

As an example, if a table has the following definitions:

    CREATE TABLE "value"(
        id INT NOT NULL PRIMARY KEY,
        entityID INT NOT NULL,
        attributeID INT NOT NULL,
        stringValue VARCHAR(40)
    )
    CREATE UNIQUE INDEX idx_value_entity 
        ON "value"(entityID ASC, attributeID ASC)
    CREATE INDEX idx_value_attribute
        ON "value"(attributeID ASC, entityID ASC)

then the call:

    $db indices value

should return the following dictionaries:

    tableName value indexName idx_value_entity unique 1
        columnName entityID keySequence 1 direction asc
    tableName value indexName idx_value_entity unique 1
        columnName attributeID keySequence 2 direction asc
    tableName value indexName idx_value_attribute unique 0
        columnName attributeID keySequence 1 direction asc
    tableName value indexName idx_value_attribute unique 0
        columnName entityID keySequence 2 direction asc

A few notes:
============

If any names in the returned data resolve in a catalog or schema other
than the default for the connection, they should be qualified in the
returned data: 'catalogName.schemaName.objectName', or whatever is
appropriate to the database in question.

An open question for discussion is whether the returned data should be
more deeply nested; specifically, should the components of a compound
key be grouped, or should the caller perform the grouping?  

OK, time to fire potshots at the idea.

-- 
73 de ke9tv/2, Kevin

[Tcl-tdbc] 1st Call For Papers, 17th Annual Tcl/Tk Conference 2010

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

17th Annual Tcl/Tk Conference (Tcl'2010)
http://www.tcl.tk/community/tcl2010/

October 11 - 15, 2010
Hilton Suites/Conference Center

Chicago/Oakbrook Terrace, Illinois, USA

Important Dates:

Abstracts and proposals due   August   1, 2010
Notification to authors       August  15, 2010
WIP and BOF reservations open August   1, 2010
Author materials due          October  1, 2010
Tutorials Start               October 11, 2010
Conference starts             October 13, 2010

Email Contact:                tcl...@go...

Submission of Summaries

Tcl/Tk 2010 will be held in Chicago/Oakbrook Terrace, Illinois USA
from October 11 - 15, 2010. 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

This year is the third year that the Tcl community is participating in
the Google Summer of Code.  The conference program committee would
like to encourage submissions that report on the Tcl projects selected
for Google SoC 2010.

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 15,
2010. Authors of accepted abstracts will have until October 1, 2010 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 1, 2010. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in June 2010. 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/tcl2010/) 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://aspn.activestate.com/ASPN/Mail/ 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           Iomas Research, LLC             Facilities Coordination
Brian Griffin           Mentor Graphics
Ron Fox                 NSCL/FRIB Michigan State University
Arjen Markus            Deltares
Mike Doyle              Iomas Research, LLC
Gerald Lester           KnG Consulting, LLC
Donal Fellows           University of Manchester
Jeffrey Hobbs           ActiveState Software Inc.
Steve Landers           Digital Smarties
Kevin Kenny             GE Global Research Center
Ken Jones               Avia Training
Larry Virden            Tcl FAQ Maintainer
Steve Redler IV		SR Technology

Contact Information     tcl...@go...


Tcl'2010 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

[Tcl-tdbc] Profiles: the Route Beyond Basic TDBC v1

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

Hi everyone

A while ago (well, probably on October 18 if the log's metadata is 
accurate) I was discussing with Kevin whether it would be possible to 
add a feature to TDBC (in essence, it was finding out the identity of 
the row just added) and he told me that it was not possible because some 
databases - or maybe more accurately some access interfaces - did not 
support it. The full log (stripped of the wholly irrelevant other 
conversations that were ongoing at the time) is attached.

As you can see from the log, my thoughts turned to how it would be 
possible to lift TDBC up above the basic lowest-common-denominator 
level. Now I'm not at all proposing that we should force databases to 
support the features that we want to see; I actually assume that that's 
impossible (OK, an oversimplification for open-source DBs, but a 
reasonable first approximation). Instead, what I want to do is to have a 
mechanism whereby a script can find out - in a standard way - what extra 
stuff is supported over and above the TDBC base.

My idea (borrowed from "standards space") is that of a "profile", which 
is a standardized way of going beyond a base level of a standard. The 
basic concept is that there are chunks of functionality that are 
commonly supported across many DBs but not all, and that where these 
things are supported, they should be done so in the same way (or not at 
all if the profile is not supported). However, this is not just a matter 
of "everyone do the same extra methods".

The (slightly) awkward thing is that it's useful for code to be able to 
discover what profiles are supported. In particular, there needs to be a 
method (either on the connection object or the class object that 
manufactures the connection, depending on whether people believe 
profiles are a property of the DB or the TDBC driver respectively) that 
returns the list supported profiles; with that, user code can easily ask 
what are supported. Then every defined profile needs to define a name, 
and user code can just do, say:

   if {$PROFILE_NAME in [$conn supportedProfiles]} {
       ... etc. ...
   }

Note that profiles are deliberately distinct from the introspection 
system. This is because introspection only reveals the interface to a 
class, and not whether some defined semantics are supported. It's not my 
intention for this mechanism to constrain what profiles do other than in 
the area of being self-described as outlined. (A profile could introduce 
a new method, many of them, or even none - e.g., if it happens to be 
doing things like constraining the SQL dialect - and this can apply 
anywhere throughout the TDBC system.) I'd suggest that baseline TDBC 
also be listed in the profile list, but that's definitely optional from 
my perspective. I suppose this also gives a way to handle evolution of 
the required parts of TDBC, but that's strictly outside the scope of 
this modest proposal.

I suggest this here because I would like feedback from other people on 
whether this is a good idea. (If people want, I can also rework this 
message into a TIP, but I don't really think that's necessary for TDBC.)

Donal.

[Tcl-tdbc] TDBC 1.0b13 released

[Kevin K. <kev...@gm...>]

I am happy to announce release 1.0b13 of TDBC.  This is the most
recent of the frequent beta releases of the TDBC core and driver code.
This release includes the new Postgres native-code driver contributed
by Slavek Cygan, supported by Google Summer of Code 2009.

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.0b12 release:
     http://tdbc.tcl.tk/index.cgi/ci/e8ac920205

(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.0b11 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.0b13-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]
     [package require tdbc::postgres]
and
     [package require tdbc::sqlite3]

tdbc1.0b13-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.

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

Significant changes since the 1.0b12 release:

tdbc::postgres:
	The 'tdbc::postgres' driver is new in this release.  This driver
	allows TDBC to access PostgreSQL databases directly through
	libpq, without needing an intermediate ODBC layer.

tdbc::odbc:
	The 'tdbc::odbc' package now uses SQLSetConnectOption
	in place of SQLSetConnectAttr to manipulate the 'autocommit'
	flag. While this function is documented as 'obsolete', it
	is observed to give better compatibility with legacy
	ODBC drivers.

Re: [Tcl-tdbc] Postgres project update.

[Kevin K. <kev...@gm...>]

Sławomir Cygan wrote:
> Hi,
> This is the actual status of the project:
> 
> -ResultSets are implemented and working (uh. mostly).
> 
> -Up to 8.1 all test are passing, i'm doing fixes now, so I expect more
> will be passed today.
> 
> -driver recognizes only "varchar" type: Implemementing types would be
> done by small trick:
> As libpq expect types have to be precized in PQprepare() call,
> ResultSet constuctor will check if any types were set (changed from
> varchar) after "::db prepare". If yes, new postgres statement will be
> prepared (another PQprepare call), similarly to the scenario, when
> STMT_FLAG_BUSY flag is set. By doing this sql statement will be parsed
> during "db prepare",  and also type's oids will be set properly.
> 

This is great news!  I've been out of town for the last couple of days,
so I haven't been able to continue my efforts at tracking down
memory management issues.  Maybe by now you've fixed them.

I'm not sure that we need to be so very specific about the types.
When I set up the initial type system, I had two major concerns,
plus a minor one.

(1) SQL's syntax for numbers is somewhat different from Tcl's,
     so it's important to use Tcl's format conversions for things
     that we know are numeric.  For that reason, the various types
     of Booleans, integers and floating point numbers were converted.

(2) Many SQL APIs do strange things for types like BINARY and BLOB,
     where the data are a byte array rather than a character string.
     Rather than trying always to adapt to the way a database handles
     binary data in string form, the TDBC API allows the binary type
     to be set on a query as well.

(3) A minor consideration: Using Tcl's cached internal representations
     where they exist saves a little bit of time.

So it's not obvious to me that we have to follow changes to the
user-defined types at all.  Couldn't we simply adopt the rule that
any type not in our predefined set is sent to the database engine
as a string and converted there?  Am I missing something important?

-- 
73 de ke9tv/2, Kevin

[Tcl-tdbc] TDBC 1.0b12 released

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

I am happy to announce release 1.0b12 of TDBC.  This is the most
recent of the frequent beta releases 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.0b12 release:
     http://tdbc.tcl.tk/index.cgi/ci/26f1376281

(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.0b11 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.0b12-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.0b12-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.

----

Significant changes since the 1.0b11 release:

tdbc:
         A bug in an adapter for drivers that have yet to adopt method
         forwarding to define their statement and result set classes
         was fixed.  http://tdbc.tcl.tk/index.cgi/tktview?name=e70d9fdce1

tdbc::odbc:
         Several bugs in interfacing with SQL Server Express were fixed,
         and the test suite was upgraded so that SQL Server interfacing
         can be tested routinely.
         http://tdbc.tcl.tk/index.cgi/tktview?name=e70d9fdce1

Packaging:
	Missing code for tdbc::odbc was returned to the binary
         distributions.

-- 
73 de ke9tv/2, Kevin

[Tcl-tdbc] TDBC 1.0b11 released

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

I am happy to announce release 1.0b11 of TDBC.  This is the most
recent of the frequent beta releases 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.0b11 release:
     http://tdbc.tcl.tk/index.cgi/ci/26bb9fcd1e

(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.0b11 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.0b11-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.0b11-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.

----

The only significant change since the 1.0b10 release is that large
character objects in the tdbc::odbc interface no longer include extra
NUL characters in the middle of their data. [Bug ticket 04d164f7d0]


-- 
73 de ke9tv/2, Kevin

Re: [Tcl-tdbc] Tdbc drivers and threads

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

John Kim wrote:
> Is it enough if the extension is written to be "thread-oblivious" (e.g., 
> no shared global data)?
> 
> Or we expected to make things like a connection handle safely-shareable 
> between threads?
> 
> Looking at the MySQL code, I'm guessing the former is enough but I want 
> to be sure.

Thread-oblivious. I'm not expecting to share connections between
threads.  Very few database APIs can cope with such a thing.
If you want shared connections, I understand that Steve Redler
is working on a 'tdbc::network' proxy interface that uses sockets;
I suspect it could fairly easily be reworked to use threads and
memchans.

-- 
73 de ke9tv/2, Kevin

[Tcl-tdbc] Tdbc drivers and threads

[John K. <hyt...@gm...>]

Is it enough if the extension is written to be "thread-oblivious" (e.g., no
shared global data)?
Or we expected to make things like a connection handle safely-shareable
between threads?

Looking at the MySQL code, I'm guessing the former is enough but I want to
be sure.

Thanks.

-John

Re: [Tcl-tdbc] 8.5.6 support (Patrick Dunnigan)

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

Hi,
>> For VC 2005+ you need to deploy using Private Assemblies or get the 
>> user to install the VC redistributable package.  In this case a 
>> better alternative may be to statically link to the runtime libs -- 
>> this has an impact on startup time and memory consumption, but gets 
>> around the problem of the target computer not having the right 
>> libraries.
>
> The static link also requires you to get your database vendor to
> make static-link-compatible libraries. I don't know anyone who's
> successfully build the MySQL libs that way. I usually address the
This is somewhat dependent on the third-party API.
If you create a DLL that is statically linked to the VC runtime libs, 
which in turn loads a DLL that is dynamically linked to the runtime 
libs, there is generally no problem unless you move Win32 objects or 
handles across that boundary (e.g. allocate memory in one and free it in 
another).  You face a similar problem if you're building with MSVC2008 
against vendor libs that were built with MSVC2005 (or with another 
compiler, for that matter).
I've downloaded the 1.0b10 sources to do some fiddling.
>> Yes, supporting the VS compiles is horribly painful.  With Tcl.  I 
>> say "with Tcl" because my company works extensively with C/C++ 
>> sources that cross-compile on multiple platforms (Win32, Linux, 
>> Solaris, and three embedded platforms), and the Windows builds are 
>> amongst the easiest.  Tcl's makefiles by comparison are an exercise 
>> in complexity, and have the side-effect of marginalizing Windows 
>> developers (you can't exploit the MSVC tools when you're working with 
>> a makefile rather than a dsp/vcproj).
> And you can't use a .dsp/vcproj anywhere but Visual Studio. Who's 
> marginalizing whom?
I wasn't suggesting only having .dsps ;p  See below.
> Anyway, just putting that out there, it seemed relevant to this 
> discussion.  If you're interesting in trying CMake for Tcl extensions 
> and TDBC drivers let me know and I can give you a hand getting 
> something working.
>
> CMake is useful, but also involves getting downstream distributors
> tooled up for it. (ActiveState at the very least!) I'd switch in
> a heartbeat if I didn't want so much to stay compatible with the
> way that Andreas does things. (I don't lobby very hard for CMake
> because of a perceived conflict of interest. I work at GE Research,
> where CMake was invented.)
I don't know how Andreas does things, but I'm very keen to see CMake 
adopted as the official build support **for WIN32**.  I can't see a move 
away from autoconf on other platforms, and with Tcl's broad availability 
on different platforms such a move may not even be desirable.  However a 
move away from the current hand-crafted makefiles for MSVC would 
certainly be welcome, and I think that CMake fits the bill.
 From my playing with CMake so far, I'm pretty sure it can replace 
anything the current makefile.vc can do, in a far more supportable 
fashion, in a way that allows extensions to keep their build processes 
up to date with the core, and in a way that supports MSVC project files 
(not just makefiles) so that Win32 developers can make better use of 
their development tools.  What, that's my humble opinion at least, and 
what the COFFEE project is all about.

Regards,
Twylite

Re: [Tcl-tdbc] 8.5.6 support (Patrick Dunnigan)

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

Twylite wrote:
> For VC 2005+ you need to deploy using Private Assemblies or 
> get the user to install the VC redistributable package.  
> In this case a better alternative may be to statically link to the 
> runtime libs -- this has an impact on startup time and memory 
> consumption, but gets around the problem of the target computer not 
> having the right libraries.

The static link also requires you to get your database vendor to
make static-link-compatible libraries. I don't know anyone who's
successfully build the MySQL libs that way. I usually address the
problem by making the user go get the VC Redistributables. It's
awkward. (WinSxS got rid of the "DLL Hell" deployment problem and
introduced worse ones.) I also include the manifest-bundling step
in the build.

> Do anyone actually use code signing?!

Not me!

> Yes, supporting the VS compiles is horribly painful.  With Tcl.  I say 
> "with Tcl" because my company works extensively with C/C++ sources that 
> cross-compile on multiple platforms (Win32, Linux, Solaris, and three 
> embedded platforms), and the Windows builds are amongst the easiest.  
> Tcl's makefiles by comparison are an exercise in complexity, and have 
> the side-effect of marginalizing Windows developers (you can't exploit 
> the MSVC tools when you're working with a makefile rather than a 
> dsp/vcproj).

And you can't use a .dsp/vcproj anywhere but Visual Studio. Who's 
marginalizing whom?

> Anyway, just putting that out there, it seemed relevant to this 
> discussion.  If you're interesting in trying CMake for Tcl extensions 
> and TDBC drivers let me know and I can give you a hand getting something 
> working.

CMake is useful, but also involves getting downstream distributors
tooled up for it. (ActiveState at the very least!) I'd switch in
a heartbeat if I didn't want so much to stay compatible with the
way that Andreas does things. (I don't lobby very hard for CMake
because of a perceived conflict of interest. I work at GE Research,
where CMake was invented.)

-- 
73 de ke9tv/2, Kevin

Re: [Tcl-tdbc] 8.5.6 support (Patrick Dunnigan)

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

Hi,
>> I don't think that I've done makefile.vc for the drivers yet.
>> I've been using mingw/msys to do my builds; I don't have VC6 any more,
>> and any newer version of Visual Studio gives deployment headaches
>> because of nasties like code signing and not being able to depend
>> on the Windows redistributables actually being on the target system.
>>     
For VC 2005+ you need to deploy using Private Assemblies 
(http://msdn.microsoft.com/en-us/library/aa375674(VS.85).aspx 
<http://msdn.microsoft.com/en-us/library/aa375674%28VS.85%29.aspx>) or 
get the user to install the VC redistributable package 
(http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en 
<http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en>).  
In this case a better alternative may be to statically link to the 
runtime libs -- this has an impact on startup time and memory 
consumption, but gets around the problem of the target computer not 
having the right libraries.

Do anyone actually use code signing?!

> OK, that's what I figured. I may then try my hand at creating the .vc file
> for the drivers tho I've never done that sort of thing before. I'm trying to
> get several packages (tcom, tdom, freewrap, tdbc, expect, etc.) to work
> together but some work on 8.6, some on 8.5. 8.5.6 is the most common
> release.
>
> Let me just add: I know the pain you are talking about with the VS compiles,
> I've done my share of failed compiles of ports on windows using VS in the
> past and have given up running my tool on windows. Recently I rebuilt my
> laptop and downloaded VS 2008 (albeit pro not express), installed and have
> been very happy with the error free compiling so far. You are right that I
> will have to make sure the redistributables don't cause deployment
> headaches.
>   
Yes, supporting the VS compiles is horribly painful.  With Tcl.  I say 
"with Tcl" because my company works extensively with C/C++ sources that 
cross-compile on multiple platforms (Win32, Linux, Solaris, and three 
embedded platforms), and the Windows builds are amongst the easiest.  
Tcl's makefiles by comparison are an exercise in complexity, and have 
the side-effect of marginalizing Windows developers (you can't exploit 
the MSVC tools when you're working with a makefile rather than a 
dsp/vcproj).

So I've been looking at CMake (http://www.cmake.org/) as an answer to 
the problem, at least for maintaining Windows builds, and so far it 
looks positive.  CMake generates makefiles and/or project files for the 
toolchain of your choice.  Take a look at 
http://cryptdev.nfshost.com/coffee for a CMake-based build of Tcl 8.6b1 
(still a work in progress, but usable).  I've been working on CMake 
files for extensions that will work with this base cmakefile, but it's 
been a low priority task so there's nothing on the site yet.

Anyway, just putting that out there, it seemed relevant to this 
discussion.  If you're interesting in trying CMake for Tcl extensions 
and TDBC drivers let me know and I can give you a hand getting something 
working.

Regards,
Twylite

Re: [Tcl-tdbc] Slowly (VERY slowly) writing Tdbc driver for Sybase

[Tomasz K. <tk...@gm...>]

I know that Dossy did some work for AOLserver database driver stack
concerning Sybase & MSSQLServer. I haven't dived into details to add
anything useful to your discussion by myself so I would like to only
notify you about this.

Regards,
Tomasz Kosiak


---------- Forwarded message ----------
From: Kevin Kenny <ke...@ac...>
Date: Sat, Apr 25, 2009 at 5:26 AM
Subject: Re: [Tcl-tdbc] Slowly (VERY slowly) writing Tdbc driver for Sybase
To: hyt...@gm...
Cc: tcl...@li...


hyt...@gm... wrote:
> First, this is something I'm doing on my free time as a learning
> exercise--which is a couple of hours a week if I'm lucky--so if
> anybody is already doing it please cut in and spare me the trouble :)

To the best of my knowledge, nobody is working on a Sybase driver,
which if done right would also provide the foundations of a native
SQL Server driver.

> The plan:
> - Develop against the ctlib distributed with ASE 15's x86 distro,
> using Visual C++ Express 2008.  I'll provide both an nmake makefile
> and the express's project file.

OK as far as it goes.  We'll probably also want a mingw equivalent,
but someone else can handle the port once the base is done.

> - Keeping FreeTDS in mind, try (if possible) to stick with only the
> ctlib routines actually supported by the latest stable FreeTDS distro.
 > - Stick with Sybase 10's TDS, for backwards compatibility.

That's fine, too. TBDC uses prety vanilla stuff, I doubt it needs
anything that isn't "lowest common denominator"

> - Use Sybase' pub* databases for accompanying unit test code.

Uhm. Ok. If you look at the test suites for the three drivers
now in existence, they all start with an empty database and
do their own CREATE TABLE statements.  Of course, there's no
need for the database to be empty, as long as the created tables
don't collide with stuff that's already there. The three test
suites borrow large amounts of code (and the test numbers) from
each other, and I'd kind of like to keep the tests as uniform
as possible. But use your judgment.

> - No support for DBLib.  At all.

I remember DBLib. With no particular affection.

> What I'm concerned about:
> - Null handling.  This seems to be an  open question.  Any particular
> reason why this can't be a method in one of the TDBC objects (e.g.,
> the resultset)?

TIP 308 defines the semantics of NULL quite explicitly and is
consistent about it. The only 'open question' is what to do about
the incessant complaints from a few users who don't agree with
it.

> - Big/Little Endian concerns, especially when working across different
> platforms.   I'm not sure how seamless this is and how much I have to
> do on my own..

I presume you mean with the database API?  Tcl hides endianity
from you, and I seem to recall that TDS does as well.

> - Internationalization.  I think Sybase has a Japanese pub, but I
> don't read Japanese so I'm kind of stuck there :)

Tcl's internal character representation is UTF-8. If you can
configure the API so that strings are UTF-8 throughout, you're
home free.  Otherwise, Tcl has a rich encoding conversion system,
and we *do* have users who are literate in Japanese (Chinese,
Korean, etc.) who can advise and check you.

> Hopefully, the developers manual will answer most of my questions and
> concerns.

Thanks for taking this on, and welcome aboard!  I'm very glad to have
you with us.  I suggest a few things:

   - Subscribe to the 'tcl-tdbc' mailing list at SourceForge and
     ask questions there.  It's *very* low volume, don't be afraid
     to join.
   - Get TIPs 308 (http://tip.tcl.tk/308) and 350
     (http://tip.tcl.tk/350) and try to understand them. They
     go into considerable detail about the API that a driver
     needs to present.
   - Go to http://tdbc.tcl.tk/, login as 'anonymous' with the
     password that appears on the login page, and follow the
     instructions to download the source ZIP. The source code
     for the ODBC and MySQL drivers should give a decent idea
     what is to be implemented. There are also comments in
     tdbc/library/tdbc.tcl about what methods a driver needs
     to support.
   - Look through the test suites of the drivers.  It's useful
     to develop a piece at a time, with the goal to get more
     tests working at each stage. The test suites are structured
     around this idea; the earliest tests are "easy" (requiring
     only opening/closing database connections), and then they
     get "harder" as you go along.  I suggest initially treating
     all database values as character strings and deferring
     data-type specific conversions to the very end of the
     development cycle.

Let me know if you need help!

--
73 de ke9tv/2, Kevin

------------------------------------------------------------------------------
Crystal Reports &#45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty&#45;free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Tcl-tdbc mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-tdbc

Re: [Tcl-tdbc] DB2

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

Neil Madden wrote:
> Hi all,
> 
> Is anyone working on a DB2 native driver? I'm playing with the free  
> ("express") edition to evaluate its support for recursive queries, and  
> think I'll have a go at knocking up a native TDBC driver while I'm at  
> it.

I don't know of any, but DB2 supports SQL/CLI, so the ODBC driver
might work as it is.  I don't know what speed gains you might make
by using a native API.

> I'm developing a generic Datalog library for Tcl/TDBC

Wow! Do keep us posted.
-- 
73 de ke9tv/2, Kevin

Re: [Tcl-tdbc] DB2

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

Thanks Brett,

That looks very interesting. A search shows that MS SQL Server and  
Oracle both provide some support for recursive queries, and MySQL has  
some limited support planned.

Cheers,

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.

Re: [Tcl-tdbc] DB2

[Brett S. <bre...@ya...>]

> ----- Original Message ----
> From: Neil Madden <ne...@Cs...>
> To: tcl...@li...
> Sent: Saturday, April 25, 2009 5:51:41 AM
> Subject: [Tcl-tdbc] DB2
> 
> Hi all,
> 
> Is anyone working on a DB2 native driver? I'm playing with the free 
> ("express") edition to evaluate its support for recursive queries, and 
> think I'll have a go at knocking up a native TDBC driver while I'm at 
> it.
> 
> As a side note: does anyone know which other DBs provide decent 
> support for SQL recursive queries? I'm developing a generic Datalog 
> library for Tcl/TDBC and for a first pass I'd like existing RDBMSs to 
> do as much of the heavy lifting as possible. The interest in DB2 is 
> that it is one of the few that seems to implement deductive database 
> optimisations like magic sets.
> 
(magic sets....I've have to read about that)


I was just reading about this actually. PostgreSQL 8.4 (in beta now) has recursive queries capabilities, although I have not tried it out yet.

http://www.postgresql.org/docs/8.4/static/queries-with.html

As a side note, I've been planning on doing a driver for PG, but haven't started any real work yet.

Cheers,
     --brett



      

[Tcl-tdbc] DB2

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

Hi all,

Is anyone working on a DB2 native driver? I'm playing with the free  
("express") edition to evaluate its support for recursive queries, and  
think I'll have a go at knocking up a native TDBC driver while I'm at  
it.

As a side note: does anyone know which other DBs provide decent  
support for SQL recursive queries? I'm developing a generic Datalog  
library for Tcl/TDBC and for a first pass I'd like existing RDBMSs to  
do as much of the heavy lifting as possible. The interest in DB2 is  
that it is one of the few that seems to implement deductive database  
optimisations like magic sets.

Cheers,

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.

Re: [Tcl-tdbc] Slowly (VERY slowly) writing Tdbc driver for Sybase

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

hyt...@gm... wrote:
> First, this is something I'm doing on my free time as a learning
> exercise--which is a couple of hours a week if I'm lucky--so if
> anybody is already doing it please cut in and spare me the trouble :)

To the best of my knowledge, nobody is working on a Sybase driver,
which if done right would also provide the foundations of a native
SQL Server driver.

> The plan:
> - Develop against the ctlib distributed with ASE 15's x86 distro,
> using Visual C++ Express 2008.  I'll provide both an nmake makefile
> and the express's project file.

OK as far as it goes.  We'll probably also want a mingw equivalent,
but someone else can handle the port once the base is done.

> - Keeping FreeTDS in mind, try (if possible) to stick with only the
> ctlib routines actually supported by the latest stable FreeTDS distro.
 > - Stick with Sybase 10's TDS, for backwards compatibility.

That's fine, too. TBDC uses prety vanilla stuff, I doubt it needs
anything that isn't "lowest common denominator"

> - Use Sybase' pub* databases for accompanying unit test code.

Uhm. Ok. If you look at the test suites for the three drivers
now in existence, they all start with an empty database and
do their own CREATE TABLE statements.  Of course, there's no
need for the database to be empty, as long as the created tables
don't collide with stuff that's already there. The three test
suites borrow large amounts of code (and the test numbers) from
each other, and I'd kind of like to keep the tests as uniform
as possible. But use your judgment.

> - No support for DBLib.  At all.

I remember DBLib. With no particular affection.

> What I'm concerned about:
> - Null handling.  This seems to be an  open question.  Any particular
> reason why this can't be a method in one of the TDBC objects (e.g.,
> the resultset)?

TIP 308 defines the semantics of NULL quite explicitly and is
consistent about it. The only 'open question' is what to do about
the incessant complaints from a few users who don't agree with
it.

> - Big/Little Endian concerns, especially when working across different
> platforms.   I'm not sure how seamless this is and how much I have to
> do on my own..

I presume you mean with the database API?  Tcl hides endianity
from you, and I seem to recall that TDS does as well.

> - Internationalization.  I think Sybase has a Japanese pub, but I
> don't read Japanese so I'm kind of stuck there :)

Tcl's internal character representation is UTF-8. If you can
configure the API so that strings are UTF-8 throughout, you're
home free.  Otherwise, Tcl has a rich encoding conversion system,
and we *do* have users who are literate in Japanese (Chinese,
Korean, etc.) who can advise and check you.

> Hopefully, the developers manual will answer most of my questions and
> concerns.

Thanks for taking this on, and welcome aboard!  I'm very glad to have
you with us.  I suggest a few things:

    - Subscribe to the 'tcl-tdbc' mailing list at SourceForge and
      ask questions there.  It's *very* low volume, don't be afraid
      to join.
    - Get TIPs 308 (http://tip.tcl.tk/308) and 350
      (http://tip.tcl.tk/350) and try to understand them. They
      go into considerable detail about the API that a driver
      needs to present.
    - Go to http://tdbc.tcl.tk/, login as 'anonymous' with the
      password that appears on the login page, and follow the
      instructions to download the source ZIP. The source code
      for the ODBC and MySQL drivers should give a decent idea
      what is to be implemented. There are also comments in
      tdbc/library/tdbc.tcl about what methods a driver needs
      to support.
    - Look through the test suites of the drivers.  It's useful
      to develop a piece at a time, with the goal to get more
      tests working at each stage. The test suites are structured
      around this idea; the earliest tests are "easy" (requiring
      only opening/closing database connections), and then they
      get "harder" as you go along.  I suggest initially treating
      all database values as character strings and deferring
      data-type specific conversions to the very end of the
      development cycle.

Let me know if you need help!

-- 
73 de ke9tv/2, Kevin

[Tcl-tdbc] 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: [Tcl-tdbc] 8.5.6 support

[Patrick D. <pat...@ac...>]

OK, that's what I figured. I may then try my hand at creating the .vc file
for the drivers tho I've never done that sort of thing before. I'm trying to
get several packages (tcom, tdom, freewrap, tdbc, expect, etc.) to work
together but some work on 8.6, some on 8.5. 8.5.6 is the most common
release.

Let me just add: I know the pain you are talking about with the VS compiles,
I've done my share of failed compiles of ports on windows using VS in the
past and have given up running my tool on windows. Recently I rebuilt my
laptop and downloaded VS 2008 (albeit pro not express), installed and have
been very happy with the error free compiling so far. You are right that I
will have to make sure the redistributables don't cause deployment
headaches.

Patrick Dunnigan

>I don't think that I've done makefile.vc for the drivers yet.
>I've been using mingw/msys to do my builds; I don't have VC6 any more,
>and any newer version of Visual Studio gives deployment headaches
>because of nasties like code signing and not being able to depend
>on the Windows redistributables actually being on the target system.


>-- 
>73 de ke9tv/2, Kevin

Re: [Tcl-tdbc] 8.5.6 support

[Kevin K. <kk...@ny...>]

Patrick Dunnigan wrote:
> Kevin I am attempting to compile tdbc for 8.5.6 on windows using vc++ (VS
> 2008). I see a win directory and makefile.vc for the tdbc directory and it
> appears to have build successfully against 8.5.6. 
> 
> However the win directory and makefile.vc for tdbcodbc, tdbcsqlite3,
> tdbcmysql don't exist. Am I missing something? 

The drivers are built separately, since each one has a different set
of external dependencies.  Build and install tdbc, then build and
install whatever driver[s] you plan to use.

I don't think that I've done makefile.vc for the drivers yet.
I've been using mingw/msys to do my builds; I don't have VC6 any more,
and any newer version of Visual Studio gives deployment headaches
because of nasties like code signing and not being able to depend
on the Windows redistributables actually being on the target system.

Things are hectic in both my personal life and at work at the moment.
It'll be at least the weekend before I can try to debug the Windows
8.5 build.

-- 
73 de ke9tv/2, Kevin

Re: [Tcl-tdbc] 8.5.6 support

[Larry W. V. <lv...@gm...>]

On Tue, Feb 24, 2009 at 1:22 PM, Patrick Dunnigan
<pat...@ac...> wrote:
> Yes, went there and downloaded the source files.
>
> What I am saying is that the source does not appear to include all the
> makefile.vc files required to build the whole solution on windows.

Ah ha! What I see in your description is "pre-configured" versions of
the Makefiles (that's the Makefile.in). That's pretty typical to find
in a source repository snapshot of a source code distribution. The
autoconf, etc. set of tools (on Unix anyways) are used to convert the
GNU configure.in, Makefile.in, etc. into working files for a specific
environment.

Alas, I am uncertain what sort of tools are necessary to convert these
things on Windows. I presume they must be a part of Mingw <
http://wiki.tcl.tk/mingw > or some packages from Cygwin <
http://wiki.tcl.tk/cygwin > . However, I don't know for certain.

-- 
Tcl - The glue of a new generation.   http://wiki.tcl.tk/
Larry W. Virden
http://www.xanga.com/lvirden/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.