GNURadio-v3.7.10.1-rc2.dmg

[Hardcore-fs]

Hi,

loading it , quarts starts up, then after about a minute the "apple script editor" window opens

then nothing.

[cfriedt]

Did you install Python 2.7 and XQuartz?

[Hardcore-fs]

yep...... something strange, if i open a terminal then go to the "notification window" and click on the message so it opens again, after a minute the program starts.

so that would prove python & XQuartz are installed.

Ok I took a look at it just now, seems it is now working correctly, I get a couple of notifications. Starting xquarz Starting gnu but now it is working.....

Perhaps it only does this the first time it is installed and run, prior to a restart. (Missing the initial init config ?)

But also i see if you quit the xQuartz "hard" , that python is left running in the background consuming 100% CPU

[Hardcore-fs]

yes seems something minor is not initting. Just over wrote the "app" and exactly the same thing happened the first time it is launched. After the first run it does not do it again, until you overwrite the app again.

[cfriedt]

@Hardcore-fs Python 2.7 specifically? GNURadio does not (yet) work with Python 3

Nevermind... I'm fairly sure that we hard-code the path to the official Mac distribution of Python2.7 ... but you may want to double-check that it's not using something from macports or elsewhere (". /Applications/GNUR.../grenv.sh" and then call "env").

[cfriedt]

That's weird... I'll try to reproduce what you're seeing on my end too, and if I can, I'll create a branch to fix this issue.

[Hardcore-fs]

python 2.7 is in and being used, the app only does it the first time osx 10.11.6 16GB ram also the path is: ". /Applications/GNURadio.app/Contents/MacOS/usr/bin/grenv.sh "

This may help:: When it is launching for the first time: the message says "launching gnuradio-companion -psn_0_421991" (this is when it throws up the "script window")

All runs after the first run the message says "launching gnuradio-companion" (NO "script window" and program launches)

[cfriedt]

Interesting. I wonder if @dholl could comment, since he introduced the code for the script windows. I haven't yet had a chance to reproduce it myself.

[dholl]

