[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) a
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) available including audio-sink and wxgui |
Date: |
Tue, 5 Jul 2005 16:24:59 -0700 |
User-agent: |
Mutt/1.5.6i |
> >I've tested some bits of the patch, and IMHO, various parts need
> >tweaks. For example the LIBGNURADIO_CORE_EXTRA_LDFLAGS is missing in
> >the src/lib/Makefile.am, the new m4 are missing in config/Makefile.am,
> Yes, I found out myself that I did write the new macros but forgot to put
> them in the Makefile.am files.
>
> >gr_libgnuradio_core_extra_ldflags.m4 should check the compiler supports
> >the option.
> Did't know (yet) how to do that.
> > To me, the createfilemapping factory should check the second
> >mapping is contiguous to the first one, pretty much the same way
> >the Cygwin patch to the mmap_tmpfile factory does.
> Is this needed?
> I did look at the cygwin code but didn't really like the code.
> I seems you try to just allocate the memomry and hope it is continuous, if
> it is not try again and again.
>From my brief look at the MSDN docs, CreateFileMapping with an hFile
of INVALID_HANDLE_VALUE looked like the way to go.
> In the end, if you stop trying after several attempts this could fail.
> While the gnuradio code does not depend on the memory being continuous.
> I searched for the places where the mapped memory is used.
> I found that all core gnuradio code only uses the first copy.
Not true. In fact, *every* block uses both the first and second
copy, they just don't know they're doing it ;-)
The second copy is implicitly used when writing, say an array that is
3/4 of the length of the buffer, but which starts 1/2 way into the
buffer. The copy operation starts at the 1/2 way point in the first
copy, and ends at the 1/4 point in the second copy, without any code
having to check for the wrap in the loop.
> But I would like to submit the patch myself to see if the patch submitting
> works (since subscribing to patch-gnuradio failed for me)
> This will give me some experience in the contribution process.
> (I am working on some more nice new features)
Fire away when you are ready!
> If you sent me the modified patch I can also do some regression tests myself
> (on, linux and windows).
> Could you also make a diff between my original patch and your modified
> patch.
> This way I can learn and it is easier for me to integrate with my latest
> gnuradio code which has a whole load of additional changes.
> "Coming soon to a gnuradio near you, gnuradioGPU"
> (This is gnuradio on the GPU, on windows and linux. For now just FIR filter
> and some basic blocks, my goal is a complete receiver on the GPU)
Sounds great.
Eric