Closed nortikin closed 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
is there Vertex really?
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
You need to first install https://github.com/wassimj/topologicPy
sudo apt-get install libfreeimage6-dev
it is no libfreeimage-dev
as in instruction on Debian 10
with that steps it needed to be makefile script to use make on linux
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(); }
^~~~~~~~~~~~~
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(); }
^~~~~~~~~~~~~
cppyy is defective somehow
cppyy is defective somehow
Can you please submit a bug report to them at: https://bitbucket.org/wlav/cppyy/issues
@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.
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
trying to replace with int - the same. this->begin()
is error
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
.
>>> 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.
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
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.
it is ok. it was owner problem chown -R %me%:%me% solved this for cppyy and topologic both
I was trying to run some
<cppyy.gbl.TopologicCore.Cluster object at 0x(nil) held by std::shared_ptr<TopologicCore::Cluster> at 0x7f349e101e80>
From scratch is ok: and from geometry not works. That is problem
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.
@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.
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.
@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.
Oh, I didn't see the connection with the temporary file and write access. Yes, that is clearly a bug. Will fix.
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?
Now fixed, and yes is in master.