It looks like GTK isnt coming up right. And the other errors all stem
from that. Is the X server running?
Yes. I'm running MacPorts' XQuartz 2.6.1. Odd, but GRC works using Apple's
X11.app (XQUartz 2.3.6). And, now, randomly, it works in XQuartz 2.6.1 as
well. Hmmm ... well, I guess all's
% which python
/opt/local/bin/python
% which pythonw
/opt/local/bin/pythonw
On May 16, 2011, at 9:47 PM, Josh Blum wrote:
can you confirm:
which python
which pythonw
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
On May 16, 2011, at 9:52 PM, Josh Blum wrote:
Hmm, well maybe my hunch is busted. Can you confirm the problem when you
run it w/
/opt/local/bin/python gnuradio-companion
Changes nothing. GRC works, but still generates that error. - MLD
___
On May 11, 2011, at 4:33 AM, Martin Braun wrote:
I'll just name some things from the top of my head... [snip] I realise most
of these things are very typical for such a large FOSS projects with so many
contributors, but still, I can imagine they can confuse other people than me.
For the sake
On May 11, 2011, at 11:06 AM, Tom Rondeau wrote:
On Wed, May 11, 2011 at 2:57 PM, Michael Dickens m...@alum.mit.edu wrote:
* 'b' for bit, 'B' for byte, 'c' for char, 'f' for 32-bit IEEE float, etc...
we have a problem. 'c' is used for complex numbers, so what do we do about
characters? I
On May 10, 2011, at 4:21 AM, Martin Braun wrote:
3a) Remove inconsistencies which have popped up due to the organic
'growth' of GNU Radio over the last years.
Can you elaborate on what you see these inconsistencies to be? Even just an
example of one would probably suffice. - MLD
Can we bring Tom's post to this list?
http://gnuradio.squarespace.com/home/2011/5/8/why-isnt-gnu-radio-used-more.html
Yes, I do actually read his posts ;) I hope others do too; he writes with
clarity and has things to say if you're into SDR and GNU Radio.
I hope Tom's post sparks some
On May 9, 2011, at 11:12 AM, Marcus D. Leech wrote:
I think there's a significant community out there that learned DSP techniques
inside the envelope of Matlab/Simulink, and that's what they're comfortable
with.
True; that's how I did (MATLAB; Simulink wasn't around yet). I'd take that a
Intellectual Property: Many people / companies view the GPL as being
incompatible with IP -- and, whether true or not, this perception is certainly
an issue. To make progress here, maybe GNU Radio could take Ettus' UHD
dual-license approach, if that is still possible? I don't know if the FSF
On May 9, 2011, at 1:22 PM, Marcus D. Leech wrote:
this is, in fact *software* defined radio. So why is it always a big
surprise when hardware types encounter an SDR platform and become
more-than-vaguely-queasy at the though of having to, perhaps, learn a little
bit about software.
If I
On May 9, 2011, at 1:59 PM, Marcus D. Leech wrote:
I think you (tangentially) touched on an interesting point. Many users come
to Gnu Radio expecting it to be A turnkey application to solve my radio
problems. They don't really get that it's a *development* platform for
*developing*
On May 9, 2011, at 2:48 PM, Alexander Chemeris wrote:
Dual-licensing is a flawed model, it's truly hard to make it working
right.
From what I understand, dual licensing mostly works for Qt -- and, I doubt
that Ettus would be exploring it for UHD if it didn't have some merits. I
wonder if you
Good points, Kunal. I know that Tom has talked about having nightly builds for
the major OSs -- as much as anything to make sure that the GIT master always
compiles and passes make check at the end of the day. Maybe he could also
set up that system such that it provides those builds as
On May 9, 2011, at 3:13 PM, Matt Ettus wrote:
I believe this conversation has strayed quite a bit from GNU Radio
itself.
Not entirely, because I think a number of us believe that licensing is a real
issue. But, as you say, that ain't gonna change any time soon unless the FSF
decides to do so
On May 9, 2011, at 4:42 PM, Marcus D. Leech wrote:
Gnu Radio, to me, is a DSP engine that happens to live on a general-purpose
compute platform.
True. But the GNU Radio model is build on data-flow, while the Octave model is
not -- and, that might be a key difference. People have grown, for
On May 9, 2011, at 5:12 PM, Ben Reynwar wrote:
I'm pretty sure you only have to release the source to people who you
are giving/selling the software too, and only if they ask for it. So
if you're developing the software for one customer there is no issue
at all. If you have more than one
I think that you'll find many people who cross multiple fields of expertise on
this list -- I think that's part of the fun of SDR and GNU Radio to many of us.
Your point that SDR encompasses many disciplines is valid, and certainly leads
to a steep learning curve for some people. I have, in
Anyone else heading to WInnComm'11 Europe, June 22-24? I'm a presenter, and am
trying to find reasonably priced accommodations -- The Hotel has a special
for this conference of EU 179 - 259 (currently US$ 260 - 376) per night, before
taxes such but including breakfast wifi, which is a bit
GNU Radio does not work with SDCC 3.0 (which is what sdcc -v you provided
says it is); latest it works with is 2.9. See also
http://lists.gnu.org/archive/html/discuss-gnuradio/2010-11/msg00460.html . -
MLD
___
Discuss-gnuradio mailing list
On Mar 8, 2011, at 11:12 PM, Marcus D. Leech wrote:
My expectation is that eventually, there will be conventional installers
for Gnu Radio + UHD for Windows, Linux, and MacOS environments, and that
those installers will be kept fairly up-to-date with the development sources.
But we're not
http://it.slashdot.org/story/11/02/15/2052252/Keys-Leaking-Through-the-Air-At-RSA
The RSA Conference is underway in San Francisco. A theme among the opening
speakers is that the attackers are winning, and even well-funded organizations
like NASDAQ can't secure their networks reliably. The
No primary article ... g ... but an interesting comment:
http://it.slashdot.org/comments.pl?sid=1997316cid=35215688
Some background (Score:5, Informative)
by Dr. JJJ (325391) on Tuesday February 15, @05:43PM (#35215688)
I'm sorry that there's no direct article for this submission, and
On Jan 28, 2011, at 2:23 PM, Ben Hilburn wrote:
As I understand it, there is code in the GNURadio scheduler stuff that
manages block scheduling, to some degree.
I'm aware of the kernel's role in switching between the threads
themselves, but I was under the impression that block scheduling,
... no longer accepts HTTPS; it is now HTTP only. I've updated the GNU Radio
Wiki pages to reflect this internal change. Google returns correct results
(HTTP only), but if (for whatever reason I do not know) you've bookmarked
radioware.nd.edu, please note that it no longer works with SSL. -
I have a feeling -- from working with OpenCL for a while now (but, not in GNU
Radio yet), watching profiling timing information (how long it takes to move
data around, how long kernels take to get queued and executed) -- that what
folks here have written seems mostly true: there is
On Jan 12, 2011, at 2:56 PM, Moeller wrote:
On 12.01.2011 14:25, Michael Dickens wrote:
the CPU). I think that if a GPU can be used, it will be most effective in
things like filterbanks, or when searching for packets (via their unique
sync sequence, so matched filtering), or very large FIR
I don't think there's much specialized info out there on this topic, since
it's relatively standard programming; experience and knowledge are your best
guides! That said, there are some excellent books on parallel algorithms and
programming out there. Some of my favorites include (in no
Assuming you're using a reasonably recent GIT checkout, then your flow-graph
should be executing in thread per block mode by default -- each block you
create in your flow-graph will reside in its own unique thread. You can
manually override this setting to be in single threaded scheduler mode
Without seeing your GRC implementation or Python script block's
implementation code, mostly what I or anyone else can provide is general
advice. GNU Radio 3.3.0 uses the thread per block (TBP) scheduler by default;
if you're not doing anything else except running the flow-graph (meaning: you
On Dec 13, 2010, at 7:33 PM, Tom Rondeau wrote:
The biggest problem that I see with cmake is that the burden of proof
lies with cmake.
I'm 100% confident that CMake, or QMake for that matter (and, I'm sure, BJam
and other build tools), could handle the GNU Radio build system robustly if
My vote: It's hilarious. But, that's after meeting Fred in person last week
noting that, indeed, he -always- does all lowercase for his name, even on the
printed program (I'm sure there are exceptions, but there were none at the
conference). If I hadn't met him or seen all of this, I'd
MacPorts just upgraded SDCC from 2.9.0 to 3.0.0, which seems to have changed
the install names of various of the executables including the one required by
USRP: asx8051 - sdas8051. I haven't verified that these executables work
equivalently; I'll try to do that tonight. Has anyone tried doing
Looks like the 3.0 series changes SDCC itself. Doing make in USRP (after
building dependencies) using SDCC 3.0 results in:
Making all in lib
sdcc -mmcs51 --no-xinit-opt -I../../../../../usrp/firmware/include -c
../../../../../usrp/firmware/lib/delay.c -o delay.rel
On Nov 12, 2010, at 4:12 PM, Alexandru Csete wrote:
I don't know if anything got fixed in the macports package but I got a tip to
execute a python_select python26 and reboot. After doing so and installing
py26-scipy I could execute the qt_digital.py example included in the gr-qtgui
On Oct 29, 2010, at 12:19 PM, Jakub Moskal wrote:
Thank you Michael for your efforts. Would that mean it is just an
issue with the test, not with the gnuradio compilation itself?
Yes; looks like that directory (and file) was updated 12 days ago (commit
4a3fb7eb7481177ae35bb98307a1845a7304d97e
On Oct 29, 2010, at 2:53 PM, Ed Criscuolo wrote:
On 10/29/10 12:29 PM, Josh Blum wrote:
Did you build and install the doxygen documentation?
I installed under OSX 10.6.4 using Michael Dickens' macports
packaging of 3.3.0
Look atprefix/etc/gnuradio/conf.d/grc.conf
Is there documentation
The issue is in
gnuradio-core/src/filter/qa_gri_fir_filter_with_buffer_ccc.cc. The ERR_DELTA
is set to 1e-5, which for some reason is too tight for OSX (at least 10.6.4
x86_64); when I change this value to 1e-4, the test passes. Since gnuradio.org
is down, I can't check to see if this value
Hi Ed - Good stuff; I'm glad someone else is trying these ports out. A few
thoughts:
(1) Can you send me, off list, the issues you're having getting ports installed
as i386 or universal or whatever (ports log files as indicated by port)?
I'll see what I can do to fix them up. For example,
On Sep 14, 2010, at 5:12 PM, Michael Dickens wrote:
We're just discussing this issue (32-bit execution) on the MacPorts' lists.
The quick end-result is: With the current MacPorts' provided python2.6 or
older, the PREFER_32_BIT stuff does not work because 'python' is actually
just a wrapper
Hi Dave - We're just discussing this issue (32-bit execution) on the MacPorts'
lists. The quick end-result is: With the current MacPorts' provided python2.6
or older, the PREFER_32_BIT stuff does not work because 'python' is actually
just a wrapper around 'exec' and the bit-preferences are no
Thank you, Alexandru, for the report. I'm glad the basics work for you; they
do for me as well. Everything seems to work except for the QtGUI. I've found
in my install that the QtGUI doesn't work yet either, in exactly the same way
that yours fails. I know where the problem lies, and I'll
I've updated the GNU Radio install via MacPorts to 3.3.0.
For those OSX users out there who are using GNU Radio and MacPorts, could you
give this a shot see if it works for you? If you do install them for testing
purposes want to use a non-MacPorts GIT install for your actual work, make
On Sep 7, 2010, at 2:04 PM, Elvis Dowson wrote:
Does it use the GTK+ with support for native OS X look and feel?
It uses whatever MacPorts provides; by default:
gtk2 @2.20.1_0 +x11
but I can specify for it to use instead:
gtk2 @2.20.1_0 +no_x11 +quartz
and then I have to go through all
On Aug 26, 2010, at 11:12 AM, HR Myler wrote:
What we really, really want is a DMG file ;-)
That would be awesome, and very difficult to create because of the
extensive background dependencies of GNU Radio / Companion (even just
for gnuradio-core). I did once create a DMG installable .app
I just updated to the latest GIT master indeed make check fails in
gr-usrp with the Symbol not found: _usb_debug in gr-usrp if MacPorts
'libusb-compat' is installed -- thanks for the pointer, Mark. I'll
request in MacPorts that the PKGCONFIG file for 'libusb-compat' be
renamed to reflect
Hi Mark - I'm glad you got it working; if you installed all of the
background dependencies with MacPorts, compiling GNU Radio should be
as simple as:
[fix bootstrap]
./bootstrap
./configure
make
make check
sudo make install
with no other options. IIRC, the 3 primary environment variables
Hi Mark - I don't know where to point you exactly, since some tests
work for you while others don't. You're using --with-fusb-
tech=libusb1, which should work but hasn't been thoroughly tested (at
least on OSX). Have you tried configuring without this flag then re-
testing to see what
Hi Mary - So long as you use MacPorts for background dependencies,
libusb1 and libusb-legacy (v0.1.12) can be installed at the same time
you can easily choose between them (different PKGCONFIG files). Do
note that libusb-compat does NOT work with FUSB/Darwin since GNU
Radio's FUSB/LIBUSB
On Aug 19, 2010, at 1:31 AM, Elvis Dowson wrote:
The issue manifests itself on both a VM and with GR running natively
on my hardware (late 2009 iMac 27 i7).
My US$0.02 worth: TTBOMKM, on the Mac OS X side you can input and
output about any sample rate CoreAudio will handle the sample rate
Shortest Answer: This list isn't the correct venue for your issues
with Qt and Carbon / Cocoa; the GNU Radio build system is working
correctly and as expected under the circumstances. If you have issues
with the way Qt build on OSX, please see their forums and possibly
issue a ticket
Hi Elvis - I'm sorry but I really can't help without further
config.log / debugging info. And, frankly, I don't have time to dig
through this issue right now -- just too much in my queue already.
I'm happy that someone else is trying to get gr-qtgui working, and I
wish you luck on this
Hi Elvis - Did you try configure --with-fusb-tech=libusb1? You have
to specify that you want to use LIBUSB version 1; config/
usrp_libusb.m4 checks to see if you've specified this on the CLI if
not then doesn't check for this version of LIBUSB.
If you did try that command line, then
On Jul 19, 2010, at 12:57 PM, Elvis Dowson wrote:
One of the things that the guys working on GTK+ mentioned was that
you should completely uninstall MacPorts, to do the GTK+
installation. The GTK+ installation has a whole bunch of
dependencies, so I will try that last. That part I think is
Use the provided 'bootstrap' routine, but remember to change the
'libtoolize' call to 'glibtoolize' or whatever you named that function
on the version you installed yourself. If you used MacPorts to
install GNU Libtool (of which 'libtoolize' is a part), then it
prepended the 'g' for you.
On Jul 18, 2010, at 3:09 AM, Elvis Dowson wrote:
WxWidgets 2.9.0 supports Cocoa on Mac OS X 10.6.4, so if I were to
get that running with WxPython, would grc automatically switch over
to using Cocoa instead of gtk, when running on Mac OS X?
Short answer: yes.
Longer answer: So long as you
Hi Elvis - As I said, good luck with the 64-bit cocoa version. I'm
choosing to wait until 2.9.0 comes out, but also concentrating my
efforts on getting Qt working well enough that it can be used instead
-- if you're running 10.5 or 10.6, you can get a 64-bit cocoa version
pretty easily.
On Jul 18, 2010, at 3:35 AM, Ninja wrote:
checking for Python include path... /usr/local/include/python2.6
checking Python.h usability... no
checking Python.h presence... no
checking for Python.h... no
configure: error: cannot find usable Python headers
what is the meaning of configure: error:
Now, you need to install Python Cheetah templates = 2.0.0,
Python lxml wrappers = 1.3.6, and Python gtk wrappers =
2.10.0 in order to GRC to be built.
Does GRC require GTK, or does it use wxPython for the GUI?
My bad: GRC uses GTK2 for the GUI, not wxPython -- right Josh?
Hi Rasyid - You have the classic problem that's been around for
years now (you can search the GNU Radio archives for Python.h and
get hits back to 2005). The problem is that autoconf generates the
test for Python.h using C-code but tries to compile it using a
Fortran compiler; more recent
On Jul 15, 2010, at 5:54 AM, Bruhtesfa Ebrahim wrote:
It is kind of confusing. I have Gnuradio installed, so executing the
gnuradio examples in their own directory works fine. But, from the
home
directory..it restult in:
$ python dial_tone.py
Hi Bruh - Glad to hear you're getting Wx to work for you. We're
working on getting the Qt GUI working as well. I know that the state
of Wx on MacPorts is confusing right now -- to me as well. If I
were you, now that you've got it working, I'd leave my MacPorts
install alone until the Wx
Hi Bruh - If you installed py26-wxpython and wxWidgets from MacPorts,
then as of this morning neither allow for 'universal' compilation, and
wxWidgets goes so far as to enforce 32-bit only compilation. Chances
are your Mac's compiler is trying to generate 64-bit code. Hence, the
wxpython
Thanks, Johnathan, for those fixes in recent check-ins; between them
and starting with a clean build, almost everything is taken care
of ... one last item now:
$ make check
[snip]
Making check in gr-video-sdl
Making check in src
make check-am
make check-TESTS
objc[56471]: Class
I just checked -- it's a MacPorts / SDL issue; I'll submit a bug
report to them. Sorry! - MLD
On Jun 3, 2010, at 9:37 AM, Johnathan Corgan wrote:
On Thu, Jun 3, 2010 at 08:16, Michael Dickens m...@alum.mit.edu
wrote:
Thanks, Johnathan, for those fixes in recent check-ins; between
them
(1) % ../../configure
checking build system type... i386-apple-darwin9.8.0
checking host system type... i386-apple-darwin9.8.0
checking target system type... i386-apple-darwin9.8.0
checking for git... /opt/local/bin/git
checking existence of git version control directory... ok
checking git
(1) % ../../configure
checking build system type... i386-apple-darwin9.8.0
checking host system type... i386-apple-darwin9.8.0
checking target system type... i386-apple-darwin9.8.0
checking for git... /opt/local/bin/git
checking existence of git version control directory... ok
checking git
Sorry for the double post; strange internet goings-on down here.
Nothing has changed about my setup w/r.t. 'cut' or anything else.
'which cut' returns '/usr/bin/cut' which is supplied by Darwin.
'which date' returns '/bin/date' which is also Darwin -- this issue
has been around for a while
(1) configure.ac:296
BUILD_DATE=`date -R -u`
The '-u' works (Display or set the date in UTC (Coordinated
Universal) time), but there is no -R option to Darwin's built-in
'date'. What does the '-R' option specify? Maybe there's another way
to do it on Darwin that's more
On Jun 1, 2010, at 2:38 PM, Johnathan Corgan wrote:
$ echo '1-2-3-4' | awk -F- '{print NF}'
4
Can you test Darwin's 'awk' for this?
the '$' line returns exactly '4' ... I guess that's good?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
On Jun 1, 2010, at 1:52 PM, Johnathan Corgan wrote:
From the manpage:
-R, --rfc-2822
output date and time in RFC 2822 format. Example: Mon,
07 Aug 2006 12:34:56 -0600
Can we instead use something like:
$ date -u +%a, %d %b %Y %R:%S
which isn't quite RFC 2822 compliant since
With the change in 'date' and using 'awk', I still got the python dyld
load error, which I tracked down to the SWIG libraries. Doing 'make
clean' there and then 'make' did the trick. !...@#$% fragile SWIG stuff.
- MLD
___
Discuss-gnuradio
3.3.0-rc3 still passes make check on OSX; I can't test further,
really, but previous candidates did work so this one probably does
too. Still does not pass make distcheck; errors on in gr-qtgui, as
it did before (see below for error message). BTW gr-qtgui is not
enabled; as before the Qt
On May 17, 2010, at 8:11 PM, Tom Rondeau wrote:
If I had access to an OSX box, I'd see about getting qtgui to work
better on it.
Well ... IIRC, the issue is that there is no standard install of Qt on
OSX; one must do it by hand from source or use MacPorts / Fink /
whatever. At least for
The standard configure; make; make check; make install; make
uninstall works just fine on OSX 10.5.8. make distcheck fails in
gr-qtgui before 'configure' even gets executed, I suppose because this
component doesn't compile easily on OSX to begin with (so, I don't use
it) -- either way,
Hi Ali - I think if you search the GNU Radio discussion list you'll
find some references similar to what you want to do. As a quick
reply: If you want to monitor the channel using the same Tx/Rx
antenna and Flex board, then you have 2 choices:
(1) Do simultaneous Tx and Rx: You'll need
Hi Martin -
On Apr 29, 2010, at 9:23 AM, Martin Braun wrote:
y(n) = x(n) + x(n-2)
My question is: can GNU Radio be modified to accept this? It's a
perfectly valid flow graph (similar to ones you find in DSP
textbooks),
and thanks to the history of the delays, one that should work. I'd be
I'm in a place where I have no USRP with which to test some changes.
The change is to move from a mix of threading via gr-omnithread and
darwin pthreads (via an intermediate class I called 'mld_threads') to
the gruel:: namespace threads. Here's the info:
$ git checkout
Hi Chris - I'm glad to hear you have at least some parts of GNU Radio
working as 64-bit on OSX 10.6. I don't have 10.6 installed (yet) for
further testing, but I'm heading that way one of these days. I've
been holding out for the release of wxPython 2.9.0, which will
officially support
Hi Ed - I never got multi-boot installed, so, no, I haven't gotten
those changes in place. That said, the MacPorts folks are discussing
ways to get WX stuff to be 64-bit compatible under 10.6, so I might
not need to do anything if they succeed soon enough. How badly do you
want / need
Hi Christian -
On Mar 20, 2010, at 2:41 PM, Christian Kendi wrote:
the git has the problem:
configure: creating ./config.status
config.status: error: cannot find input file: `gruel/Makefile.in'
With or without CFLAGS/CXXFLAGS=-arch i386 doesnt matter. yes,
been bootstrapping before.
The
I think this is an issue between wxWidgets the JPEG library. Try:
sudo port selfupdate
sudo port upgrade outdated
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Sagar resolved this issue off-list, without my help but with some good
discussion. That said, I got curious about what might be going one,
and after some hacking around on my Mac's installs of GNU Radio I
think the issue is that you have multiple versions installed and this
particular
Hi Vincenzo - Can you also provide links to your papers, both the
WSR10 one and whatever you can on your MA technique? Enquiring minds
will want to know more about MA ... Thanks! - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
On Mar 4, 2010, at 2:45 PM, Jakub Moskal wrote:
Last question.. I own to USRPs and I successfully installed the
gnuradio with grc on two MacBooks (10.6.2). Examples run fine, but
when it comes to the tunnel.py I cannot make the TUN/TAP interface to
work on OSX, has anyone had luck with that? I
On Mar 5, 2010, at 5:24 PM, Sagar Kapare wrote:
The exact same code works on two other machines, both running OSX
10.5. The sink is a locally created modules, so it is entirely
possible that there is something missing in the instantiation that
is being caught on only on my machine and not
Hi Kunal - I can't directly address the question of whether or not
custom blocks work on OSX 10.6 x86_64, since I've never compiled by
custom blocks under that OS (yet). I need to do some 10.6 x64 work
anyway, so I'll try out my blocks later today see what happens.
Not sure if this makes
Hi Fabrizio - Glad to hear you had success using MacPorts to install
GNU Radio on your 10.5 box. That's the goal!
On Feb 19, 2010, at 1:19 PM, Fabrizio Tappero wrote:
seem (to me) to indicate the wrong path (at least for my
installation). To have all working I had to change:
if [
Hi Affan - Since you modified the how-to stuff to meet your needs,
it'll be difficult for any of us to provide definitive assistance
without seeing your code (I, personally, have very little free time
this week until I get a presentation finished). That said, if you do
succeed come up
Hi Ed - Thanks for the feedback, it's useful; I don't mind being
wrong! I'll have to set up my Mac to do multi-boot (10.5 and 10.6) in
order to further test this issue out. That said, the kernel bit-tage
doesn't really matter since it's the compiler that determines the
applications
Hi Affan - Glad to hear you're up and running, and using PPC and
10.5. If you're planning on using a USRP, I hope you have a USB 2.0
adapter ... those older PPC Macs didn't do USB 2.0 very well.
Hmm ... that's all quite strange; by default how-to is installed into /
usr/local , with the
hanks for all the feedback thus far! Can those of you on this thread
return back to me the following (as executed in a terminal,
individually):
gcc -v
machine
uname -a
Once I figure out the logic (and, via the below discussion, I think I
know what to do but I just want more info to
Marcel, Ed, and Kunal - Thanks for the data points -- it looks like
all 3 of your computers booted from the 64-bit kernel; please correct
me if I'm wrong.
---
Anyone else on the GR list have a Mac running OSX 10.5 or 10.6 who
would care to participate in getting some more data points? I'm
I've checked in MacPorts modifications that should allow for
installing GNU Radio 3.2.2 via MacPorts on 10.5 (Intel or PPC; 32 or
64 bit; universal too) or 10.6 (32 or 64 bit, except for gr-wxgui
since it relies on wxPython which doesn't have a 64-bit compatible
version yet; wxWidgets
Thank you Marcel for mentioning that little detail: before trying
MacPorts out, if it's already installed, you'll want to do what he
wrote below in order to get the latest portfiles w/ patches such.
Hopefully that will solve your issue Kunal; if not, let me know.
% sudo port selfupdate
%
Is there any update on this issue? Is there any workaround available?
A quick search of the discuss GNU Radio list archive at
http://lists.gnu.org/archive/html/discuss-gnuradio/
reveals the following in the first page:
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-10/msg00185.html
I've updated MacPorts to use GNU Radio 3.2.2 ; if you're using OSX
10.5 or 10.6 as 32-bit, please give these ports a try see if they
work for you. And, let me know if you run into any difficulties.
Your shell environment's PYTHONPATH and such just need to work with
MacPorts -- nothing
On Jan 27, 2010, at 11:10 AM, Clark Pope wrote:
Didn't realize they cared as long as you purchase the OS. Guess I'll
try dual boot instead, but I doubt that's this particular problem.
Everything else seems to run okay.
I'm not saying they do care; my bet is that so long as you own a
On Feb 1, 2010, at 2:29 PM, Charles Brown wrote:
I finally received word just now that I'll be approved shortly as a
MacPorts developer; yay! Once I'm approved, I'll update the
MacPorts portfiles for GNU Radio for the 3.2.2 release tarball.
I'll see if I can get additional
Hi Clark - Various levels of response. Bottom line is: You're way
outside the scope of usual OSX / GNU Radio / MacPorts installs, so I
don't know what assistance we can provide if the issue is non-
standard (as this one seems to be). Good luck! - MLD
0) According to the EULA for Mac OS X
Hi Charles - Thanks for your extensive and quick reply! I'll give it
a shot using RPMforge as you suggest. If I can get anything going,
I'll push it to the GR wiki (since there is no entry for CentOS yet).
- MLD
On Jan 13, 2010, at 10:20 AM, Charles Herdt wrote:
I haven't installed
701 - 800 of 1164 matches
Mail list logo
