Activity for Antoine Lambert
-
Antoine Lambert posted a comment on ticket #895
To be noted, the crash occurs with the upstream version of the Intel drivers installed from a PPA, reverting back to the default one bundled by Ubuntu makes the crash goes away. Nevertheless, the libglapi.so should still be removed from the AppImage in order to use the one from the host system instead and avoid this crash on future Ubuntu releases.
-
Tulip 5.7.3 AppImage does not start on Ubuntu 22.04 with Intel iris graphics driver
-
I looked into that issue and managed to reproduce it as I have an old Intel NUC with legacy Intel HD Graphics GPU (same as you Andre I guess) that is taking the dust but is still functional. This looks like a bug in the mesa crocus driver when OpenGL rendering mode is set to GL_SELECT (used when selecting graph elements in views with the mouse). I also tested using the latest version of the driver on Ubuntu (using https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) and I still got the...
-
I looked into that issue and managed to reproduce it as I have an old Intel NUC with legacy Intel HD Graphics GPU (same as you Andre I guess) that is taking the dust but is still functional. This looks like a bug in the mesa crocus driver when OpenGL rendering mode is set to GL_SELECT (used when selecting graph elements in views with the mouse). I also tested using the latest version of the driver on Ubuntu (using https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) and I still got the...
-
Hi Andre, The issue likely comes to the fact that the OGDF library bundled in Tulip source folder is compiled with the following GCC flags: -march=native which produces binaries non portable across CPU architectures. Commenting lines 16 to 19 in file tulip-5.7.2/thirdparty/OGDF/cmake/compiler-specifics.cmake and rebuilding the AppImage should fix the issue. Cheers !
-
This regression has been in introduced in this commit and the issue appeared since the Tulip 5.6.1 release. Below is the patch to fix it: diff --git a/library/tulip-gui/src/TlpQtTools.cpp b/library/tulip-gui/src/TlpQtTools.cpp index 488908f78..3a68044ac 100644 --- a/library/tulip-gui/src/TlpQtTools.cpp +++ b/library/tulip-gui/src/TlpQtTools.cpp @@ -377,7 +377,8 @@ void initTulipSoftware(tlp::PluginLoader *loader, bool removeDiscardedPlugins) { // OpenSSL libraries Qt was compiled against before Python...
-
If you want to modify node coordinates to be all positive, you can do a layout translation using Python. Simply enter those instructions in the Tulip Python REPL: bb = tlp.computeBoundingBox(graph) graph['viewLayout'].translate(bb[0]*-1)
-
That's because you need to add the path to the Tulip DLLs in the PATH environment variable before importing the tulip module. os.environ['PATH'] += ';C:/Program Files/Tulip-5.3.1/bin' You can also install the module from PyPI using the following command: $ pip install tulip-python
-
You can fix that link issue by applying the following patch to the root CMakeLists.txt of the Tulip 5.3.1 release: https://github.com/Tulip-Dev/tulip/commit/ed8f1a059ebcf88cd14f072895c57a53a68ec97f#diff-af3b638bc2a3e6c650974192a53c7291
-
For your information, I started developing that view during my PhD almost ten years ago and still maintaining it today. I always liked plugging GIS features inside Tulip so don't worry I will work something out in the coming weeks ;-)
-
Hi, Tulip development moved to GitHub (blame its main maintainer for not having updated the project description). I have created an issue to track the progress on that feature request. This should not be difficult to implement. Antoine
-
Hi, Tulip development moves to GitHub (blame its main maintainer for not having updated the project description). I have created an issue to track the progress on that feature request. This should not be difficult to implement. Antoine
-
I also tested the reported behavior on Mac OS Sierra with Tulip 5.3.0 installed from its dmg bundle and the parsing error for the corrupted tlp file was correctly reported. Just by curiosity, which Mac OS version are you using ? If you use Tulip 5.2.1, does the crash still appear ?
-
I also tested the reported behavior on Mac OS Sierra with Tulip 5.3.0 installed from its dmg bundle and the parsing error for the corrupted tlp file was correctly reported. Just by curiosity, which Mac OS version are you using ? If you use Tulip 5.2.1, does the crash still appears ?
-
Hi Léo, Tulip development moved to GitHub so you should post bug reports there instead in order for Tulip developers to spot them quickly. I have created a GitHub issue forwarding your bug report: https://github.com/Tulip-Dev/tulip/issues/115 Cheers !
-
Hi, You can check an experimental integration of Tulip graph visualizations in Jupyter notebook I worked on a few years ago (based on emscripten and WebGL) : https://github.com/anlambert/tulip_python_notebook To get a look on what it is, you can check that example: http://nbviewer.jupyter.org/github/anlambert/tulip_python_notebook/blob/80c4a6e946a21e28bc50c4e0b30158ff8eaab959/Tulip%20Python%20notebook%20tests.ipynb Basically, you can create any WebGL based interactive visualization from the Tulip...
-
Hello Thibault, I just compiled Tulip 5.1 from the release tarball on Debian stretch and I did not have any issues running it afterwards. I think you missed the install step of Tulip after its compilation ($ make install). By default, Tulip will be installed in /usr/local but you can change that path through the CMAKE_INSTALL_PREFIX variable. Once it is installed, launch the tulip or tulip_perspective executable located in the install bin folder. Tulip is a framework that is based on plugins so if...
-
Hi, You can check an experimental integration of Tulip graph visualizations in Jupyter notebook I worked on a few years ago (based on emscripten and WebGL) : https://github.com/anlambert/tulip_python_notebook To get a look on what it is, you can check that example: http://nbviewer.jupyter.org/github/anlambert/tulip_python_notebook/blob/a59ac246291481865c303569927fd0aa30c49b3b/Tulip%20Python%20notebook%20tests.ipynb Basically, you can create any WebGL based interactive visualization from the Tulip...
-
Hi, You can check an experimental integration of Tulip graph visualizations in Jupyter notebook I worked on a few years ago (based on emscripten and WebGL) : https://github.com/anlambert/tulip_python_notebook. To get a look on what it is, you can check that example: http://nbviewer.jupyter.org/github/anlambert/tulip_python_notebook/blob/a59ac246291481865c303569927fd0aa30c49b3b/Tulip%20Python%20notebook%20tests.ipynb Basically, you can create any WebGL based interactive visualization from the Tulip...
-
Hi, You can check an experimental integration of Tulip graph visualizations in Jupyter notebook I worked on a few years ago (based on emscripten and WebGL) : https://github.com/anlambert/tulip_python_notebook. To get a look on what it is, you can check that example: http://nbviewer.jupyter.org/github/anlambert/tulip_python_notebook/blob/a59ac246291481865c303569927fd0aa30c49b3b/Tulip%20Python%20notebook%20tests.ipynb. Basically, you can create any WebGL based interactive visualization from the Tulip...
-
Hi, You can find Tulip binaries for windows and mac os compiled and shipped with Qt5 on GitHub (https://github.com/Tulip-Dev/tulip/releases) but also BinTray (https://bintray.com/tulip-dev/tulip_binaries/Tulip/5.1.0). Tulip development is now hosted on GitHub by the way. Cheers!
-
forgot to add this change with commit 12780
-
update Tulip dependencies in README
-
use correct License file in windows and mac installers (LGPL instead of GPL)
-
add missing bitmaps in tulipgui wheels
-
ensure to correctly bundle Tulip Python plugins in wheels
-
last Python fixes for the release regarding correct initialization of the tulipgui module
-
ready for the release of Tulip-Python 5.1: update documentation + some last minute polishing
-
fix plugins doc generation with Python 3.x on windows
-
fix msvc builds on appveyor after recent changes in upstream clcache
-
update Tulip AppImage build on TravisCI: now only compile on CentOS 6 for wider compatibilty (especially debian jessie) but uses Python 2.7 and Qt 4.8 (instead of legacy Python 2.6 and Qt 4.6)
-
avoid to install .svn files when copying directories with CMake
-
fix Qt4 build after commit 12765, my bad
-
be more explicit about the reasons a project needs to be saved when exiting Tulip
-
send window modified notifications only when the content of Python files to save has changed (should avoid to tell the user that the Tulip project has to be saved when it does not need to)
-
ensure to hide the Python IDE window when exiting Tulip otherwise it will gain focus and need to be closed manually
-
forgot that H3 layout needs numpy so add checks for its availability
-
some fixes for Python wheels generation after the removal of the tulipogl module
-
add a new 3D layout plugin written in Python: H3 from T. Munzner (implementation under MIT license is taken from https://github.com/buzzfeed/pyh3)
-
fix size policy issue for Python IDE (on CentOS the full height of the IDE dialog was not used)
-
copy Tulip Python plugins in build folder in order to avoid adding compiled Python files (*.pyo, *.pyc, __pycache__) in source folder when generating the documentation
-
silent output of call to update-*-database when calling 'make install' on linux
-
add missing TULIPConfigVersion.cmake file in order to check that the required Tulip version (second argument of CMake FIND_PACKAGE) is compatible with the one installed on the host system + consider Tulip 5.x backward compatible with Tulip 4.x as there is not breaking API changes
-
Hi, sorry for the delayed answer. You should be able to obtain what you want by playing with the OpenGL stencil values associated to nodes and edges while rendering the graph. Open the 'Layers' widget on the top right corner of the graph view. Then expand the 'Main' then 'graph' tree entry. Then uncheck the stencil checkbox for 'Nodes' and check the one for 'Edges'. The edges should now be drawn on top of the map node. Cheers!
-
last polishing after the previous round of commits
-
fix 'make bundle' invocation on MacOS
-
update CI: now install Tulip once it is compiled + add Travis builds for Tulip AppImage packaging (using CentOS 6 and CentOS 7 docker images)
-
fix detection of qhull 2003.1 on CentOS
-
ensure to install Linux desktop configuration files for Tulip in the right place when packaging for a distro
-
use correct install paths and names for Tulip CMake modules + do not install QtX and Sphinx module (those are intended to be only used internally when compiling Tulip, if you want to use them anyway adjust your CMake module path to the cmake folder located in the Tulip source tree)
-
some changes regarding the installation of Tulip Python modules to ease the packaging for Linux distributions:
-
ensure Tulip libraries and plugins can be correctly packaged and executed on every Linux distributions (especially those from the Red Hat family like CentOS, Fedora, ...):
-
reorganize color scale image files: put all ColorBrewer ones into a separate folder and add the LICENSE file instead of those long and ugly file names *_from_ColorBrewer.org
-
add a new exhaustive Python test regarding plugins registration and supported parameter types
-
copy Qt plugins on windows only when the CMake flag TULIP_FIXUP_BUNDLE is enabled
-
fix quazip detection on MSYS2 (it is now named quazip5 as it is Qt5 based)
-
fix MSYS2 build on Appveyor after recent upgrade to Qt 5.9.2 (see https://github.com/Alexpux/MINGW-packages/issues/3036)
-
fix a Python test that may fail sometimes
-
remove the FindGLEW cmake Module as there is already one in the standard CMake library since the 2.8.10 release
-
fix msys2 builds on appveyor
-
add a new Python test for graph properties creation and manipulation
-
small fix after last commit
-
finally add tests for Python bindings (never too late): start with basic graph structure ones
-
rename 'unit_test' folder to 'tests'
-
add new static method tlp::PluginLibraryLoader::loadPluginsFromDir to recursively load Tulip plugins from a root directory and use it in tlp::initTulipSoftware function
-
fix for Python 2 after last commit
-
finally found a way to include the automatic generation of Tulip Plugins documentation for the Python API in the CMake build process
-
rework the way graphs loaded in Tulip are destroyed when exiting the application: prefer delete them in GraphPerspective destructor and ensure views and interactors are destroyed first to avoid possible segfaults when exiting (for instance when the neighborhood interactor is still active when exiting)
-
fix memory leaks detected with clang asan
-
when closing a view, ensure to uninstall current interactor to avoid possible crashs (due to its Qt event filter being still active)
-
don't link Color Mapping plugin to Qt when building Tulip-Python wheels in order to distribute it with the tulip-python wheel rather than with the tulipgui-python one
-
Python API cleanup: remove the tulipogl module (not really needed neither used) and merge its small content into the tulip and tulipgui modules
-
fix a couple of Qt memory leaks
-
fix compilation warning when using python provided by MSYS2
-
update documentation regarding how to setup tulip Python modules from a MacOS bundle installation
-
integrates fixes from probonopd regarding AppImage packaging (see https://github.com/tulip5/tulip/pull/12 and https://github.com/tulip5/tulip/pull/14)
-
fix some crashs in Python bindings appeared with commit 12679: ensure correct object ownership when using SIP C api for converting from Python layer to C++ one
-
fix regression after commit 12679: ensure backward compatibility for Python API
-
enabling more Pythonic stuffs in the bindings: optional arguments of functions and methods (those with a default value) can now be used as keyword arguments + update function and method signatures in API documentation
-
following brenoust feature request on GitHub regarding Python bindings: allow to assign to assign tuples/lists to color/layout/size properties (for instance: "graph['viewColor'][n] = [128, 128, 128]")
-
take edge border width into account when using the 3D edges rendering mode
-
when building Tulip with AppVeyor, run the 64 bits build jobs before the 32 bits ones
-
when building Tulip with TravisCI, run Linux build jobs before the Mac OS ones as Mac builds can take some time to start compared to the Linux ones
-
add CMake target dependencies for Python bindings as Tulip parallel build can fail sometimes otherwise (see https://ci.appveyor.com/project/anlambert/tulip/build/1.0.91/job/qyamfiecfb62o781)
-
revert commits 12665 and 12666 as it breaks C++98 build and does not bring significant improvements
-
Hi Sylvain, Thanks for reporting the issue. It is now fixed in the current Tulip trunk and the issue will not appear anymore in next Tulip release. Antoine
-
fix sf bug #869: semantic value of TULIP_INT_VERSION is broken, now uses two digits for the Tulip minor version when generating the Tulip integer version number
-
- prefix all Tulip defined CMake macros in TulipUseFile.cmake by TULIP_ in order to distinguish them from CMake builtin commands + rename some of them
-
This is definitely a include directory order issue but that's weird as we already took care of including the correct include path for sip.h prior to other include paths in the compiler command line (see line 9 in thirdparty/sip-4.19.1/siplib/CMakeLists.txt). You can check the gcc commands issued by running 'make VERBOSE=1'. Maybe we could spot an issue here ?
-
- towards moving to Github in a near future: add cross-platform continuous integration in the cloud setup for Tulip through TravisCI (Linux and MacOS) but also AppVeyor (Windows). When pushing changes to source code, Tulip will be built on every supported platforms and its tests will be run afterwards.
-
update Tulip website url in license header and comments
-
Hi Eyal, I did not manage to reproduce your build issue on Linux Mint 18.2 x86_64. My guess is that something went wrong when configuring the SIP tool bundled with the Tulip source. You should check if there is a "sip.h" file in the following directory: /usr/local/src/tulip-5.0.0/build/thirdparty/sip-4.19.1/siplib/ . If it is not present, the "sip.h" file installed on your system is used instead and as the version mismatch the one we are using in Tulip, the compilation fails. Maybe you should try...
-
fix minimum required CMake version and tulip website url in README
-
fix methods visibility in tlp::VoronoiDiagram Python wrapper
1 >
