I write Java code for a living, and quite frankly, I have not seen anything more demoralizing than trying to build the Bitshares/Keyhotee workspace.  I have wasted countless hours on this to no avail.  Every hurdle cleared is met by the next obstacle.  If it were not for the fact that I have a DAC I want to build, I would have given up long ago.  I have invested far too much of my time and money for me to let this die.   THIS IS A CRITICAL ROADBLOCK FOR ANY POTENTIAL DAC DEVELOPER! For better or worse, my target platform is VS2012/Win7/64.  That means in addition to building the workspace on my platform, I need to build every single dependency on my platform too.  Quite frankly, the documentation to do this sucks.  The error codes suck.  The support sucks.  Not just I3,  but Boost, Qt, etc, everyone who needs to support my platform.  It sucks because every platform has its own set of quirks that the user must be familiar with,  and if every user is using a different environment, it increases the chances that they get unique errors that no one else has seen before.  Why did I pick my platform?  Because no one told me "use this" instead.  I would much prefer something that I know works than something I have a base level of comfort working in.  I was not married to using VS2102, but I may just be now since I've spent so much time on it. If it weren't for sites like Stack Overflow, I would be nowhere.  This is not just my problem.  This is everyone in the community's problem.  If I can't build you a DAC, then you are getting cheated as an AGS/PTS holder.  Like I said, I write Java code for a living.  I figured there would be some bumps along the way getting re-acquainted with C++, but this is just unacceptable. If I do this for a living and can't get this working, then I can't be the only one whose had issues and given up.  I'm willing to bet that there are others who have been made to feel stupid by this opaque process, and that they've been made to think that these issues are due to their own technical limitations. 

Here is what I propose as a solution.  I3 needs to hire a full time configuration management specialist.  They should be responsible for all working build environments.  Having a bounty for a working build system is not enough.  This CM person would be responsible for maintaining at the minimum, one working Windows, Mac, and Linux environment.  They would need to write tutorials for building the workspace for developers.  This has to be a step by step guide for building every dependency from a clean machine.  Make no assumptions about what the user knows.  I want a complete list of tools to use and the URL to find them.  It should be written in such a way that a non-developer can set set up the workspace.  And finally, they should be supporting developers who are still having issues in order to get it working.

ps - When building Qt statically, I get the following error, so please try to convince me that this doesn't suck:

NMAKE : fatal error U1077: 'cd' : return code '0x2'

Ok I fixed all my previous linking errors.  It looks like I still need to do a static build of Qt to get Keyhotee compiled.  Every other project compiles except for bts_wallet, I get a few errors that look related to this one:

Error   4   error C2039: 'signal' : is not a member of 'fc'   C:\Users\Scott\Documents\GitHub\keyhotee\BitShares\bts_wallet\main.cpp   109   1   bts_wallet

Does anyone have any insight?

Quote from: unlimited_power on February 25, 2014, 09:07:39 pm

Brian, looks like Ethereum is getting on the Keiser report (https://twitter.com/stacyherbert/status/438256072160468994). It would be amazing if we could do the same.

I suppose if enough of you write to Max and Stacy...

This would be amazing 

 

Ok I will do that when I get home from work.  It will be in a few hours

I will most likely be attending this conference.  It seems to be that a reasonable expected cost would be from $500-$1000, but I guess this all depends on the agenda and the value provided. Any idea on when we can find out more info?

Does this mean to treat our test shares as if they were the real thing because they might become so at any moment? Only a critical failure that requires a restart will reset their value?

Quote from: pariah99 on January 14, 2014, 04:22:24 am

This may be a really dumb question, but at what level of precision are AGS going to be calculated?  I am assuming 8 decimal places, but if it's less, I'm curious; also, if they're less, it would be nice to know if they are going to be truncated or rounded.

I only ask because I'm considering trickling in my daily mined PTS > AGS.

This is a very good question and I think my answer is that you should be considerate and send every small donation from the SAME source address.  Then when we build the genesis block it will only be 1 output rather than many small ones.   I would rather not make a rule on this, but for the sake of clarity I am going to make the min threshold to be 0.001 AGS

How do you specify this?  I keep having new addresses being generated.  All of my donations have been at least 1PTS or greater, so I'm not worried about the decimal issue, but its getting to be inconvenient tracking all of my donations.