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
