Author Topic: Invictus Innovations - Help Wanted!  (Read 18171 times)

0 Members and 1 Guest are viewing this topic.

Offline Ykw

  • Full Member
  • ***
  • Posts: 88
    • View Profile
Are you still looking for c++ coding? I already wrote you in keyhotee but i'm not sure if you got the message.

We are looking to hire quality c++ developers full time.  AGS funding has opened up many positions, please email me dlarimer at invictus-innovations....


If you (invictus) were here 10 years ago... I would have jumped in to apply with a "I don't care for the salary"...

Offline bytemaster

Are you still looking for c++ coding? I already wrote you in keyhotee but i'm not sure if you got the message.

We are looking to hire quality c++ developers full time.  AGS funding has opened up many positions, please email me dlarimer at invictus-innovations.... 

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

drekrob

  • Guest
Are you still looking for c++ coding? I already wrote you in keyhotee but i'm not sure if you got the message.

Offline bytemaster

I'm available for graphic design and translating English to Spanish, just in case someone is interested, good quality, fast, economically reasonable...

We need a lot of graphic design work and translation into Spanish.  Let your skills be known in the Website Bounty Thread and I believe there is a $12K sub-bounty for website logos. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline robonix

  • Full Member
  • ***
  • Posts: 100
    • View Profile
    • Auto Hackeate, Reprogramando el sustrato vital
I'm available for graphic design and translating English to Spanish, just in case someone is interested, good quality, fast, economically reasonable...
« Last Edit: January 02, 2014, 06:01:05 am by robonix »

Offline arcke

  • Full Member
  • ***
  • Posts: 115
    • View Profile
    • Diaspora
Is there any guide to build under Ubuntu? I get various compilation errors.
https://bitsharestalk.org/index.php?topic=1672.msg19078#msg19078

What are you doing now to build it and what errors are you getting? Let me know where you get stuck.
OpenPGP: 0x22d7e9cc35375665
PTS - PawnbhoiXhmkrKJEPAsCiwkpP81nRXJGTD
Diaspora profile - https://pod.orkz.net/u/arcke

Offline pvaladares

  • Full Member
  • ***
  • Posts: 100
    • View Profile
Is there any guide to build under Ubuntu? I get various compilation errors.
PTS : PkbJAm9uxuGgC9n2NVwWYs8bvX3Mj8uAg3 | MMC : M91vp33SSVBG7N3X9CbrgMcwSBxTDQeDAb
BTC : 1CrAkkYZrVCnwDKSBw3bcnMSYMakEhfB6N
Trade BTC/PTS @ cryptsy.com

Offline barwizi

  • Hero Member
  • *****
  • Posts: 764
  • Noirbits, NoirShares, NoirEx.....lol, noir anyone?
    • View Profile
    • Noirbitstalk.org
Hi, maybe you could offer permanent jobs to those who jump onto Bounties (like me) it simplifies things and halts delays caused by the need for someone with permissions to review code. Employees get access right?
--Bar--  PiNEJGUv4AZVZkLuF6hV4xwbYTRp5etWWJ

The magical land of crypto, no freebies people.

Offline earthbound

  • Full Member
  • ***
  • Posts: 120
    • View Profile
    • earthbound.io
Here is my first attempt for a logo/theme for ProtoShares.. Give me some feedback - http://www.imm.io/1m9hR
P.S. I know this is over.. Just doing it for fun!

What's over? Clueless here :)

I like it. I might discard the ribbon, and maybe make the whole thing look more coin-ish. Maybe with a font that could be minted on to a coin (a more slab or slab-serif font)? OR dramatically depart from that theme, and make it look like non-denominational universal fiat paper (whatever that looks like) and/or company shares.

BTW (@forum/bytemaster), I'm curious:

1) What libraries/tools are required to build Keyhotee on Windows 7, e.g. what version of QT, boost, etc. Going to try to give it a spin.
2) Is/will the development version (and/or the beta) be on a testnet?
« Last Edit: December 30, 2013, 05:11:59 am by McGreedy »
I think I'm not alone when I say I'd like to see more and more planets fall under the ruthless dominion of our solar system. -Jack Handey

Offline adsactly

  • Newbie
  • *
  • Posts: 5
    • View Profile
I Here to help and I have many people looking for work even volunteers lets take back our
System from the Elites One Day At a Time!

Offline jeff777

  • Newbie
  • *
  • Posts: 10
    • View Profile
Here is my first attempt for a logo/theme for ProtoShares.. Give me some feedback - http://www.imm.io/1m9hR
P.S. I know this is over.. Just doing it for fun!

Offline arcke

  • Full Member
  • ***
  • Posts: 115
    • View Profile
    • Diaspora

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.
OpenPGP: 0x22d7e9cc35375665
PTS - PawnbhoiXhmkrKJEPAsCiwkpP81nRXJGTD
Diaspora profile - https://pod.orkz.net/u/arcke

Offline Evan

  • Full Member
  • ***
  • Posts: 75
    • View Profile
  • BitShares: evan

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.

Offline arcke

  • Full Member
  • ***
  • Posts: 115
    • View Profile
    • Diaspora
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.
OpenPGP: 0x22d7e9cc35375665
PTS - PawnbhoiXhmkrKJEPAsCiwkpP81nRXJGTD
Diaspora profile - https://pod.orkz.net/u/arcke

Offline Evan

  • Full Member
  • ***
  • Posts: 75
    • View Profile
  • BitShares: evan
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.