wassimj / TopologicSverchok

Topologic custom nodes for sverchok on Blender3D
GNU Affero General Public License v3.0
83 stars 18 forks source link

Vertex cannot import? No. Cppyy sudo problems + libfreeimage6-dev + Topollogy by geometry node problems. #1

Closed nortikin closed 3 years ago

nortikin commented 3 years ago
  File "/home/ololo/Downloads/INSTALL/blender-2.90.0-linux64/2.90/scripts/modules/addon_utils.py", line 351, in enable
    mod = __import__(module_name)
  File "/home/ololo/.config/blender/2.90/scripts/addons/topologicsverchok/__init__.py", line 31, in <module>
    from topologic import Vertex, Edge, Wire, Face, Shell, Cell, CellComplex, Cluster
ImportError: cannot import name 'Vertex' from 'topologic' (/home/ololo/Downloads/INSTALL/blender-2.90.0-linux64/2.90/python/lib/python3.7/site-packages/topologic/__init__.py)
nortikin commented 3 years ago

my topologic init file looks like:

  GNU nano 3.2                                                                                                      __init__.py                                                                                                               

# Copyright (c) Microsoft Corporation.
# Licensed under the MIT license.

from .version.version import name, version as __version__

# VITAL NOTE: ORDER MATTERS
from .exceptions import DialectException, InvalidGraphError, UnweightedGraphError

# load individual modules into the top level topologic namespace
from .connected_components import number_connected_components, \
    largest_connected_component, \
    connected_components_generator
from .partitioned_graph import PartitionedGraph
from .graph_augmentation import rank_edges, diagonal_augmentation

from . import similarity
from . import io
from . import projection
from . import statistics
from . import embedding
from . import partition

__all__ = [
    'connected_components_generator',
    'DialectException',
    'InvalidGraphError',
    'largest_connected_component',
    'number_connected_components',
    'PartitionedGraph',
    'diagonal_augmentation',
    'UnweightedGraphError'
]

directory is:

assertions.py            __init__.py           __pycache__
connected_components.py  io                    similarity.py
embedding                partition             statistics
exceptions.py            partitioned_graph.py  version
graph_augmentation.py    projection
nortikin commented 3 years ago

is there Vertex really?

brunopostle commented 3 years ago

You need TopologicPy, which in turn depends on cppyy and the Topologic C++ library

[edit] also these files are not from the topologicsverchok.zip file

wassimj commented 3 years ago

You need to first install https://github.com/wassimj/topologicPy

nortikin commented 3 years ago

sudo apt-get install libfreeimage6-dev it is no libfreeimage-dev as in instruction on Debian 10

nortikin commented 3 years ago

with that steps it needed to be makefile script to use make on linux

nortikin commented 3 years ago

Doing something wrong

>>> import topologic
/usr/local/lib/python3.7/dist-packages/cppyy_backend/loader.py:125: UserWarning: No precompiled header available (/usr/local/lib/python3.7/dist-packages/cppyy_backend/etc not writable); this may impact performance.
  warnings.warn('No precompiled header available (%s); this may impact performance.' % msg)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ololo/git/TopologicPy/cpython/topologic/__init__.py", line 101, in <module>
    cppyy.include(topologic_inc + "/" + header )
  File "/usr/local/lib/python3.7/dist-packages/cppyy/__init__.py", line 229, in include
    raise ImportError('Failed to load header file "%s"%s' % (header, err.err))
ImportError: Failed to load header file "/usr/local/include/TopologicCore/Aperture.h"
In file included from input_line_19:1:
In file included from /usr/local/include/TopologicCore/Aperture.h:20:
In file included from /usr/local/include/TopologicCore/Topology.h:22:
/usr/local/include/TopologicCore/Dictionary.h:40:9: error: 'auto' return without trailing return type; deduced return types are a C++14 extension
        auto GetEnumerator() { return this->begin(); }
        ^
/usr/local/include/TopologicCore/Dictionary.h:40:39: error: no viable conversion from returned value of type 'std::map<std::basic_string<char>, std::shared_ptr<TopologicCore::Attribute>,
      std::less<std::basic_string<char> >, std::allocator<std::pair<const std::basic_string<char>, std::shared_ptr<TopologicCore::Attribute> > > >::iterator' (aka '_Rb_tree_iterator<std::pair<const std::basic_string<char>,
      std::shared_ptr<TopologicCore::Attribute> > >') to function return type 'int'
        auto GetEnumerator() { return this->begin(); }
                                      ^~~~~~~~~~~~~
nortikin commented 3 years ago
  File "/home/ololo/.config/blender/2.90/scripts/addons/topologicsverchok/__init__.py", line 31, in <module>
    from topologic import Vertex, Edge, Wire, Face, Shell, Cell, CellComplex, Cluster
  File "/home/ololo/Downloads/INSTALL/blender-2.90.0-linux64/2.90/python/lib/python3.7/site-packages/topologic/__init__.py", line 101, in <module>
    cppyy.include(topologic_inc + "/" + header )
  File "/home/ololo/Downloads/INSTALL/blender-2.90.0-linux64/2.90/python/lib/python3.7/site-packages/cppyy/__init__.py", line 229, in include
    raise ImportError('Failed to load header file "%s"%s' % (header, err.err))
