Stephen Warren wrote:
> On Mon, June 23, 2008 4:53 pm, Phil Dibowitz wrote:
>> Because you didn't ask for an LH type. You asked for a standard type.
>> Strings, ints, etc. I think are standard.
>
> The type of an object has absolutely nothing to do with how it was
> allocated; to return a pointer,
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)
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 cours
Andreas Schulz wrote:
> On Tuesday 24 June 2008, Andreas Schulz wrote:
>> So, maybe we can agree on the following interface:
> ...
>> void destroy_key_names(char **garbage);
> ...
>> void destroy_ir_signal(uint32_t *garbage);
> ...
>> void destroy_post_string(char *garbage);
>
> As I just recogniz
On Mon, June 23, 2008 4:31 pm, Stephen Warren wrote:
> On Mon, June 23, 2008 3:11 pm, 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 i
On Mon, June 23, 2008 4:53 pm, Phil Dibowitz wrote:
> Because you didn't ask for an LH type. You asked for a standard type.
> Strings, ints, etc. I think are standard.
The type of an object has absolutely nothing to do with how it was
allocated; to return a pointer, code could malloc() memory, ret
Stephen Warren wrote:
> 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 o
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
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 suff
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 currentl
(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
Phil Dibowitz wrote:
> Stephen Warren wrote:
>> I really don't like the static buffer used by get_key_name. ...
>
> I went back and forth on this myself. I don't like it on principal, but
> then again, libconcord also does this.
>
> They're not equivalent however... one involves working with more
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 ABI
Stephen Warren wrote:
> I really don't like the static buffer used by get_key_name. It's nasty
> that a client can only use this API on a single data blob at a time, and
> that the API internally maintains non-obvious implicit state. I'd prefer
> something more like the API below, where the XMLBuff
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_coun
Next, here comes the latest version of my IR learning patch for
libconcord. As my first try, it changes the API from one
'learnIR' function to four functions:
char *get_key_name(uint8_t *data, uint32_t size, uint32_t index);
int learn_from_remote(uint32_t *carrier_clock, uint32_t **pulses,
16 matches
Mail list logo
