2013-11-27 20:35:28 +0000diagramsbot- [13diagrams-lib] 15jeffreyrosenbluth comment on pull request #141 14e182745: Perhaps a compromise is to add a `NoColor` attribute value for `FillColor`, something like... 02http://git.io/cYcs0g
2013-11-27 20:37:24 +0000diagramsbot- [13diagrams-lib] 15byorgey comment on pull request #141 14e182745: Re: assuming that only SVG fills open paths: that's true, but it's something of an implementation detail/accident. Reorganization of other backends might produce the same problem (in particular, postscript has not been ported to the backend tree stuff yet). And in any case, even so it's not true that we only have to worry about what transparent fill means for backends we don't
2013-11-27 20:39:55 +0000diagramsbot- [13diagrams-lib] 15byorgey comment on pull request #141 14e182745: Re: adding `NoColor`, I thought of that, but I don't think it's a very good solution. If the SVG backend implements it by `fcA transparent` then we still have to worry about whether this is the same as no fill (it seems like it *should* be, of course, but I still don't know this for certain); and if other backends can't do that, then they might have to do some whole-tree analys
2013-11-27 20:49:07 +0000diagramsbot- [13diagrams-lib] 15jeffreyrosenbluth comment on pull request #141 14e182745: I'm don't love either of the two proposed solutions so perhaps we should keep thinking about it. 02http://git.io/2dQ94A
2013-11-27 20:55:23 +0000diagramsbot- [13diagrams-lib] 15byorgey comment on pull request #141 14e182745: Sure. As I mentioned earlier, I think users are very unlikely to run into this often in practice (and it's very easy to work around if they do), so there's no particular rush to fix this. It's definitely worth sitting on it for a while until we have something we're all happy with. 02http://git.io/rc4D3Q
2013-11-27 20:57:24 +0000diagramsbot- 01[13diagrams-builder01] 15byorgey pushed 1 new commit to 06cleanup: 02http://git.io/Pm4cVw
2013-11-27 20:57:24 +0000diagramsbot- 13diagrams-builder/06cleanup 14c5b8fbd 15Brent Yorgey: function to help with creating BuildOpts records
2013-11-27 21:01:21 +0000diagramsbot- 01[13diagrams-builder01] 15byorgey pushed 1 new commit to 06cleanup: 02http://git.io/6qe8aQ
2013-11-27 21:01:22 +0000diagramsbot- 13diagrams-builder/06cleanup 14efe65a8 15Brent Yorgey: bump version to 0.5
2013-11-27 21:01:29 +0000 <byorgey> fryguybob: ^^^ see the new 'cleanup' branch for diagrams-builder
2013-11-27 21:01:38 +0000 <byorgey> let me know what extra options/features you might like to see
2013-11-27 21:08:36 +0000 <byorgey> oh, hrmm, Data.Hashable only produces Int values.
2013-11-27 21:09:29 +0000 <byorgey> an interesting question of probabilities: assuming the hash values of diagrams are IID, how many diagrams do you have to create before you expect (p > 0.5) a hash collision? -- if the hash space is Int
2013-11-27 21:09:43 +0000 <byorgey> I guess this is just the birthday problem
2013-11-27 21:12:10 +0000 <Martingale> yes, easy to figure out if you know the distribution
2013-11-27 21:12:23 +0000 <travis-ci> [travis-ci] 13diagrams-builder/06cleanup 14c5b8fbd http://travis-ci.org/diagrams/diagrams-builder/builds/14623177 The build is still failing.
2013-11-27 21:16:41 +0000cinimod(~user@cpc12-nmal16-2-0-cust137.croy.cable.virginm.net) (Ping timeout: 272 seconds)
2013-11-27 21:22:19 +0000 <byorgey> ah, the wikipedia page on the birthday problem has a table answering exactly this question =)
2013-11-27 21:22:53 +0000 <travis-ci> [travis-ci] 13diagrams-builder/06cleanup 14efe65a8 http://travis-ci.org/diagrams/diagrams-builder/builds/14623449 The build is still failing.
2013-11-27 21:23:00 +0000 <byorgey> for 64-bit hashes, you need 5 x 10^9 hashed things before the probability of collision goes over 0.5
2013-11-27 21:24:24 +0000 <Martingale> I think that assumes each hash is equally likely which may depend on the algorithm
2013-11-27 21:27:56 +0000 <Martingale> Which is supposedly true for good hash functions
2013-11-27 21:29:20 +0000 <byorgey> in any case, this is certainly good enough for hashing options records and so on. I think I will continue to use MD5 for hashing the actual diagram source code.
2013-11-27 21:30:32 +0000joelb(~textual@office.khanacademy.org)
2013-11-27 21:30:55 +0000 <Martingale> byorgey why do you hask diagram source code?
2013-11-27 21:31:01 +0000 <Martingale> *hash
2013-11-27 21:31:03 +0000 <byorgey> no, actually, just using Hashable should be fine.
2013-11-27 21:31:27 +0000 <byorgey> Martingale: this is for diagrams-builder. It hashes the source + options, etc., and saves a cached version under a filename made from the hash value.
2013-11-27 21:31:39 +0000 <byorgey> then, the next time it is called, it can quickly decide which diagrams need to be rebuilt
2013-11-27 21:32:10 +0000 <Martingale> Ah
2013-11-27 21:42:14 +0000cinimod(~user@cpc12-nmal16-2-0-cust137.croy.cable.virginm.net)
2013-11-27 21:49:13 +0000cinimod(~user@cpc12-nmal16-2-0-cust137.croy.cable.virginm.net) (Ping timeout: 252 seconds)
2013-11-27 21:49:48 +0000 <Martingale> although 64 bits does seem awfully small by todays standards ?
2013-11-27 21:51:48 +0000 <carter> oh did you guys figure out that line rotation bug?
2013-11-27 21:52:05 +0000 <carter> cscheid: did you send Martingale that example of big svgs?