Re: [concordance-devel] [patch 0/2] Change of libconcord API for IR codes learning - Build 20081010
Stephen Warren wrote: > Phil Dibowitz wrote: >> Stephen - I know you've been keeping Congruity in step with Andreas patches, >> but now that his patches are actually applied, you may want to make sure it >> works with CVS head. > > Yup, congruity (irlearn branch) works fine with libconcord CVS, > including for IR learning. BTW, I added a link to Congruity on the Concordance front page. It may get moved to a "links" page at some point, but for now, I think this'll work. =) -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming signature.asc Description: OpenPGP digital signature - 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=/___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [patch 0/2] Change of libconcord API for IR codes learning - Build 20081010
Stephen Warren wrote: > Phil Dibowitz wrote: >> Stephen - I know you've been keeping Congruity in step with Andreas patches, >> but now that his patches are actually applied, you may want to make sure it >> works with CVS head. > > Yup, congruity (irlearn branch) works fine with libconcord CVS, > including for IR learning. Great! -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming signature.asc Description: OpenPGP digital signature - 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=/___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [patch 0/2] Change of libconcord API for IR codes learning - Build 20081010
Stephen Warren wrote: > Phil Dibowitz wrote: >> Stephen - you have a patch waiting in the wings - can you send that in now? >> Sorry to make you wait so long. > > No problem; updated patch attached. Applied, thanks. -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming signature.asc Description: OpenPGP digital signature - 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=/___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [patch 0/2] Change of libconcord API for IR codes learning - Build 20081010
Phil Dibowitz wrote: > Stephen - I know you've been keeping Congruity in step with Andreas patches, > but now that his patches are actually applied, you may want to make sure it > works with CVS head. Yup, congruity (irlearn branch) works fine with libconcord CVS, including for IR learning. - 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=/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [patch 0/2] Change of libconcord API for IR codes learning - Build 20081010
Phil Dibowitz wrote:
> Stephen - you have a patch waiting in the wings - can you send that in now?
> Sorry to make you wait so long.
No problem; updated patch attached.
I have validated congruity against the resultant modified libconcord.py,
but using a previous version of Andreas's patch for the libconcord C
files. I'll validate congruity against latest concordance CVS as soon as
I can.
Patch description:
concordance/libconcord/bindings/python/README:
* Add information on how to enable the debug tracing
concordance/libconcord/bindings/python/libconcord.py:
* Add error-code constants
* Implement debug tracing
Prints all functions called, their parameters, and results
* Modify the "prototyping" mechanism for the libconcord functions, allowing
parameters to be explicitly marked as input or output (required for debug
tracing), and integrating result error-checking into the return type
definition.
* Modify formatting of new IR functions to match the rest of the file.
? libconcord/.libconcord.h.swp
? libconcord/bindings/python/.libconcord.py.swp
? libconcord/bindings/python/.swp
Index: libconcord/bindings/python/README
===
RCS file: /cvsroot/concordance/concordance/libconcord/bindings/python/README,v
retrieving revision 1.1
diff -u -p -r1.1 README
--- libconcord/bindings/python/README 15 Apr 2008 02:34:08 - 1.1
+++ libconcord/bindings/python/README 12 Oct 2008 23:07:21 -
@@ -32,3 +32,14 @@ the bindings to your PYTHONPATH. For exa
export PYTHONPATH=/path/to/libconcord/bindings/python
+Debugging
+
+
+If you set the environment variable LIBCONCORD_PY_TRACE to string "1", then
+libconcord.py will trace all function calls. This may prove helpful when
+debugging client applications.
+
+For example, in bash:
+
+LIBCONCORD_PY_TRACE=1 ./congruity /path/to/Connectivity.EZHex
+
Index: libconcord/bindings/python/libconcord.py
===
RCS file: /cvsroot/concordance/concordance/libconcord/bindings/python/libconcord.py,v
retrieving revision 1.2
diff -u -p -r1.2 libconcord.py
--- libconcord/bindings/python/libconcord.py 12 Oct 2008 22:35:26 - 1.2
+++ libconcord/bindings/python/libconcord.py 12 Oct 2008 23:07:22 -
@@ -1,7 +1,7 @@
#
-# vi: formatoptions+=tc textwidth=80 tabstop=8 shiftwidth=8 noexpandtab:
+# vi: formatoptions+=tc textwidth=80 tabstop=8 shiftwidth=4 expandtab:
#
-# $Id: libconcord.py,v 1.2 2008/10/12 22:35:26 jaymzh Exp $
+# $Id: libconcord.py,v 1.1 2008/04/08 09:50:29 jaymzh Exp $
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -18,19 +18,58 @@
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
-
from ctypes import *
+from ctypes import _Pointer
import platform
+import os
import sys
+import traceback
+
+# Debug request parsing
+
+debug = (os.environ.get("LIBCONCORD_PY_TRACE", "0") == "1")
+
+# Define the libconcord ABI this libconcord.py corresponds to
+# Bump this when the .so file version gets bumped
+
+ABI_VERSION = 0
+
+# Load the DLL
-# Internal DLL handle
if platform.system() == 'Windows':
_dll = cdll.LoadLibrary('libconcord.dll')
else:
-_dll = cdll.LoadLibrary('libconcord.so.0')
+_dll = cdll.LoadLibrary('libconcord.so.' + str(ABI_VERSION))
+
+# Public libconcord API: Custom types
+
+# typedef void (*lc_callback)(uint32_t, uint32_t, uint32_t, void*);
+callback_type = CFUNCTYPE(None, c_uint, c_uint, c_uint, py_object)
+
+# Public libconcord API: Error codes
+
+LC_ERROR = 1
+LC_ERROR_INVALID_DATA_FROM_REMOTE = 2
+LC_ERROR_READ = 3
+LC_ERROR_WRITE = 4
+LC_ERROR_INVALIDATE = 5
+LC_ERROR_ERASE = 6
+LC_ERROR_VERIFY = 7
+LC_ERROR_POST = 8
+LC_ERROR_GET_TIME = 9
+LC_ERROR_SET_TIME = 10
+LC_ERROR_CONNECT = 11
+LC_ERROR_OS = 12
+LC_ERROR_OS_NET = 13
+LC_ERROR_OS_FILE = 14
+LC_ERROR_UNSUPP = 15
+LC_ERROR_INVALID_CONFIG = 16
+LC_ERROR_IR_OVERFLOW = 17
+
+# Public libconcord API: Exception types
-# This exception may be raised by any function that returns an LC_ERROR_*.
class LibConcordException(Exception):
+"""This exception may be raised by any function that returns an LC_ERROR_*."""
def __init__(self, func, result):
self.func = func
self.result = result
@@ -47,6 +86,7 @@ class LibConcordException(Exception):
)
# Internal function result checking functionality
+
class _CheckRetCode(object):
def __init__(self, func_name):
self.func_name = func_name
@@ -57,179 +97,308 @@ class _CheckRetCode(object):
raise LibConcordException(self.func_name, result)
return result
+# Internal helpers for result prototyping
+
+class _ret(object):
+def __init__(self):
+pass
+
+class _ret_void(_ret):
+def __init__(self):
+pass
+
+def real_ctypes_type(self):
+return c_int
+
+def checker(self):
+ret
Re: [concordance-devel] [patch 0/2] Change of libconcord API for IR codes learning - Build 20081010
Andreas Schulz wrote:
> Eventually, I hope that I got most of Phil's and Stephen's remarks into this
> patch. Patch is against the current CVS status (as of 2008-10-10).
Applied. Thank you for your patience and all of your work. This is a really
great patch, and our IR code is MUCH better because of it.
Stephen - I know you've been keeping Congruity in step with Andreas patches,
but now that his patches are actually applied, you may want to make sure it
works with CVS head.
Stephen - you have a patch waiting in the wings - can you send that in now?
Sorry to make you wait so long.
Andreas, I'd like to get a release out with these patches in mid-late
November, and following that release will be a good time to start merging
your pronto stuff.
Everyone - anything at all waiting now should be sent! Unfortunately, I have
a pretty hectic traveling schedule starting this coming week for a few
weeks, but I really want to get back to trying to make firmware work on the
rest of the non-zwave remotes...
> - Checking return codes of functions against LC_OK:
> if (try_something(data) != LC_OK) {...)
> should IMHO also replace the frequent:
> if (try_something(data)) { /* failed */...'
> to make the code more readable.
I think the later is fine, honestly. It's pretty standard in the open source
world.
--
Phil Dibowitz [EMAIL PROTECTED]
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Never write it in C if you can do it in 'awk';
Never do it in 'awk' if 'sed' can handle it;
Never use 'sed' when 'tr' can do the job;
Never invoke 'tr' when 'cat' is sufficient;
Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
signature.asc
Description: OpenPGP digital signature
-
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=/___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] [patch 0/2] Change of libconcord API for IR codes learning - Build 20081010
Eventually, I hope that I got most of Phil's and Stephen's remarks into this
patch. Patch is against the current CVS status (as of 2008-10-10).
Changes are mostly editorial, as suggested by Phil, plus a few constant
definitions and minor adjustments in the processing flow.
Added missing timeout/buffer full check detected by Stephen.
For details (relative to my previous patch) see following messages;
For details about the IR learning API, see attachment.
This patchset has been build and tested with a Harmony 785, on the
following platforms:
- LINUX (Mandriva Kernel 2.6.26.3-custom/gcc-4.3.2)
- Windows XP Home SP3 / Visual C++ Express 2008
Patchset description:
=
This patchset consists of two parts:
1/2 : changes to files in libconcord
2/2 : changes to concordance
== TODO ==
Functional:
- There are still a few functions in remote.cpp that expose
HID return values, which should return some LC_ERROR instead.
- Thinking about reasonable progress callbacks for LearnIR
(which will mean another change in the libconcord interface).
- Still no progress with PERL stuff.
- Still some tester for Mac needed.
Editorial:
- There's still lots of single-line blocks in both libconcord and
concordance that would need some braces, like:
if (foo)
printf("bar");
- We should also have some LC_OK or LC_SUCCESS (= 0), instead of returning
and checking against 0 all over the code.
- Checking return codes of functions against LC_OK:
if (try_something(data) != LC_OK) {...)
should IMHO also replace the frequent:
if (try_something(data)) { /* failed */...'
to make the code more readable.
I started to fix some of those, but didn't want to put too much into this
patch.
Andreas
Change of libconcord API for IR codes learning
==
This patch changes the part of the libconcord API releated to learning IR
signals. The main goals of the new API are:
a) allow to process LearnIR.EZTut files containing more than one key to learn
(several keys selected in the web interface)
b) allow to inject IR signals from other sources, e.g. RC5 or NEC codes or
Philips Pronto Hex format.
Also included are some minor, mostly editorial, changes to fix warnings
reported/marked by MS Visual C++ 2008 and the kdevelop editor
(see detailed descriptions for parts 1 and 2)
API change:
===
The new learning API consists of four functions, which implement distinct
processing steps of the received data. Splitting the processing allows the
application to process (i.e. to display or replace) the intermediate data.
The functions have to be called in the following order:
1) int get_key_names(uint8_t *data, uint32_t size,
char ***key_names, uint32_t *key_names_length);
To be called once in the beginning to return in key_names the key names and in
key_names_length the number of key names found in the buffer *data, i.e. the
contents of the received LearnIR.EZTut file.
Note that in post_new_code below, Logitech will only accept keynames already
present in the database or user-defined via 'Learn new Key' web page for the
current device, so it is essential to read the key names to be learned first.
For each key name, repeat the following:
2) int learn_from_remote(uint32_t *carrier_clock,
uint32_t **ir_signal, uint32_t *ir_signal_length);
Returns in carrier clock, ir_signal and ir_signal_length the IR code learned
from another remote control via Harmony IR receiver.
carrier_clock: in Hz, usually ~36000..4
*ir_signal : IR mark/space durations (alternating) in microsconds
ir_signal_length : total number of mark and space durations in ir_signal.
ir_signal will start with a mark and end with a space
duration, so ir_signal_length will always be even.
The function will stop learning when the IR signal is interrutped for longer
than 0.5 sec.
It will return with LC_ERROR_READ if no IR signal at all is received
within 5 sec.
It will return LC_ERROR_IR_OVERFLOW if the received IR signal lasts
longer than 5 sec or has filled the available buffer space.
Note: An application may also provide the IR code in this format from
some other source. In this case, it is apparently not needed to call
learn_from_remote.
3) int encode_for_posting(uint32_t carrier_clock,
uint32_t *ir_signal, uint32_t ir_signal_length,
char **encoded_signal);
Returns in *encoded_signal as a string the IR code specified by carrier_clock,
ir_signal and ir_signal_length encoded to Logitech posting string format.
Note: an application may allow to display and enter IR codes in this format,
which would provide another format to exchange learned IR codes.
4) int post_new_code(uint8_t *data, uint32_t size,
char *key_name, char *encoded_signal);
Post encoded IR-code for key_name and using additional information from
received XML *data to Logitech.
All functions return 0
