< jonasschnelli>
Or extract the "cleverness" of the CPAN modules and write your own python script?
< Luke-Jr>
I doubt it would be any better than the python ds_store module.
< jonasschnelli>
ah.. there is one. Nice. Try with the python one then?
< jonasschnelli>
I can try to find out, why the current background is not working...
< Luke-Jr>
that's what this does..
< jonasschnelli>
ah... ha. Okay. Let me see if i find the reason why it's not working.
< jonasschnelli>
So you say, the your current PR does create the DS_Store with the python script? So positioning of the icons is done correct...
< Luke-Jr>
yes
< jonasschnelli>
`backgroundImageAlias`: `'\x00\x00\x00\x00[...]` <-- what the hell is that?
< Luke-Jr>
a blob from the original DS_Store, modified by the mac_alias python module
< jonasschnelli>
Luke-Jr: Hmm... I diffed the DS_Store and I guess it's very hard to fine the source of the problem,.. could be a missing 0x00 or similar. What if you try to build the DS_Store with http://dmgbuild.readthedocs.org/en/latest/example.html?
< Luke-Jr>
I don't think that works on non-Mac
< Luke-Jr>
can you upload the DS_Store for me to look at?
< jonasschnelli>
I don't have a new one... i just compared yours against the 0.11.2 ones.
< jonasschnelli>
I can't fix yours...
< Luke-Jr>
O.o
< Luke-Jr>
Mac won't let you change it? (copy out of the DMG first)
< jonasschnelli>
Luke-Jr: but `biplist.Data(alias.to_bytes())`?
< jonasschnelli>
I can duplicate the dmg and make it writeable and make OSX create a new DS_Store. But i guess it would be identical to the one from 0.11.2
< jonasschnelli>
(same files)
< Luke-Jr>
not byte-for-byte - my hope is the delta might be smaller
< jonasschnelli>
I think your PR does the right, thing, expect of the byte-fiddling, why could you not use "biplist.Data(alias.to_bytes())"?
< Luke-Jr>
jonasschnelli: pushing a test commit to change the actual name; feel like checking that it works completely? :D
< Luke-Jr>
(1 line changed; all other references are in docs/locale)
< jonasschnelli>
Yes. Pushed already?
< Luke-Jr>
yep
< * jonasschnelli>
is building...
< Luke-Jr>
hmm, I think this build will fail
< Luke-Jr>
looking at the osx descriptor, it seems to assume bitcoin-* prefix in the filename
< Luke-Jr>
hm, it succeeded I guess
< * Luke-Jr>
ponders why
< jonasschnelli>
its still building...
< Luke-Jr>
oh, it works because we don't actually use "Bitcoin Core" in filenames
< Luke-Jr>
oh well, not sure I care enough to dig into that
< jonasschnelli>
Luke-Jr: tested. Works prefect.
< Luke-Jr>
great
< jonasschnelli>
But i guess it would also work if we would use different filename (now i think we just fake the name over the translations/i18n file)?
< Luke-Jr>
?
< jonasschnelli>
Luke-Jr: your TestyCOIN-Crazy projects still uses "Bitcoin-Qt.app" as filename (as you mentioned). But I guess the whole dmg process should also work if we would use a different filename? right?
< Luke-Jr>
jonasschnelli: probably not. but I meant the output DMG filename itself
< MarcoFalke>
wumpus, you synced the missing resources from #7158 to the 0.12 transifex branch?
< MarcoFalke>
They show as "untranslated" and have a "100% match" in "suggestions"
< wumpus>
re: the c++11 stuff there is always a reason to require a new gcc, first it was gcc4.6+ then gcc4.8+ now gcc5.1+, I've given up on it, wake me up when we're at gcc 6 or so
< morcos>
wumpus: fwiw i was in favor of forging ahead with c++11. at a certain point its just risk of an ordinary bug and not a consensus bug, and you can't avoid all bugs.
< jgarzik>
same here
< wumpus>
morcos: also there's no guarantee that there aren't bugs in the non-c++11 part of the compiler that e.g. influence consensus. It's never entirely without risks, but I'd say for c++11 it's worth it, especially as it helps getting rid of boost dependency for more of the consensus code.
< wumpus>
but I'm just tired of the eternal arguing
< morcos>
there do not seem to be many voices against... what do sipa and gmaxwell think?
< wumpus>
AFAIK they're for, at least sipa has been asking for it for quite some time
< morcos>
i'm glad Luke-Jr raises a concern like that, and i'd want to know that more experienced devs than me have spent the time to think about the issue he raises. but to say we avoid all risk is nonsensical.
< wumpus>
anyhow better luck in 6 months I guess
< wumpus>
it's not that urgent either...
< wumpus>
just hoped to get it over with
< jgarzik>
I definitely think this is too risk averse - There are incentives on the other side that make it work - Communicating ahead of time "we're switching to c++11" and then moving ahead should be fine - Users adjust because it's not a big hurdle to keep it working on our main supported platforms
< benjyz1>
heavy censorship on bitcoin-dev.. what is going on
< jgarzik>
off topic for this channel
< wumpus>
only development discussion here, please
< benjyz1>
?
< benjyz1>
is this still opensource?
< benjyz1>
seriously... who is censoring my posts and why?
< wumpus>
"The developer mailing list should be used to discuss complicated or controversial changes before working on a patch set." seems OK te me, that's what the list is for
< wumpus>
it's moderated due to heavy abuse
< benjyz1>
k. and abuse is defined by ...
< benjyz1>
I'll propose a change to contributor policy and readme then
< benjyz1>
since its no longer accurate
< wumpus>
off topic things not related to bitcoin development, If it fits into the above category, you're a legit contributor and somehow got 'censored' feel free to send a complaint to me
< benjyz1>
ok. what is the "correct" place to discuss the above mentioned contributor policy?
< benjyz1>
your honour
< wumpus>
<jgarzik> benjyz1, #bitcoin-dev please
< sdaftuar>
all -- #7062 still needs review; it fixes prioritisetransaction to work correctly with mempool limiting and rbf and imo should go into 0.12.
< wumpus>
thanks sdaftuar will take a look
< sdaftuar>
thanks!
< instagibbs>
Core uses UniValue for all json object stuff, correct?
< jgarzik>
instagibbs, yes
< instagibbs>
was it just to remove a dep? or improve functionality Core requires?
< instagibbs>
(latter is both I suppose)
< jgarzik>
instagibbs, reduces size of compiled code + runtime
< jgarzik>
instagibbs, it was faster in one micro-benchmark I made, but performance of json encode/decode was not the driving factor
< wumpus>
boost spirit wasn't a very good library for our purpose
< wumpus>
and other JSON libraries insist on e.g. parsing numbers as floats/doubles, whereas we need them as fixed point strings
< wumpus>
memory usage of univalue is also better esp. for deeply nested structures
< jgarzik>
ah yes, number parsing was another key issue
< instagibbs>
Cool, thanks. I learned UniValue first, so trying to figure out history on it.
< sipa>
plus better compile time, i'm sure
< sipa>
spirit was templates all the way down to being able to choose your own container data structures
< wumpus>
yes, spirit was also notoriously bad for compile time, due to using templates to generate a scanner/lexer. I also expected dropping it would lower memory usage during compile, but for that it was apparently not the bottleneck
< cfields>
Luke-Jr: looking
< cfields>
Luke-Jr: what's missing in the bitcoin build itself? the python libs?
< sdaftuar>
is it important that we call CheckBlock immediately in ProcessNewBlock and return failure before calling AcceptBlock?
< sdaftuar>
it turns out that call to CheckBlock causes us to not permanently mark blocks as failed even if they fail in CheckBlock
< sdaftuar>
seems like we could just not call it there, and let AcceptBlock do its work?
< sipa>
sdaftuar: interesting!
< sipa>
can't we instead make checkblock failure also mark it as invalid?
< sdaftuar>
we could, although i think at that point in the code it is possible for the block to not yet have been added to mapBlockIndex. not 100% sure of that though
< sdaftuar>
but it would require duplicating the code from acceptblock
< sdaftuar>
seems suboptimal?
< sdaftuar>
it seems like we do extra work on every valid block to avoid doing slightly more work on invalid blocks
< sdaftuar>
i'm not sure that tradeoff makes sense?
< sipa>
oh i see
< sipa>
the question is whether a dos attacker gains something by us doing the check later
< sdaftuar>
right
< sdaftuar>
looks like the only thing we save is a call to AcceptBlockHeader. i think that's fast?
< sipa>
i guess we go from no mapBlockIndex lookup to a lookup
< sipa>
i think that's negligable
< sdaftuar>
it's certainly negligible compared to bitcoind's current behavior, of repeatedly calling CheckBlock on failed blocks :)
< sipa>
agree
< sdaftuar>
ok i'll submit a PR to scrap that call to CheckBlock
< cfields>
Luke-Jr: what's the point of imagemagick_convert ?
< GitHub173>
[bitcoin] sdaftuar opened pull request #7225: Eliminate unnecessary call to CheckBlock (master...eliminate-extra-checkblock) https://github.com/bitcoin/bitcoin/pull/7225
< sdaftuar>
wumpus: i really like that comptool has a way to do reject-message testing, this is making tests better and helping uncover strange behaviors...
< cfields>
Luke-Jr: oh, it can't export to tiff?
< jonasschnelli>
cfields: Luke-Jr's name unify PR works really good. We might want to fix the osx application name ("Bitcoin-Qt").
< cfields>
jonasschnelli: yea, i really like the idea
< cfields>
jonasschnelli: what was the snag last time? we avoided changing the name for some rason
< cfields>
*reason
< jonasschnelli>
Yes. We kept bitcoin-qt because otherwise new versions would not overwrite old ones.
< jonasschnelli>
But IMO we could rename it once and tell the users to delete the old version (release notes).