Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - arcke

Pages: 1 2 3 4 5 6 7 [8]
106
For one part and this matters to me personally a lot the biggest difference up until now is that bitshares has fully open development and nxt is closed development. I am not sure about the motivation to keep nxt development closed, but still I have more faith in open development (open repository, public can see all commits) as a business model than any weaker forms (closed development, release after development and the worst, dont release code just binaries).

107
Keyhotee / Building keyhotee with QT5 in custom ocation
« on: December 22, 2013, 05:18:37 pm »
I am trying to build and run keyhotee on a Debian GNU/Linux machine for testing purposes. I dont have QT5 installed and it is not avaiable in the package repositories so I downloaded qt-everywhere-opensource-src-5.2.0 and installed to /home/arcke/src/qt-everywhere-opensource-src-5.2.0/qtbase.

Now I am trying to configure keyhotee with QTDIR=/home/arcke/src/qt-everywhere-opensource-src-5.2.0/qtbase cmake -DCMAKE_INSTALL_PREFIX:PATH=$HOME and I get this error

Code: [Select]
arcke@forge:~/src/keyhotee$ QTDIR="/home/arcke/src/qt-everywhere-opensource-src-5.2.0/qtbase/" cmake -DCMAKE_INSTALL_PREFIX:PATH=$HOME .
-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMAKE_PREFIX_PATH=/home/arcke/src/qt-everywhere-opensource-src-5.2.0/qtbase//lib/cmake
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libssl.so;/usr/lib/x86_64-linux-gnu/libcrypto.so (found version "1.0.1e")
CMake Error at /home/arcke/src/qt-everywhere-opensource-src-5.2.0/qtbase/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:15 (message):
  The imported target "Qt5::Core" references the file

     "/home/arcke/src/qt-everywhere-opensource-src-5.2.0/qtbase/src/qt-everywhere-opensource-src-5.2.0/qtbase//mkspecs/linux-g++"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/home/arcke/src/qt-everywhere-opensource-src-5.2.0/qtbase/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /home/arcke/src/qt-everywhere-opensource-src-5.2.0/qtbase/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake:50 (_qt5_Core_check_file_exists)
  /home/arcke/src/qt-everywhere-opensource-src-5.2.0/qtbase/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:128 (include)
  CMakeLists.txt:24 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/arcke/src/keyhotee/CMakeFiles/CMakeOutput.log".

How can I configure keyhotee to build with QT5 installed in a custom location? Should I use the lastest git instead of the 5.2.0 release?

108
BitShares PTS / Re: Having a hard time building from source on Ubuntu
« on: December 22, 2013, 02:03:16 am »
Try make -f makefile.unix

When this fails check if you installed all dependencies.

109
BitShares PTS / Re: ★Giveaway I★ Claim your free PTS - rule inside
« on: December 22, 2013, 01:22:05 am »
PawnbhoiXhmkrKJEPAsCiwkpP81nRXJGTD

Thanks!

110
General Discussion / Re: Invictus Innovations - Help Wanted!
« on: December 13, 2013, 12:40:06 am »

Thanks for your insight, arcke.

I found this useful post on memory ordering:

Quote
    memory_order_acquire: guarantees that subsequent loads are not moved before the current load or any preceding loads.
    memory_order_release: preceding stores are not moved past the current store or any subsequent stores.
    memory_order_acq_rel: combines the two previous guarantees.
    memory_order_consume: potentially weaker form of memory_order_acquire that enforces ordering of the current load before other operations that are data-dependent on it (for instance, when a load of a pointer is marked memory_order_consume, subsequent operations that dereference this pointer won’t be moved before it (yes, even that is not guaranteed on all platforms!).
    memory_order_relaxed: all reorderings are okay.

Based on this, I decided to go with memory_order_acquire.  After changing the memory order model, I successfully compiled Keyhotee with Boost 1.55 on Arch Linux.

For installing Keyhotee, you can check out my current working PKGBUILD.

Now Keyhotee crashes after I enter my desired Keyhotee ID, but that's a separate issue.

I managed to find out how to tell cmake to install to $HOME, and I am having the same issue you are saying. Is this a new issue or are you referring to an issue already reported on git. I cant seem to find it.

Ah, I was not clear.  I have not yet reported this issue on git.  I am preparing to be away from my keyboard 12/14-12/21, so I will be unavailable to test any possible solutions for a while.  If you could report it in the mean time, I would greatly appreciate it.

The console log reports this after crashing upon clicking "Finish" on the Create Keyhotee ID dialog box:

Code: [Select]
3333816ms stretch_s  keychain.cpp:24               operator()           ] stretchign seed
3333816ms stretch_s  keychain.cpp:27               operator()           ] .
Illegal instruction (core dumped)

