Hi Emmanuel - I'm the GR OSX "expert" (LOL), as I do a lot of testing and verification and development on OSX (various versions). I'm happy to help as best I can. It might be that your issue is a generic GR bug. Let's take this discussion off-list & see what we can work out. If there's something relevant we can report back to the list and/or create a GR issue for it. - MLD
On Thu, Aug 8, 2019, at 10:02 AM, Emmanuel Blot wrote: > Hi Marcus, > > > my Apple experience limits itself to using an iPod in the summer 2010 > > or so, but I hope I can still be of help. > > :-) > > > First of all: Which path are > > you taking to build stuff? > > I’m using Homebrew (https://brew.sh) to build *nix applications on > macOS. > It is nice to have a controlled build environment. > > To build GR 3.0.0.8-rc2, I’m using the default Apple compiler: > > $ cc --version > Apple LLVM version 10.0.1 (clang-1001.0.46.4) > Target: x86_64-apple-darwin18.7.0 > Thread model: posix > > and the following major dependencies: > > cmake 3.15.2 > ninja 1.9.0 > swig 4.0.0 > python 3.7.4 > pyqt 5.10.1 > qwt 6.1.4 > qt 5.13.0 > > For PyGTK, I’m not sure which version is actually used. > > >>> import gi > >>> gi.version_info > (3, 32, 2) > > but PyGTK2 was also installed. > > Let me know if there is a good/better way to check this point. > > Less relevant I believe: > > adwaita-icon-theme 3.32.0 > doxygen 1.8.15 > pkg-config 0.29.2 > sphinx 2.1.2 > boost 1.70.0 > fftw 3.3.8_1 > gsl 2.5 > numpy 1.16.4 > portaudio 19.6.0 > libyaml 0.2.2 > mpir 3.0.0 > uhd 3.14.1.0 > zeromq 4.3.2 > freeglut 3.0.0 > log4cpp 1.1.3 > + all sub-dependencies + all Python modules :P > > GR is therefore built with CMake/Ninja, from an out of source build. > I can post the build log if it can help. > > I’m not sure I answer your question about the build path I take, > please let me know. > > > Ah! That might be a package naming problem. For example, on Fedora 30, > > the package you want for python3 PyQt would be python3-PyQt5 and > > python3-qt5-devel. > > I think on QT side this is correct (QT5), but I’m not sure how to > check which actual GTK version is actually used. > I do develop on the same host with PyGTK3. > > I removed GTK2 and pygtk (for Py2) packages as they were only used for > the previous GR 3.7 series on my host - it did not help up to now. > > > So, two different things: making GRC work (GTK), and making gr-qtgui > > (QT, PyQt, Qwt) work. > > Ok, got it. > > > Hope I got you out of that confusion! > > Yes. Thanks a lot for these details, I really mean it. > > > That's probably something else, as said, Qt isn't used in GRC. You > > don't need Qt to have GRC, and you don't need GRC to get gr-qtgui. > > Ok. > > > I'd call that a bug! > > Can you tell us which blog you dragged onto the canvas, or does this > > happen with all blocks? > > It happens with any block, as simple as the logical AND block, or > Constant waveform source > > I was tracing the call before I receive your reply, and for now, here is > what I found: > > BlockTreeWindow.py: > def _handle_drag_get_data(self, widget, drag_context, > selection_data, info, time): > key = self._get_selected_block_key() > if key: > # key is a valid text string, e.g. “blocks_and_xx” or > “analog_const_source_x” > selection_data.set_text(key, len(key)) > > > DrawingArea.py: > def _handle_drag_data_received(self, widget, drag_context, x, y, > selection_data, info, time): > coords = x / self.zoom_factor, y / self.zoom_factor > # here, selection_data is empty (no data, no text, no type), I > can’t tell why. > self._flow_graph.add_new_block(selection_data.get_text(), > coords) > > > flowgraph.py: > def add_new_block(self, key, coor=None): > id = self._get_unique_id(key) > ... > # key is None, and exception is raised > block = self.new_block(key) > > > > Also: this is a clean install, right? There's no e.g. flowgraph.py > > flying around anywhere else on your system where python might be > > erratically picking it up? > > No, I’ve removed all the previous GNUradio installation, and Homebrew > always installs each app in its own versioned directory, here > “/usr/local/Cellar/gnuradio/3.8.0.0-rc2/“ > There is no custom PYTHONPATH, and I also unset GRC_BLOCKS_PATH from a > previous setup. When I edit the Python file (to track down this issue), > my trace messages are executed as expected. > > PYTHONPATH is therefore defined to: > PYTHONPATH="/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages:\ > > /usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/site-packages:\ > > /usr/local/Cellar/gnuradio/3.8.0.0-rc2/libexec/vendor/lib/python3.7/site-packages" > > 1: lib/python3.7/dist-packages: gnuradio, pmt > 2: lib/python3.7/site-packages: volk_modtool > 3: libexec/vendor/lib/python3.7/site-packages# Python modules for > gnuradio (yaml, lxml, six, mako, click, …) > > > Thanks for your help, > Emmanuel. > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