ImportError: Failed to load header file "/usr/local/include/TopologicCore/Aperture.h"
In file included from input_line_19:1:
In file included from /usr/local/include/TopologicCore/Aperture.h:20:
In file included from /usr/local/include/TopologicCore/Topology.h:22:
/usr/local/include/TopologicCore/Dictionary.h:40:9: error: 'auto' return without trailing return type; deduced return types are a C++14 extension
        auto GetEnumerator() { return this->begin(); }
        ^
/usr/local/include/TopologicCore/Dictionary.h:40:39: error: no viable conversion from returned value of type 'std::map<std::basic_string<char>, std::shared_ptr<TopologicCore::Attribute>,
      std::less<std::basic_string<char> >, std::allocator<std::pair<const std::basic_string<char>, std::shared_ptr<TopologicCore::Attribute> > > >::iterator' (aka '_Rb_tree_iterator<std::pair<const std::basic_string<char>,
      std::shared_ptr<TopologicCore::Attribute> > >') to function return type 'int'
        auto GetEnumerator() { return this->begin(); }
                                      ^~~~~~~~~~~~~
nortikin commented 3 years ago

cppyy is defective somehow

wassimj commented 3 years ago

cppyy is defective somehow

Can you please submit a bug report to them at: https://bitbucket.org/wlav/cppyy/issues

nortikin commented 3 years ago

https://github.com/NonManifoldTopology/Topologic/issues/20 https://bitbucket.org/wlav/cppyy/issues/315/topologic-installation-broken

brunopostle commented 3 years ago

@nortikin I'll try and describe the dependencies in order:

topologicsverchok requires (blender, sverchok, obviously) and the topologicPy python bindings to the Topologic C++ library.

topologicPy uses cppyy for C++ bindings, some people have had success with simply:

pip install cppyy

Myself (on fedora), I had to install four packages, in this order: cppyy-cling, cppyy-backend, CPyCppyy, and finally cppyy

The way that cppyy works is that it compiles the bindings at runtime, so for topologicPy to work you need to have the Topologic C++ header files in /usr/include/TopologicCore or /usr/local/include/TopologicCore, as well as having the libTopologicCore.so.* library installed normally.

Topologic depends on opencascade, so you need this too.

nortikin commented 3 years ago

all in places, but no viable conversion from returned value of type char to function return type int in headers Dictionary.h line: auto GetEnumerator() { return this->begin(); } what is auto in case? not bool not char string not int, but auto. I'm not C proger, so auto not clear how it works and what to do

nortikin commented 3 years ago

trying to replace with int - the same. this->begin() is error

wlav commented 3 years ago

Somehow the installation dropped to C++11, instead of C++17 (the default). Check what cppyy thinks it has:

import cppyy
cppyy.cppexec('std::cerr << __cplusplus << std::endl')

which should print 201703.

nortikin commented 3 years ago
>>> import cppyy
/usr/local/lib/python3.7/dist-packages/cppyy_backend/loader.py:125: UserWarning: No precompiled header available (/usr/local/lib/python3.7/dist-packages/cppyy_backend/etc not writable); this may impact performance.
  warnings.warn('No precompiled header available (%s); this may impact performance.' % msg)
