1 2012-12-28 01:23:26 <Leco> Hi, will be possible edit the shared wallets? https://moqups.com/gavinandresen/no8mzUDB/p:a8ef81fa8
 2 2012-12-28 01:24:35 <Leco> After isso create the shared wallet I can edit it? Add more participants...
 3 2012-12-28 01:24:47 <Leco> After i
 4 2012-12-28 01:25:39 <Leco> Or will need to delete it and create another shared wallet?
 5 2012-12-28 01:35:10 <Luke-Jr> what is this website that refuses to use standards?
 6 2012-12-28 01:42:25 <gmaxwell> Leco: the rules about the wallet are baked into the addresses the coins are assigned to.
 7 2012-12-28 01:43:11 <gmaxwell> Leco: so, no, you couldn't edit it??? perhaps the software would let you e.g. change the contact information for participants or the description... but e.g. the rules to satisify it would likely be fixed.
 8 2012-12-28 01:43:21 <gmaxwell> Leco: but thats okay, just create a new one and transfer the funds.
 9 2012-12-28 01:43:47 <Leco> Understand. Thanks
10 2012-12-28 01:43:58 <Luke-Jr> 
ACTION ponders

11 2012-12-28 01:44:21 <Luke-Jr> in theory, it might be possible to construct a script that can be changed <.<
12 2012-12-28 01:45:09 <Luke-Jr> have it read the spending keys from outside the script itself, plus a signature, and verify the signature of those keys is one (or more) of the original ones <.<
13 2012-12-28 01:46:03 <Luke-Jr> but probably better to use some payment API for that kind of detail IMO
14 2012-12-28 01:50:21 <Leco> I'm not a device, just an user. I ask: the shared wallets thing is something hard to develop? We will see it soon? Appear an amazing thing
15 2012-12-28 01:50:38 <Leco> I'm not a developer
16 2012-12-28 01:51:12 <Leco> And my English is not good.
17 2012-12-28 03:04:55 <gmaxwell> Odd: -salvagewallet fails on a totally normal and valid wallet because db.verify returns DB_VERIFY_BAD. Man page says,
18 2012-12-28 03:04:58 <gmaxwell> The DB->verify function returns a non-zero error value on failure, 0 on success, and DB_VERIFY_BAD if a database is corrupted. When the DB_SALVAGE flag is specified, the DB_VERIFY_BAD return means that all key/data pairs in the file may not have been successfully output.
19 2012-12-28 03:09:36 <stealth222> I would love to have some better exception handling in main and init
20 2012-12-28 03:10:01 <stealth222> a bunch of functions that just return false on failure and do a printf somewhere
21 2012-12-28 03:10:44 <stealth222> further up the call stack you have a better sense for the context of the error
22 2012-12-28 03:10:53 <gmaxwell> ...
23 2012-12-28 03:11:58 <stealth222> if you go very deep into the call stack, you have minute details of the exact call that produced the error - but you don't necessarily understand *why* the call was being made in the first place
24 2012-12-28 03:12:05 <gmaxwell> Introducing a bunch of C++ exceptions is a great way to make the code incomprehensible. There is a good reason google pretty much bans them outright in their own coding guidelines for C++.
25 2012-12-28 03:12:31 <stealth222> really? I actually find that when exceptions are well-used, it makes code a heck of a lot more readable
26 2012-12-28 03:13:00 <gmaxwell> In _java_ perhaps.
27 2012-12-28 03:13:23 <stealth222> how's java better in this regard?
28 2012-12-28 03:14:37 <stealth222> perhaps in that it forces you to declare your intentions up front a little more
29 2012-12-28 03:14:55 <stealth222> in C++, you can throw any kind of object at any time
30 2012-12-28 03:15:12 <stealth222> Java forces you to use a throwable object and to declare a method to throw that kind of object
31 2012-12-28 03:15:52 <stealth222> when abused, exceptions are ugly - but that's true for anything in C++, really
32 2012-12-28 03:15:57 <gmaxwell> A couple of ways??? it's clear what exceptions you may need to deal with or not deal with??? and because you can generally deal with things you don't understand (e.g in cases where you can handle all errors generically). Also, the memory management model in java makes it so that exceptions don't accidentally produce leaks.
33 2012-12-28 03:16:25 <stealth222> C++ accidentally produces leaks with or without exceptions
34 2012-12-28 03:16:51 <stealth222> that's the price to pay for better control over memory management
35 2012-12-28 03:17:24 <gmaxwell> Yes, exceptions help. Basically in C++ your code has to be prepared to cope with the consequences of exceptions from below, but at the same time there is no good way to even know about them, unless you have the whole codebase in your mind.
36 2012-12-28 03:17:50 <gmaxwell> Meh. It's a price you pay even when you're not using it. But I didn't mean to start ragging on C++ in general.
37 2012-12-28 03:17:57 <stealth222> lol
38 2012-12-28 03:18:44 <gmaxwell> (look at the horrific fragmentation problems we have with bitcoin right now??? just because we use a bunch of heap allocated container object on small things all over the place... we're close to running into address space issues on 32 bit systems due to the fragmentation with glibc malloc)
39 2012-12-28 03:19:09 <stealth222> we could be using our own internal memory pools
40 2012-12-28 03:19:51 <stealth222> but generally speaking, unless you're doing systems level programming you probably don't want to deal with that crap
41 2012-12-28 03:20:40 <stealth222> in any case, 32 bit systems are the past :p
42 2012-12-28 03:21:29 <gmaxwell> And replace fragmentation with leaks, pool corruption.. and different kinds of fragmentation problems! :P  Switching to another malloc implementation solves it in a more safe way than pools. I assume if this becomes a problem thats what we'll do, I've already tested it.
43 2012-12-28 03:22:06 <gmaxwell> stealth222: surpringly common still because of mostly foolish reasons, though some good ones??? e.g. they're common on VPSs because they have lower base memory usage.
44 2012-12-28 03:23:16 <stealth222> machines are cheap, anyway. it's good programmers that are hard to come by
45 2012-12-28 03:24:14 <stealth222> today's programming languages are mostly designed to let poor programmers do something useful :p
46 2012-12-28 03:24:15 <gmaxwell> Fortunately replacing malloc is super cheap to do and test.
47 2012-12-28 03:24:36 <gmaxwell> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Exceptions#Exceptions < for your edification (the clicky arrow expands it and gives their justification)
48 2012-12-28 03:24:50 <stealth222> cool, thanks for the link
49 2012-12-28 03:27:42 <gmaxwell> hmph. and after fixing salvage to trudge through... Error: Cannot initialize keypool :-/
50 2012-12-28 03:27:45 <stealth222> "When you add a throw statement to an existing function, you must examine all of its transitive callers." - one could argue that when you call a function that might throw an exception, you should probably be catching it somewhere
51 2012-12-28 03:29:36 <jgarzik> neat C++ style guide
52 2012-12-28 03:29:57 <jgarzik> I generally agree with their "do not use <this feature> advice".  They turn off a lot of stuff.
53 2012-12-28 03:29:59 <stealth222> I don't think that argument is very persuasive. If you are returning error codes and the caller doesn't check for them, it's arguably even worse since two levels up the call stack the code will have absolutely no idea what failed
54 2012-12-28 03:30:35 <gmaxwell> stealth222: it's really easy to violate that w/ C++ though. Unless you start packing metadata about exceptions into all your function/method names (and god knows how you cope with overridden operators). :P
55 2012-12-28 03:31:39 <gmaxwell> stealth222: but at least the control flow around a return code is explicit. You can clearly see if you check a return or not, and you can annotate function so that the compile will fail if you ignore the return! (using language extensions that everyone has)
56 2012-12-28 03:32:22 <stealth222> in languages like java, where methods must declare what they might throw, you can also do that I suppose
57 2012-12-28 03:33:03 <gmaxwell> Correct. Yea, my complaint was about C++ exceptions specifically. I think java ones are more safe for quite a few reasons.
58 2012-12-28 03:33:30 <jgarzik> C++ exceptions infect unrelated code.  your AccountingSystem class hierarchy suddenly might need to be aware of LowLevelDB::ExceptionFoo.  it's infectious outside their domain.
59 2012-12-28 03:35:09 <stealth222> one could set C++ guidelines that require stating explicitly what exceptions a function might throw and making sure that all callers either catch them themselves or make it clear to their callers that they might have to catch them
60 2012-12-28 03:35:13 <gmaxwell> ::shrugs:: In any case, I am totally the wrong guy to be arguing this. I am a C coder. My knoweldge of C++ comes mostly from a bit of morbid curiosity over the piles of bodies from my fellow coders slain by it. :P  I do know that I feel evel less confident that I can write safe and correct code in the presence of C++ exceptions than I can around many of the other C++ features I don't much care for (most of them).
61 2012-12-28 03:35:54 <stealth222> it seems like it's largely a matter of style - and if google already has considerable codebase that doesn't take this approach, I can understand their dislike of integrating code that does
62 2012-12-28 03:36:37 <gmaxwell> stealth222: yea, but I'm not sure how you'd really go about that short of mangling a description of them into the method names??? and you can't even do that for operators. (though operators don't have return values either??? you're you're kinda screwed wrt error handling on them)
63 2012-12-28 03:38:22 <gmaxwell> stealth222: the reason I say mangling the names.. e.g. say I'm moving some code from foo() where it calls baz()    to bar(). I didn't (recently) write foo or baz. The chance that I'll miss the fact that baz can throw something that foo was safe relative to but bar is not is quite high.
64 2012-12-28 03:40:08 <Luke-Jr> gmaxwell: personally, I rename functions when they change behaviours in notable ways; even if that means just appending a '2'
65 2012-12-28 03:40:20 <gmaxwell> (also??? the exception prohibition isn't a unique to google thing. At my prior dayjob we had a product get exceptions barred midlife.. (later it was replaced with a rewrite in C as part of merging it into another product))
66 2012-12-28 03:40:24 <stealth222> appending a 2? lol
67 2012-12-28 03:41:48 <gmaxwell> One of the major arguments people make against statically typed languages is that static typing doesn't actually achieve correctness simply because the type doesn't express everything relevant about thing thing in question. So doing stuff like renaming things when their functionality changes makes some sense I guess. It makes you go check all the callers at least.
68 2012-12-28 03:41:50 <stealth222> anyhow, Google's main argument is that they already have a lot of code that's not exception-friendly...but if you start a new project with exception-friendliness in mind, it's actually a good style.
69 2012-12-28 03:43:07 <stealth222> it's not that C++ exceptions are intrinsically bad - it's that if you are mixing a bunch of different styles in a single project, the parts that were not written with exception-handling in mind will have problems getting along with the parts that were
70 2012-12-28 03:43:32 <gmaxwell> I'm unconvinced by your read on it. The need to be hyper vigilant about invisible behavior is true no matter where you start. (I worry a lot about implict behavior in bitcoin, because it could potentially hide protocol rules)
71 2012-12-28 03:43:56 <stealth222> I'm just paraphrasing their "Decision"
72 2012-12-28 03:47:48 <stealth222> I really don't like having code that reads bError = TryFoo(); if (bError) { DoSomethingAboutFooGoingWrongWhichAlmostWillNeverHappenButTakesABunchOfLines(); } bError = TryWhatAlmostAlwaysIsDoneAfterFoo(); if (bError) { AgainDoSomethingWhichTakesABunchOfLinesOfCodeAndMaybeEvenCallsAFewMoreFunctionsAlongTheWayEvenThoughThisHappensOnceInAMillion(); } ...
73 2012-12-28 03:48:28 <stealth222> By the time I'm finished reading one of the error clauses, I forgot what I was trying to do in the first place
74 2012-12-28 03:51:04 <gmaxwell> You can also error |= TryFoo() ...  if (error) ...   so long as you make sure that the intermediate points and overall behavior are safe if foo errored, which actually looks somewhat like exception safe code, except the behavior is all explicit.
75 2012-12-28 03:53:51 <stealth222> or you can do void TryFoo() { if (!Foo()) throw foo_failed; } void TryBar() { if (!Bar()) throw bar_failed; } try { TryFoo(); TryBar(); } catch (foo_failed) { ... } catch (bar_failed) { ... } :)
76 2012-12-28 03:55:37 <Luke-Jr> gmaxwell: some things, I wish would behave more exceptionally :P
77 2012-12-28 03:55:41 <Luke-Jr> like memory allocation failures
78 2012-12-28 03:56:14 <gmaxwell> hah.. let me show you what I typed but didn't send a bit ago.
79 2012-12-28 03:56:18 <gmaxwell> It also depends on what you mean by error. Most real errors are actually things you want to address. The things you don't want to address is the impossible stuff, like malloc failing. But if thats happened its unlikely that exceptions are going to save you.
80 2012-12-28 03:56:33 <stealth222> or even better: void TryFoo(); void TryBar(); try { TryFoo(); TryBar(); } catch (foo_failed) { ... } catch (bar_failed) { ... } void TryFoo() { if (!Foo()) throw foo_failed; } void TryBar() { if (!Bar()) throw bar_failed; }
81 2012-12-28 03:56:48 <stealth222> leave all the tedious error handling which is almost never done at the end :)
82 2012-12-28 03:58:47 <gmaxwell> Luke-Jr: if you want you can just wrap malloc with safe_malloc. safe_malloc does this:  ret=malloc() if(!ret){fprintf(stderr,"crap\\n");abort();}}   then you can write assuming that safemalloc never fails.
83 2012-12-28 03:59:14 <gmaxwell> And just wrap your whole system in a restart loop. And design it so it can recover safely and quickly after a crash.
84 2012-12-28 03:59:18 <Luke-Jr> yeah, would be nice if there was a standard function that did that <.<
85 2012-12-28 04:00:28 <gmaxwell> You can be extra snazzy and do  #define safe_malloc(x)  safe_malloc_impl((x),__FILE,__LINE__) and have your dying gasp actually spit out which malloc failed and how much it was trying to malloc. :P