|
From: Dan L. <dl...@gm...> - 2008-09-10 18:25:09
|
Hi all,
I've been using Python to write GPIB code for a long time. I recently got
sick of Cygwin and decide to try things under Linux. I was really
pleasantly surprised with how easy it was to get my PCI-GPIB card
working!!!
I have made some improvements to the Python bindings, which I have
attached here as a patch:
* gpib.dev() = ibdev (sorely needed, IMHO!)
* gpib.listener() = ibln
* gpib.ask() = ibask
* all the TNONE, T10us, etc. constants for timeouts
I've also cleaned up some of the cruftier code to match normal CPython
coding standards, and I combined read/readbin and write/writebin in a sane
way that should just Do The Right Thing. As far as I can tell, those were
written as a sort of workaround by someone who wasn't used to Python's
handling of strings with embedded NUL characters. The distinction is
definitely not important in Python.
My main goal was to get PyVISA working under Linux... however I've found
that the Natl Instruments VISA libraries are binary-only, bloated, and
only designed to run on 32-bit systems. Ugh. So I have also written a
Python module called "fakevisa" which mimics the interface of PyVISA, but
can only access GPIB devices since it depends only on linux-gpib. Now my
existing PyVISA scripts work pretty much fine without needing to actually
install the VISA libs. If anyone is interested in the code, let me know.
Dan
Patch:
Index: gpibinter.c
===================================================================
--- gpibinter.c (revision 1509)
+++ gpibinter.c (working copy)
@@ -10,76 +10,62 @@
/* ----------------------------------------------------- */
-static char gpib_find__doc__[] =
+static char gpib_dev__doc__[] =
""
;
-static PyObject* gpib_find(PyObject *self, PyObject *args)
+static PyObject *gpib_dev(PyObject *self, PyObject *args)
{
- char *name;
- int ud;
+ int minor, pad, sad, timeout, send_eoi, eos_mode, ud;
- if (!PyArg_ParseTuple(args, "s",&name))
+ if (!PyArg_ParseTuple(args,
"iiiiii",&minor,&pad,&sad,&timeout,&send_eoi,&eos_mode))
return NULL;
- if((ud = ibfind(name)) & ERR){
- PyErr_SetString(GpibError,"Find Error: can't find device!");
+ ud = ibdev(minor, pad, sad, timeout, send_eoi, eos_mode);
+ if(ud & ERR)
+ {
+ PyErr_SetString(GpibError,"ibdev Error: ibdev() failed");
return NULL;
}
- return Py_BuildValue("i",ud);
+ return PyInt_FromLong(ud);
}
-static char gpib_read__doc__[] =
+static char gpib_find__doc__[] =
""
;
-static PyObject* gpib_read(PyObject *self, PyObject *args)
+static PyObject* gpib_find(PyObject *self, PyObject *args)
{
- char *result;
- int device;
- int len;
- PyObject *retval;
+ char *name;
+ int ud;
- if (!PyArg_ParseTuple(args, "ii",&device,&len))
+ if (!PyArg_ParseTuple(args, "s",&name))
return NULL;
- result = malloc(len + 1);
- if(result == NULL)
- {
- PyErr_SetString(GpibError,"Read Error: can't get Memory ");
- return NULL;
+ if((ud = ibfind(name)) & ERR){
+ PyErr_SetString(GpibError,"Find Error: can't find device!");
+ return NULL;
}
- if( ibrd(device,result,len) & ERR )
- {
- PyErr_SetString(GpibError,"Read Error: ibrd() failed");
- free(result);
- return NULL;
- }
- result[ibcnt] = '\0';
-
- retval = Py_BuildValue("s", result);
- free(result);
- return retval;
+ return PyInt_FromLong(ud);
}
-static char gpib_readbin__doc__[] =
+static char gpib_read__doc__[] =
""
;
-
-static PyObject* gpib_readbin(PyObject *self, PyObject *args)
+static PyObject* gpib_read(PyObject *self, PyObject *args)
{
char *result;
- PyObject *retval;
int device;
int len;
+ PyObject *retval;
if (!PyArg_ParseTuple(args, "ii",&device,&len))
return NULL;
- result = malloc(len + 1);
+ result = PyMem_Malloc(len);
if(result == NULL)
{
PyErr_SetString(GpibError,"Read Error: can't get Memory ");
@@ -93,12 +79,11 @@
return NULL;
}
- retval = Py_BuildValue("s#", result, ibcnt);
+ retval = PyString_FromStringAndSize(result, ibcnt);
free(result);
return retval;
}
-
static char gpib_write__doc__[] =
""
;
@@ -107,40 +92,62 @@
{
char *command;
int device;
+ int cmdlength;
+ int length=0;
- if (!PyArg_ParseTuple(args, "is",&device,&command))
+ if (!PyArg_ParseTuple(args, "is#|
i",&device,&command,&cmdlength,&length))
return NULL;
- if( ibwrt(device,command,strlen(command)) & ERR ){
+ if (!length)
+ length = cmdlength;
+ if( ibwrt(device,command,length) & ERR ){
PyErr_SetString(GpibError,"Write Error: ibwrt");
return NULL;
}
- Py_INCREF(Py_None);
- return Py_None;
+ Py_RETURN_NONE;
}
-static char gpib_writebin__doc__[] =
+static char gpib_listener__doc__[] =
""
;
-static PyObject* gpib_writebin(PyObject *self, PyObject *args)
+static PyObject* gpib_listener(PyObject *self, PyObject *args)
{
- char *command;
int device;
- int length;
- int cmdlength;
+ int pad;
+ int sad;
+ short found_listener;
- if (!PyArg_ParseTuple(args,
"is#i",&device,&command,&cmdlength,&length))
+ if (!PyArg_ParseTuple(args, "iii",&device,&pad,&sad))
return NULL;
- if( ibwrt(device,command,length) & ERR ){
- PyErr_SetString(GpibError,"Write Error: ibwrt");
+ if( ibln(device,pad,sad,&found_listener) & ERR ){
+ PyErr_SetString(GpibError,"Listener Error: ibln");
return NULL;
}
- Py_INCREF(Py_None);
- return Py_None;
+ return PyBool_FromLong(found_listener);
}
+static char gpib_ask__doc__[] =
+""
+;
+
+static PyObject* gpib_ask(PyObject *self, PyObject *args)
+{
+ int device;
+ int option;
+ int result;
+
+ if (!PyArg_ParseTuple(args, "ii",&device,&option))
+ return NULL;
+ if ( ibask(device,option,&result) & ERR){
+ PyErr_SetString(GpibError,"Ask Error: ibask");
+ return NULL;
+ }
+
+ return PyInt_FromLong(result);
+}
+
static char gpib_cmd__doc__[] =
""
;
@@ -157,8 +164,7 @@
return NULL;
}
- Py_INCREF(Py_None);
- return Py_None;
+ Py_RETURN_NONE;
}
static char gpib_ren__doc__[] =
@@ -178,8 +184,7 @@
return NULL;
}
- Py_INCREF(Py_None);
- return Py_None;
+ Py_RETURN_NONE;
}
static char gpib_clear__doc__[] =
@@ -199,8 +204,7 @@
}
- Py_INCREF(Py_None);
- return Py_None;
+ Py_RETURN_NONE;
}
static char gpib_close__doc__[] =
@@ -219,8 +223,7 @@
return NULL;
}
- Py_INCREF(Py_None);
- return Py_None;
+ Py_RETURN_NONE;
}
static char gpib_wait__doc__[] =
@@ -249,8 +252,7 @@
}
- Py_INCREF(Py_None);
- return Py_None;
+ Py_RETURN_NONE;
}
static char gpib_tmo__doc__[] =
@@ -269,8 +271,7 @@
PyErr_SetString(GpibError,"Timeout Error: ibtmo() failed");
return NULL;
}
- Py_INCREF(Py_None);
- return Py_None;
+ Py_RETURN_NONE;
}
static char gpib_rsp__doc__[] =
@@ -309,8 +310,7 @@
return NULL;
}
- Py_INCREF(Py_None);
- return Py_None;
+ Py_RETURN_NONE;
}
static char gpib_ibsta__doc__[] =
@@ -319,11 +319,7 @@
static PyObject* gpib_ibsta(PyObject *self, PyObject *args)
{
-
- if (!PyArg_ParseTuple(args, ""))
- return NULL;
-
- return Py_BuildValue("i",ibsta);
+ return PyInt_FromLong(ibsta);
}
static char gpib_ibcnt__doc__[] =
@@ -332,31 +328,30 @@
static PyObject* gpib_ibcnt(PyObject *self, PyObject *args)
{
-
- if (!PyArg_ParseTuple(args, ""))
- return NULL;
-
- return Py_BuildValue("i",ibcnt);
+ return PyInt_FromLong(ibcnt);
}
/* List of methods defined in the module */
static struct PyMethodDef gpib_methods[] = {
- {"find", gpib_find, 1, gpib_find__doc__},
- {"read", gpib_read, 1, gpib_read__doc__},
- {"readbin", gpib_readbin, 1, gpib_readbin__doc__},
- {"write", gpib_write, 1, gpib_write__doc__},
- {"writebin", gpib_writebin, 1, gpib_writebin__doc__},
- {"cmd", gpib_cmd, 1, gpib_cmd__doc__},
- {"ren", gpib_ren, 1, gpib_ren__doc__},
- {"clear", gpib_clear, 1, gpib_clear__doc__},
- {"close", gpib_close, 1, gpib_close__doc__},
- {"wait", gpib_wait, 1, gpib_wait__doc__},
- {"tmo", gpib_tmo, 1, gpib_tmo__doc__},
- {"rsp", gpib_rsp, 1, gpib_rsp__doc__},
- {"trg", gpib_trg, 1, gpib_trg__doc__},
- {"ibsta", gpib_ibsta, 1, gpib_ibsta__doc__},
- {"ibcnt", gpib_ibcnt, 1, gpib_ibcnt__doc__},
+ {"dev", gpib_dev, METH_VARARGS, gpib_dev__doc__},
+ {"find", gpib_find, METH_VARARGS, gpib_find__doc__},
+ {"read", gpib_read, METH_VARARGS, gpib_read__doc__},
+ {"readbin", gpib_read, METH_VARARGS, gpib_read__doc__},
+ {"write", gpib_write, METH_VARARGS, gpib_write__doc__},
+ {"writebin", gpib_write, METH_VARARGS, gpib_write__doc__},
+ {"listener", gpib_listener, METH_VARARGS, gpib_listener__doc__},
+ {"ask", gpib_ask, METH_VARARGS, gpib_ask__doc__},
+ {"cmd", gpib_cmd, METH_VARARGS, gpib_cmd__doc__},
+ {"ren", gpib_ren, METH_VARARGS, gpib_ren__doc__},
+ {"clear", gpib_clear, METH_VARARGS, gpib_clear__doc__},
+ {"close", gpib_close, METH_VARARGS, gpib_close__doc__},
+ {"wait", gpib_wait, METH_VARARGS, gpib_wait__doc__},
+ {"tmo", gpib_tmo, METH_VARARGS, gpib_tmo__doc__},
+ {"rsp", gpib_rsp, METH_VARARGS, gpib_rsp__doc__},
+ {"trg", gpib_trg, METH_VARARGS, gpib_trg__doc__},
+ {"ibsta", gpib_ibsta, METH_NOARGS, gpib_ibsta__doc__},
+ {"ibcnt", gpib_ibcnt, METH_NOARGS, gpib_ibcnt__doc__},
{NULL, NULL} /* sentinel */
};
@@ -379,13 +374,30 @@
/* Add some symbolic constants to the module */
d = PyModule_GetDict(m);
- GpibError = PyString_FromString("gpib.error");
+ GpibError = PyErr_NewException("gpib.GpibError", PyExc_IOError,
NULL); /*PyString_FromString("gpib.error");*/
PyDict_SetItemString(d, "error", GpibError);
+
+ /* XXXX Add constants here */
+ PyDict_SetItemString(d, "TNONE", PyInt_FromLong(0));
+ PyDict_SetItemString(d, "T10us", PyInt_FromLong(1));
+ PyDict_SetItemString(d, "T30us", PyInt_FromLong(2));
+ PyDict_SetItemString(d, "T100us", PyInt_FromLong(3));
+ PyDict_SetItemString(d, "T300us", PyInt_FromLong(4));
+ PyDict_SetItemString(d, "T1ms", PyInt_FromLong(5));
+ PyDict_SetItemString(d, "T3ms", PyInt_FromLong(6));
+ PyDict_SetItemString(d, "T10ms", PyInt_FromLong(7));
+ PyDict_SetItemString(d, "T30ms", PyInt_FromLong(8));
+ PyDict_SetItemString(d, "T100ms", PyInt_FromLong(9));
+ PyDict_SetItemString(d, "T300ms", PyInt_FromLong(10));
+ PyDict_SetItemString(d, "T1s", PyInt_FromLong(11));
+ PyDict_SetItemString(d, "T3s", PyInt_FromLong(12));
+ PyDict_SetItemString(d, "T10s", PyInt_FromLong(13));
+ PyDict_SetItemString(d, "T30s", PyInt_FromLong(14));
+ PyDict_SetItemString(d, "T100s", PyInt_FromLong(15));
+ PyDict_SetItemString(d, "T300s", PyInt_FromLong(16));
+ PyDict_SetItemString(d, "T1000s", PyInt_FromLong(17));
- /* XXXX Add constants here */
-
- /* Check for errors */
+ /* Check for errors */
if (PyErr_Occurred())
Py_FatalError("can't initialize module gpib");
}
-
Index: Gpib.py
===================================================================
--- Gpib.py (revision 1509)
+++ Gpib.py (working copy)
@@ -26,6 +26,14 @@
self.res = gpib.readbin(self.id,len)
return self.res
+ def listener(self):
+ self.res = gpib.listener(self.id,self.id,-1)
+ return self.res
+
+ def ask(self,option):
+ self.res = gpib.ask(self.id,option)
+ reutnr self.res
+
def clear(self):
gpib.clear(self.id)
|
|
From: Frank M. H. <fm...@sp...> - 2008-09-11 22:02:47
|
On Wednesday 10 September 2008 14:21, Dan Lenski wrote: > Hi all, > > I've been using Python to write GPIB code for a long time. I recently > got sick of Cygwin and decide to try things under Linux. I was really > pleasantly surprised with how easy it was to get my PCI-GPIB card > working!!! > > I have made some improvements to the Python bindings, which I have > attached here as a patch: > * gpib.dev() = ibdev (sorely needed, IMHO!) > * gpib.listener() = ibln > * gpib.ask() = ibask > * all the TNONE, T10us, etc. constants for timeouts Hi Dan, Please resend your patch to me as an attachment. Putting it inline results in the line wrapping, etc. messing it up. I intend to apply it, but I don't use the python wrapper myself, so if any python users have criticisms of the changes you should speak up now. |
|
From: Keith D. <da...@go...> - 2008-09-12 03:22:33
Attachments:
_gpibmodule.c
|
On Thu, 11 Sep 2008, Frank Mori Hess wrote: > > Please resend your patch to me as an attachment. Putting it inline results > in the line wrapping, etc. messing it up. I intend to apply it, but I > don't use the python wrapper myself, so if any python users have > criticisms of the changes you should speak up now. Uh oh, I actually have another heavily modified Python wrapper. :-O This version has: - more complete error reporting. - ibask wrapper - Faster "ask" function (write-read query). - Also works with Ines driver and compatibility library (with a #define) - Supports the lockdev library to keep multiple processes from stomping on each other (in the "find" function). Take your pick. :-) -- ------------------------------ Keith Dart <da...@go...> GPG Key Id: 57C0417D http://go/powerdroid ================================= |
|
From: Dan L. <dl...@gm...> - 2008-09-12 21:40:10
|
On Thu, 11 Sep 2008 20:22:22 -0700, Keith Dart wrote: > On Thu, 11 Sep 2008, Frank Mori Hess wrote: > > >> Please resend your patch to me as an attachment. Putting it inline >> results in the line wrapping, etc. messing it up. I intend to apply >> it, but I don't use the python wrapper myself, so if any python users >> have criticisms of the changes you should speak up now. > > Uh oh, I actually have another heavily modified Python wrapper. :-O > > This version has: > > - more complete error reporting. > - ibask wrapper > - Faster "ask" function (write-read query). - Also works with Ines > driver and compatibility library (with a #define) - Supports the lockdev > library to keep multiple processes from stomping on > each other (in the "find" function). Hi Keith, Since my previous post, I have written *another* Python wrapper... this one is based on ctypes and also has a more useful Exception class that reports the iberr code, and short and long descriptions of the error message (the same as in your code, it seems). > Take your pick. :-) Frankly, I would vote for Keith's code!!! It is much more complete than the patch I just submitted (although mine has a few minor cleanups that it lacks, I could "patch the patch" if desired). Maybe all of us writing Python wrappers for Linux-gpib should join forces??? There is another one too... http://people.debian.org/~jordens/ gpib-devices/doc/ It seems quite complete but is very complicated. What to do? Dan |
|
From: Daniel M. <dan...@im...> - 2008-09-13 09:24:14
|
On Friday 12 September 2008 23:39:59 Dan Lenski wrote: > On Thu, 11 Sep 2008 20:22:22 -0700, Keith Dart wrote: > > On Thu, 11 Sep 2008, Frank Mori Hess wrote: > >> Please resend your patch to me as an attachment. Putting it inline > >> results in the line wrapping, etc. messing it up. I intend to apply > >> it, but I don't use the python wrapper myself, so if any python users > >> have criticisms of the changes you should speak up now. Hi, I am no developer but a simple user and what is going on here in the past days makes me really happy :) We are using the existing Python wrapper and despite its shortcomings it is already quite usable and we have been able to write pretty nice applications with it. As soon as there is a consistent package with the new wrapper and hopefully some good example of the new/updated methods it provides, I will test and report feedback! Thank you very much for this effort! |
|
From: Frank M. H. <fm...@sp...> - 2008-09-13 23:29:11
|
On Friday 12 September 2008 17:39, Dan Lenski wrote: > On Thu, 11 Sep 2008 20:22:22 -0700, Keith Dart wrote: > > > > Uh oh, I actually have another heavily modified Python wrapper. :-O > > > > This version has: > > > > - more complete error reporting. > > - ibask wrapper > > - Faster "ask" function (write-read query). - Also works with Ines > > driver and compatibility library (with a #define) - Supports the > > lockdev library to keep multiple processes from stomping on > > each other (in the "find" function). > > Frankly, I would vote for Keith's code!!! It is much more complete than > the patch I just submitted (although mine has a few minor cleanups that > it lacks, I could "patch the patch" if desired). I've tried to integrate the patches from Keith and Dan, plus made some additional changes of my own (in svn now). I deliberately left out the lockdev stuff since I don't believe the binding should prohibit multiple processes from using a board. If you want that kind of functionality, I'd suggest adding support for iblock/ibunlock to the main library, then adding bindings. I also left off the "ask" part which combined a write and read into one function, as I don't want to extend the library in bindings, and it seems unlikely to provide significant speedup due to the slowness of the gpib bus. If I dropped anything else from the patches, it might just be an oversight. Also, I haven't actually tested the changes beyond making sure it compiles. |
|
From: Dan L. <dl...@gm...> - 2008-09-15 15:36:51
Attachments:
patch
|
Frank Mori Hess writes: > I've tried to integrate the patches from Keith and Dan, plus made some > additional changes of my own (in svn now). I deliberately left out the > lockdev stuff since I don't believe the binding should prohibit multiple > processes from using a board. If you want that kind of functionality, I'd > suggest adding support for iblock/ibunlock to the main library, then > adding bindings. I also left off the "ask" part which combined a write > and read into one function, as I don't want to extend the library in > bindings, and it seems unlikely to provide significant speedup due to the > slowness of the gpib bus. > > If I dropped anything else from the patches, it might just be an oversight. > > Also, I haven't actually tested the changes beyond making sure it compiles. Frank, there's still an issue with the version current in SVN: Keith's patch renamed the extension module from "gpib" to "_gpib" (probably to avoid conflict with the official version, I would assume?). Under the current build system, however, it gets put in a library named "gpib.so", which means that Python can't find and load it. To get it working again, please apply the attached patch (changes the name of the init function and module name to "gpib" again). Dan |
|
From: Frank M. H. <fm...@sp...> - 2008-09-15 21:31:42
|
On Monday 15 September 2008 11:36, Dan Lenski wrote: > To get it working again, please apply the attached patch (changes the > name of the init function and module name to "gpib" again). Thanks, I've applied your patch to svn. |
|
From: Dan L. <dl...@gm...> - 2008-09-15 16:44:55
|
On Sat, 13 Sep 2008 19:29:06 -0400, Frank Mori Hess wrote: > If I dropped anything else from the patches, it might just be an > oversight. > > Also, I haven't actually tested the changes beyond making sure it > compiles. One other small problem with Keith's patch: in case of EDRV or EFSO, it looks at the "errno" variable rather than ibcnt/ThreadIbcnt(), which gives wrong error numbers on my system at least. I'm working on some more cleanup of the code, adding documentation strings to all the functions, etc. There are a couple inconsistencies in the Python module which I'm not sure how to resolve: * Function naming: some function names are expanded, e.g. ibwrt() -> gpib.write, while others are left in their terse form, e.g. ibtrg() -> gpib.trg(). Should these be named uniformly? Should we keep the terse names or the long names? * Return values: some Python functions return their C return values (e.g. the wrappers for ibdev(), ibfind(), ibwait()). Others get the interesting return value from a C pointer, e.g. the wrappers for ibrd(), ibln(), ibask (), etc. That's all well and good I think. But many of the Python functions return *nothing* for no apparent reason. Should these just return ibsta as in C? There's no downside to this... Dan |
|
From: Frank M. H. <fm...@sp...> - 2008-09-15 21:46:45
|
On Monday 15 September 2008 12:44, Dan Lenski wrote: > * Function naming: some function names are expanded, e.g. ibwrt() -> > gpib.write, while others are left in their terse form, e.g. ibtrg() -> > gpib.trg(). Should these be named uniformly? Yes > Should we keep the terse > names or the long names? I slightly prefer the long names, but either way is fine. > * Return values: some Python functions return their C return values > (e.g. the wrappers for ibdev(), ibfind(), ibwait()). Others get the > interesting return value from a C pointer, e.g. the wrappers for ibrd(), > ibln(), ibask (), etc. That's all well and good I think. But many of > the Python functions return *nothing* for no apparent reason. Should > these just return ibsta as in C? There's no downside to this... Ok |
|
From: Dan L. <dl...@gm...> - 2008-09-16 09:34:16
Attachments:
linux-gpib.patch
|
Frank Mori Hess writes:
> On Monday 15 September 2008 12:44, Dan Lenski wrote:
>> * Function naming: some function names are expanded, e.g. ibwrt() ->
>> gpib.write, while others are left in their terse form, e.g. ibtrg() ->
>> gpib.trg(). Should these be named uniformly?
>
> Yes
>
>> Should we keep the terse
>> names or the long names?
>
> I slightly prefer the long names, but either way is fine.
>
>> * Return values: some Python functions return their C return values
>> (e.g. the wrappers for ibdev(), ibfind(), ibwait()). Others get the
>> interesting return value from a C pointer, e.g. the wrappers for ibrd(),
>> ibln(), ibask (), etc. That's all well and good I think. But many of
>> the Python functions return *nothing* for no apparent reason. Should
>> these just return ibsta as in C? There's no downside to this...
>
> Ok
You want it, you got it. Here's a patch on the current SVN. A whole
bunch of changes:
* fixed error handling to get errno from the right place
* __doc__ strings for every function (modeled on the ones Keith had written)
* a few function names made less terse:
cmd->command
tmo->timeout
trg->trigger
(I left ren, rsp, and ifc alone since remote_enable, request_serial_poll,
and interface_clear seemed unreasonable long to me, but those could be
changed as well.)
* integer constants for IbaXXXX and IbcXXXX added to the module
* all functions--that don't have something else useful to return--return
ibsta, just like the C versions
* the read() function now puts its result directly into the Python output
string, with /no copying/ from a C string to a Python string. This should
improve efficiency of large and/or frequent reads.
I'm itching to improve the Python wrapper class in Gpib.py,
but decided to restrain myself from any further changes in this patch :-)
Especially if some people are using it in its current form.
Dan
|
|
From: Frank M. H. <fm...@sp...> - 2008-09-17 18:07:19
|
On Tuesday 16 September 2008 12:33, Dan Lenski wrote: > You want it, you got it. Here's a patch on the current SVN. A whole > bunch of changes: Thanks. > * fixed error handling to get errno from the right place > * __doc__ strings for every function (modeled on the ones Keith had > written) * a few function names made less terse: > cmd->command > tmo->timeout > trg->trigger > (I left ren, rsp, and ifc alone since remote_enable, > request_serial_poll, and interface_clear seemed unreasonable long to me, > but those could be changed as well.) I'd like to keep it consistent with the full names. request_serial_poll could be shortened to just serial_poll, the others seem okay to me. > I'm itching to improve the Python wrapper class in Gpib.py, > but decided to restrain myself from any further changes in this patch > :-) Especially if some people are using it in its current form. Would you resubmit your patch with the longer names and the indentation fixed (indent with tabs)? I could do it myself, but it would probably cause you a bunch of bogus conflicts with your checkout when you update. |
|
From: Dan L. <dl...@gm...> - 2008-09-17 20:43:11
Attachments:
patch
|
Frank Mori Hess writes: >> (I left ren, rsp, and ifc alone since remote_enable, >> request_serial_poll, and interface_clear seemed unreasonable long to me, >> but those could be changed as well.) > > I'd like to keep it consistent with the full names. request_serial_poll > could be shortened to just serial_poll, the others seem okay to me. Cool, I changed these. > >> I'm itching to improve the Python wrapper class in Gpib.py, >> but decided to restrain myself from any further changes in this patch >> :-) Especially if some people are using it in its current form. > > Would you resubmit your patch with the longer names and the indentation > fixed (indent with tabs)? I could do it myself, but it would probably > cause you a bunch of bogus conflicts with your checkout when you update. Done, everything is now indented with tabs. Patch attached. Dan |
|
From: Keith D. <da...@go...> - 2008-09-18 07:17:27
|
This is all really great, thanks. I knew about the mis-reported errno, but didn't get a chance to fix it yet. I renamed the module to _gpib because I have another Python layer, named gpib.py that wraps that with additional functionality. This is somewhat common practice in the Python world. I haven't shown the gpib.py module because it introduces a number of dependencies that you don't have. It is part of a broader test and measurement framework that I've developed here. It also pulls in modules from my other open-source project, pycopia. The non-opensource parts should be open-sourced in the near future. Then those parts might be pulled out and placed into this project. But it would probably be better to make a new project that has linux-gpib as a dependency. On Wed, Sep 17, 2008 at 8:42 PM, Dan Lenski <dl...@gm...> wrote: > Frank Mori Hess writes: > > (I left ren, rsp, and ifc alone since remote_enable, >>> request_serial_poll, and interface_clear seemed unreasonable long to me, >>> but those could be changed as well.) >>> >> >> I'd like to keep it consistent with the full names. request_serial_poll >> could be shortened to just serial_poll, the others seem okay to me. >> > > Cool, I changed these. > > >> I'm itching to improve the Python wrapper class in Gpib.py, >>> but decided to restrain myself from any further changes in this patch >>> :-) Especially if some people are using it in its current form. >>> >> >> Would you resubmit your patch with the longer names and the indentation >> fixed (indent with tabs)? I could do it myself, but it would probably cause >> you a bunch of bogus conflicts with your checkout when you update. >> > > Done, everything is now indented with tabs. Patch attached. > > Dan > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > > -- -- ------------ Keith Dart ========= |
|
From: Marcos D. <md...@ex...> - 2008-09-22 14:45:18
|
On Wed, Sep 17, 2008 at 11:42:52PM -0400, Dan Lenski wrote:
> Frank Mori Hess writes:
>
> >> (I left ren, rsp, and ifc alone since remote_enable,
> >>request_serial_poll, and interface_clear seemed unreasonable long to me,
> >>but those could be changed as well.)
> >
> >I'd like to keep it consistent with the full names. request_serial_poll
> >could be shortened to just serial_poll, the others seem okay to me.
>
> Cool, I changed these.
wich would be the first version that will support this? the company
I work for maintains a software that uses the 'older' API and we would
like to mention (up to) which version of linux-gpib it's compatible
with, at least until we update to the 'new' API.
--
Marcos Dione | |/_
[ 浪人 - ronin ] | .(_)
md...@ex... | http://except.com.ar/
|
|
From: Dan L. <dl...@gm...> - 2008-09-18 09:38:07
|
On Thu, 18 Sep 2008 07:17:10 -0700, Keith Dart wrote: > This is all really great, thanks. I knew about the mis-reported errno, > but didn't get a chance to fix it yet. It's great that you offered up your patch! Seems to have gotten the ball rolling :-) > I renamed the module to _gpib because I have another Python layer, named > gpib.py that wraps that with additional functionality. This is somewhat > common practice in the Python world. Ah, gotcha. Yeah, I guess this is a common way to do an extension: a very thin C wrapper, and then a cushier Python wrapper on that. I suppose that's the purpose of the Gpib.py module in Linux-gpib right now, but it's a bit underpowered at this point... Dan |
|
From: Frank M. H. <fm...@sp...> - 2008-09-18 20:06:07
|
On Wednesday 17 September 2008 23:42, Dan Lenski wrote: > > Done, everything is now indented with tabs. Patch attached. I applied it to svn. |
|
From: Keith D. <da...@go...> - 2008-09-18 20:23:17
|
BTW, I don't see the iblck or iblock functions in the docs. Are they in the code? On Thu, Sep 18, 2008 at 8:05 PM, Frank Mori Hess <fm...@sp...>wrote: > On Wednesday 17 September 2008 23:42, Dan Lenski wrote: > > > > Done, everything is now indented with tabs. Patch attached. > > I applied it to svn. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > > -- -- ------------ Keith Dart ========= |
|
From: Frank M. H. <fm...@sp...> - 2008-09-20 02:08:53
|
On Thursday 18 September 2008 23:23, Keith Dart wrote: > BTW, I don't see the iblck or iblock functions in the docs. Are they in > the code? No, they aren't implemented anywhere in linux-gpib. |