>>> cppyy.cppexec('std::cerr << __cplusplus << std::endl')
201103
True
~$ cpp --version
cpp (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
nortikin commented 3 years ago

seems like no cpp17 in official PPA:

autobahn-cpp-dev - WAMP in C++ for Boost/Asio - development headers
libbackward-cpp-dev - Beautiful stack trace pretty printer for C++
libeiskaltdcpp-dev - DC++ kernel from EiskaltDC++ (development files)
libjsonrpccpp-dev - development files for JSON-RPC C++ framework
libjsoncpp-dev - library for reading and writing JSON for C++ (devel files)
libjsoncpp-doc - API documentation for libjsoncpp-dev
libosmium2-dev - C++ framework for working with OSM data files
libpmemobj-cpp-dev - C++ bindings to libpmemobj
libyang-cpp-dev - parser toolkit for IETF YANG data modeling - C++ development files
libmcpp-dev - Alternative C/C++ preprocessor (development files)
libpcg-cpp-dev - compile-time library for PCG random number generation
libpoppler-cpp-dev - PDF rendering library -- development files (CPP interface)
libprocess-cpp-dev - C++11 library for handling processes (dev headers and libraries)
libproperties-cpp-dev - C++11 library providing properties/signals - dev headers
libproperties-cpp-doc - Documentation files for libproperties-cpp-dev
libqpid-proton-cpp12-dev - C++ Development libraries for writing messaging apps with Qpid Proton
libqrcodegencpp-dev - QR Code generator library in multiple languages - C++ development headers
libsvncpp-dev - Subversion C++ library (development files)
libbondcpp-dev - Development files for Robot OS bondcpp library
libroscpp-dev - Robot OS development files for libroscpp
libxmlrpcpp-dev - development files for Robot OS libxmlrpcpp
libasynccpp-dev - AsyncCpp library for SvxLink (development files)
libtercpp-dev - Translation Error Rate scoring tool - development files
libucpp-dev - embeddable, quick and light C preprocessor -- development
libui-gxmlcpp-dev - High-level C++ wrapper library for libxml2/libxslt (development)
libui-utilcpp-dev - UI C++ utility library (development)
libutfcpp-dev - UTF8-CPP: UTF-8 with C++ - dev
libyaml-cpp-dev - YAML parser and emitter for C++ - development files
wlav commented 3 years ago

No, I don't mean a package called cpp17, but the C++ standard version 2017, aka C++17. Since Cling is a compiler, you can tell it to adhere to different standards. Given the code snippet, the minimum should be C++14, but it looks like it's somehow set to C++11. Let me dig to see whether I can reproduce some conditions that would make it think C++11 is the max (certainly, 8.3.0 should be fine). It may be b/c it can place the precompiled header in the install location.

nortikin commented 3 years ago

it is ok. it was owner problem chown -R %me%:%me% solved this for cppyy and topologic both

nortikin commented 3 years ago

I was trying to run some <cppyy.gbl.TopologicCore.Cluster object at 0x(nil) held by std::shared_ptr<TopologicCore::Cluster> at 0x7f349e101e80> изображение

nortikin commented 3 years ago

From scratch is ok: изображение and from geometry not works. That is problem изображение

wlav commented 3 years ago

chown -R %me%:%me% solved this for cppyy and topologic both

Thanks; I changed the warning message to explicitly note the option of setting the CLING_STANDARD_PCH envar if the default placement directory is not writable (see also: https://cppyy.readthedocs.io/en/latest/installation.html#precompiled-header), and made a note in the documentation that w/o the PCH, the C++ standard defaults to the one with which cppyy-cling was built.

Aside, the PCH should have been generated as part of the installation process (i.e. when that installation is virtually guaranteed to be writable), so I still want to figure out why that didn't happen in this case.

brunopostle commented 3 years ago

@wlav I built rpm packages of cppyy and the way the PCH is created is problematic, from my packaging notes:

Basically, allDict.cxx.pch_tmp_<PID> gets built in /usr/lib/python3.8/site-packages/cppyy_backend/ on the system, so obviously fails unless you are running this process as root (rpm like lots of packaging systems expects to be able to install as a non-root user).

After it is created it needs to end up as /usr/lib/python3.8/site-packages/cppyy_backend/etc/allDict.cxx.pch

My solution was to create a writable copy of this cppyy_backend folder, manipulate PYTHONPATH and CLING_STANDARD_PCH to build and install the PCH in this writable folder. Then finally to copy the PCH into the package.

wlav commented 3 years ago

Just to be sure I follow: the above is when installing the rpm package on a target system? (Not when building the package for distribution.) If rpm package is part of a larger system where the version of the system compiler is known (is e.g. the case with conda), then you can actually pre-package the PCH.

In fact, upstream does this for their binary builds. I chose otherwise b/c a) the PCH is big, and b) there are too many different systems out there, so I found rebuilding after installation to be much more portable than patching up known incompatabilities. But it is still just a choice, and with the PCH, no system compiler is needed on the final target, which can be useful on Windows (but it needs rebuilding if a different compiler is present).

With pre-compiled modules (of which there can be many, rather than just the single one as in the case of the PCH), all of this becomes moot, as Clang can put them under /tmp or wherever. But although upstream got quite far with modules on Windows, apparently it's not quite functional yet. It does work fine on Linux, though.

brunopostle commented 3 years ago

@wlav I'm building rpm packages for distribution via the fedora channels. When a user installs the cppyy rpm, it already contains a PCH file optimised for their architecture (x86_64, armv8, etc..). This is how you want it to work if and when cppyy becomes part of the base libraries for all the linux distributions.

I can't (and shouldn't) build these rpms at home, so they are created on a fedora build server where I do not (and should not) have root access. This is ok because all software allows me to build in a local folder and install to a temporary folder, all without root privileges.

Except cppyy, it builds this PCH file at install time (which is fine), the problem is that it creates it in one place and then moves it to the final location. The location of this temporary file is wherever cppyy_backend is already installed, which in this case is a system folder in /usr/lib, hence the installation fails.

The solution is to create this temporary PCH file in the source tree, or directly in the destination folder.

Apologies for hijacking this bug report. I was planning on reporting on bitbucket, there are a couple more issues but this is the major one.

wlav commented 3 years ago

Oh, I didn't see the connection with the temporary file and write access. Yes, that is clearly a bug. Will fix.

nortikin commented 3 years ago

Oh, I didn't see the connection with the temporary file and write access. Yes, that is clearly a bug. Will fix.

would you merge your corrected fork to original git master?

wlav commented 3 years ago

Now fixed, and yes is in master.