On Tuesday 24 June 2008, Phil Dibowitz wrote:
Andreas Schulz wrote:
As I just recognized, better make that delete_*, to be consistent
with delete_blob..
Delete blob always deletes the same thing - in your case you have lots
of different things..
Sure, by 'delete_*' I meant of course to
On Tue, June 24, 2008 1:04 am, Andreas Schulz wrote:
So, maybe we can agree on the following interface:
That should work. Just a few mostly small comments:
In the delete_* functions, I'd use a more descriptive name for the
parameter than garbage, e.g.:
void delete_key_names(char **key_names);
(I re-added some cuts by Phil to answer both posts in one)
On Sunday 22 June 2008, Phil Dibowitz wrote:
On Sunday 22 June 2008, Stephen Warren wrote:
A pulse is usually a low-high-low transition, whereas these docs
talk about pulses and spaces. There should be differentiation between
Andreas Schulz wrote:
In the documentation for get_key_name, it may be worth mentioning that
valid index values start at 1
anything wrong with index starting at 1 for '1'st entry?
All arrays have their 1st entry at 0. That's how CS works. :)
I would say, start at 0.
I currently don't see
On Mon, June 23, 2008 3:11 pm, Andreas Schulz wrote:
On Sunday 22 June 2008, Stephen Warren wrote:
In the documentation for get_key_name, it may be worth mentioning
that valid index values start at 1
anything wrong with index starting at 1 for '1'st entry?
Probably not, but it's sufficiently
On Mon, June 23, 2008 3:28 pm, Phil Dibowitz wrote:
Andreas Schulz wrote:
Well, concordance could do that as well, so what about:
char **get_keynames(uint8_t *data, uint32_t size);
void destroy_keynames(char **names);
and be done with the XML data in one call?
I don't think we need the
Andreas Schulz wrote:
Next, here comes the latest version of my IR learning patch for
libconcord.
A few comments on the API:
+ * pulse_count : total number of pulse and space durations in pulses
+ * pulses should start with a pulse and end with a space duration,
+ * hence pulse_count
Stephen Warren wrote:
The version number of the DLL should be increased to indicate that the
API changed incompatibly.
Oh - just as a side note, please don't do this in patches. There's no
need to increase it everytime a CHECKIN causes a change. At _release_
time, I'll compare the APIs and ABIs
