From ivan at cs.washington.edu Mon Mar 8 09:57:16 2010 From: ivan at cs.washington.edu (Ivan Beschastnikh) Date: Mon Mar 8 18:58:31 2010 Subject: [egenix-users] segfault in mxte_impl.h on tag() In-Reply-To: <12233be21003071919q403fdb6exa439f0f1278ed7b5@mail.gmail.com> References: <12233be21003071919q403fdb6exa439f0f1278ed7b5@mail.gmail.com> Message-ID: <12233be21003080957n681b409bi8986e9917f268bb0@mail.gmail.com> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: tagit.tar.gz Type: application/x-gzip Size: 14715 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20100308/a1f473f9/tagit.tar.bin From mal at egenix.com Mon Mar 15 18:21:31 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Mar 15 18:21:35 2010 Subject: [egenix-users] segfault in mxte_impl.h on tag() In-Reply-To: <12233be21003080957n681b409bi8986e9917f268bb0@mail.gmail.com> References: <12233be21003071919q403fdb6exa439f0f1278ed7b5@mail.gmail.com> <12233be21003080957n681b409bi8986e9917f268bb0@mail.gmail.com> Message-ID: <4B9E6C9B.2070807@egenix.com> Ivan Beschastnikh wrote: > 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 for reporting the problem. We will open a ticket for it and try to reproduce it. Regarding the size of the string: This is unlikely a problem, since mxTextTools can easily handle several GB of text. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Tue Mar 16 10:44:42 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Mar 16 10:44:46 2010 Subject: [egenix-users] segfault in mxte_impl.h on tag() In-Reply-To: <4B9E6C9B.2070807@egenix.com> References: <12233be21003071919q403fdb6exa439f0f1278ed7b5@mail.gmail.com> <12233be21003080957n681b409bi8986e9917f268bb0@mail.gmail.com> <4B9E6C9B.2070807@egenix.com> Message-ID: <4B9F530A.1070508@egenix.com> M.-A. Lemburg wrote: > Ivan Beschastnikh wrote: >> 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 for reporting the problem. We will open a ticket for it > and try to reproduce it. > > Regarding the size of the string: This is unlikely a problem, since > mxTextTools can easily handle several GB of text. So far, we've had one run with a segfault. All others (without shell limits) completed without problems. Unfortunately, that one run with the segfault did not generate a core dump, so we'll have to keep on trying. It's possible that the stack size limit is causing the core dump. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 16 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Tue Mar 16 11:02:19 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Mar 16 11:02:22 2010 Subject: [egenix-users] segfault in mxte_impl.h on tag() In-Reply-To: <4B9F530A.1070508@egenix.com> References: <12233be21003071919q403fdb6exa439f0f1278ed7b5@mail.gmail.com> <12233be21003080957n681b409bi8986e9917f268bb0@mail.gmail.com> <4B9E6C9B.2070807@egenix.com> <4B9F530A.1070508@egenix.com> Message-ID: <4B9F572B.8060806@egenix.com> M.-A. Lemburg wrote: > M.-A. Lemburg wrote: >> Ivan Beschastnikh wrote: >>> 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 for reporting the problem. We will open a ticket for it >> and try to reproduce it. >> >> Regarding the size of the string: This is unlikely a problem, since >> mxTextTools can easily handle several GB of text. > > So far, we've had one run with a segfault. All others (without > shell limits) completed without problems. > > Unfortunately, that one run with the segfault did not generate > a core dump, so we'll have to keep on trying. > > It's possible that the stack size limit is causing the core dump. Rerunning the script with just the coredumpsize limit set to unlimited results in an more or less immediate core dump, so the stack size must be cause of the problem. FWIW: The script runs through fine with a stack size of 32MB. I haven't checked the complete stack depth at the time of the core dump with an 8MB limit, but it was certainly more than 5100 level deep. Note that the tagging engine in mxTextTools does not apply any of the stack checks that Python does. Perhaps it should to give a more meaningful error message than a seg fault. In any case, the input you are passing to the script opens more than 40000 {{-braces without closing them, so it's no surprise that you're hitting the stack limit while searching for balanced braces. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 16 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From ivan at cs.washington.edu Tue Mar 16 08:05:57 2010 From: ivan at cs.washington.edu (Ivan Beschastnikh) Date: Tue Mar 16 16:06:26 2010 Subject: [egenix-users] segfault in mxte_impl.h on tag() In-Reply-To: <4B9F572B.8060806@egenix.com> References: <12233be21003071919q403fdb6exa439f0f1278ed7b5@mail.gmail.com> <12233be21003080957n681b409bi8986e9917f268bb0@mail.gmail.com> <4B9E6C9B.2070807@egenix.com> <4B9F530A.1070508@egenix.com> <4B9F572B.8060806@egenix.com> Message-ID: <12233be21003160805g48a23a2dyc428479899f66436@mail.gmail.com> Yes, it is an unfortunate string for the stack. Ideally the code would throw an exception near the stack recursion depth limit, but I'll find some other way to detect this. Thanks for the work on this. ivan. On Tue, Mar 16, 2010 at 3:02 AM, M.-A. Lemburg wrote: > M.-A. Lemburg wrote: >> M.-A. Lemburg wrote: >>> Ivan Beschastnikh wrote: >>>> 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 for reporting the problem. We will open a ticket for it >>> and try to reproduce it. >>> >>> Regarding the size of the string: This is unlikely a problem, since >>> mxTextTools can easily handle several GB of text. >> >> So far, we've had one run with a segfault. All others (without >> shell limits) completed without problems. >> >> Unfortunately, that one run with the segfault did not generate >> a core dump, so we'll have to keep on trying. >> >> It's possible that the stack size limit is causing the core dump. > > Rerunning the script with just the coredumpsize limit > set to unlimited results in an more or less immediate core > dump, so the stack size must be cause of the problem. > > FWIW: The script runs through fine with a stack size of 32MB. > I haven't checked the complete stack depth at the time of > the core dump with an 8MB limit, but it was certainly more > than 5100 level deep. > > Note that the tagging engine in mxTextTools does not apply > any of the stack checks that Python does. Perhaps it should > to give a more meaningful error message than a seg fault. > > In any case, the input you are passing to the script opens > more than 40000 {{-braces without closing them, so it's > no surprise that you're hitting the stack limit while > searching for balanced braces. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source ?(#1, Mar 16 2010) >>>> Python/Zope Consulting and Support ... ? ? ? ?http://www.egenix.com/ >>>> mxODBC.Zope.Database.Adapter ... ? ? ? ? ? ? http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... ? ? ? ?http://python.egenix.com/ > ________________________________________________________________________ > > ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: > > > ? eGenix.com Software, Skills and Services GmbH ?Pastor-Loeh-Str.48 > ? ?D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > ? ? ? ? ? Registered at Amtsgericht Duesseldorf: HRB 46611 > ? ? ? ? ? ? ? http://www.egenix.com/company/contact/ > From mal at egenix.com Tue Mar 16 21:05:50 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Mar 16 21:05:55 2010 Subject: [egenix-users] segfault in mxte_impl.h on tag() In-Reply-To: <12233be21003160805g48a23a2dyc428479899f66436@mail.gmail.com> References: <12233be21003071919q403fdb6exa439f0f1278ed7b5@mail.gmail.com> <12233be21003080957n681b409bi8986e9917f268bb0@mail.gmail.com> <4B9E6C9B.2070807@egenix.com> <4B9F530A.1070508@egenix.com> <4B9F572B.8060806@egenix.com> <12233be21003160805g48a23a2dyc428479899f66436@mail.gmail.com> Message-ID: <4B9FE49E.2030207@egenix.com> Ivan Beschastnikh wrote: > Yes, it is an unfortunate string for the stack. Ideally the code would > throw an exception near the stack recursion depth limit, but I'll find > some other way to detect this. Thanks for the work on this. The problem is with defining such a limit: there's no easy and portable way to determine the number of bytes needed on the stack per call to the parsing function and neither is there an easy way to determine how much stack space is available. We could add a counter to the function, so that the user can limit the recursion depth. > ivan. > > On Tue, Mar 16, 2010 at 3:02 AM, M.-A. Lemburg wrote: >> M.-A. Lemburg wrote: >>> M.-A. Lemburg wrote: >>>> Ivan Beschastnikh wrote: >>>>> 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 for reporting the problem. We will open a ticket for it >>>> and try to reproduce it. >>>> >>>> Regarding the size of the string: This is unlikely a problem, since >>>> mxTextTools can easily handle several GB of text. >>> >>> So far, we've had one run with a segfault. All others (without >>> shell limits) completed without problems. >>> >>> Unfortunately, that one run with the segfault did not generate >>> a core dump, so we'll have to keep on trying. >>> >>> It's possible that the stack size limit is causing the core dump. >> >> Rerunning the script with just the coredumpsize limit >> set to unlimited results in an more or less immediate core >> dump, so the stack size must be cause of the problem. >> >> FWIW: The script runs through fine with a stack size of 32MB. >> I haven't checked the complete stack depth at the time of >> the core dump with an 8MB limit, but it was certainly more >> than 5100 level deep. >> >> Note that the tagging engine in mxTextTools does not apply >> any of the stack checks that Python does. Perhaps it should >> to give a more meaningful error message than a seg fault. >> >> In any case, the input you are passing to the script opens >> more than 40000 {{-braces without closing them, so it's >> no surprise that you're hitting the stack limit while >> searching for balanced braces. >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Source (#1, Mar 16 2010) >>>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >> ________________________________________________________________________ >> >> ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: >> >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 16 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From fredvd at gmail.com Tue Mar 23 16:51:39 2010 From: fredvd at gmail.com (Fred van Dijk) Date: Tue Mar 23 16:51:42 2010 Subject: [egenix-users] Using mxodbc ZopeDA 1.0.X on Snow leopard? Message-ID: <99f1890a1003230851l4deb8c1ao29f26e0f09b2905d@mail.gmail.com> Hi, I've been trying to get one of our Plone 3 systems where we use the mxODBC zope da to run on a Snow Leopard system, but I'm out of luck with the prebuilt binaries that can be downloaded. Main issue is that on 64bit enabled systems it's almost impossible to compile a 32bit python release. Last year when OS X 10.6 snow leopard was released there have been a number of issues getting correct python 2.4 support. In the Plone community there's a special buildout that compiles and patches pythons 2.4/2.5 and 2.6 from source to get everything running. But these are 64bit. That buildout is here: http://svn.plone.org/svn/collective/buildout/python Would it be possible to compile and elease an mxODBC zopeDA prebuilt for python2.4 and zope 2.10.X on Snow Leopard for 64bit? With kind regards Fred van Dijk -- Zest Software Kaasmakerstraat 44 3194 DJ Hoogvliet Tel: 010-2959251 "Connect by sharing your knowledge online" From charlie at egenix.com Tue Mar 23 17:36:34 2010 From: charlie at egenix.com (Charlie Clark) Date: Tue Mar 23 17:36:38 2010 Subject: [egenix-users] Using mxodbc ZopeDA 1.0.X on Snow leopard? In-Reply-To: <99f1890a1003230851l4deb8c1ao29f26e0f09b2905d@mail.gmail.com> References: <99f1890a1003230851l4deb8c1ao29f26e0f09b2905d@mail.gmail.com> Message-ID: Am 23.03.2010, 16:51 Uhr, schrieb Fred van Dijk : > Hi, > I've been trying to get one of our Plone 3 systems where we use the > mxODBC zope da to run on a Snow Leopard system, but I'm out of luck > with the prebuilt binaries that can be downloaded. > Main issue is that on 64bit enabled systems it's almost impossible to > compile a 32bit python release. Last year when OS X 10.6 snow leopard > was released there have been a number of issues getting correct python > 2.4 support. In the Plone community there's a special buildout that > compiles and patches > pythons 2.4/2.5 and 2.6 from source to get everything running. But > these are 64bit. That buildout is here: > http://svn.plone.org/svn/collective/buildout/python I remember - Apple hacked their own version of Python together and didn't give anyone the fixes. > Would it be possible to compile and elease an mxODBC zopeDA prebuilt > for python2.4 and zope 2.10.X on Snow Leopard for 64bit? There are two problems: firstly, Python 2.4 isn't supported on OS X 10.6 by anyone; secondly, Apple have made ODBC support more difficult. I think a build is possible on request but we won't be releasing 1.0 for OS X 10.6 as a buildout-compatible 2.0 release is nearly ready. Charlie -- Charlie Clark eGenix.com Professional Python Services directly from the Source >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From info at egenix.com Wed Mar 24 13:36:13 2010 From: info at egenix.com (eGenix Team: M.-A. Lemburg) Date: Wed Mar 24 13:38:53 2010 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 2.0.0 Message-ID: <4BAA073D.8070700@egenix.com> ________________________________________________________________________ ANNOUNCEMENT mxODBC Zope Database Adapter Version 2.0.0 for Zope and the Plone CMS Available for Zope 2.12 and later on Windows, Linux, Mac OS X, FreeBSD and other platforms This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mxODBC-Zope-DA-2.0.0-GA.html ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter allows you to easily connect your Zope or Plone installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. The mxODBC Zope Database Adapter is highly portable, just like Zope itself and provides a high performance interface to all your ODBC data sources, using a single well-supported interface on Windows, Linux, Mac OS X, FreeBSD and other platforms. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority, establishing an excellent basis and scalable solution for your Plone CMS. ________________________________________________________________________ NEWS We are pleased to announce a new version 2.0 of our mxODBC Zope DA product. The new version was changes to conform with the new Zope 2.12 layout and installation system and includes many enhancements over our previous 1.0 version: * Includes mxODBC 3.1 with updated support for many current ODBC drivers, giving you more portability and features for a wider range of database backends. * Mac OS X 10.6 (Snow Leopard) support. * Python 2.5 and 2.6 support. * Zero maintenance support to automatically reconnect the Zope connection after a network or database problem. * More flexible Unicode support with options to work with pure Unicode, plain strings or mixed setups - even for databases that don't support Unicode * Automatic and transparent text encoding and decoding * More flexible date/time support including options to work with Python datetime objects, mxDateTime, strings or tuples * New decimal support to have the Zope DA return decimal column values using Python's decimal objects. * Fully eggified to simplify easy_install and buildout based installation ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA 1.0.x licenses, we offer you a time limited upgrade option: * If you have purchased the licenses between 2009-06-01 and 2009-12-31 you can get a 20% discount on the full price of version 2.0. * If you have purchased the licenses after 2010-01-01 you can get a 40% discount on the full price of version 2.0. This offer is time limited until 2010-09-30. Please write to sales@egenix.com for details on how to get the needed discount coupons. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope Database Adapter, licensing and download instructions, please visit our web-site: http://www.egenix.com/products/zope/mxODBCZopeDA/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 24 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Wed Mar 24 14:35:44 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Mar 24 14:35:47 2010 Subject: [egenix-users] Using mxodbc ZopeDA 1.0.X on Snow leopard? In-Reply-To: <99f1890a1003230851l4deb8c1ao29f26e0f09b2905d@mail.gmail.com> References: <99f1890a1003230851l4deb8c1ao29f26e0f09b2905d@mail.gmail.com> Message-ID: <4BAA1530.2050604@egenix.com> Fred van Dijk wrote: > Hi, > > I've been trying to get one of our Plone 3 systems where we use the > mxODBC zope da to run on a Snow Leopard system, but I'm out of luck > with the > prebuilt binaries that can be downloaded. > > Main issue is that on 64bit enabled systems it's almost impossible to > compile a 32bit python release. Last year when OS X 10.6 snow leopard > was released there have been a number of issues getting correct python > 2.4 support. In the Plone community there's a special buildout that > compiles and patches > pythons 2.4/2.5 and 2.6 from source to get everything running. But > these are 64bit. That buildout is here: > http://svn.plone.org/svn/collective/buildout/python > > Would it be possible to compile and elease an mxODBC zopeDA prebuilt > for python2.4 and zope 2.10.X on Snow Leopard for 64bit? As Charlie already mentioned, we've been working on a new Zope release in recent months. The GA release was today: http://www.egenix.com/company/news/eGenix-mxODBC-Zope-DA-2.0.0-GA.html While this may work with Zope 2.10, we have so far only tested it with Zope 2.12 and its new egg-based installation approach. Note that we only support Python 2.6 on Mac OS X 10.6, since Python 2.5 has some serious issues on 64-bit Macs, both in getting it configured and with the distutils version that comes with it. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 24 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/