[Finally DONE] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
Re: [WIP] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
Hello, I can not download the source code. ( https://github.community/t/downloads-as ... d/171192/3 )
Is there some other place where I can download the source code?
Is there some other place where I can download the source code?
Read my profile in order to get more detail about my tools and preferences.
Re: [WIP] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
I use an automatic downloader, GitHub Desktop, but it looks very easy to download directly from
https://github.com/FreeCAD/FreeCAD
Zip format, not tar-gz.
Gene
https://github.com/FreeCAD/FreeCAD
Zip format, not tar-gz.
Gene
Re: [WIP] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
...
Gene, It seems GitHub disconnects the download after 23 minutes, at best 30 minutes. See provided link for GitHub support in my post. I have at best 60KB/s on rare occasions 120KB/s. FreeCAD source 0.18.5 is 210MB, which would be 29 minutes to download for me in best case conditions. So far since 19.1 is out, I tried several times but didn't come further then 160MB. Note that downloading the 838MB AppImage is no problem (provided I have 4 hours of coffee, to not accidently fall in sleep on the "break"-key)
On your suggestion I tried the ZIP also but its just the same...
Please place the source code on the FreeCAD server, a local archive of source code releases wouldn't be a bad idea anyway. I would do it myself, if I had the permission. In fact I have options to do just a thing like that, if there is no other sensible way to put my hours in ...
...GeneFC wrote: ↑Tue Mar 30, 2021 6:24 pmbut it looks very easy to download directly from https://github.com/FreeCAD/FreeCAD
Gene, It seems GitHub disconnects the download after 23 minutes, at best 30 minutes. See provided link for GitHub support in my post. I have at best 60KB/s on rare occasions 120KB/s. FreeCAD source 0.18.5 is 210MB, which would be 29 minutes to download for me in best case conditions. So far since 19.1 is out, I tried several times but didn't come further then 160MB. Note that downloading the 838MB AppImage is no problem (provided I have 4 hours of coffee, to not accidently fall in sleep on the "break"-key)
On your suggestion I tried the ZIP also but its just the same...
Please place the source code on the FreeCAD server, a local archive of source code releases wouldn't be a bad idea anyway. I would do it myself, if I had the permission. In fact I have options to do just a thing like that, if there is no other sensible way to put my hours in ...
Read my profile in order to get more detail about my tools and preferences.
Re: [WIP] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
Sorry to hear that.
This problem has been reported before. It appears the GitHub servers in Europe sometimes severely limit downloads. The solution promoted on this forum was to use torrents, but I do not know if the source code is available in that manner.
I am in the US, and I can download anything from GitHub in a matter of seconds. I have never seen a problem. Some folks have tried to blame Microsoft, but the problem does not seem to be worldwide.
Gene
Re: [DONE] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
"fight the good fight"
Re: [DONE] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
Thank you , that solved it. First time right, got the source in 1h15m, not a single error.sgrogan wrote: ↑Wed Mar 31, 2021 2:25 pmWe have a mirror on GitLab, I don't know if it's any better.
https://gitlab.com/freecad/FreeCAD
Read my profile in order to get more detail about my tools and preferences.
Re: [DONE] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
I am recently trying to adress the mac smesh issue. Maybe someone more familiar with c++ can help to find the root of the problem:
The issue occures during the creation of a mesh. (eg meshing a box)
The error message i get with lldb is the following:
the destructor of SMDS_ElementChunk looks like this:
The issue occures only on osx (compiling with clang).
Also the tests for smesh itself are failing with:
https://dev.azure.com/conda-forge/feeds ... 3b5843ce8b
this is the test whcih fails:
https://github.com/trelau/SMESH/blob/ma ... hers.t.cpp
The issue occures during the creation of a mesh. (eg meshing a box)
The error message i get with lldb is the following:
Code: Select all
thread #1, name = 'CrBrowserMain', queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
* frame #0: 0x000000011fdf0b7b libSMDS.dylib`SMDS_ElementChunk::~SMDS_ElementChunk() + 283
Code: Select all
//================================================================================
/*!
* \brief SMDS_ElementChunk destructor
*/
//================================================================================
SMDS_ElementChunk::~SMDS_ElementChunk()
{
delete [] myElements;
myFactory->myChunksWithUnused.erase( this );
}
The issue occures only on osx (compiling with clang).
Also the tests for smesh itself are failing with:
Code: Select all
$SRC_DIR/SMESH/test/src/StdMeshers.t.cpp:16: FAILED:
{Unknown expression after the reported line}
due to a fatal error condition:
SIGILL - Illegal instruction signal
this is the test whcih fails:
https://github.com/trelau/SMESH/blob/ma ... hers.t.cpp
Re: [C++ EXPERT NEEDED!!!!] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
and this is the output from lldb running the StdMeshers test:
So it should be possible to use the test for debugging the problem. Interesting is also that lldb claims to have no debug build allthough I switched to debug mode by setting -D CMAKE_BUILD_TYPE:STRING="Debug" .
Code: Select all
lldb test_StdMeshers
(lldb) target create "test_StdMeshers"
(lldb) run
Process 8312 launched: '/Users/lo/miniconda3/conda-bld/debug_1633193024057/work/SMESH/test/tests/test_StdMeshers' (x86_64)
libSMDS.dylib was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 8312 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0000000101321815 libSMDS.dylib`SMDS_ElementChunk::~SMDS_ElementChunk() [inlined] SMDS_MeshElement::~SMDS_MeshElement(this=<unavailable>) at SMDS_MeshElement.hxx:55 [opt]
Target 2: (test_StdMeshers) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
* frame #0: 0x0000000101321815 libSMDS.dylib`SMDS_ElementChunk::~SMDS_ElementChunk() [inlined] SMDS_MeshElement::~SMDS_MeshElement(this=<unavailable>) at SMDS_MeshElement.hxx:55 [opt]
frame #1: 0x0000000101321815 libSMDS.dylib`SMDS_ElementChunk::~SMDS_ElementChunk(this=<unavailable>) at SMDS_ElementFactory.cxx:545 [opt]
frame #2: 0x000000010131fae9 libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] SMDS_ElementChunk::~SMDS_ElementChunk(this=0x0000000104c30cf0) at SMDS_ElementFactory.cxx:544 [opt]
frame #3: 0x000000010131fae1 libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] void boost::checked_delete<SMDS_ElementChunk const>(x=<unavailable>) at checked_delete.hpp:36 [opt]
frame #4: 0x000000010131fadc libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] void boost::delete_clone<SMDS_ElementChunk>(r=<unavailable>) at clone_allocator.hpp:45 [opt]
frame #5: 0x000000010131fadc libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] void boost::heap_clone_allocator::deallocate_clone<SMDS_ElementChunk>(r=<unavailable>) at clone_allocator.hpp:63 [opt]
frame #6: 0x000000010131fadc libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] void boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<SMDS_ElementChunk, std::__1::vector<void*, std::__1::allocator<void*> > >, boost::heap_clone_allocator>::remove<boost::void_ptr_iterator<std::__1::__wrap_iter<void**>, SMDS_ElementChunk> >(this=<unavailable>, i=<unavailable>) at reversible_ptr_container.hpp:237 [opt]
frame #7: 0x000000010131fad9 libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] void boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<SMDS_ElementChunk, std::__1::vector<void*, std::__1::allocator<void*> > >, boost::heap_clone_allocator>::remove<boost::void_ptr_iterator<std::__1::__wrap_iter<void**>, SMDS_ElementChunk> >(this=<unavailable>, first=<unavailable>, last=<unavailable>) at reversible_ptr_container.hpp:244 [opt]
frame #8: 0x000000010131fac6 libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<SMDS_ElementChunk, std::__1::vector<void*, std::__1::allocator<void*> > >, boost::heap_clone_allocator>::remove_all(this=<unavailable>) at reversible_ptr_container.hpp:205 [opt]
frame #9: 0x000000010131fac6 libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<SMDS_ElementChunk, std::__1::vector<void*, std::__1::allocator<void*> > >, boost::heap_clone_allocator>::~reversible_ptr_container(this=<unavailable>) at reversible_ptr_container.hpp:499 [opt]
frame #10: 0x000000010131fac6 libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] boost::ptr_sequence_adapter<SMDS_ElementChunk, std::__1::vector<void*, std::__1::allocator<void*> >, boost::heap_clone_allocator>::~ptr_sequence_adapter(this=<unavailable>) at ptr_sequence_adapter.hpp:135 [opt]
frame #11: 0x000000010131fac6 libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] boost::ptr_vector<SMDS_ElementChunk, boost::heap_clone_allocator, void>::~ptr_vector(this=<unavailable>) at ptr_vector.hpp:39 [opt]
frame #12: 0x000000010131fac6 libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] boost::ptr_vector<SMDS_ElementChunk, boost::heap_clone_allocator, void>::~ptr_vector(this=<unavailable>) at ptr_vector.hpp:39 [opt]
frame #13: 0x000000010131fac6 libSMDS.dylib`SMDS_ElementFactory::Clear() [inlined] void (anonymous namespace)::clearVector<boost::ptr_vector<SMDS_ElementChunk, boost::heap_clone_allocator, void> >(v=<unavailable>) at ObjectPool.hxx:34 [opt]
frame #14: 0x000000010131faa6 libSMDS.dylib`SMDS_ElementFactory::Clear(this=<unavailable>) at SMDS_ElementFactory.cxx:270 [opt]
frame #15: 0x000000010132beca libSMDS.dylib`SMDS_Mesh::Clear(this=<unavailable>) at SMDS_Mesh.cxx:1554 [opt]
frame #16: 0x00000001011b9ce6 libSMESHDS.dylib`SMESHDS_Mesh::ClearMesh(this=<unavailable>) at SMESHDS_Mesh.cxx:1033 [opt]
frame #17: 0x0000000100581a5d libSMESH.dylib`SMESH_Mesh::~SMESH_Mesh(this=<unavailable>) at SMESH_Mesh.cxx:192 [opt]
frame #18: 0x0000000100581eee libSMESH.dylib`SMESH_Mesh::~SMESH_Mesh() [inlined] SMESH_Mesh::~SMESH_Mesh(this=<unavailable>) at SMESH_Mesh.cxx:178 [opt]
frame #19: 0x0000000100581ee9 libSMESH.dylib`SMESH_Mesh::~SMESH_Mesh(this=<unavailable>) at SMESH_Mesh.cxx:178 [opt]
frame #20: 0x000000010003f6d3 test_StdMeshers`____C_A_T_C_H____T_E_S_T____0() at StdMeshers.t.cpp:41 [opt]
frame #21: 0x00000001000221f1 test_StdMeshers`Catch::RunContext::invokeActiveTestCase() [inlined] Catch::TestCase::invoke(this=<unavailable>) const at catch.hpp:14160 [opt]
frame #22: 0x00000001000221e5 test_StdMeshers`Catch::RunContext::invokeActiveTestCase(this=<unavailable>) at catch.hpp:13020 [opt]
frame #23: 0x000000010001fe4f test_StdMeshers`Catch::RunContext::runCurrentTest(this=<unavailable>, redirectedCout=<unavailable>, redirectedCerr=<unavailable>) at catch.hpp:12993 [opt]
frame #24: 0x000000010001f403 test_StdMeshers`Catch::RunContext::runTest(this=<unavailable>, testCase=<unavailable>) at catch.hpp:12754 [opt]
frame #25: 0x0000000100025d82 test_StdMeshers`Catch::Session::runInternal() at catch.hpp:13347 [opt]
frame #26: 0x0000000100025c1c test_StdMeshers`Catch::Session::runInternal(this=<unavailable>) at catch.hpp:13553 [opt]
frame #27: 0x0000000100025292 test_StdMeshers`Catch::Session::run(this=<unavailable>) at catch.hpp:13509 [opt]
frame #28: 0x000000010003f2bf test_StdMeshers`main [inlined] int Catch::Session::run<char>(this=<unavailable>, argc=<unavailable>, argv=<unavailable>) at catch.hpp:13231 [opt]
frame #29: 0x000000010003f295 test_StdMeshers`main(argc=<unavailable>, argv=<unavailable>) at catch.hpp:17526 [opt]
frame #30: 0x00007fff68d78015 libdyld.dylib`start + 1
Re: [C++ EXPERT NEEDED!!!!] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
From the backtrace it seems like something is going wrong when the mesh is cleared. Maybe one of the objects were already deleted and the destructor is called a second time.
Still I don't know why lldb is telling me that optimization was used allthough I did a debug-build.
Still I don't know why lldb is telling me that optimization was used allthough I did a debug-build.
Re: [C++ EXPERT NEEDED!!!!] conda: vtk9 / occt7.5 / python3.9 / boost1.74 migration
ok, the error is clearly related to the deletion of the object at the end of the file. Commenting out this section makes the test pass:
Looking at the backtrace again, my interpretation is that the destructor (SMDS_ElementChunk::~SMDS_ElementChunk()) is called twice. So the question is: Is it possible to avoid such cases?
Code: Select all
delete mesh;
delete gen;
Looking at the backtrace again, my interpretation is that the destructor (SMDS_ElementChunk::~SMDS_ElementChunk()) is called twice. So the question is: Is it possible to avoid such cases?