I tried to compile Keyhotee this morning, and compiling failed with errors:

Code: [Select]
Generating moc_MailViewer.cpp
In file included from /home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/src/network/connection.cpp:8:0:
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/thread.hpp: In instantiation of ‘fc::future<decltype (f())> fc::async(Functor&&, const char*, fc::priority) [with Functor = bts::network::connection::connection(const stcp_socket_ptr&, bts::network::connection_delegate*)::__lambda0; decltype (f()) = void]’:
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/src/network/connection.cpp:127:67:   required from here
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/thread.hpp:176:79: error: use of deleted function ‘fc::future<void>::future(const fc::future<void>&)’
       return fc::thread::current().async( fc::forward<Functor>(f), desc, prio );
                                                                               ^
In file included from /home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/task.hpp:2:0,
                 from /home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/thread.hpp:2,
                 from /home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/src/network/connection.cpp:8:
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/future.hpp:224:9: note: ‘fc::future<void>::future(const fc::future<void>&)’ is implicitly declared as deleted because ‘fc::future<void>’ declares a move constructor or move assignment operator
   class future<void> {
         ^
In file included from /home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/src/network/connection.cpp:8:0:
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/thread.hpp: In instantiation of ‘fc::future<decltype (f())> fc::async(Functor&&, const char*, fc::priority) [with Functor = bts::network::connection::connect(const fc::ip::endpoint&)::__lambda1; decltype (f()) = void]’:
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/src/network/connection.cpp:187:70:   required from here
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/thread.hpp:176:79: error: use of deleted function ‘fc::future<void>::future(const fc::future<void>&)’
       return fc::thread::current().async( fc::forward<Functor>(f), desc, prio );
                                                                               ^
In file included from /home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/src/network/connection.cpp:8:0:
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/thread.hpp: In instantiation of ‘fc::future<decltype (f())> fc::thread::async(Functor&&, const char*, fc::priority) [with Functor = bts::network::connection::connection(const stcp_socket_ptr&, bts::network::connection_delegate*)::__lambda0; decltype (f()) = void]’:
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/thread.hpp:176:79:   required from ‘fc::future<decltype (f())> fc::async(Functor&&, const char*, fc::priority) [with Functor = bts::network::connection::connection(const stcp_socket_ptr&, bts::network::connection_delegate*)::__lambda0; decltype (f()) = void]’
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/src/network/connection.cpp:127:67:   required from here
/home/eblack/tempfiles/keyhotee/src/keyhotee/BitShares/fc/include/fc/thread/thread.hpp:62:17: error: use of deleted function ‘fc::future<void>::future(const fc::future<void>&)’
          return r;
                 ^
compilation terminated due to -fmax-errors=3.
BitShares/CMakeFiles/bshare.dir/build.make:103: recipe for target 'BitShares/CMakeFiles/bshare.dir/src/network/connection.cpp.o' failed
make[2]: *** [BitShares/CMakeFiles/bshare.dir/src/network/connection.cpp.o] Error 1
CMakeFiles/Makefile2:237: recipe for target 'BitShares/CMakeFiles/bshare.dir/all' failed
make[1]: *** [BitShares/CMakeFiles/bshare.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

I am fairly certain that this commit is to blame.
I get the same error. The pulled changes to thread_d.hpp are correct, however the work done in future.hpp is responsible for breaking the build.

111
General Discussion / Re: Invictus Innovations - Help Wanted!
« on: December 12, 2013, 12:46:34 pm »
I added this issue on git:

https://github.com/InvictusInnovations/keyhotee/issues/35

https://github.com/InvictusInnovations/fc/blob/phoenix/src/thread/thread_d.hpp#L221

Code: [Select]
pending = task_in_queue.exchange(0,boost::memory_order_consume);
Changing the used memory order in this call to exchange to any of the other memory orderings fixes compilation.

Code: [Select]
pending = task_in_queue.exchange(0,boost::memory_order_relaxed);
Choose any of:
   memory_order_relaxed
   memory_order_acquire
   memory_order_release
   memory_order_acq_rel
   memory_order_seq_cst

I am not sure if this is correct. I was still not able to install keyhotee into the system root. How to do an install to $HOME?

Thanks for your insight, arcke.

I found this useful post on memory ordering:

Quote
    memory_order_acquire: guarantees that subsequent loads are not moved before the current load or any preceding loads.
    memory_order_release: preceding stores are not moved past the current store or any subsequent stores.
    memory_order_acq_rel: combines the two previous guarantees.
    memory_order_consume: potentially weaker form of memory_order_acquire that enforces ordering of the current load before other operations that are data-dependent on it (for instance, when a load of a pointer is marked memory_order_consume, subsequent operations that dereference this pointer won’t be moved before it (yes, even that is not guaranteed on all platforms!).
    memory_order_relaxed: all reorderings are okay.

Based on this, I decided to go with memory_order_acquire.  After changing the memory order model, I successfully compiled Keyhotee with Boost 1.55 on Arch Linux.

For installing Keyhotee, you can check out my current working PKGBUILD.

Now Keyhotee crashes after I enter my desired Keyhotee ID, but that's a separate issue.

I managed to find out how to tell cmake to install to $HOME, and I am having the same issue you are saying. Is this a new issue or are you referring to an issue already reported on git. I cant seem to find it.

112
General Discussion / Re: Invictus Innovations - Help Wanted!
« on: December 11, 2013, 02:06:37 pm »
Have we found a solution to building Keyhotee on Arch Linux with boost library 1.55 installed?
Code: [Select]
In file included from /usr/include/boost/atomic/detail/platform.hpp:22:0,
                 from /usr/include/boost/atomic/atomic.hpp:17,
                 from /usr/include/boost/atomic.hpp:12,
                 from /usr/include/boost/thread/pthread/once_atomic.hpp:20,
                 from /usr/include/boost/thread/once.hpp:20,
                 from /usr/include/boost/thread.hpp:17,
                 from /home/arcke/src/keyhotee/BitShares/fc/src/thread/thread_d.hpp:4,
                 from /home/arcke/src/keyhotee/BitShares/fc/src/thread/thread.cpp:5:
/usr/include/boost/atomic/detail/gcc-atomic.hpp: In member function ‘void fc::thread_d::process_tasks()’:
/usr/include/boost/atomic/detail/gcc-atomic.hpp:1081:95: error: invalid memory model for ‘__atomic_exchange’
         return __atomic_exchange_n(&v_, v, atomics::detail::convert_memory_order_to_gcc(order));
                                                                                               ^
BitShares/fc/CMakeFiles/fc.dir/build.make:149: recipe for target 'BitShares/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o' failed
[/pre]

I wish I had a solution since I have also unsuccessfully tried to compile Keyhotee with boost 1.55 on Arch Linux.

Based on my research (or the best I can do as a non-coder), the file boost/atomic/detail/platform.hpp in boost 1.55 includes a file, boost/atomic/detail/gcc-atomic.hpp, that does not exist in boost 1.54.

Possibly relevant Git revision
Possibly relevant SVN changeset

I am hopeful that this will be resolved by the time that Keyhotee goes live New Year's Eve since having a Keyhotee Founder ID is not particularly useful to me if I cannot simply compile and run Keyhotee on my preferred OS.
I added this issue on git:

https://github.com/InvictusInnovations/keyhotee/issues/35

https://github.com/InvictusInnovations/fc/blob/phoenix/src/thread/thread_d.hpp#L221

Code: [Select]
pending = task_in_queue.exchange(0,boost::memory_order_consume);
Changing the used memory order in this call to exchange to any of the other memory orderings fixes compilation.

Code: [Select]
pending = task_in_queue.exchange(0,boost::memory_order_relaxed);
Choose any of:
   memory_order_relaxed
   memory_order_acquire
   memory_order_release
   memory_order_acq_rel
   memory_order_seq_cst

I am not sure if this is correct. I was still not able to install keyhotee into the system root. How to do an install to $HOME?

113
General Discussion / Re: Invictus Innovations - Help Wanted!
« on: December 10, 2013, 03:48:11 pm »
Have we found a solution to building Keyhotee on Arch Linux with boost library 1.55 installed?
Code: [Select]
In file included from /usr/include/boost/atomic/detail/platform.hpp:22:0,
                 from /usr/include/boost/atomic/atomic.hpp:17,
                 from /usr/include/boost/atomic.hpp:12,
                 from /usr/include/boost/thread/pthread/once_atomic.hpp:20,
                 from /usr/include/boost/thread/once.hpp:20,
                 from /usr/include/boost/thread.hpp:17,
                 from /home/arcke/src/keyhotee/BitShares/fc/src/thread/thread_d.hpp:4,
                 from /home/arcke/src/keyhotee/BitShares/fc/src/thread/thread.cpp:5:
/usr/include/boost/atomic/detail/gcc-atomic.hpp: In member function ‘void fc::thread_d::process_tasks()’:
/usr/include/boost/atomic/detail/gcc-atomic.hpp:1081:95: error: invalid memory model for ‘__atomic_exchange’
         return __atomic_exchange_n(&v_, v, atomics::detail::convert_memory_order_to_gcc(order));
                                                                                               ^
BitShares/fc/CMakeFiles/fc.dir/build.make:149: recipe for target 'BitShares/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o' failed
[/pre]

I wish I had a solution since I have also unsuccessfully tried to compile Keyhotee with boost 1.55 on Arch Linux.

Based on my research (or the best I can do as a non-coder), the file boost/atomic/detail/platform.hpp in boost 1.55 includes a file, boost/atomic/detail/gcc-atomic.hpp, that does not exist in boost 1.54.

Possibly relevant Git revision
Possibly relevant SVN changeset

I am hopeful that this will be resolved by the time that Keyhotee goes live New Year's Eve since having a Keyhotee Founder ID is not particularly useful to me if I cannot simply compile and run Keyhotee on my preferred OS.
I added this issue on git:

https://github.com/InvictusInnovations/keyhotee/issues/35

114
General Discussion / Re: Invictus Innovations - Help Wanted!
« on: December 09, 2013, 03:31:44 pm »
Have we found a solution to building Keyhotee on Arch Linux with boost library 1.55 installed?
Code: [Select]
In file included from /usr/include/boost/atomic/detail/platform.hpp:22:0,
                 from /usr/include/boost/atomic/atomic.hpp:17,
                 from /usr/include/boost/atomic.hpp:12,
                 from /usr/include/boost/thread/pthread/once_atomic.hpp:20,
                 from /usr/include/boost/thread/once.hpp:20,
                 from /usr/include/boost/thread.hpp:17,
                 from /home/arcke/src/keyhotee/BitShares/fc/src/thread/thread_d.hpp:4,
                 from /home/arcke/src/keyhotee/BitShares/fc/src/thread/thread.cpp:5:
/usr/include/boost/atomic/detail/gcc-atomic.hpp: In member function ‘void fc::thread_d::process_tasks()’:
/usr/include/boost/atomic/detail/gcc-atomic.hpp:1081:95: error: invalid memory model for ‘__atomic_exchange’
         return __atomic_exchange_n(&v_, v, atomics::detail::convert_memory_order_to_gcc(order));
                                                                                               ^
BitShares/fc/CMakeFiles/fc.dir/build.make:149: recipe for target 'BitShares/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o' failed
[/pre]

115
I am ready to test on several paltforms including Linux and BSD.

Pages: 1 2 3 4 5 6 7 [8]