On Sunday 22 June 2008, Stephen Warren wrote:
Phil Dibowitz wrote:
Stephen Warren wrote:
It'd be nice if all symbols (types, values, functions, etc.) were all
prefixed with e.g. IRR_/irr_ to ensure they never conflict with any
other library.
ACK for the public functions, definitely.
I highly prefer lower case.
Yeah, I meant irr_ for functions, IRR_ for defines/enums.
Accepted - admittedly, I tend to ignore the lack of distinct
namespaces in 'C'.
Doesn't the LIRC project have a library that does this kind of thing
already, that could be re-used instead of re-inventing the wheel? In
fact, don't they have a big database of key codes that might be useful?
I was going to go do some research on if another library already did
this, actually, but never got around to it. If another library already
supports the actions we're looking for with a decent API, we shouldn't
merge our own without good reason.
I took a look at LIRC. It doesn't seem like they have a separate
NEC/RC5/... protocol encode/decode library (although perhaps they have
that code just hidden inside lircd or something). I guess looking at the
Pronto format, it's also essentially just a list of mark/space timings,
so perhaps needing IR protocol encode/decode functionality isn't that
common right now, so a new library makes sense. Still, I didn't search
outside of the LIRC project yet, so that'd be worth doing too.
I have been using LIRC for a while to program undocumented codes into
my Harmony (through a second learing remote, since I didn't know about
libconcord by then). I didn't discover any remotely usable interface
inside either, except maybe if someone would write a device driver that
spits out IR codes in Harmony posting format, instead of sending the
signals to some hardware.
The LIRC devices database, except for the fact that it can be easily
edited and new codes can be added by the user, is otherwise IMHO
not even remotely a competitor to the Logitech database.
Recently, a converter for Pronto hex files to LIRC config files has been
added to LIRC, but that is no much use here either (even though it's
written in Python).
There seem to be a few tools for generating Pronto codes from NEC, RC5,
etc. - but AFIAK, all of them are for Windows (as all Pronto programming),
and most likely closed source.
Coming back to Stephen's other remarks from the first post:
On Sunday 22 June 2008, Stephen Warren wrote:
scanf_pronto_hex, printf_pronto_hex: It seems like accepting a FILE
*file or int fd instead of char *filename would be more flexible,
and avoid all the special-cases for stdout.
I guess I should probably even drop the file/stdin/stdout for good and
just leave the string-pronto_hex version, handing the responsiblity
for file/console-I/O to the caller. I just used them to start, since
scanf was easier to handle than sscanf.
For APIs that return pointers to memory, please define whether the
client or library is reponsible for de-allocating the memory, and when
this will occur. Please provide an API for clients to call to do this if
required.
Accepted (and almost completed). Just not quite sure if this will also
work with the python bindings. In addition, a single-shot application
like concordance will IMHO not actually suffer too much from a small
memory leak. I've seen other applictaions at work, running 24/7 for
weeks, where even few bytes leaking here and there eventually crashed
the system, but that's a completely different story..
When calling pronto_to_pulses, how does one initialize the pronto_hex
structure? Is there some kind of standard representation for the data in
that structure that a user would use? If so, it seems that libIRRemotes
should provide a function to parse that user input and convert it to
pronto_hex, rather than making each client application write that code
themselves.
I though it was obvious (apparently not?) that that is exactly the purpose
of (s)scanf_pronto_hex - string or text file with hex code gets in,
pronto_hex structure out.
Is this library intended to support anything other than Pronto codes
(e.g. CIR, RC5, ... encode/decode)? If not, naming the library something
with pronto in the name seems like a good idea (ignoring trademark
issues anyway.) At least, something much less generic would be good.
You probably missed the paragraph in the IGN^H^H^HREADME file:
Future extensions should also include en-/decoding of standard
IR protocols like the NEC and RC5 protocols.
Andreas
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
