Stephen Warren wrote: > On Wed, April 2, 2008 2:36 am, Phil Dibowitz wrote: >> Stephen Warren wrote: >>> In congruity, I have some code to identify the action to take for a >>> specific EzHex/EZUp file, without relying on any facet of the filename. >> I'm curious as to what you use to figure it out... there are some tells >> like firmware has '<TYPE>Firmware_Main</TYPE>' ... but not all >> of them are so straight forward - did you just pick a unique option >> from each file? > > Yes, pretty much. The algorithm will be the same as the current Python > code in congruity, with the addition of validating that there really is an > INFORMATION tag, and "IR learn" detection, which congruity didn't have.
I haven't read through your code - I did try harmonygui once, but I haven't actually looked through the code. > Your code flow suggestions sound good. I was actually going to nuke all of the read_*_from_file garbage when I got the patch to abstract that out - I'm still planning on doing that in the next day or so, so if you want you can just concentrate on porting your identify_file API. >> In fact, we could even use the appropriate MODE_* defines as the >> filetype defines if we want (obviously we wouldn't use them all, just >> MODE_WRITE_* and MODE_LEARN_IR). > > Well, we'd need to be careful that application operation mode definitions > don't creep into libconcord.h, so (from memory of the code) I imagine that > we'd end up with libconcord.h only defining the file types, and > concordance.c having a switch to map them. OK, lets just pretend I never suggested that in the first place, it was a horrible idea. :) >> So as I've worked on the XS perl wrappers (finally got everything working >> tonight I think, now I'm just cleaning stuff up), > >>From my limited knowledge of XS, I jokingly suggest it would have been > easier to port Python's ctypes module to Perl and use that instead, rather > than suffering XS:-) [Actually, all joking aside, I'm sure the Perl > community would love a ctypes module, but that's a whole other project]. HAHA! ctypes is nice. There's a lot of things that really irk me about python (http://www.phildev.net/phil/blog/index.php?title=a_perl_guy_s_honest_look_at_python&more=1&c=1&tb=1&pb=1) but ctypes is just awesome and simple and amazing. Perl6's mechanism for this, however, is also very, very sleek. I'm also starting to be a bit of a ruby fan, so expect ruby bindings as well after the perl ones are done. The hard part for the XS was not the basic wrappers - swig just reads in your header file and does all the work for you. The hard part was implementing the callback glue which as you'll see when I check it in, is way uglier than it aught to be. In fact, I implemented it twice... one way is maintainable and simple and as we add APIs we just re-run swig and all is done. The other way would require a few lines of glue logic in the C wrapper everytime we add an API call that accepts a callback - HOWEVER, its reentrant safe and generally "better." As of now, I've been working mostly with the former - but an idea struck me this morning on the treadmill on how I may be able to bend swig to my will to make the "better" solution also maintainable. [the rest was about the blob API and was put in another email] -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docs Insanity 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
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
