http://blog.gmane.org/gmane.comp.python.egenix.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.python.egenix.user/1456 <pre>Hi, I'm attempting to run tag() on a string that has 1314211 chars in it (~1.3MB). The same program works fine on other relatively large strings, although they probably don't have as bad a structure as this particular string. Running the python program with gdb I'm getting: Program received signal SIGSEGV, Segmentation fault. 0xb7d17d2f in mxTextTools_TaggingEngine (textobj=0xb6b99008, sliceleft=422374, sliceright=1314211, table=0x84c97f0, taglist=0x85aa5cc, context=0x0, next=0xbf6ca178) at mx/TextTools/mxTextTools/mxte_impl.h:62 Is the string too long, or is something else the culprit here? Attached is tagit.tar.gz which includes tagit.py. You can run it to reproduce the segfault. thanks, ivan. _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Ivan Beschastnikh 2010-03-08T17:57:16 http://permalink.gmane.org/gmane.comp.python.egenix.user/1455 <pre> True. You'd have to use all lower or all upper case letters for the dictionary access - or use positional access to avoid any such issues. Unfortunately, the Zope Results and Record classes (see Shared/DC/ZRDB/Results.py and the Zope Record package) don't support case-insensitive field access. Regards, </pre> M.-A. Lemburg 2010-02-25T16:35:55 http://permalink.gmane.org/gmane.comp.python.egenix.user/1454 <pre> _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Fernando 2010-02-25T14:55:17 http://permalink.gmane.org/gmane.comp.python.egenix.user/1453 <pre> _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Fernando 2010-02-25T14:49:47 http://permalink.gmane.org/gmane.comp.python.egenix.user/1452 <pre> For the above to work, you have to create the tables, views, etc. without using quoted identifiers. In the above case, you seem to have a field created as "BuildCode" (with quotes). If you create this as BuildCode (without the quotes), the first example will fail, but the second will work. My suggestion is to not use quoted identifiers at all in your application or the schema definition. That way you get a more portable application. You can still use CamelCase in the definitions, queries, etc. to improve readability, but at the database kernel level, this is normally not needed. If you still need those CamelCase columns or table names for some reason, I'd suggest to use "SELECT CamelCase as "CamelCase", ..." and/or views to rebind the column names using quoted versions. </pre> M.-A. Lemburg 2010-02-25T11:25:08 http://permalink.gmane.org/gmane.comp.python.egenix.user/1451 <pre> _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Fernando 2010-02-25T10:49:26 http://permalink.gmane.org/gmane.comp.python.egenix.user/1450 <pre> mxODBC itself does not parse the SQL you pass to it. The ODBC driver and/or database do such parsing and thus it's possible that the ODBC driver can implement such conversion between mixed case and all upper case identifiers. However, I wonder why that's a problem in your case: DB2 adheres to the SQL standard which mandates to be case insensitive regarding identifiers, unless those identifiers are quoted. I'm not sure whether it's in the standard as well, but most enterprise databases use all capital letter for storing identifiers (and some even for things like user names and passwords). So you have the following situation: MyTable, MYTABLE and myTable are all the same table. The database uses MYTABLE to reference the table internally. "MyTable", "MYTABLE" and "myTable" are three different tables. Unless you have a situation where case really matters, e.g. two fields "ID" and "id", you should be able to just continue using mixed case identifiers in your Zope application (without quoting them) and have the database match these case-insensitive to what it stores internally. Here's an article about case sensitivity of DB2: http://www.ibm.com/developerworks/data/library/techarticle/0203adamache/0203adamache.html Also note that the DB2 ODBC provides quite a few options to make porting existing applications easier: http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.apdv.cli.doc/doc/r0007964.htm You can use those with mxODBC or our mxODBC Zope DA. This is the official MySQL to DB2 conversion guide: http://www.redbooks.ibm.com/abstracts/sg247093.html </pre> M.-A. Lemburg 2010-02-25T09:52:50 http://permalink.gmane.org/gmane.comp.python.egenix.user/1449 <pre> The Zope DA 1.0 defaults to using 8-bit strings for text interaction with the database. For 2.0, we are going to add an option to use Unicode or a mixed setup as well. UCS2 vs. UCS4 only affects Unicode objects, so if you don't use Unicode, there's not a lot of difference between the two builds. If you do intend to go with Unicode in the future, the question of memory consumption and conversion performance arises. Both are only relevant if you store lots of text in Unicode. UCS2 uses 2 bytes to store a single character, UCS4 4 bytes. Most ODBC drivers on Linux use 2 byte characters for Unicode, so if you use UCS4, the Zope DA would have to convert between Python's UCS4 and the driver's UCS2. Note that Python's default is UCS2 (on all platforms), because it was found to be a good compromise between memory consumption and flexibility. The glibc on Linux chose to go with UCS4, which is why many Linux distributions use UCS4 as default Python build. The BSDs are yet undecided: FreeBSD now ships with UCS4 as default build. Mac OS X uses UCS2. UCS4 makes things easier for Asian scripts, since these sometimes use characters outside the UCS2 range. In such a case, UCS2 has to use 2 storage units to store a single characters (the so-called surrogates). UCS4 avoids this, since a single storage unit can handle all Unicode characters. However, it's not the all-inclusive "doesn't break when sliced" solution that some propagate it as. Just like UCS2, UCS4 has the same problems with slicing when it comes to combining characters, e.g. an "e" combined with a "´" to form "é". Hope that provides some guidelines. Regards, </pre> M.-A. Lemburg 2010-02-25T09:10:40 http://permalink.gmane.org/gmane.comp.python.egenix.user/1448 <pre>Hi, I have a zope Intranet website with a MySQL backend and I'm tasked to migrate from MySQL to DB2 Express (the official dbms). Zope will also have to go away sooner or later, but I the first step is the DBMS. The problem I'm facing with, is that DB2 "prefers" to work with tables and field names in capitals, whereas the db in MySQL mixes case. That means that I cannot migrate transparently, at first sight. I could change the SQL statements to use quotes and force the mixed case, but it's still quite a bit of work. I could migrate to a capital case system and change the zope front-end, but that's even more work. Now, I also have a MS-Access frontend and as a matter of fact the ODBC layer (or MS Access) takes care of transparently converting from mixed to capital case and vice-versa. I was wondering if the mxODBC interface for DB2 can actually do the same? Regards, Fernando _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Fernando Martins 2010-02-25T08:56:38 http://permalink.gmane.org/gmane.comp.python.egenix.user/1447 <pre>Hi, Our application only require support latin-1 character. Do you reccomend to use UCS2 version of mxODBCZopeDA for Linux ? If we use UCS4, does it going to use more memory ? Regards, Baiju M _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Baiju M 2010-02-25T06:55:36 http://permalink.gmane.org/gmane.comp.python.egenix.user/1446 <pre> BTW: There's one catch with the iODBC manager that you run into: It defaults to using the 4-byte wchar_t type for Unicode on Linux. Since many ODBC drivers follow the MS ODBC standard which uses a 2-byte wchar_t type for Unicode, iODBC will cause problems when used with these drivers and Unicode. It does not appear to be easily possible to compile iODBC to use a 2-byte Unicode type, short of editing sqltypes.h to force use a 2-byte type. unixODBC uses the 2-byte Unicode type on Linux per default, so you don't run into these issues, but you have other issues related to a few length types being 4 bytes on older versions and 8 bytes in more recent ones on 64-bit Linux - which iODBC doesn't have. </pre> M.-A. Lemburg 2010-02-24T23:15:58 http://permalink.gmane.org/gmane.comp.python.egenix.user/1445 <pre> We have now spoken to EasySoft who maintain unixODBC: they apparently switched two important variable types between the releases 2.2.12 and 2.2.13 of the unixODBC manager. In 2.2.12, unixODBC defaults to using 32-bit values for the SQLLEN/SQLULEN types. In 2.2.14, it defaults to 64-bit values. Unfortunately, they left the library version name at the same libodbc.so.1.0.0, so the linker won't hint you to a possible problem with the API change. Our products are built against unixODBC 2.2.12 and use its default settings. As a result they use 32-bit values for all SQLLEN/SQLULEN parameters. When used against a 2.2.14+ unixODBC manager library, the linker won't complain (it sees the same version on the file), but all calls will end up creating a garbled stack. Now, to make things even more interesting, the Oracle driver for 64-bit Linux uses 64-bit SQLLEN values as well, so you can't use it with unixODBC 2.2.12, but you should be able to use it with 2.2.14 or a later version. Note that iODBC, the other ODBC manager for Unix, still uses the 32-bit defaults. We'll have to find a way to make all this just magically work in some way. 64-bit ODBC is a real mess and the fact that MS changed SQLLEN from long to long long on Win64 late in the spec process and after Unix 64-bit platforms had already adopted the 32-bit interpretation didn't really help either. </pre> M.-A. Lemburg 2010-02-16T11:58:12 http://permalink.gmane.org/gmane.comp.python.egenix.user/1444 <pre>Thanks Marc &amp; Charlie for your valuable comments. We will these options. P.S: We are eagerly waiting for final release of mxODBCZopeDA for Zope 2.12 with Python 2.6 in 64 bit Linux. Regards, Baiju M _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Baiju M 2010-02-06T12:22:49 http://permalink.gmane.org/gmane.comp.python.egenix.user/1443 <pre>Just to clarify: The situation with the Oracle Instant Client has gotten a lot better recently and is now updated frequently enough to base serious applications on. Charlie was referring to the early days when Oracle recommended to use the ODBC driver that comes with the Oracle server instead of the one that shipped with Oracle Instant Client. The number of reported problems with the Oracle ODBC driver has dropped to zero lately. Charlie Clark wrote: </pre> M.-A. Lemburg 2010-02-06T11:47:56 http://permalink.gmane.org/gmane.comp.python.egenix.user/1442 <pre>Am 05.02.2010, 17:10 Uhr, schrieb Baiju M &lt;mbaiju-QHTyk4n1zzFBDgjK7y7TUQ&lt; at &gt;public.gmane.org&gt;: Hiya Baiju, given a number of errors in the past we would warn against using the Oracle Instant Client and ODBC. Charlie </pre> Charlie Clark 2010-02-05T18:33:04 http://permalink.gmane.org/gmane.comp.python.egenix.user/1441 <pre> Setting up iODBC is just a straight-forward as setting up unixODBC. See e.g. this how-to: http://www.iodbc.org/dataspace/iodbc/wiki/iODBC/IODBCPythonHOWTO These are few links to the mxODBC Zope DA documentation: http://www.egenix.com/products/zope/mxODBCZopeDA/doc/#_Toc117329296 http://www.egenix.com/products/zope/mxODBCZopeDA/doc/#_Toc117329299 The mxODBC Zope DA allows you to select which ODBC manager to use on Unix - depending on which are installed. Since both managers provide more or less the same interface, it's usually best to just install one of them and select the "Platform Default" choice. This results in mxODBC Zope DA picking up the ODBC that's installed on the system and is more portable in case you plan to move the connection object to a different installation: http://www.egenix.com/products/zope/mxODBCZopeDA/doc/#_Toc117329309 </pre> M.-A. Lemburg 2010-02-05T16:24:11 http://permalink.gmane.org/gmane.comp.python.egenix.user/1440 <pre>Hi, Is there any document which explains setting up mxODBCZopeDA with iODBC in Linux. I am looking for something which use Oracle instantclient. Regards, Baiju M _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Baiju M 2010-02-05T16:10:43 http://permalink.gmane.org/gmane.comp.python.egenix.user/1439 <pre> This is the first time we hear of such a problem. Are there any entries in the Windows error log related to this ? Could you provide a test database and Python script which shows the problem ? Thanks, </pre> M.-A. Lemburg 2010-01-14T09:21:24 http://permalink.gmane.org/gmane.comp.python.egenix.user/1438 <pre> _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Bryn Divey 2010-01-14T08:40:52 http://permalink.gmane.org/gmane.comp.python.egenix.user/1437 <pre> _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users </pre> Tim Cook 2010-01-04T23:08:05 http://permalink.gmane.org/gmane.comp.python.egenix.user/1436 <pre> I've now tracked this down: The "problem" is that egenix-mx-base now provides it's own implementation of bdist_egg which easy_install use to build an egg from the source tarball. Due to the monkey patching applied by setuptools, a lot of distutils internals get modified in non-standard ways and while our bdist_egg works without problems to build the egg (e.g. if run manually), easy_install appears to expect some side effects caused by its various patched distutils commands which our version does not provide. We could provide egg files via PyPI as well, but the problem with that is ... again easy_install: it doesn't know about the difference between UCS2 and UCS4 builds of Python and so the eggs cannot use names which include this important build detail. While the system default Python installations typically use UCS4 on Linux, custom builds (as in e.g. Zope and Plone) often use the Python default UCS2. Since we're already experimenting with our own PyPI index to address the UCS2/UCS4 problem, you might want to use that for the time being... For UCS2 builds: python easy_install -i http://downloads.egenix.com/python/index/ucs2/ egenix-mx-base For UCS4 builds: python easy_install -i http://downloads.egenix.com/python/index/ucs4/ egenix-mx-base If you're using buildout, just add the correct index URL for the index to your "find-links = ..." section in buildout.cfg. See e.g. http://plone.org/documentation/manual/developer-manual/managing-projects-with-buildout/understanding-buildout.cfg for some details on how this works. In the next release of egenix-mx-base, we'll also add some support code to mxSetup.py which disables our own bdist_egg command if we find that setuptools has hooked up on distutils ;-) </pre> M.-A. Lemburg 2010-01-04T21:34:14 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.egenix.user