Looks like your linux distribution's libc++ is too old for the binary.
What linux distribution are you on?
David E DeMarle
Kitware, Inc.
R Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
On Fri, Jun 10, 2016 at 6:07 PM, 曹智选 wrote:
> Why I still
Why I still have the error:
How could I get rid of them?
/rohit1/data/users/zhixuanc/Soft/ParaView-5.1.0-RC1-Qt4-OpenGL2-MPI-Linux-64bit/lib/paraview-5.1/paraview:
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by
On 10.06.2016 18:21, Utkarsh Ayachit wrote:
New binaries for linux have been uploaded. Please give them a go.
Now it seems to work... At least it starts and I can do basic stuff.
Thanks, Utkarsh!
Thanks
Utkarsh
On Thu, Jun 9, 2016 at 7:10 PM, Utkarsh Ayachit
Ok, that doesn't sound as bad as I expected. But still, is it necessary to
"poll" the socket, checking its "select" method?
I am not familiar with the details of socket communication, but I expect it
should be possible that the socket invokes some callback when a message
arrives? Or does some of
Content in Xdmf's context is the data that XdmfArray contains. In XML this is
the data between the XML tags.
For the Array:
output.h5:Data6
The "Content" is "output.h5:Data6" which is then parsed into an HDF5 reference.
The term "Content" is a carryover from the XML parser that Xdmf uses.
I'm trying to use Paraview with xdmf files which I've generated in a python
script (both the xml light data and the hdf5 heavy data). Initially I was
working with Paraview-4.0.1 which I could install from apt and loaded the
data fine. Recently I downloaded Paraview-5.0.1, which fails to load the
New binaries for linux have been uploaded. Please give them a go.
Thanks
Utkarsh
On Thu, Jun 9, 2016 at 7:10 PM, Utkarsh Ayachit
wrote:
> Roger that. I've getting a new build. I switched to using a new build
> machine -- looks like that was premature. I'll upload
ProcessEvents() doesn't poll the server. It only "select"s on the
socket to see if the server sent any new messages to the client.
> One more question out of curiosity: isn't it quite ineffient, if clients
> continuously invoke vtkNetworkAccessManager::ProcessEvents´()? For smooth
> interaction