Sorry if these are obvious questions, but this is very not obvious to me. As I understand it right now, it's not even a question of copy and pasting files over to gr-analog, because that would overwrite the code for all the other blocks, at least when it comes to swig. So let me outline what I need to do and see how close I am to understanding this:
1) I can copy and paste the source code, the qa code and example files over to corresponding gr-analog directories 2) I have to make changes to existing swig files in gr-analog, which amounts to copying the various lines from my OOT swig into the gr-analog swig 3) I don't know if I should be copying CMakeFile stuff or touching any of that by hand. I need guidance here. Am I supposed to build this and confirm its merged correctly before I submit a pull request? Rich On Wed, Sep 23, 2015 at 12:06 PM, Tom Rondeau <t...@trondeau.com> wrote: > On Wed, Sep 23, 2015 at 2:38 PM, Richard Bell <richard.be...@gmail.com> > wrote: > >> When merging my OOT module with the forked GNU Radio base, should I hand >> copy the *.xml, *.h, *_impl.h, *_impl.cc, qa_*.cc and qa_*.h in the >> appropriate gr-analog folder locations, or should I just dump my entire OOT >> module into the top level of the GNU Radio repo? I'm not familiar enough >> with CMake and how it does its thing to think this through on my own. >> >> Rich >> > > > You need to copy your code into gr-analog and make sure that the cmake > files and swig files are also updated accordingly. > > Tom > > > > >> On Wed, Sep 23, 2015 at 11:10 AM, Marcus D. Leech <mle...@ripnet.com> >> wrote: >> >>> On 09/23/2015 02:07 PM, Dan CaJacob wrote: >>> >>> I like keeping the algorithm logic in comments. I can't count how many >>> times I have optimized something, overwriting the original readable code, >>> then come back in a few months to discover I have no idea how it works >>> anymore. >>> >>> Months? Weeks for me :) >>> >>> >>> >>> On Wed, Sep 23, 2015 at 1:54 PM Martin Braun <martin.br...@ettus.com> >>> wrote: >>> >>>> On 23.09.2015 10:39, Richard Bell wrote: >>>> > Hey everyone, >>>> > >>>> > I'm in the process of submitting my first OOT module for merge with >>>> GNU >>>> > Radio base. It's a log gain AGC which converges much faster then the >>>> > current AGCs when the input signal energy is low. I've read through >>>> the >>>> > following link: >>>> > >>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ >>>> > >>>> > 1) My first question relates to documentation. Up to now, I've added >>>> > documentation into my XML files as <doc></doc> tags. To use Doxygen, >>>> am >>>> > I correct to put them in the public *.h file? Is this the only place >>>> it >>>> > should go, or should I add it to the XML as well? I've never been able >>>> > to get my documentation to propagate through to the GRC block without >>>> > putting it into the XML, is this a sign of a problem? >>>> >>>> You should only need to put your docs in the Doxygen block. >>>> >>>> > 2) If I understand the above link correctly, I should fork GNU Radio, >>>> > create a new branch which I might call Log_AGC, add my code to that >>>> > branch and then make a pull request. Am I misunderstanding anything? >>>> >>>> That's the way to go. See also >>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Development >>>> >>>> > 3) As far as code style goes, should I avoid using >>>> > >>>> > #define DEBUG >>>> > #ifdef DEBUG >>>> > std::cout << "Debug stuff" << "\n"; >>>> > #endif >>>> >>>> Absolutely. Please use the logging interface. See also >>>> http://gnuradio.org/doc/doxygen/page_logger.html >>>> > >>>> > statements to hide debug code? That is what I currently do but I know >>>> > it's not prevalent in the source. >>>> > >>>> > 4) I currently have an Optimize option in the GRC block which picks >>>> > between the way you would write the block if you just used standard >>>> C++ >>>> > statements (not optimized) and if you use Volk (optimized). Using >>>> > control ports to compare the two, there is an improvement with volk. >>>> But >>>> > I like that someone looking into the block can see how not to do it >>>> and >>>> > then how to do it. Good for beginners jumping into GNU Radio. >>>> >>>> That's noble, but for core GNU Radio stuff it's probably best if you >>>> stick with the VOLK implementation. >>>> >>>> M >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>> -- >>> Very Respectfully, >>> >>> Dan CaJacob >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing >>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
