Core Bitcoin Development Help Wanted - page 2.

ScriptGadget

newbie

Activity: 49

Merit: 0

Quote from: Steve on March 09, 2011, 04:18:11 PM

I have to agree. It's not so much the fact that the current code is in one gigantic file...it's that the the code being in one gigantic tends to encourage sloppy practices (not to say one can't write nicely factored code in one gigantic file). Also, if you're ever going to get serious about unit tests, you'll need well factored code to facilitate testing all the various bits (and writing unit tests tends to force the issue of good factoring).

Did someone says unit test?

I haven't looked at the code yet, but I was looking for a bitcoin related project. I have a couple of launches this week (home project and a work project), but starting Monday I can pull down the code and take a look at adding some trivial unit tests to get things started. Does anyone have a serious problem with me using cppunit?

Update: Just spotted the Unit Test thread. I'll read-up.

Steve

hero member

Activity: 868

Merit: 1008

Quote from: Jim Hyslop on March 07, 2011, 11:09:42 PM

Quote from: Gavin Andresen on January 19, 2011, 07:22:12 PM

Having spent a lot of time working with the existing code, I don't think splitting the code into multiple files would make it much easier to work with. The hard part is figuring out how everything fits together (for example "if I have a CWalletTx, how do I get the CBlock that it is in (if any)?"). Just rearranging the code that is there now won't make that problem any better.

No, but splitting main.cpp into smaller files will make compiles much faster when you make a tiny change to a single function. As would eliminating headers.h; it's been my experience that "#include everything you might possibly need and then some" leads to code that is far too tightly coupled, which makes the code even harder to understand.

Just my two cents worth, based on 20 years of C++ programming :-D

I have to agree. It's not so much the fact that the current code is in one gigantic file...it's that the the code being in one gigantic tends to encourage sloppy practices (not to say one can't write nicely factored code in one gigantic file). Also, if you're ever going to get serious about unit tests, you'll need well factored code to facilitate testing all the various bits (and writing unit tests tends to force the issue of good factoring).

Jim Hyslop

member

Activity: 98

Merit: 20

Quote from: Gavin Andresen on January 19, 2011, 07:22:12 PM

Having spent a lot of time working with the existing code, I don't think splitting the code into multiple files would make it much easier to work with. The hard part is figuring out how everything fits together (for example "if I have a CWalletTx, how do I get the CBlock that it is in (if any)?"). Just rearranging the code that is there now won't make that problem any better.

No, but splitting main.cpp into smaller files will make compiles much faster when you make a tiny change to a single function. As would eliminating headers.h; it's been my experience that "#include everything you might possibly need and then some" leads to code that is far too tightly coupled, which makes the code even harder to understand.

Just my two cents worth, based on 20 years of C++ programming :-D

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

Quote from: genjix on March 01, 2011, 04:35:40 AM

Why not keep an up-to-date TODO list of small tasks for new developers to get mucked into? A launchpad.

Good Idea. You should do that. Maybe marking issues at github with a "Launchpad" tag would be a good system?

Dixie

newbie

Activity: 5

Merit: 0

Yeah.I was trying my best to say it out

genjix

legendary

Activity: 1232

Merit: 1076

Why not keep an up-to-date TODO list of small tasks for new developers to get mucked into? A launchpad.

henrik

newbie

Activity: 1

Merit: 0

I'm working my way up to a home compiled version, but got confused.
Win and Unix uses db 4.7 but Mac uses db 4.8
Is this intended? As long as I don't trie to copy between the platforms it would work, but I was puzzeled.

Nice work!

tuxsoul

newbie

Activity: 40

Merit: 0

Quote from: tcatm on February 05, 2011, 08:02:36 PM

I added version tags (0.3.20 and 0.3.21 for now) to some issues and will try to keep them up to date so we'll always know what's blocking a release.

hi,

i can't find that tags, is possible can you tell me which commit is 0.3.20 and 0.3.21 ?

greeting's.

tcatm

sr. member

Activity: 337

Merit: 285

I added version tags (0.3.20 and 0.3.21 for now) to some issues and will try to keep them up to date so we'll always know what's blocking a release.

dduane

newbie

Activity: 47

Merit: 0

I'd love to have sub-cents payments both in the RPC and in the GUI.

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: Luke-Jr on January 26, 2011, 11:34:07 AM

Currently, its master branch mirrors the GitHub one, but with a few bugfixes I added.

This (http://gitorious.org/bitcoin/bitcoin/commit/c16b9402673cf7376c81cad4fe00fc2099e790a8) doesn't look like a bug fix:

Code:

- int64 nAmount = roundint64(dAmount * 100.00) * CENT;
+ int64 nAmount = (int64)(dAmount * (double)COIN);

It looks like removing a feature that was deliberately added.

You should open a thread on the forum to discuss whether being able to make sub-cent payments using the RPC interface is something most people want.

Chris.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

I've created a Gitorious project at http://gitorious.org/bitcoin/bitcoin (via git, git://gitorious.org/bitcoin/bitcoin.git )

Currently, its master branch mirrors the GitHub one, but with a few bugfixes I added.

I also have a "neutral" branch which has a (backward-compatible) RPC API upgrade to version 1 (the older being 0) which removes (in principle, but not code) the deprecated methods, and uses base units rather than floating-point decimal BitCoin values (this makes it neutral between decimal and tonal, makes it faster for devices without a FPU, and fixes possible accuracy problems due to unexpected floating-point approximations). Constructive design, API. and code review is welcome and appreciated.

Others are welcome to use Gitorious rather than GitHub for development as well; contact me if you need to be added to the Gitorious project (or if some senior developers want to take over the Gitorious project, I'm sure there's a way to transfer control of it, too).

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

Quote from: bitcoinex on January 19, 2011, 05:41:42 PM

1. Not to touch anything and make "a week of refactoring".

I personally do not quite understand the code which is in one giant file main.cpp. I twice tried to start watch it but fell asleep in the middle. Git does not like this arrangement of the code too.

Having spent a lot of time working with the existing code, I don't think splitting the code into multiple files would make it much easier to work with. The hard part is figuring out how everything fits together (for example "if I have a CWalletTx, how do I get the CBlock that it is in (if any)?"). Just rearranging the code that is there now won't make that problem any better.

Quote

2. We're all bitcoin millionaires and billionaires (except of me, probably). Maybe it's time to hire 1-2 employees? Or establish a reward for bugs busters?

I don't think anybody who has worked on the code, except for Satoshi, has a lot of bitcoins. I certainly don't. I hope to earn some with Clearcoin....

Quote

I am concerned about errors that prevent realize listtransatstions ( https://www.bitcoin.org/smf/index.php?topic=2306.0 ). From a distance at least one bug look quite dangerous: https://github.com/bitcoin/bitcoin/issues/#issue/28

The listaccounts bug is nearly fixed. I cannot reproduce the dangerous-looking bug, even running bitcoind under the valgrind memory-checking tool (valgrind actually simulates machine instructions to catch memory access errors)-- tcatm seems to be the only person having the issue.

bitcoinex

sr. member

Activity: 350

Merit: 252

probiwon.com

Two suggestions:

1. Not to touch anything and make "a week of refactoring".

I personally do not quite understand the code which is in one giant file main.cpp. I twice tried to start watch it but fell asleep in the middle. Git does not like this arrangement of the code too.

2. We're all bitcoin millionaires and billionaires (except of me, probably). Maybe it's time to hire 1-2 employees? Or establish a reward for bugs busters?

I am concerned about errors that prevent realize listtransatstions ( https://www.bitcoin.org/smf/index.php?topic=2306.0 ). From a distance at least one bug look quite dangerous: https://github.com/bitcoin/bitcoin/issues/#issue/28

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: Gavin Andresen on January 14, 2011, 07:29:57 PM

And it would be fantastic to get somebody who knows, or is willing to learn, git to step up and volunteer to submit translation file patches.

I know git, and have time on my hands (as evidenced by the number of typo corrections I've made recently in the wiki...). I'd be willing to submit translation file patches if it doesn't require me being able to speak languages other than English... Let me know what you need.

Quote from: Gavin Andresen on January 14, 2011, 07:29:57 PM

I'll soon be asking for building and testing help, too (after fixing another couple of bugs, I think it'll be time to pull non-controversial patches into the integration tree and start some serious testing to prepare for another release).

I only have Ubuntu on the computers here, but have various versions (10.04, 10.10, 11.04 pre-release) so can build and test on those.

In the mean time I'll take a look at the bug list and see if there's anything I can work on. I have a fair bit of C++ experience, but am quite new to Bitcoin.

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: Luke-Jr on January 16, 2011, 07:18:43 PM

Git-side of things to free software (such as Gitorious), rather than GitHub (which is anti-free software).

Can you post some more details ?

EDIT:
Never mind, found it out myself:

Quote from: http://stackoverflow.com/questions/78991/why-is-github-more-popular-than-gitorious

The source code for GitHub itself, as well as egitd, the Erlang implementation of git-daemon, are proprietary – that's the main difference between GitHub and Gitorious

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: Luke-Jr on January 16, 2011, 07:18:43 PM

I'd be glad to redo them in Git if someone cares to mirror/move the Git-side of things to free software (such as Gitorious), rather than GitHub (which is anti-free software).

Just post your to-be-pulled branches on the sanctified git server of your choice.

davout

legendary

Activity: 1372

Merit: 1008

1davout

Quote from: Luke-Jr on January 16, 2011, 07:18:43 PM

rather than GitHub (which is anti-free software).

meh

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Various bugs fixed on branches listed at https://code.launchpad.net/~luke-jr
I'd be glad to redo them in Git if someone cares to mirror/move the Git-side of things to free software (such as Gitorious), rather than GitHub (which is anti-free software).

genjix

legendary

Activity: 1232

Merit: 1076

Damn, this is a project I'd really love to get involved with if I wasn't under so many persistent pressures... Lots of exciting areas to muck around in.

Topic: Core Bitcoin Development Help Wanted - page 2. (Read 9286 times)