Camelia, the Perl 6 bug

IRC log for #darcs, 2009-06-28

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

Time S Nick Message
00:29 ertai joined #darcs
05:14 kpreid_ joined #darcs
05:26 gwern joined #darcs
06:41 adu joined #darcs
07:42 lelit joined #darcs
08:23 balor joined #darcs
08:28 tux_rocker_ joined #darcs
08:32 mamalujo joined #darcs
08:53 sm_ joined #darcs
08:54 mamalujo hello, Ive been trying to use darcs w etckeeper on my debian (squeeze, w a little bit of sid). unfortunately, this resulted in my apt freezing on the step where its to log the changes in VCS. it seems to freeze on 'Removing from pending' darcs version is 2.2.0-1, etckeeper is 0.37 . I didnt specify it should use darcs during installation, but changed /etc/etckeeper/etckeeper.conf after (and did etckeeper init), so i still have a .git ...
08:55 mamalujo ... (the default VCS) there. I believe I also made a darcs initialise manually some time before on /etc, but never did anything with it, before hearing about this neat script (ie etckeeper) Should probably also note that I dont know how to use darcs yet, thought to make this usage a motivation to learn, just hoped I wouldnt come into as major problem as a crashed apt so immediately :) so, am I stumbling into some familiar problem or ...
08:55 mamalujo ... misuse, or is this something more obscure?
08:58 kolmodin joined #darcs
09:00 mornfall mamalujo: Are you sure it's darcs that's hanging? Can you just run a few commands in your /etc? (darcs changes, darcs wh)
09:05 mamalujo I cant say I am. the former command says nothing at all. the latter is spewed huge amounts of data after a short pause.
09:08 mornfall Well, I guess darcs itself is working just fine.
09:09 mornfall Although you may want to rm -rf _darcs and go with the etckeeper manual.
09:09 mornfall s/go/start over/ or something
09:12 mamalujo k, thx for the advice
09:20 mamalujo left #darcs
09:29 nomeata joined #darcs
10:01 gh_ mornfall: darcs 2.3 beta 1 is often reporting that a file does not exist when I do a "darcs whatsnew" on it
10:01 gh_ but still it does the whatsnew
10:08 mornfall gh_: Oh?
10:08 mornfall Can you paste example output?
10:16 mornfall gh_: ?
10:18 gh_ yep sorry
10:18 gh_ pc was slow
10:19 gh_ $ darcs w src/HTab/Formula.hs
10:19 gh_ WARNING: File 'src/HTab/Formula.hs' does not exist!
10:19 gh_ What's new in "src/HTab/Formula.hs":
10:19 gh_ No changes!
10:19 mornfall And the file is there, right?
10:19 gh_ yes
10:19 gh_ it does not say it for every file:
10:19 mornfall That's curious.
10:19 gh_ $ darcs w src/htab.hs
10:19 gh_ What's new in "src/htab.hs":
10:19 gh_ No changes!
10:20 mornfall Could it match a boring regexp somehow?
10:20 mornfall That is probably a bug (maybe a different one): we now say does not exist if the file is merely boring, too.
10:20 mornfall Hm.
10:20 gh_ hmm nope
10:21 mornfall Although I don't see how it could be boring, either.
10:21 mornfall Can you pack up the repo and publish?
10:21 mornfall Also, can you, in ghci run:
10:21 gh_ it seems to only affect files that are 2 levels deep
10:21 mornfall :m Storage.Hashed
10:21 gh_ 2 and more
10:22 mornfall :m + Storage.Hashed.Tree
10:22 mornfall t <- expand =<< readPlainTree "."
10:22 mornfall printPath t "src/HTab"
10:22 mornfall ?
10:22 gh_ k
10:23 mornfall gh_: Nevermind, reproduced.
10:23 mornfall It always happens with 2 or deeper. Bug in hashed-storage, presumably.
10:23 gh_ ah ok
10:23 gh_ good thing we catch it now
10:23 mornfall Yeah. That's why we do betas. :)
10:24 mornfall Thanks for the report, too.
10:25 gh_ you're welcome :)
10:43 mornfall gh_: Fixed. Stupid typo it was...
10:49 gh_ cool
10:52 Jerri joined #darcs
11:08 mamalujo joined #darcs
11:26 mamalujo hm, removing /etc/_darcs and starting seemed to have worked, though it took such a long time that I considered it a hang and gave up on it - and since the previous try, everything was duplicated cuz i didnt delete residual .git, perhaps there wasnt any problem to begin with. but, I do hope apt will not continue to be that drastically slow on further usage..
11:28 mornfall I have no idea what etckeeper is doing, so I can't help you much.
11:56 nomeata joined #darcs
12:16 kpreid_ joined #darcs
12:36 mornfall (wiki is down again)
12:36 tux_rocker__ joined #darcs
12:53 arjanb joined #darcs
13:27 * tux_rocker__ realizes he doesn't like to work on darcs unless he's caffeinated
13:36 intripoon joined #darcs
14:05 Riastradh I can't recall whether I've asked about this before, but why does `darcs get http://...' spray what looks like wget output for every patch it downloads, for some repositories?  (I don't know what repositories.)  This is under Darcs 2.0.2 (ought I just to upgrade?).
14:16 tux_rocker__ Riastradh: sometimes darcs actually uses wget to fetch those patches
15:53 Jerri joined #darcs
16:09 Riastradh Yes, tux_rocker__, but why does it spew the output of wget?
16:44 klapaucjusz joined #darcs
17:21 sm joined #darcs
17:52 [1]intripoon joined #darcs
19:17 kolmodin joined #darcs
19:44 dcoutts__ joined #darcs
19:52 mornfall Hmm. Lots of code for the endianity conversion business.
19:52 mornfall Maybe I should outsource part of it to some other module (but, which).
20:26 lispy mornfall: do you use Data.Binary?
20:31 mornfall lispy: No, it's too slow.
20:32 mornfall I use Foreign.Storable.
20:33 mornfall (And I implemented linux-C-style xlate32/xlate64...)
20:35 mornfall Btw. there's now http://repos.mornfall.net/hashed-storage/trac/ -- see "timeline" and "browse source" : - )
20:35 lispy Data.Binary is too slow?  I find that surprising only because of all the sucess stories I've seen on haskell-cafe about it having good performance
20:37 mornfall It is great, but it can't beat Foreign.Storable, only if because it has to copy the data (unlike Foreign.Storable).
20:37 mornfall I need to access the bits inline in the mmap area.
20:40 mornfall Don't worry, I originally used Data.Binary and profiled the thing. I gained nontrivial speedup from switching.
20:41 Heffalump the reason being that you can modify the data inplace?
20:41 mornfall Basically, yes. But reading is also faster this way.
20:42 Heffalump do you know why that is?
20:42 mornfall Well, I don't really know -- but even reading the index involves updating the timestamps and hashes in it, and using Data.Binary would mean rewriting the whole 7 megabyte binary blob.
20:42 Heffalump ah, right
20:42 mornfall So even if reading was on par, that wouldn't help.
20:42 Heffalump so it's probably inplace-ness again
20:42 Heffalump ah, ok
20:44 mornfall (Well, purely theoretically, I could try doing partial Data.Binary based updates and then poke the parts to be updated in-place. I am not sure it would lead to shorter or better code though. Hmm.)
20:46 mornfall However, with the xlate stuff, the common case gets no runtime penalty in the common case (little endian system). From looking at Data.Binary, my impression is, that even with getWord64le on a le system, there's a penalty, unless the compiler is super-smart...
20:47 mornfall (Hmm, that's what you get for not reading before hitting enter. Whatever.)
20:49 mornfall Anyway, I'm quite happy about today's progress.
20:49 mornfall (Just that I have been neglecting Russian and piano. Bahmpf. : - P)
20:58 fophillips joined #darcs
21:58 ertai_ joined #darcs
22:18 kpreid_ joined #darcs

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary