capi-sig August 2008

capi-sig@python.org

4 participants
5 discussions

Raise an error when PyObject_New is used with Py_TPFLAGS_HAVE_GC

by Duncan Webb

Hi all, I was happily using PyObject_New instead of PyObject_GC_New with flags containing Py_TPFLAGS_HAVE_GC during development of some bindings. The module was working just fine with the debug build. As soon as building a release build things started to crash and it took me about five days to figure this one out. The reason is GC decrements a counter which does not affect debug build too much but does decrement the address of a tuple in release builds. Do you think that an error could be raised when the incorrect New is used with or without the Py_TPFLAGS_HAVE_GC set? Previously I fixed up pygoom (for Freevo) to work bit I'm a bit of a newbee to writing C extensions from scratch. These bindings are to monitor and control Orbacus CORBA servers. Thanks, Duncan

12 years, 11 months

Storesonline, Ecommerce and Advertising

by Mister Nice Guy

*Storesonline, Ecommerce and Advertising* Did you know the same rules that apply for print, audio and video advertising are also true for Internet advertising? In the United States the Federal Trade Commission is charged with the enforcement of ?truth in advertising? standards ? even on the web. Interestingly, it is the web designer or advertising agency that must validate the claims of the business. Essentially the manufacturers claims must be validated if advertising is going to be distributed that will make a claim. Since the ad agency or the web designer may be held partially liable for the advertising on a site it is always in their best interest to make sure the claims of the manufacturer can be validated. Because certain product descriptions are lengthy and certain claims have conditions the use of disclaimers (or fine print) may be required to ensure you are following Internet advertising laws. The FTC does allow autoresponder emails to ?fill in the blanks? on Internet advertising in some cases. If a potential customer signs up for more information then a full-disclosure of the products claims, contest conditions or other disclaimers may be sent to the prospect as a condition of full disclosure. It is safe to say that many online businesses either are unaware of these rules or simply believe they will never be caught, but the FTC does look into fraudulent advertising ? even on the web. Understanding the rules of advertising will not only help you avoid problems later, it can actually help you devise a credible, well established advertising campaign now.

12 years, 11 months

Re: [capi-sig] Extension module with meschach library and numpy.i (SWIG)

by Juan David Hernandez

Hi, ----- Original Message ---- From: M.-A. Lemburg <mal(a)egenix.com> To: Juan David Hernandez <juandhv(a)yahoo.com> Cc: capi-sig(a)python.org Sent: Wednesday, August 6, 2008 5:31:48 PM Subject: Re: [capi-sig] Extension module with meschach library and numpy.i (SWIG) On 2008-08-06 21:17, Juan David Hernandez wrote: > There are 3 things that I'd like to know: > 1. Is this the correct way to include the meschach library ? extra_objects=['../mesch12b/meschach.a'] > 2. Is there any problem if Meschach use malloc, calloc and realloc? > 3. Is there any problem if I declare some variables as static? e.g. static MAT *M1; Hard to say... could you explain what "Meschach" is and does ? Meschach is a C-language library of routines for performing matrix computations > I'm running this on a virtual machine over ubuntu with 512MB of RAM, I know that's not too much, but I think is enough for a module (My module is not bigger than numpy!!). I can import my module on MAC OS X with more RAM (even on linux with 1GB) but when I tried to import the module with the complete sotware (others high level tools like graphics and GUI) I get the same problem The error message you are getting is generated by the dynamic linker and doesn't really have anything to do with Python. You'll likely need more RAM to your app (Linux overcommits RAM and then fails with errors such as the above if it tries to actually use the allocated RAM). That was something that I thought at the beginning, but my boss changed the limit stacksize, typing this "limit stacksize newvalue" and It run, but this is just a temporal solution. I think there is something wrong on the quantity of memory that apparently the module needs. But that's not true because when the module is imported and use its methods it uses more memory and there's not problem, Any idea? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 07 2008) >>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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

12 years, 11 months

Extension module with meschach library and numpy.i (SWIG)

by Juan David Hernandez

Hi everybody, I'm working on some functions to calculate the response of some physics models. Initially, I coded with C, nevertheless, I had to connect the physics toolbox to some graphics tools; for that reason, I decided to use python; actually python is controlling the high level interface but I decided to keep the physics core with C(performance); I'm using SWIG to connect my python high level interface with the C physics. I use numpy on python to the define the inputs and outputs for my physics toolbox. To improve the calculation time I use the meschach vectors and matrices library. This is my setup.py --- from distutils.core import setup, Extension import numpy try: numpy_include = numpy.get_include() except AttributeError: numpy_include = numpy.get_numpy_include() _cmd_wrapper = Extension("_cmd_wrapper", ["cmd_source1.c","cmd_source2.c",...], include_dirs = [numpy_include,'../mesch12b'], extra_objects=['../mesch12b/meschach.a'], libraries=['m'], ) setup (name = "cmd_wrapper", description = "CMD wrapper", version = "0.1", author = "juandhv", py_modules = ["cmd_wrapper"], ext_modules = [_cmd_wrapper] ) ---- When I try to import the result module, import cmd_wrapper, I got this error: import _cmd_wrapper ImportError: /ModCMD/_cmd_wrapper.so: failed to map segment from shared object: Cannot allocate memory There are 3 things that I'd like to know: 1. Is this the correct way to include the meschach library ? extra_objects=['../mesch12b/meschach.a'] 2. Is there any problem if Meschach use malloc, calloc and realloc? 3. Is there any problem if I declare some variables as static? e.g. static MAT *M1; I'm running this on a virtual machine over ubuntu with 512MB of RAM, I know that's not too much, but I think is enough for a module (My module is not bigger than numpy!!). I can import my module on MAC OS X with more RAM (even on linux with 1GB) but when I tried to import the module with the complete sotware (others high level tools like graphics and GUI) I get the same problem Any help I'll be thankful (sorry for any english mistake) Juan David

12 years, 11 months

Extension module with meschach library and numpy.i (SWIG)

by Juan David Hernandez

12 years, 11 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

capi-sig August 2008