[cgma-dev] CGM 13.1 and PyTAPS
Anthony Scopatz
scopatz at gmail.com
Mon Dec 16 12:36:09 CST 2013
Hi Iulian,
To differentiate in the test iGeom will have to have a version number
associated with it that is accessible from Python (probably via another
part of PyTAPS). Then you can compare the version number and execute the
appropriate part of the test.
Arguably a better solution would be for the PyTAPS wrapper function to keep
the same API it has now, test what version of igeom it has, and perform the
appropriate call. This is a much better solution because then downstream
code, tests included, won't need to change.
For further arguments sake, it is probably not the right thing to do for
the function signatures to change on micro version numbers. This is really
bad for stability. I don't know what the specific use case is here,though,
so maybe it is justified.
Be Well
Anthony
On Mon, Dec 16, 2013 at 12:04 PM, Iulian Grindeanu <iulian at mcs.anl.gov>wrote:
> Hello,
> I was giving a wrong example for what we need to accomplish.
> More exactly, the signature of scale and reflect functions are different
> in igeom.h between version 1.4.0 and 1.4.1
> Because of that, the python bindings look different (pytaps)
>
>
> The test though, should test differently, in
> <pytaps>/test/igeom/creation.py
>
> def testScale(self):
> ent = self.geom.createBrick(2, 2, 2)
> self.geom.scaleEnt(ent, [1,2,3])
> lo, hi = self.geom.getEntBoundBox(ent)
> self.assertArray(lo, [-1,-2,-3])
> self.assertArray(hi, [ 1, 2, 3])
>
> instead of calling
> self.geom.scaleEnt(ent, [1, 2, 3])
> we should call it with
> self.geom.scaleEnt(ent,[0,0,0], [1, 2, 3]) for newer version of igeom
>
> how can we differentiate in the test itself? Is there something that can
> be "exported" like a version number?
>
> In <pytaps>iGeom.c, in pytaps, we differentiate between versions, we can
> do it, because this is c code:
>
> #if IBASE_VERSION_GE(1,4,1)
> static PyObject *
> iGeomObj_scaleEnt(iGeom_Object *self,PyObject *args,PyObject *kw)
> {
> static char *kwlist[] = {"entity","point","scale",0};
> int err;
> iBaseEntity_Object *entity;
> PyObject *in_vec,*vec, *in_point, *point;
>
>
> if(!PyArg_ParseTupleAndKeywords(args,kw,"O!OO",kwlist,&iBaseEntity_Type,
> &entity,&in_point,&in_vec))
> return NULL;
>
> vec = PyArray_ToVectors(in_vec,NPY_DOUBLE,1,3,0);
> if(vec == NULL)
> return NULL;
> point = PyArray_ToVectors(in_point,NPY_DOUBLE,1,3,0);
> if(point == NULL)
> return NULL;
>
> double *coords = PyArray_DATA(vec);
> double *pt_coords = PyArray_DATA(point);
> iGeom_scaleEnt(self->handle,entity->handle,pt_coords[0], pt_coords[1],
> pt_coords[2],
> coords[0],coords[1],coords[2],
> &err);
> Py_DECREF(vec);
> Py_DECREF(point);
>
> if(checkError(self->handle,err))
> return NULL;
> Py_RETURN_NONE;
> }
> #else
> static PyObject *
> iGeomObj_scaleEnt(iGeom_Object *self,PyObject *args,PyObject *kw)
> {
> static char *kwlist[] = {"entity","scale",0};
> int err;
> iBaseEntity_Object *entity;
> PyObject *in_vec,*vec;
>
> if(!PyArg_ParseTupleAndKeywords(args,kw,"O!O",kwlist,&iBaseEntity_Type,
> &entity,&in_vec))
> return NULL;
>
> vec = PyArray_ToVectors(in_vec,NPY_DOUBLE,1,3,0);
> if(vec == NULL)
> return NULL;
>
> double *coords = PyArray_DATA(vec);
>
> iGeom_scaleEnt(self->handle,entity->handle,coords[0],coords[1],coords[2],
> &err);
> Py_DECREF(vec);
>
> if(checkError(self->handle,err))
> return NULL;
> Py_RETURN_NONE;
> }
> #endif
>
>
>
> ------------------------------
>
> On Mon, Dec 16, 2013 at 7:49 AM, Paul Wilson <wilsonp at engr.wisc.edu>wrote:
>
>> Hi Andy, Iulian,
>>
>> I've added Anthony Scopatz into this conversation, as he has a growing
>> interest in PyTAPS. He is also a python expert. I'm not sure if he is on
>> the CGMA list yet.
>>
>
> Hello All,
>
> I didn't know there was a cgma-dev list :) I have applied now.
>
>
>> <nudge>Tim was also planning to move it to bitbucket soon (last month?)
>> to facilitate collaborative development </nudge>
>>
>
> <doublenudge />
>
>
>> On 12/13/2013 12:22 PM, Iulian Grindeanu wrote:
>>
>> It looks like in python there is no equivalent to ifdefs.
>>
>> It isn't entirely clear to me what you are trying to ifdef around here.
> The code here was for the OS but Andy was mentioning code version. Still,
> I would say that the ifdef concept doesn't exactly apply. In Python, the
> API should be the same across all platforms and the implementation should
> vary based on the system you are on. Think of this kind of a
> environment-based duck typing :). It is much more normal in Python to
> write something like the following:
>
> import os
>
> def foo(x):
> if os.name == 'posix':
> rtn = x * x
> else:
> rtn = x + 42
> return rtn
>
> This is different than the version written by Iulian because you are
> guaranteed the same foo() object no matter where you are. If you are going
> to be doing this comparison a lot it might behoove you to bank the result
> globally.
>
> import os
> ON_POSIX = os.name == 'posix'
>
> def foo(x):
> if ON_POSIX:
> rtn = x * x
> else:
> rtn = x + 42
> return rtn
>
> Hope this helps!
> Be Well
> Anthony
>
>> We could simply use an if statement, but we need to have something
>> different for cgm >= 13
>> Python is an interpreted language, and we can do something like this:
>>
>> import os
>> if os.name == "posix":
>> def foo(x):
>> return x * xelse:
>> def foo(x):
>> return x + 42
>>
>>
>> Now, we need to export somehow the version from iGeom.h / iBase.h, to be
>> visible in pytaps.
>>
>> Another solution is to create an svn branch for pytaps too (I prefer not
>> to, because there is not much difference, so far) And as long as iGeom.h
>> does not change, we do not really need different branches.
>>
>> Any suggestions?
>>
>> Iulian
>>
>> ------------------------------
>>
>> Hello,
>> Does anybody know how to do ifdefs in python? Or something similar?
>> This is what I am using for pytaps built with cgm trunk (actually,
>> cgm/tags/13.1.1)
>> (you should be able to apply this patch on pytaps source, and use it also
>> for trunk version)
>>
>> Iulian
>> ------------------------------
>>
>> HI
>>
>> I think the iMesh implmentation in CGM13.1 is mismatched for the PyTAPS
>> 1.4, PyTAPS 1.4 failed to build when using CGM 13.1, but is fine with
>> 12.2. The error messages are all code issues regarding mismatched
>> arguments to functions, passing ints when it should be doubles and so on.
>>
>> I figured this should be reported here since I couldnt find PyTAPS dev
>>
>> Thanks
>>
>> Andy
>>
>>
>>
>>
>> --
>> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
>> Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal
>> Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu
>> Faculty Director, Advanced Computing Infrastructure
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20131216/e2a63366/attachment-0001.html>
More information about the cgma-dev
mailing list