discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]