| Time |
S |
Nick |
Message |
| 01:01 |
|
|
darcscommitbot joined #darcs |
| 02:08 |
|
|
shachaf joined #darcs |
| 02:43 |
|
|
copumpkin joined #darcs |
| 03:58 |
|
|
idnar joined #darcs |
| 04:09 |
|
|
blackdog joined #darcs |
| 04:09 |
|
blackdog |
how do you show a particular patch in a darcs repo? |
| 04:16 |
|
|
blackdog left #darcs |
| 06:13 |
|
|
gour joined #darcs |
| 06:35 |
|
gour |
morning |
| 06:41 |
|
gour |
CosmicRay recently did http://changelog.complete.org/[…]e-project-hosting review. now i'm interested what would you suggest for someone working with darcs? (while tinkering with bzr in the past, i created some setup at launchpad and now i could use vmikllos's darcs-fast-export(import) with bzr to provide public repos there, but i'm interested if you have some other recommendation? (i know about patch-tag, but not |
| 06:41 |
|
gour |
sure whether it has some features besides holding a repo...) |
| 07:01 |
|
|
darcscommitbot joined #darcs |
| 07:22 |
|
|
lelit joined #darcs |
| 08:08 |
|
|
kowey joined #darcs |
| 08:09 |
|
kowey |
good morning! |
| 08:09 |
|
kowey |
http://www.reddit.com/r/progra[…]ode_final_report/ |
| 08:15 |
|
mornfall |
Yeah, more of usual uninformed slander. |
| 08:20 |
|
kowey |
it's really impressive how long it takes to dislodge old ideas |
| 08:21 |
|
kowey |
don't forget to send that final update to the mailing list, by the way |
| 08:26 |
|
twb |
kowey: though we have commit bits, I think you should still try to assign specific people to review bundles. |
| 08:26 |
|
twb |
kowey: otherwise there is a bystander effect |
| 08:28 |
|
twb |
As for "<smarter technology> is slower", you could take Fortran as a case study to work out when the meme will die. I don't think too many people consider it slow anymore :-) |
| 08:31 |
|
mornfall |
twb: That's because many people don't know what fortran is anymore. Other than "something from the prehistory of computing". |
| 08:32 |
|
kowey |
twb: yeah, I was worrying about that |
| 08:33 |
|
kowey |
twb: I was hoping that somebody would Take Charge so that I could go take care of the bugtracker for a while |
| 08:35 |
|
mornfall |
I am not convinced it makes any sense to take charge. |
| 08:36 |
|
mornfall |
Fix stuff, announce releases with the fixes. |
| 08:36 |
|
mornfall |
Talk is cheap and therefore a waste of time. |
| 08:36 |
|
mornfall |
At least as talking about darcs performance and bugs goes. |
| 08:38 |
|
* kowey |
was referring to the pile of patches awaiting review |
| 08:41 |
|
* Heffalump |
would like to discuss some of the outstanding review stuff with mornfall on IRC, but is having a rather disjointed weekend due to decorating |
| 08:42 |
|
kowey |
by the way, it may be a good idea to break up that review on the wiki with headers |
| 08:42 |
|
kowey |
I pushed the patches, but never bothered to reply |
| 08:42 |
|
Heffalump |
headers in what sense? |
| 08:43 |
|
Heffalump |
it has topic headers |
| 08:43 |
|
kowey |
------------------------------ |
| 08:43 |
|
kowey |
oh |
| 08:43 |
|
Heffalump |
oh, right |
| 08:43 |
|
kowey |
depends on what you two find most readable |
| 08:43 |
|
Heffalump |
I was thinking of indenting it more, but then people reading without a large resolution monitor will find it a bit unpleasant |
| 08:43 |
|
Heffalump |
anyway, content over form :-) |
| 08:44 |
|
kowey |
:-) |
| 09:01 |
|
mornfall |
Well, I'm leaving internet in a few hours and can't guarantee onlineness till end of August. Maybe a few evenings. |
| 09:02 |
|
Heffalump |
I'm around now for a bit |
| 09:03 |
|
Heffalump |
mainly wanted to discuss the hash stuff a bit more |
| 09:03 |
|
mornfall |
Ok. |
| 09:03 |
|
mornfall |
Fire, I have a while now. |
| 09:04 |
|
Heffalump |
I added a few more comments on the review page - in particular I still find fact that it's valid to have both SHA1 and SHA256 hashes in the same tree disconcerting |
| 09:04 |
|
mornfall |
kowey: Ah. Patches -- well, I reviewed and pushed some. I am trying not to do all of them, lest people forget they should do that as well. |
| 09:04 |
|
mornfall |
Heffalump: Can't do much about it, since existing darcs repos mix them. |
| 09:04 |
|
kowey |
speak up... not all talk is hot air |
| 09:05 |
|
kowey |
meanwhile, I've sent a mail to lispy seeing if I can recruit him as PM :-) |
| 09:05 |
|
Heffalump |
mornfall: ah. How do they do that? |
| 09:05 |
|
mornfall |
Heffalump: Well, there's at least one special case, that empty files always get a SHA1 and never a SHA256. |
| 09:05 |
|
Heffalump |
is that deliberate, or a cock-up? |
| 09:06 |
|
mornfall |
I'd guess it's a bug. |
| 09:06 |
|
mornfall |
Actually, it only seems to happen for empty repos? Wait a minute. |
| 09:06 |
|
Heffalump |
also, is dropping the size really a good idea? I had the impression that hash+size was generally considered significantly stronger than just hash |
| 09:06 |
|
mornfall |
Well, doing a darcs init leaves you with a repo with a SHA1 pristine. |
| 09:08 |
|
mornfall |
Adding anythinAdding anything into that repo seems to fix the SHA1, so it's only for empty repos really. |
| 09:08 |
|
Heffalump |
joy |
| 09:09 |
|
mornfall |
But basically, darcs is built in a way that it accepts 3 hash formats in pristine, and there were darcs versions that produced, I think, all of the 3. |
| 09:09 |
|
Heffalump |
ok, so as far as darcs is concerned the current Hash type is right, apart from the slight question over whether the DarcsSHA256 format is worthwhile or not |
| 09:10 |
|
mornfall |
I have already removed DarcsSHA256 in HEAD, and I think that's a worthwhile simplification of matters. |
| 09:10 |
|
mornfall |
I think sha256 is strong enough as far as I care. |
| 09:11 |
|
mornfall |
Also, it does not impose a hard limit on filesizes we can handle... |
| 09:11 |
|
Heffalump |
ok, that's a good point :-) |
| 09:11 |
|
Heffalump |
not that darcs will handle 10GB files very well anyway |
| 09:12 |
|
mornfall |
Sure, but it's a little close to the practical limit to be comfortable... |
| 09:12 |
|
Heffalump |
ok, so another question: if and when darcs wants to upgrade hashes, how does it do it? |
| 09:12 |
|
mornfall |
It doesn't, I believe. It just writes out new bits with new hashes. |
| 09:13 |
|
mornfall |
IIRC to get rid of intermediate hash formats, you had to re-convert from old-fashioned. |
| 09:13 |
|
Heffalump |
yes, I realise that, but how does it do it given the fact that the hash decisions are all in hashed-storage now? |
| 09:13 |
|
mornfall |
Like the no-sizes hashed format. |
| 09:13 |
|
mornfall |
Oh. |
| 09:13 |
|
Heffalump |
I'm mainly still arguing for hashed-storage to overload over the particular hash format |
| 09:13 |
|
mornfall |
Well, I added optimize --pristine in darcs-hs that just builds a new pristine with whatever hash format hashed-storage currently uses. |
| 09:14 |
|
Heffalump |
I think it would have to store Maybe h in the trees to stop it getting really ugly with whether or not hashes were guaranteed present. |
| 09:14 |
|
Heffalump |
But it shouldn't really care about what the actual hash being used is. Then Darcs could have its really ugly union of different hash types, and other clients could just have SHA256 or whatever. |
| 09:15 |
|
mornfall |
I don't think it's worth it -- it's a lot of trouble and lots of code would get uglier, for a relatively questionable benefit. |
| 09:15 |
|
Heffalump |
optimize --pristine sounds good |
| 09:15 |
|
Heffalump |
what makes it a lot of trouble? |
| 09:15 |
|
* Heffalump |
did have a quick go and most of the difficulty seemed to be with presence/absence |
| 09:16 |
|
mornfall |
Yeah, the Maybe wrapping is something I was really glad to get rid of... |
| 09:16 |
|
mornfall |
And adding another type parameter to Tree... dunno. |
| 09:16 |
|
mornfall |
hashed-storage will never create anything but SHA256 -- the others, for simplicity, are there so it can read, out of the box, legacy hashed trees. |
| 09:16 |
|
Heffalump |
well, you already have Maybe wrapping, it's just hidden in the NoHash type |
| 09:17 |
|
Heffalump |
well, I guess the other functionality of hashed-storage isn't really the business of my review, but why shouldn't it create things other than SHA256? |
| 09:17 |
|
mornfall |
Well, why should it? |
| 09:17 |
|
twb |
Heffalump: maybe they're too cryptographically weak? |
| 09:17 |
|
Heffalump |
well, a quick google suggests that git uses SHA1 |
| 09:17 |
|
twb |
(Guessing.) |
| 09:18 |
|
mornfall |
Heffalump: Well, yes, but SHA1 is insecure. If we need to *write* git-compatible repos, then we'll have to sha1 things, sure. |
| 09:18 |
|
Heffalump |
also, the world might move on and decide that SHA512 is a better choice, and then clients of hashed-storage should surely be able to make their own decisions about whether to upgrade. |
| 09:19 |
|
mornfall |
But that's a long way ahead. As things are, hashed-storage only needs to create one hash type (we can upgrade to SHA512 later -- in which case, the ability to read SHA256 stuff buys us automatic backward compatibility...) |
| 09:21 |
|
mornfall |
There aren't many places where we actually compute new hashes -- these could be parametrized, separately of the Hash type, with what they should create. |
| 09:21 |
|
mornfall |
I still think that we should read whatever comes. It's just a lot more flexible, and the API is easier. |
| 09:21 |
|
Heffalump |
what if you wind up with hashes that you can't distinguish dynamically? |
| 09:21 |
|
mornfall |
Well, then you are in a mess you don't want to be in. :) |
| 09:22 |
|
Heffalump |
I mean what happens if some client wants a new hash type that can't be distinguished dynamically from the existing set in Hash? |
| 09:22 |
|
Heffalump |
if they could specify that one of the existing set couldn't possibly happen then they'd be fine |
| 09:22 |
|
mornfall |
I guess I don't want to cater for that use-case. It's not reasonable to cover all needs of all people anyway. |
| 09:23 |
|
mornfall |
It doesn't really make any sense, does it? |
| 09:24 |
|
Heffalump |
IMO hardcoding a particular hash type is what doesn't make any sense. The properties a hash type requires are quite small and well-delimited. |
| 09:25 |
|
mornfall |
You can say that about a directory listing. Or file path. |
| 09:25 |
|
Heffalump |
it's not just about extensibility or future flexibility, but also about clearly defining what needs to change for a new hash type |
| 09:26 |
|
|
tux_rocker joined #darcs |
| 09:27 |
|
* Heffalump |
suspects this isn't getting anywhere. |
| 09:28 |
|
Heffalump |
The other issue was splitting all the darcs-specific stuff out of hashed-storage. |
| 09:28 |
|
mornfall |
Well, my experience is, that overgeneralization is more dangerous that overspecialization, in library design. |
| 09:29 |
|
mornfall |
I myself don't have (and don't expect to have) any use for hash overloading. I mean something actually useful. Conceptual purity is great, but it's not an end of itself. |
| 09:30 |
|
mornfall |
Well, darcs-specific. What constitutes darcs-specific in this case? |
| 09:30 |
|
mornfall |
There's reading and writing of "darcs pristine". |
| 09:30 |
|
twb |
mornfall: so your argument is "when a client app asks for it, I'll add it"? |
| 09:30 |
|
mornfall |
twb: My argument is when a client app makes a reasonable argument for needing that, we can think about adding it. :) |
| 09:31 |
|
Heffalump |
mornfall: that sounds pretty darcs specific :-) |
| 09:32 |
|
Heffalump |
anything that naturally has darcs in its name would be a good discriminator. |
| 09:32 |
|
mornfall |
Heffalump: Second, there's the darcs directory listing format (that sucks, but we need to be able to read it). |
| 09:32 |
|
mornfall |
Heffalump: I don't think we can get rid of all of it. Reading pristine may be a good candidate, but that would mean a separate hackage lib for 3 functions, which I'm not very fond of. |
| 09:33 |
|
mornfall |
Either that, or not having a library interface to read it. |
| 09:33 |
|
mornfall |
(Or yet different, putting it in libdarcs and hoping that it will become manageable in the future, so we can actually tell people to use it.) |
| 09:35 |
|
mornfall |
Most darcs-specific things are these: http://repos.mornfall.net/hash[…]e/Hashed/Darcs.hs -- plus some bits in Storage/hashed.hs. |
| 09:36 |
|
mornfall |
However, I can't remove any of that without making hashed-storage unable to read the hashed format darcs uses. |
| 09:36 |
|
Heffalump |
the issue with the darcs directory listing format is that the directory hashes need to know it to be computed? |
| 09:37 |
|
mornfall |
That, and you also need to write the trees sometimes. |
| 09:37 |
|
mornfall |
And to write the tree, you naturally need to write the directory listings. |
| 09:37 |
|
Heffalump |
are directory listings themselves written out as text then? |
| 09:37 |
|
mornfall |
Yes. |
| 09:37 |
|
mornfall |
(How else they would?) |
| 09:37 |
|
Heffalump |
yeah, good point |
| 09:38 |
|
mornfall |
So basically, what needs to be done is move a few bits from Storage/Hashed.hs into Storage/Hashed/Darcs.hs and then decide what we want to keep and what we don't, out of those. |
| 09:39 |
|
* Heffalump |
is still convinced that it's not appropriate to have anything darcs-specific in hashed-storage. |
| 09:39 |
|
mornfall |
Reading and writing darcs hashed trees is fairly essential (I think). Reading the pristine root pointer from _darcs/hashed_inventory and knowing that darcs pristine lives in _darcs/pristine.hashed is removable. |
| 09:40 |
|
mornfall |
Well, maybe, but then hashed-storage becomes useless alone, and you will always need libdarcs to use it. |
| 09:40 |
|
mornfall |
Or you have to implement an alternative incompatible format for no reason. |
| 09:40 |
|
Heffalump |
what about this tar file application you mentioned? |
| 09:40 |
|
mornfall |
It uses the darcs-style hashed format (there isn't any other implemented in hashed-storage)... |
| 09:41 |
|
Heffalump |
then why not call hashed-storage darcs-storage? |
| 09:41 |
|
mornfall |
Because I want it to handle more than just that? |
| 09:41 |
|
mornfall |
For one, the existing darcs format is not very good, but it will take time to implement a better one. |
| 09:41 |
|
mornfall |
Second, there's the packed storage stuff that I'm working on, that doesn't really have any darcs counterpart so far. |
| 09:42 |
|
twb |
Because it's hard to change a package name in Hackage, and mornfall expects it to generalize one day -- just not yet ;-) |
| 09:43 |
|
mornfall |
Well, it already does indexing that is not darcs-specific. |
| 09:43 |
|
mornfall |
It's not like all of the lib was specific to darcs. But the only hashed storage format it currently supports is the one darcs uses. |
| 09:44 |
|
mornfall |
(It also supports plain directories and plain directories with hashed index...) |
| 09:50 |
|
Heffalump |
how are other people supposed to maintain it if half the functionality lives inside hashed-storage? |
| 09:51 |
|
mornfall |
Maintain what? |
| 09:51 |
|
Heffalump |
anything to do with the darcs repo format |
| 09:52 |
|
mornfall |
Presumably by patching hashed-storage. This is open source, the library is not a black box... |
| 09:53 |
|
Heffalump |
but then they have to worry about breaking other clients of hashed-storage |
| 09:53 |
|
mornfall |
No difference from having it in libdarcs, is there? |
| 09:53 |
|
mornfall |
Unless we don't really mean what we say when we talk about libdarcs. |
| 09:54 |
|
Heffalump |
we explicitly advertise that we don't care about the libdarcs API yet. |
| 09:54 |
|
mornfall |
Do we plan on starting? |
| 09:54 |
|
Heffalump |
no idea. Is that what you're saying hashed-storage is? |
| 09:55 |
|
mornfall |
I am just saying that if we want to make a public API and actually support it, it doesn't make a difference if it's in darcs tree or not. |
| 09:55 |
|
mornfall |
As far as the API support is concerned. |
| 09:56 |
|
mornfall |
It makes difference to change directories and to issue extra commands to build things. |
| 09:56 |
|
mornfall |
But not as far as breaking things for other people goes. |
| 09:56 |
|
Heffalump |
sure |
| 09:56 |
|
Heffalump |
but it's not obvious that we do yet want to make a public API |
| 09:56 |
|
Heffalump |
and the different trees are a substantial issue in their own right |
| 09:58 |
|
mornfall |
Yes. It's up to the rest of darcs hackers to decide if they agree or not. Not my call. I propose a way to go. I have a backup if people think we both don't want to expose an API and we don't want to change things out of darcs tree. |
| 09:59 |
|
Heffalump |
what's the backup, pull hashed-storage into the darcs tree? |
| 10:00 |
|
mornfall |
Well, more like building a bottom-up darcs by the side, whether actual darcs cares or not. |
| 10:02 |
|
Heffalump |
I don't quite understand what that means |
| 10:02 |
|
mornfall |
That means that I continue to work on hashed-storage, and I dismantle darcs-hs instead of integrating it into darcs. |
| 10:03 |
|
Heffalump |
but you can't reimplement all of darcs in hashed-storage |
| 10:03 |
|
mornfall |
No, I don't intend to. |
| 10:03 |
|
Heffalump |
so I don't really see what the end-state of that route is |
| 10:03 |
|
mornfall |
A few more libraries in hashed-storage spirit, I guess. |
| 10:04 |
|
Igloo |
I think if there's anything darcs-specific in hashed-storage then it ought to be in the darcs repo, as it's not truly a separate library |
| 10:04 |
|
Igloo |
And should probably have darcs in its name |
| 10:04 |
|
mornfall |
We are back to the original problem of what darcs-specific means. |
| 10:05 |
|
Heffalump |
well, you already said the directory listing style wasn't very good |
| 10:05 |
|
* Igloo |
can't define it,but I know it when I see it :-) |
| 10:06 |
|
mornfall |
Heffalump: Sure. But I still need to support reading it -- there's tons of trees with that directory listing format. |
| 10:07 |
|
Heffalump |
but that behaviour properly belongs in darcs, not in hashed-storage |
| 10:07 |
|
mornfall |
True. So when I implement reading git hashed trees, will you say that functionality properly belongs in git? |
| 10:08 |
|
Igloo |
If that needes to be in hashed-storage, then all users of hashed storage would need something equivalent in the library, and that doesn't make sense for a general hashed-storage library |
| 10:08 |
|
Heffalump |
in a git-specific haskell library, yes |
| 10:08 |
|
mornfall |
So hashed-storage-git and hashed-storage-darcs? |
| 10:10 |
|
mornfall |
Both the formats are an open spec. I don't see why a library should not implement them. |
| 10:10 |
|
mornfall |
It's not like you could change them incompatibly without breaking old darcs anyway. |
| 10:11 |
|
Heffalump |
well, hashed-storage-darcs could live in the darcs tree then |
| 10:15 |
|
mornfall |
Well, let's say this differently. I don't really care about what darcs does. I will keep the darcs read/write code in hashed-storage, since there's a number of reasons to do it (testability of hashed-storage standalone, among other things). If you decide to merge darcs-hs, I will work on it further, if no, well, I will find other ways to entertain myself. |
| 10:15 |
|
mornfall |
I have use for hashed-storage as it is, regardless of darcs, really. |
| 10:28 |
|
tux_rocker |
what if we define darcs-specific code as code that one can't imagine being used by any application but darcs? |
| 10:29 |
|
Heffalump |
well, apparently other people are willing to use the same directory hashing format for their application (whether unknowingly or not) |
| 10:30 |
|
mornfall |
Of course they are. At least they don't invent a new one out of thin airr. |
| 10:31 |
|
tux_rocker |
i wouldn't consider our directory hashing format "darcs-specific" in itself |
| 10:32 |
|
tux_rocker |
assuming that it lives somewhere in a _darcs directory *is* darcs-specific |
| 10:32 |
|
tux_rocker |
and while i haven't seen the code, wouldn't it be simple to parameterise it with the file name of the index and the root? |
| 10:33 |
|
Heffalump |
I think that's what mornfall proposed above. |
| 10:34 |
|
tux_rocker |
then i agree with mornfall :-) |
| 10:37 |
|
Heffalump |
ok. I'll try to write up the outstanding points of significant importance in an email. |
| 10:38 |
|
Heffalump |
(might make sense to wait until mornfall is available online to actually start the discussion on darcs-users, though) |
| 10:54 |
|
mornfall |
tux_rocker: The code is parametric in that respect. |
| 10:55 |
|
mornfall |
Apart from hashed tree format, there's only very little with any knowledge about _darcs, and these can be easily removed (although I don't see a reason to have them removed). |
| 10:57 |
|
mornfall |
Anyway, I'm off now. See you in two weeks. |
| 11:05 |
|
|
gour left #darcs |
| 11:12 |
|
|
arjanb joined #darcs |
| 11:51 |
|
|
gbeshers_ joined #darcs |
| 11:51 |
|
|
mae joined #darcs |
| 11:57 |
|
|
balor joined #darcs |
| 12:07 |
|
|
kowey joined #darcs |
| 12:07 |
|
kowey |
not more downtime! |
| 12:12 |
|
kowey |
sigh, support request filed |
| 12:16 |
|
|
balor joined #darcs |
| 13:01 |
|
|
darcscommitbot joined #darcs |
| 13:21 |
|
dleverton |
Are the unit tests supposed to work from the hackage tarball? |
| 13:23 |
|
kowey |
yes as far as I know |
| 13:24 |
|
kowey |
unfortunately darcs.net is down at the the moment, so we can't consult the bugtracker |
| 13:24 |
|
dleverton |
Says it can't find Darcs.Patch.Unit |
| 13:24 |
|
kowey |
whoops, did we forget to ship something? |
| 13:24 |
|
kowey |
the functional tests work for you, right? (all those shell scripts) |
| 13:25 |
|
dleverton |
Not tried those yet |
| 13:26 |
|
kowey |
I see that the library does not expose Darcs.Patch.Unit as a module |
| 13:27 |
|
kowey |
I wonder if that's just a minor cabal sdist hiccup then (as the unit tests are still disabled by default, if I recall correctly) |
| 13:27 |
|
kowey |
thanks very much for reporting this! |
| 13:27 |
|
dcoutts |
someone needs to implement "cabal distcheck" |
| 13:27 |
|
dcoutts |
like automake's make distcheck |
| 13:28 |
|
dcoutts |
which makes the tarball, builds from the tarball and checks it works and can reconstruct the same source tarball. |
| 13:29 |
|
dleverton |
Should the shell script tests be run by Setup test? |
| 13:29 |
|
kowey |
yeah, cabal test runs those |
| 13:30 |
|
* kowey |
goes for his weekend outing into town |
| 13:30 |
|
dleverton |
OK, cool |
| 13:30 |
|
dleverton |
I was slightly worried I'd have to figure out how to do it manually.... |
| 13:37 |
|
dleverton |
Shell scripts all pass |
| 13:50 |
|
|
kpreid_ joined #darcs |
| 14:05 |
|
gwern |
dcoutts: hey, let's get a cabal builddist first! |
| 14:06 |
|
dcoutts |
gwern: meaning? |
| 14:06 |
|
gwern |
it's a bug I filed ages ago - to have cabal build not out of current dir but the unpacked sdist tarball |
| 14:06 |
|
dcoutts |
ah right yes |
| 14:07 |
|
dcoutts |
it's not essential for this task, but it's a nice feature to have in general |
| 14:07 |
|
* gwern |
thinks it's a more important task than testing from sdist |
| 14:11 |
|
dcoutts |
gwern: so what are the important use cases for it? |
| 14:11 |
|
gwern |
everyone. testing before uploading to hackage |
| 14:12 |
|
gwern |
how many times have I seen people upload incomplete tarballs... (people including myself) |
| 14:12 |
|
dcoutts |
right but that's testing the sdist |
| 14:12 |
|
twb |
Pfft. |
| 14:12 |
|
gwern |
it'd also make a good post-record hook; even experienced people like ndm forget to record files or put them in the .cabal |
| 14:12 |
|
twb |
Hackage should do the build testing |
| 14:12 |
|
dcoutts |
I thought you were talking about being able to build from a different directory |
| 14:12 |
|
gwern |
twb: it does. later. assuming hackage could ever build it |
| 14:13 |
|
dcoutts |
gwern: like cabal build ../some/other/project |
| 14:13 |
|
gwern |
twb: eg. someone using anything using anything...gtk2hs is SOL with hackage's buildreports; why would they even look at the buildreport when they *know* it's going to fail? |
| 14:13 |
|
dcoutts |
current hackage design is broken in that respect, that there's only one build machine |
| 14:35 |
|
|
zooko joined #darcs |
| 14:57 |
|
|
gour joined #darcs |
| 15:10 |
|
twb |
2.3 in debian incoming, yay |
| 15:10 |
|
* tux_rocker |
tries if the unit test work from the current mainline |
| 15:10 |
|
twb |
took two weeks to get the new build-deps through new :-( |
| 15:10 |
|
tux_rocker |
twb: congrats! |
| 15:11 |
|
|
sm joined #darcs |
| 15:12 |
|
twb |
AND I washed my hair |
| 15:12 |
|
twb |
So today is like the highlight of my year |
| 15:20 |
|
tux_rocker |
my hair looked so positively weird when i came out of bed, i left it that way |
| 15:20 |
|
|
kowey joined #darcs |
| 15:21 |
|
kowey |
darcs.net back up again |
| 15:22 |
|
kowey |
how puzzling... I thought I'd told samhain to update its database, but there it goes freaking out on me again |
| 15:23 |
|
lelit |
http://progetti.arstecnica.it/[…]or/wiki#Thefuture |
| 15:23 |
|
twb |
kowey: why use it if it causes so much grief? ;-) |
| 15:23 |
|
Heffalump |
hiya |
| 15:23 |
|
kowey |
well I inherited it and I'm assuming it's good practice |
| 15:23 |
|
kowey |
and I believe that in time I can learn how to make it less false-alarmy |
| 15:24 |
|
twb |
Dunno; I only see nagios and munin in the wild |
| 15:24 |
|
Heffalump |
I think automatic warning stuff is more hassle than its worth unless you're really sure of yourself |
| 15:25 |
|
twb |
Oh it's intrusion detection, not health monitoring |
| 15:26 |
|
twb |
I thought it was more a "send me an email when darcs.net stops responding to icmp/http/whatever" |
| 15:27 |
|
twb |
kowey: I dunno whether I'd bother using samhain if it was being a whiny bitch all the time |
| 15:29 |
|
kowey |
perhaps... I've just been operating under the assumption that I've been Doing it Wrong or something |
| 15:29 |
|
twb |
Quite possibly |
| 15:34 |
|
tux_rocker |
dleverton: were you running the unit tests from the autoconf? that may be broken |
| 15:35 |
|
tux_rocker |
dleverton: they work from cabal ('cabal configure -ftest && cabal build && dist/build/unit/unit') |
| 15:38 |
|
dleverton |
tux_rocker: there's a module missing from the tarball on hackage, because it's not listed in the cabal file |
| 15:39 |
|
tux_rocker |
dleverton: ah, that could be. but there's no Darcs.Patch.Unit anymore, I think it's Darcs.Test.Patch.Unit now |
| 15:39 |
|
* kowey |
confirms that he saw D.P.U in 2.3.0 and D.T.P.U in darcs darcs |
| 15:40 |
|
|
nomeata joined #darcs |
| 15:47 |
|
|
alesb joined #darcs |
| 15:51 |
|
|
gour joined #darcs |
| 16:00 |
|
|
fophillips joined #darcs |
| 16:18 |
|
|
fophillipse joined #darcs |
| 16:25 |
|
|
fophillipse joined #darcs |
| 16:35 |
|
|
kolmodin joined #darcs |
| 17:24 |
|
kowey |
gwern: ping |
| 17:25 |
|
kowey |
hmm, no DarcsWiki/gitit.log? |
| 18:17 |
|
|
gour left #darcs |
| 18:20 |
|
|
balor joined #darcs |
| 18:58 |
|
|
waern_ joined #darcs |
| 19:01 |
|
|
darcscommitbot joined #darcs |
| 19:25 |
|
|
amuck joined #darcs |
| 20:20 |
|
gwern |
kowey: I dunno. the existing one when I logged in just now seems to be post-reboot |
| 20:21 |
|
kowey |
hmm |
| 20:21 |
|
kowey |
so possible culprits in my mind are: gitit + google/msn spiders and recent roundup activity |
| 20:21 |
|
kowey |
any other suggestions for what might be going on? |
| 20:21 |
|
gwern |
on the other hand, I'm not actually sure how to interpret '16/Aug/2009:17:26:43 +000' |
| 20:21 |
|
gwern |
this UTC? |
| 20:22 |
|
gwern |
but it's 16:22 here, so subtract the 3 hours or whatever for my EST, puts it back at 1300, but you sent the email yesterday or at least more like 0200 |
| 20:24 |
|
kowey |
it was early afternoon my time when I sent you that email |
| 20:24 |
|
kowey |
you mean the one to support osu, right? |
| 20:24 |
|
gwern |
yes |
| 20:25 |
|
kowey |
I sent that at 13:00+0100 which would translate to 08:00-0400 for your Eastern Daylight Time, I think |
| 20:26 |
|
gwern |
ok, let's run ab on this sucker and see whether page views drive up RAM |
| 20:26 |
|
kowey |
ab? |
| 20:26 |
|
gwern |
dah, ab won't take multiple URLs? |
| 20:26 |
|
kowey |
ah http://httpd.apache.org/docs/2.0/programs/ab.html |
| 20:27 |
|
kowey |
err... GET /_expire/TheCommands |
| 20:28 |
|
kowey |
grep _expire DarcsWiki/gitit.log | wc -l |
| 20:28 |
|
kowey |
13 |
| 20:28 |
|
|
zooko left #darcs |
| 20:28 |
|
gwern |
? |
| 20:28 |
|
|
darcscommitbot joined #darcs |
| 20:28 |
|
gwern |
our posthook firing? |
| 20:28 |
|
kowey |
why doesn't http://wiki.darcs.net/robots.txt tell googlebot et al. "please don't expire my cached pages"? |
| 20:29 |
|
kowey |
try it out |
| 20:29 |
|
gwern |
we have a robots.txt? |
| 20:29 |
|
kowey |
the grep thingy |
| 20:29 |
|
kowey |
we don't |
| 20:29 |
|
kowey |
but shouldn't gitit support something like that? |
| 20:29 |
|
kowey |
right now it points to an empty wiki page |
| 20:30 |
|
kowey |
(I had similar pain years ago when I created a trac+darcs instance... learned really quick the value of a robots.txt file) |
| 20:31 |
|
gwern |
bwa ha ha... wiki.darcs.net, experience the full power of this armed and operation score of abs |
| 20:31 |
|
gwern |
*operational |
| 20:32 |
|
gwern |
('no! darcsaraan is a peaceful wiki!' 'but microsoft.com would not serve as a convincing demonstration to the outlying sites') |
| 20:32 |
|
kowey |
I do believe that GoogleBot visiting our _expire pages is a definite problem |
| 20:32 |
|
Heffalump |
kowey: how much disk does the darcs.net VM have? |
| 20:32 |
|
Heffalump |
and how much is currently in use? |
| 20:32 |
|
gwern |
why are there 4 apaches anyway? |
| 20:32 |
|
kowey |
14G of which 8 are now in use |
| 20:33 |
|
kowey |
gwern: 4 apaches? |
| 20:34 |
|
gwern |
top has 4 apaches running |
| 20:34 |
|
Heffalump |
hmm, do you have some idea what the 8 are for? (would making me an account so I can poke around for myself be feasible, or are they kept fairly limited? I'm just investigating the feasibility of offering darcs another VM as I mentioned a while back) |
| 20:35 |
|
idnar |
is that not just apache forking worker processes? |
| 20:35 |
|
kowey |
Heffalump: I'm afraid I don't... is there an easy way to get a rough breakdown? |
| 20:35 |
|
kowey |
du perhaps? |
| 20:35 |
|
Heffalump |
yes, du |
| 20:35 |
|
Heffalump |
I generally do 'du -s *' in the root, and then follow the interesting bits further |
| 20:35 |
|
Heffalump |
don't worry about it if you're busy now |
| 20:35 |
|
kowey |
I used to use this Perl script called dutree |
| 20:36 |
|
gwern |
idnar: dunno… I always thought apache was supposed to be highperformance and would use threads |
| 20:36 |
|
kowey |
wow, my fingers are conditioned to type "tmp" every time I type "cd /" |
| 20:36 |
|
* gwern |
wonders how on earth I just did that unicode ellipse |
| 20:37 |
|
Heffalump |
gwern: doesn't look like unicode to me |
| 20:37 |
|
idnar |
gwern: the default mpm is still the worker model, but there is a threaded mpm |
| 20:37 |
|
Heffalump |
gwern: apache2 does have a threaded version |
| 20:37 |
|
idnar |
"high performance...threads" amuses me, though ;P |
| 20:38 |
|
gwern |
hm. whatever the gitit problem is, it's not reads. my abs have been hammering on a dozen different pages and gitit's still at 6.9 |
| 20:38 |
|
kowey |
ok, so the breakdown is 3.0G in /home, 1.6G in /usr and 2.5G in /var |
| 20:39 |
|
gwern |
let's toss in an allpages, a random, and a recent changes |
| 20:39 |
|
kowey |
going further... David's directory accounts for 1.6 of those G (he also has a copy of the old darcs.net in there somewhere) |
| 20:39 |
|
Heffalump |
the /var stuff is probably logfiles |
| 20:39 |
|
Heffalump |
I bet most of it is in /var/log/apache or /var/log/apache2 |
| 20:39 |
|
kowey |
(one of these days, it may be good to resurrect the old RT tracker as read-only) |
| 20:40 |
|
kowey |
561M for /var/log/apache |
| 20:41 |
|
kowey |
gwern: I'm in #osuosl warning them that we're running ab on gitit |
| 20:43 |
|
|
gwern joined #darcs |
| 20:48 |
|
|
waern_ joined #darcs |
| 20:50 |
|
gwern |
ah, I've managed to put it up to 7.5% |
| 20:50 |
|
gwern |
but maybe someone was editing... |
| 21:12 |
|
gwern |
dozens of abs later, I've managed to push it to 9.1% |
| 21:12 |
|
gwern |
yeesh |
| 21:44 |
|
|
darcscommitbot joined #darcs |
| 23:12 |
|
|
nomeata joined #darcs |
| 23:56 |
|
|
waernZzz joined #darcs |
