I’ll be adding the GNU Scientific Library (GSL) as a new dependency
on the trunk. GSL is a huge numerical library that’s been under
active development for more than 10 years:
Under Fedora the relevant packages are: gsl-devel gsl pygsl:
$ sudo yum install gsl-devel gsl pygsl
I’m not exactly sure of the package names under Debian or Ubuntu.
Could someone who knows please let us know and update the Debian and
Ubuntu build pages on the wiki? I’ll update the Fedora page.
gsl-1.11 is the latest, but it looks like gsl-1.10 is what’s widely
distributed. 1.10 should be fine.
On Wed, Sep 10, 2008 at 03:40:56PM -0400, Philip B. wrote:
about gsl and it builds for the beagle.
But, I am still curious, what parts of GNU Radio use gsl? Will it be
possible to deply GNU Radio apps that do not need it? Or will gsl
creep into the very core of GNU Radio?
Philip
At this instant nothing uses it.
There are some wavelet blocks and polyphase filtering coming soon that
need it.
Today’s msg was the advanced warning.
If this turns out to be a pain, we could probably make it optional,
but then we’d need (even more) conditional build stuff.
and now you toss this my way. Fortunately, OpenEmbedded already knows
There are some wavelet blocks and polyphase filtering coming soon that need it.
Today’s msg was the advanced warning.
Thanks for the warning. I’m not terribly unhappy with gsl, except that
for good performance on the OMAP3 I’d have to look into the guts to
add NEON specific routines and my todo list grows without limit
If this turns out to be a pain, we could probably make it optional,
but then we’d need (even more) conditional build stuff.
Have you ever thought about creating a structure to build sets of
blocks outside the main source tree? Having this structure in place
would be a big help for “outside” developers also.
I’ll be adding the GNU Scientific Library (GSL) as a new dependency
on the trunk. GSL is a huge numerical library that’s been under
active development for more than 10 years:
I’ve been making progress getting GNU Radio trunk running on the OMAP3
and now you toss this my way. Fortunately, OpenEmbedded already knows
about gsl and it builds for the beagle.
But, I am still curious, what parts of GNU Radio use gsl? Will it be
possible to deply GNU Radio apps that do not need it? Or will gsl
creep into the very core of GNU Radio?
In gnuradio-core, there will be new filter bank technology introduced
that will use gsl to accomplish the debauchery of the indices in
compact readable form. We are about to use gsl to compute discrete
wavelet transforms. There are others but these suffice.
One could always replace the underlying routines with local ones that
are not bound to gsl.
The simple facts are that gnuradio cannot be all things to all people.
It might come closer than almost anything else but it cannot run
without modification on all computing equipment from dspPic’s to
Vertex 5’s to Cell to x86_64 to OMAP3XXX !
I really like the OMAP with its ARM9, TI DSP chip and Neon SIMD math
chip and OpenGL acceleration hardware. It is a worthy target of
effort.
On Wed, Sep 10, 2008 at 04:07:27PM -0400, Philip B. wrote:
Have you ever thought about creating a structure to build sets of
blocks outside the main source tree? Having this structure in place
would be a big help for “outside” developers also.
Funny you should ask, I’m just finishing that up.
Look for it in the next day or two.
On Thursday 11 September 2008 21:28:53 Greg T. wrote:
I’ll be adding the GNU Scientific Library (GSL) as a new dependency
on the trunk. GSL is a huge numerical library that’s been under
active development for more than 10 years:
http://www.gnu.org/software/gsl
FYI this is in pkgsrc as math/gsl and it’s at 1.11.
G’day Greg,
FYI: GNU Radio currently won’t built on pkgsrc as the versions of boost,
wxGTK
and py-wxWindows are too old. It also lacks py-gsl.
73, Berndt
VK5ABN
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