@Hardcore-fs Hmmm.... I wasn't able to reproduce (yet) either, but I'm tracing through the logic of the launch script "run-grc.sh"... (For reference, I'm on OS X 10.12.6.)

As a hack test, could you edit this script: GNURadio.app/Contents/MacOS/usr/bin/run-grc and make these changes:

1. Uncomment this block near the end:

   ## Strip out the -psn_... argument added by the OS.
   #if [ "x${1#-psn_}" != "x${1}" ]; then
   #   shift 1
   #fi

2. And move that block before this if statement

   if command -v xset >/dev/null 2>&1 ; then
       # If xset is available,
       ...
   else
       ...
   fi

The complete script should look like this:

#!/bin/sh

XQUARTZ_APP_DIR=/Applications/Utilities/XQuartz.app
PYTHON_FRAMEWORK_DIR=/System/Library/Frameworks/Python.framework/Versions/2.7

set -e

show_fail_message () {
    osascript -e 'display notification "Failed to start GNU Radio Companion.\nDetail: '"$*"'" with title "GNU Radio Companion"' > /dev/null 2>&1 || true
    return 0
}

# If the exec fails for some reason, then our EXIT handler will get invoked.
# At exit, run cleanup_script but let the exit status still be whatever the
# shell was going to exit with:
trap 'show_fail_message "exit status $?"' EXIT

# If we get a signal such as SIGINT SIGQUIT or SIGTERM, then mask signal,
# show_fail_message, restore default handler, and raise signal again to let it
# propagate to whatever process started this script:
trap '{ trap - EXIT ; trap "" INT  ; show_fail_message "received signal INT"  ; trap - INT  ; kill -s INT  $$ ; }' INT
trap '{ trap - EXIT ; trap "" QUIT ; show_fail_message "received signal QUIT" ; trap - QUIT ; kill -s QUIT $$ ; }' QUIT
trap '{ trap - EXIT ; trap "" TERM ; show_fail_message "received signal TERM" ; trap - TERM ; kill -s TERM $$ ; }' TERM
# The leading "trap - EXIT" disables the EXIT signal handler or otherwise
# show_fail_message gets called twice.

# Uncomment one at a time to test each exit condition:
#kill -s INT -- $$
#kill -s QUIT -- $$
#kill -s TERM -- $$
#exit 2

# Figure out where this script is located:
case "$0" in
    /*)
        # $0 is absolute path since it starts with /
        argv0_path="$0"
        ;;
    *)
        # Assume $0 is relative path:
        argv0_path="$PWD/$0"
        ;;
esac
# This script is in GNURadio.app/Contents/MacOS/usr/bin with grenv.sh
grenv_path="${argv0_path%/*}/grenv.sh"

if ! test -d ${XQUARTZ_APP_DIR} ; then
    osascript \
        -e 'on run(argv)' \
        -e 'display dialog ("XQuartz is not installed. Download it at http://www.xquartz.org/") buttons {"OK"} default button 1 with icon stop with title "GNU Radio Companion"' \
        -e 'end run' \
        > /dev/null 2>&1 || true
    printf 'XQuartz is not installed. Download it at http://www.xquartz.org/\n' 1>&2
fi

if ! test -d ${PYTHON_FRAMEWORK_DIR} ; then
    osascript \
        -e 'on run(argv)' \
        -e 'display dialog ("Python 2.7 is not installed. Download it here: https://www.python.org/downloads/") buttons {"OK"} default button 1 with icon stop with title "GNU Radio Companion"' \
        -e 'end run' \
        > /dev/null 2>&1 || true
    printf 'Python 2.7 is not installed. Download it here: https://www.python.org/downloads/\n' 1>&2
fi

if ! test -e "${grenv_path}" ; then
    osascript \
        -e 'on run(argv)' \
        -e 'display dialog ("Unable to find grenv.sh at " & item 1 of argv) buttons {"OK"} default button 1 with icon stop with title "GNU Radio Companion"' \
        -e 'end run' \
        -- "${grenv_path}" \
        > /dev/null 2>&1 || true
    printf 'Unable to find grenv.sh at %s\n' "${grenv_path}" 1>&2
    exit 1
fi
. "${grenv_path}"

# Strip out the -psn_... argument added by the OS.
if [ "x${1#-psn_}" != "x${1}" ]; then
    shift 1
fi

if command -v xset >/dev/null 2>&1 ; then
    # If xset is available, then we'll use that to silently launch the X server.
    # While we wait, use osascript to tell the user what we're up to.
    osascript -e 'display notification "Starting X server..." with title "GNU Radio Companion"' > /dev/null 2>&1 || true
    if xset q >/dev/null 2>&1 ; then
        osascript \
            -e 'on run(argv)' \
            -e 'display notification ("exec gnuradio-companion " & item 1 of argv) with title "GNU Radio Companion" subtitle "Launching GNU Radio Companion..."' \
            -e 'end run' \
            -- "$*" \
            > /dev/null 2>&1 || true
    else
        osascript -e 'display notification "Unable to verify running X server.  Will attempt anyway..." with title "GNU Radio Companion"' > /dev/null 2>&1 || true
    fi
else
    osascript \
        -e 'on run(argv)' \
        -e 'display notification ("exec gnuradio-companion " & item 1 of argv) with title "GNU Radio Companion" subtitle "Launching GNU Radio Companion..."' \
        -e 'end run' \
        -- "$*" \
        > /dev/null 2>&1 || true
fi

# Prime the exit status with "( exit 127 ) || " in case exec fails.  Otherwise,
# $? is 0 during trap EXIT.
( exit 127 ) || exec gnuradio-companion "${@}"
# Without the "trap ... EXIT", then we wouldn't need the "( exit 127 ) || ",
# since the shell would automatically return the appropriate error number from
# exec's failure.  Is this a glitch in bash since sh is symlinked to bash on my
# system?  Note that exec can return other exit status beside 127, so this
# stunt is suboptimal, but an optimally pedantic solution would require exec to
# interact better wirth trap EXIT.

I just attached a copy. Rename it from run-grc.txt to run-grc, and ensure its file permissions are 755 such as chmod 755 /Applications/GNURadio.app/Contents/MacOS/usr/bin/run-grc run-grc.txt

[Hardcore-fs]

Yep.... i'm on an old early 2008 tank (10.11.6) so no further updates are allowed by Apple Not to be pedantic....... Surely the "correct" instruction would be:

1. download a clean copy of "GNURadio.app" (to trigger bug, since it only does it first time)
2. replace old script in "path" with enclosed script
3. test

That said....... two tests.

1. re-install unmodified package (broken on initial launch)

2. re-Install AND modify/replace script. when running modified application, problem appears solved.

[dholl]

huh.... So, the tweaked script fixes the issue? I wonder if there's something about that -psn#### arg being passed to osascript for the "exec ..." diagnostic message, or if it is python / gtk trying to do something with that argument when grc starts.

I just submitted a PR.

[Hardcore-fs]

Ahh.. the mystery that is computer code. like I say, it only happens the first time the program is cleanly installed, so most people will put it down to " oh, ill just restart it again."

But it is reproducible(on my machine) and the fix is reproducible on my machine, so all is good but we can see from above , on the 1st launch with the script fix, no "-psn### was used. (1m)

and even with the "broken" script(10m), that "-psn###" appears to only be used the first time and not subsequently.

Anyway you guys did a good job, its the only startup issue i have had, all other issues are internal module related, so ill report them to GNU

[dholl]

Thank you!

Yeah, one source of start-up mysteries is that GRC does not bother to process native Apple Events, because it is pyGTK and handling native Mac events in pyGTK seems to require more think-time than I have available at the moment. If anyone is game for it, this integration with Finder / Launch Services might be a nifty opportunity to contribute to @cfriedt's work. :)

-- aside:

Otherwise, I have been slowly toying around with an experimental build that does not require X11 but does leverage MacPorts. I've only recently gotten the .app bundle to be relocatable, and still need to get around to testing Launch Services / Finder integration... However, in this alternative build, I haven't focused at all on the extra packages / options that @cfriedt has included in this repo. [I just enable whatever bells-n-whistles are available in MacPorts, and then belt-sand the whole thing down to hide a trimmed-down MacPorts tree inside the .app bundle.] :)

[Hardcore-fs]

As a developer ,I would stay away from mac ports and all these other package /build shells. The cleanliness of "X11" is where it's at. perhaps that is my issue with this package failing : 10 years of past crap , mac ports, java libraries , x11, arm tools, python 2.7 & 3.0 Just too many interactions.

I think I have seen "issues" with the mac events, both on the sliders & source/ sink packages in GNU

like the sound driver being able to block events is potentially "dangerous" , plus having seen sliders track from 0-100 with steps of 2 , suddenly jumping to 900K or 900M

[cfriedt]

@Hardcore-fs - I completely hear you. My next GNU Radio project will likely be a native Mac OS X UI using Cocoa. Next... maybe a browser-based UI for Chromium / Chrome ? I only ever switched to Mac because the Linux desktop started spiraling.

[Hardcore-fs]

Actually that might work!!!!! a backend CLI (possibly GNUradio with API) and a web front end, get away from all this cross platform" nastiness" "Radare" is making good inroads into this with their disassembler.

I would drop the "mac specific" app Idea, I regularly work on multiple platforms switching between them, so a web interface would really work, plus there is potentially a money maker in there.... from an educational/share designs/ "cloud" point of view, it might even scale to "mobile devices"

[cfriedt]

@Hardcore-fs , I'm tempted to use the Electron framework that @github uses themselves.

https://desktop.github.com/

[zendata]

Any idea why I would get this display? It appears that the receiver is running OK but QT is not rendering properly. OS 10.13.1 on MacBook Air.

[cfriedt]

@zendata Are you able to provide your .grc file?

Also, edit the /Applications/GNURadio.app/Contents/MacOS/usr/bin/run-grc file (it's just a bash script) and add the 'env' command in somewhere useful. That will dump the environment variables you are using.

Open Terminal.app and execute /Applications/GNURadio.app/Contents/MacOS/usr/bin/run-grc on the command line. You'll probably also see some error messages from the Qt libraries, by the looks of it.

Personally, I'm unable to update to High Sierra yet because they stopped supporting AppleRaid :(, so I can't test it with that version. It's possible that a version number just needs to be bumped in a patch file somewhere. The Mac linker accepts flags like "-mmacosx-version-min=", and compatibility versions, and so on, which really just serve to complicate things.

[zendata]

Hi Chris

Sure I attach the .grc file, the .py file and the run notes.

Thanks for having a look - happy to help you test - the idea of a native Mac app version of gnuradio is so appealing, as someone who has struggled for ever with MacPorts implementations and Linux VMs with their USB port issues etc.

Cheers, Graham Cottew Technology Director Zendata Pty Ltd +61417722400

Run notes: Generating: '/Users/graham/Dropbox/Gnuradio/cfriedt_dmg_test.py'

Executing: /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -u /Users/graham/Dropbox/Gnuradio/cfriedt_dmg_test.py

gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.10.1 built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya [INFO] [UHDMac OS; Clang version 8.1.0 (clang-802.0.42); Boost_106300; UHD_3.11.0.local-master-233-g25fc32af]  Using device #0 Realtek RTL2838UHIDIR SN: 00000001 Found Rafael Micro R820T tuner [R82XX] PLL not locked! [R82XX] PLL not locked!

Done

On 3 Dec 2017, at 02:33, Christopher Friedt notifications@github.com wrote:

@zendata https://github.com/zendata Are you able to provide your .grc file?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cfriedt/gnuradio-for-mac-without-macports/issues/59#issuecomment-348699499, or mute the thread https://github.com/notifications/unsubscribe-auth/ACki6H3Q8VPWSYWwq5RGQseT2qM9ODboks5s8W3HgaJpZM4Phx4I.

[nsmith-]

Hi @zendata,

I faced a similar issue and found the problem was that fontconfig was not searching the correct directories on my system, for whatever reason. The solution was to edit /Applications/GNURadio.app/Contents/MacOS/usr/etc/fonts/fonts.conf and change the nonexistent directory on line 27:

    <dir>/usr/X11R6/lib/X11/fonts</dir>

to

    <dir>/usr/X11/lib/X11/fonts</dir>

which seems to be a symlink to my xquartz installation in /opt/X11

P.S. Actually this was the latter half of the struggle. The first pain was learning that it does not work in El Capitan and (about time) upgrading to Sierra. This was because fontconfig would segfault if it tried to use a syscall that doesn't exist in MacOS until Sierra, namely mkostemp More info here Perhaps it would be good to add the flag mentioned to the fontconfig build step.

[zendata]

Hi Nicholas

Thanks your help. I will try your suggested change - I am running High Sierra and guess that may bring another few issues over Sierra.

Will let you know when I have had a go at it.

Cheers, Graham

On 15 Feb 2018, at 05:44, Nicholas Smith notifications@github.com wrote:

Hi @zendata,

I faced a similar issue and found the problem was that fontconfig was not searching the correct directories on my system, for whatever reason. The solution was to edit /Applications/GNURadio.app/Contents/MacOS/usr/etc/fonts/fonts.conf and change the nonexistent directory on line 27:

/usr/X11R6/lib/X11/fonts

to

/usr/X11/lib/X11/fonts

which seems to be a symlink to my xquartz installation in /opt/X11

P.S. Actually this was the latter half of the struggle. The first pain was learning that it does not work in El Capitan and (about time) upgrading to Sierra. This was because fontconfig would segfault if it tried to use a syscall that doesn't exist in MacOS until Sierra, namely mkostemp More info here Perhaps it would be good to add the flag mentioned to the fontconfig build step.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[cfriedt]

I did finally upgrade to High Sierra (reluctantly, because I was losing RAID support), so now I should be able to give this a shot soonish.

[Vladivostoks]

hi, i try to open it with run-grc ,but there is something like "ImportError: No module named grc.main".i can import gnuradio module in python2 console, but it seems grc.main is missing?Could anyone help me?

[discort]

still have the same issue, release v3.7.10.1-rc2

[cfriedt]

If you are able to put together a fix yourself, can demonstrate that the fix works, and make a pull request, I will gladly merge your changes.

However, I no longer have access to a Mac OS machine, so cannot test changes individually. I'm also unable to build new releases unfortunately.

I'd be happy to merge PR's until the time someone else is able to take over maintainership.

[ernestp]

Having same font issue with uhd_fft.grc from gnuradio github sources. MacOS Catalina 10.15.

Fixed issue with this comment https://github.com/ktemkin/gnuradio-for-mac-without-macports/issues/69#issuecomment-542480877

ln -s /opt/X11/share/fonts ~/.fonts

[cfriedt]

Thanks, @ernestp - I'm not sure if @ktemkin will be maintaining a 3.7 release branch, but this will likely be fixed in 3.8. Currently, there is a 3.8 pre-release.

[cfriedt]

I'm going to close this issue, since it seems to actually have several issues lumped into one and some of them seem to be fixed in a later release.

[ernestp]

@cfriedt @ktemkin It seems 3.8 currently have a lot of issues with UHD. Maintaining 3.7 will be good idea.

[cfriedt]

@ernestp can you please open a separate issue for whatever you're having? This one seems to cover several unrelated issues.

[ernestp]

@cfriedt Sure, already did https://github.com/gnuradio/gnuradio/issues/2851

There also too many open issues with 3.8 https://github.com/gnuradio/gnuradio/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+3.8