Does Haskell hurt your brain?

Feel free to bitch about Haskell in the comments! I'm interested to see how one should go about writing the How to read Haskell tutorial, as well as the Haskell wikibook.

The tutorial is aimed at people who want to understand some piece of Haskell code they encounter, or who like to learn by example (and quickly find themselves lost). The wikibook is more aimed at people who are new to programming and who are said to have an easier time picking up Haskell than their l33t hacker friends (you know, not so much unlearning to do). Speaking of l33t hackers, maybe this would be a good chance to point out Haskell for C programmers...

Anyway, yeah so, if you've been turned off by Haskell because it's hard, weird or painful, let me know. Note that if I receive any comments at all, I'm somewhat expecting them to be about IO and monads. Those comments are welcome too, although I would like them better if you followed up with any insights about what make them hard for you to understand. Otherwise, what I would most like to see are the complaints about reading and understanding Haskell code.

Feel free to bitch about Haskell in the comments! I'm interested to see how one should go about writing the How to read Haskell tutorial, as well as the Haskell wikibook.

The tutorial is aimed at people who want to understand some piece of Haskell code they encounter, or who like to learn by example (and quickly find themselves lost). The wikibook is more aimed at people who are new to programming and who are said to have an easier time picking up Haskell than their l33t hacker friends (you know, not so much unlearning to do). Speaking of l33t hackers, maybe this would be a good chance to point out Haskell for C programmers...

Anyway, yeah so, if you've been turned off by Haskell because it's hard, weird or painful, let me know. Note that if I receive any comments at all, I'm somewhat expecting them to be about IO and monads. Those comments are welcome too, although I would like them better if you followed up with any insights about what make them hard for you to understand. Otherwise, what I would most like to see are the complaints about reading and understanding Haskell code.

Does Haskell hurt your brain?

eric shuts up at last (and dreams of tidyness)

Alright, I'm going to put my foot down and force myself to take the thesis more seriously. This means you should be

1. seeing me posting only before my 22:00 bedtime (eh... oops)
2. not be hearing from me as much (yay!).

reorganising our stuff

I wonder what it would look like if somebody got down to it and started tidying up the darcs hierarchy... I think I've talked about this, like, a year ago, but somebody on the channel (wisely) said that we should wait until the conflictors stuff is finished... Hmm... but hypothetically, what would it look like? Maybe something like this?

Darcs.Support
         .Arguments
         .Flags
Darcs.Command (formerly DarcsCommand)
         .Add
         .Get
         .Record
Darcs.Repository (as in Darcs/Repository.lhs)
         .DarcsRepo
         .GitRepo
Darcs.Patch
         .Info
         .Match
Darcs.Util
         .External
         .FilePath
         .IsoDate

Darcs.Support sounds pretty stupid, but I don't know what else I'd call it. Basically for stuff which supports the Darcs.Command stuff (maybe it'd just go under Darcs, as in, Darcs.Arguments). This isn't the only way to do it, of course. Somebody else might have a better idea... but whatever way we choose, it'll be a lot nicer than what we have now. A bit more approachable, anyway.

Alright, I'm going to put my foot down and force myself to take the thesis more seriously. This means you should be

1. seeing me posting only before my 22:00 bedtime (eh... oops)
2. not be hearing from me as much (yay!).

reorganising our stuff

I wonder what it would look like if somebody got down to it and started tidying up the darcs hierarchy... I think I've talked about this, like, a year ago, but somebody on the channel (wisely) said that we should wait until the conflictors stuff is finished... Hmm... but hypothetically, what would it look like? Maybe something like this?

Darcs.Support
         .Arguments
         .Flags
Darcs.Command (formerly DarcsCommand)
         .Add
         .Get
         .Record
Darcs.Repository (as in Darcs/Repository.lhs)
         .DarcsRepo
         .GitRepo
Darcs.Patch
         .Info
         .Match
Darcs.Util
         .External
         .FilePath
         .IsoDate

Darcs.Support sounds pretty stupid, but I don't know what else I'd call it. Basically for stuff which supports the Darcs.Command stuff (maybe it'd just go under Darcs, as in, Darcs.Arguments). This isn't the only way to do it, of course. Somebody else might have a better idea... but whatever way we choose, it'll be a lot nicer than what we have now. A bit more approachable, anyway.

eric shuts up at last (and dreams of tidyness)

wxhaskell / wxC

I have a new project! (Oh no). So one day, sort of randomly, J.O'D on haskell-cafe takes the intiative to a start a wxhaskell revival process, and naturally enough, I volunteered to help out. I have now been assigned the task of making sure the Unicode stuff works (which I'm interpreting mostly as figure out how to write a semi-automated eyeball test suite).

Of course, one of the first things I ask for is for wxhaskell to switch to darcs. This project has been first-hand experience for me why a distributed version control system is so useful: it keeps the bit-rot away. Darcs's patch-oriented nature would have allowed us to keep a Unicode fork of wxhaskell alive whilst waiting for the official maintainers to find the time to bring the project back to life. You can't blame them... people are busy, right? The situation we faced with wxhaskell was one where Unix patch was piling on top of Unix patch; it was getting a little messy and annoying. This was exactly the kind of situation where easy forking and easy healing can keep a niche project alive.

I feel kinda silly. I've apparently had a tailorised darcs mirror of wxhaskell lying around since early July and just never went public with it. So tonight, after TD offered to host the darcs stuff, I finally dusted it off, and converted my Unicode mega-patch into 5 darcs patches and uploaded the whole deal on my homepage. I'm not linking it, because it's really supposed to be temporary. But the rest of the wxhaskell revival team know about it. So it's moving!

wxC and SWIG

SS on the wxc list has suggested we switch from handwriting our wxC stuff to autogenerating it with SWIG. It's been interesting discussing with him. Learned a bit from the process, and got a reminder (duh) that wxC is actually C++ code (of course, what else would it be?), only that it behaves exactly like C code on the outside. Anyway, long term project's looking interesting. SS says that given enough configuration, we should be able to generate the wxC code directly, even including the kind of annotations that wxhaskell needs. But we also agree that this kind of thing is for the long term. Short term priority is to get the new wxhaskell and wxc out the door!

I have a new project! (Oh no). So one day, sort of randomly, J.O'D on haskell-cafe takes the intiative to a start a wxhaskell revival process, and naturally enough, I volunteered to help out. I have now been assigned the task of making sure the Unicode stuff works (which I'm interpreting mostly as figure out how to write a semi-automated eyeball test suite).

Of course, one of the first things I ask for is for wxhaskell to switch to darcs. This project has been first-hand experience for me why a distributed version control system is so useful: it keeps the bit-rot away. Darcs's patch-oriented nature would have allowed us to keep a Unicode fork of wxhaskell alive whilst waiting for the official maintainers to find the time to bring the project back to life. You can't blame them... people are busy, right? The situation we faced with wxhaskell was one where Unix patch was piling on top of Unix patch; it was getting a little messy and annoying. This was exactly the kind of situation where easy forking and easy healing can keep a niche project alive.

I feel kinda silly. I've apparently had a tailorised darcs mirror of wxhaskell lying around since early July and just never went public with it. So tonight, after TD offered to host the darcs stuff, I finally dusted it off, and converted my Unicode mega-patch into 5 darcs patches and uploaded the whole deal on my homepage. I'm not linking it, because it's really supposed to be temporary. But the rest of the wxhaskell revival team know about it. So it's moving!

wxC and SWIG

SS on the wxc list has suggested we switch from handwriting our wxC stuff to autogenerating it with SWIG. It's been interesting discussing with him. Learned a bit from the process, and got a reminder (duh) that wxC is actually C++ code (of course, what else would it be?), only that it behaves exactly like C code on the outside. Anyway, long term project's looking interesting. SS says that given enough configuration, we should be able to generate the wxC code directly, even including the kind of annotations that wxhaskell needs. But we also agree that this kind of thing is for the long term. Short term priority is to get the new wxhaskell and wxc out the door!

wxhaskell / wxC

ssh stuff fixed

Fixed the ssh stuff on Saturday, making patches for sftp -q, sftp -b, and --disable-ssh-cm

Apparently, sftp has changed recently, by actually implementing the behaviour they've been documenting for some time, namely:

-b batchfile
Batch mode reads a series of commands from an input batchfile instead of stdin. Since it lacks user interaction it should be used in conjunction with non-interactive authentication.

That'll be man page I'm quoting there. Anyhow, that's part of the reason why issue273 was so weird. There's still other stuff mixed in there. For instance, I don't know why salty-horse's server randomly dies during or before scp when ControlMaster is enabled, nor do I know why scp doesn't give us something nice and useful, like an exit code for bad things afoot. But at least now things work like they should.

Also, my --disable-ssh-cm uses a little bit of evilness, namely, unsafePerformIO . newIORef to simulate global variables like you get in other languages. Eeewww... but it seems like the alternative would be to have a bunch of parameters everywhere, just to keep passing that DisableSSHControlMaster flag all the way down to the ssh calls. Lesser of two evils? I hope I know what I'm doing. #haskell seemed a bit doubtful at first, but basically told me it was ok, if I shouted NOINLINE at the compiler. And I hope this doesn't start a precedent of coding sloppily just because doing it right would be mildly inconvenient. The "global" variable is write once, read many, I figure. It's practically a constant, so it couldn't really hurt, could it?

no query cat

I tried looking at query cat today, but didn't get very far. I think I ought to see what DiffCommand does when you pass it file(s) as an argument.

guilty darcsing

Also, I've been rather active on #darcs and on the bug tracker lately. No, no, I'm not trying to take over the bug tracker (though I suppose other darcsers would be happy to have somebody take charge of it), nor have I been specially assigned to the job. It's just that things are going kinda badly at work. That is to say, I have to write up my yearly progress report, which is kinda hard (though not as bad as writing a paper), and so I just end procrastinating a lot... So as soon as I get my act together workwise and start disciplining myself again, my darcs activity should reduce to pre-July levels. Anyway, that's the general idea. If you see me talking, like a WHOLE lot on mailing lists, it probably just means I'm trying to avoid something important.

Fixed the ssh stuff on Saturday, making patches for sftp -q, sftp -b, and --disable-ssh-cm

Apparently, sftp has changed recently, by actually implementing the behaviour they've been documenting for some time, namely:

-b batchfile
Batch mode reads a series of commands from an input batchfile instead of stdin. Since it lacks user interaction it should be used in conjunction with non-interactive authentication.

That'll be man page I'm quoting there. Anyhow, that's part of the reason why issue273 was so weird. There's still other stuff mixed in there. For instance, I don't know why salty-horse's server randomly dies during or before scp when ControlMaster is enabled, nor do I know why scp doesn't give us something nice and useful, like an exit code for bad things afoot. But at least now things work like they should.

Also, my --disable-ssh-cm uses a little bit of evilness, namely, unsafePerformIO . newIORef to simulate global variables like you get in other languages. Eeewww... but it seems like the alternative would be to have a bunch of parameters everywhere, just to keep passing that DisableSSHControlMaster flag all the way down to the ssh calls. Lesser of two evils? I hope I know what I'm doing. #haskell seemed a bit doubtful at first, but basically told me it was ok, if I shouted NOINLINE at the compiler. And I hope this doesn't start a precedent of coding sloppily just because doing it right would be mildly inconvenient. The "global" variable is write once, read many, I figure. It's practically a constant, so it couldn't really hurt, could it?

no query cat

I tried looking at query cat today, but didn't get very far. I think I ought to see what DiffCommand does when you pass it file(s) as an argument.

guilty darcsing

Also, I've been rather active on #darcs and on the bug tracker lately. No, no, I'm not trying to take over the bug tracker (though I suppose other darcsers would be happy to have somebody take charge of it), nor have I been specially assigned to the job. It's just that things are going kinda badly at work. That is to say, I have to write up my yearly progress report, which is kinda hard (though not as bad as writing a paper), and so I just end procrastinating a lot... So as soon as I get my act together workwise and start disciplining myself again, my darcs activity should reduce to pre-July levels. Anyway, that's the general idea. If you see me talking, like a WHOLE lot on mailing lists, it probably just means I'm trying to avoid something important.

ssh stuff fixed

patch, match, matches

I sometimes wonder if we should simplify the patch matching interface, or at least document fewer commands. At the very least, it seems we could just nix --patch altogether and replace it by --match='name Foo'.

Also, maybe we should just get rid of the distinction between singular and plural forms. --match should just match everything, and the --last should be used to select among these matches. In fact, I think that's how it already behaves, and that the doc is just a little bit out of date.

Finally, I would even be tempted to get rid of --tag (and likewise --from-tag, --to-tag), and just implement something like --match='tag '.

I suppose we could keep around the old flags for users who are accustomed to them (although I doubt people would really miss them...) and just simplify the documentation.

I sometimes wonder if we should simplify the patch matching interface, or at least document fewer commands. At the very least, it seems we could just nix --patch altogether and replace it by --match='name Foo'.

Also, maybe we should just get rid of the distinction between singular and plural forms. --match should just match everything, and the --last should be used to select among these matches. In fact, I think that's how it already behaves, and that the doc is just a little bit out of date.

Finally, I would even be tempted to get rid of --tag (and likewise --from-tag, --to-tag), and just implement something like --match='tag '.

I suppose we could keep around the old flags for users who are accustomed to them (although I doubt people would really miss them...) and just simplify the documentation.

patch, match, matches

Arrrrghhh

I just spent today debugging some ssh stuff with a user. Oh man. It seems like everytime I submit a patch, I have to submit ten other patches afterwards to correct bugs in my first patch, and bugs in my bugfixes.

I just spent today debugging some ssh stuff with a user. Oh man. It seems like everytime I submit a patch, I have to submit ten other patches afterwards to correct bugs in my first patch, and bugs in my bugfixes.

Arrrrghhh

query cat

Did I just promise to implement 'darcs query cat'? Gah, no, bad eric! Extra commitments bad! The most surefire way to break your current promises is take on new ones. It should be easy though. But you know it goes when you say stuff like that...

Did I just promise to implement 'darcs query cat'? Gah, no, bad eric! Extra commitments bad! The most surefire way to break your current promises is take on new ones. It should be easy though. But you know it goes when you say stuff like that...

query cat

updated images

On a random burst of inspiration, I have finally gotten around to updating the images used in Understanding Darcs. They include some ideas from #darcs, namely Heffalump's suggestion that I colour the _darcs stuff differently than the working dir. Also, I have uploaded the Omnigraffle sources for these diagrams so that you can look at it and go "Ugh! XML!", or open it on your Mac.



Yeah, yeah, I know I should be using something Free-er like Inkscape... but Omnigraffle, man... it's so fantastically easy to use! Aack, no! There I go, I'm promoting non-free software... Nooooo (well then again, I'm still addicted to the comfort of my Mac, though Ubuntu's looking better and better these days, so I'm pretty much screwed for ideology in either case)

See, this is the kind of stuff I should be working in my free time when I'm looking for something easy. Much more constructive, and even massages the creative juices a tiny bit, much better than, say, going on a 16 hour Freeciv binge... which isn't something I would... actually... do... of course.

Updated again - 23:20

Another update, 8 hours later. This time, went for a model which makes it possible to represent everything in one picture (instead of having a before/after comparison).

That speeds up my diagram-development time considerably. It's already pretty smooth sailing, thanks to layers, but having half as many layers as before is always welcome.



Also added diagrams for revert, unrecord, obliterate.

Anyway, I'd better not get too eager about this book. I do have real work to do, after all. Also, a few diagrams by themselves probably isn't going to make things that much easier for the user. We'll need actual examples, and probably a patient walkthrough, something which I probably do not have the energy to do.

On a random burst of inspiration, I have finally gotten around to updating the images used in Understanding Darcs. They include some ideas from #darcs, namely Heffalump's suggestion that I colour the _darcs stuff differently than the working dir. Also, I have uploaded the Omnigraffle sources for these diagrams so that you can look at it and go "Ugh! XML!", or open it on your Mac.



Yeah, yeah, I know I should be using something Free-er like Inkscape... but Omnigraffle, man... it's so fantastically easy to use! Aack, no! There I go, I'm promoting non-free software... Nooooo (well then again, I'm still addicted to the comfort of my Mac, though Ubuntu's looking better and better these days, so I'm pretty much screwed for ideology in either case)

See, this is the kind of stuff I should be working in my free time when I'm looking for something easy. Much more constructive, and even massages the creative juices a tiny bit, much better than, say, going on a 16 hour Freeciv binge... which isn't something I would... actually... do... of course.

Updated again - 23:20

Another update, 8 hours later. This time, went for a model which makes it possible to represent everything in one picture (instead of having a before/after comparison).

That speeds up my diagram-development time considerably. It's already pretty smooth sailing, thanks to layers, but having half as many layers as before is always welcome.



Also added diagrams for revert, unrecord, obliterate.

Anyway, I'd better not get too eager about this book. I do have real work to do, after all. Also, a few diagrams by themselves probably isn't going to make things that much easier for the user. We'll need actual examples, and probably a patient walkthrough, something which I probably do not have the energy to do.

updated images

ssh does indeed invoke a shell

And so continues our saga of Eric Doesn't Actually Know How Computers Work...

New discovery of the day? SSH does indeed invoke a shell when you do something like ssh myserver mycommand I always somehow figured that when you did that, magically mycommand would be invoked, like really first thing when you log in, no shell or nuthing. Nope, that's not how it works, and come to think of it, that kinda makes sense, right, because the computer gets to enforce what the user runs when (s)he logs in (duh). If it didn't go through a shell, then what would be the point of having that bit in /etc/passwd that tells the computer what shell to run? The user could totally bypass that by saying ssh myserver /launch/ze/missles. Oh wait... then again, maybe it's not for security reasons, because the user wouldn't have +x on /launch/ze/missles (but I am le tired!)... ugh, it's late, and the later it gets the more easily I confuse myself. Ok, so point being, ssh invokes a shell when you try to launch a command through it. Check.

Makes my issue223 kinda redundant, then, don't it?

the wikibook

Oh, and a minor note, I have slightly fleshed out the Understanding Darcs wikibook. Now, you might think that having a wikibook is redundant with either the Darcs manual, or the Darcs wiki, or both, but I would tend to disagree. I'd like you first of all to think of the wikibook not as a Wiki, but a Book. See, we got three things here, a Manual, a Wiki and a Book.

The way I figure, a Manual's job is to be terse and complete. It needs to be a good reference guide, the kind of thing that mechanics can thumb through without wading through a bunch of useful "helpful" stuff. The K+R book is what comes to mind when I think of this. No nonsense, here's everything you need to know. Of course, a Manual can be friendly if it wants, but only as long as said friendliness does not get in the way of its core mission, thumb-through-ability.

Now what's a software Wiki's job? Not to be friendly either! I'm not sure what I'd put down as its core mission, because you know, if anything wikis are meant to be chaotic and messy. No more than neccesary, of course; it's always nice to have someone come in and try to sweep things around and put things in their place. I guess if anything, a Wiki's core mission is to cover the fokelore. In fact, let's not call it Wiki anymore. Abstract over the fact that it's a wiki. A Folklore Repository is meant to know everything that the community knows. It can be friendly if the community is feeling friendly, but really, its main role is sprawl out into all the little niches of Our knowledge (and that's why wikis are ideal for this, because every one of Us can go plug something in).

And now we get to a Book. What's a Book supposed to do (I should call it something else, like a Guide). So scratch that. What's a Guide supposed to do? Be friendly. And that's we don't have yet in the darcs community. We've got the Manual covered (and we rock because our comments are our manual, go David!). We've got the Folklore down, but not alot of Folk and thus, not a lot of lore. But what we're sorely, sorely missing is an actual Guide. And this is where wikibooks comes in. Hyper-text is nice and all, but one thing which makes a document friendly, I think, is it doesn't force you to choose anything. Not even the order that you read stuff. No a Guide should really be telling you, look, ok, of course you can approach this any way you want, but if you listen to the way I tell it, if you follow me, I will tell you a coherent story. I might be full of crap about this, but in order to make a Guide work, you have to make it sequential. Point being, a Guide needs to be a book, not a wiki. You can put hypertext in it to make it richer, but there must be a canonical order for users to fall back on. Of course, then why use wikibooks? Because I want to author this with the community. I don't think I can pull it off myself. What we're producing is not a real Guide, but sort of a compromise between Folklore and a Guide. But then... why Wikibooks? Why not just put the Guide on the darcs wiki? Oh technical reasons. MoinMoin isn't the easiest thing to work with for fancy stuff. I wish there was a latex-based wiki out there. Like good. Well, actually, there's another part to that, in that I want it on wikibooks, because I want editors to look at that thing and think Book (not Wiki). Book as in, let me try to be pedagogical. Not Wiki as in, let me slap down what I know any old way.

There ya go. Three paragraphs of rambling nonsense with Capital Letters liberally sprinkled throughout. I'd better go home and try to do something useful with my time instead.

And so continues our saga of Eric Doesn't Actually Know How Computers Work...

New discovery of the day? SSH does indeed invoke a shell when you do something like ssh myserver mycommand I always somehow figured that when you did that, magically mycommand would be invoked, like really first thing when you log in, no shell or nuthing. Nope, that's not how it works, and come to think of it, that kinda makes sense, right, because the computer gets to enforce what the user runs when (s)he logs in (duh). If it didn't go through a shell, then what would be the point of having that bit in /etc/passwd that tells the computer what shell to run? The user could totally bypass that by saying ssh myserver /launch/ze/missles. Oh wait... then again, maybe it's not for security reasons, because the user wouldn't have +x on /launch/ze/missles (but I am le tired!)... ugh, it's late, and the later it gets the more easily I confuse myself. Ok, so point being, ssh invokes a shell when you try to launch a command through it. Check.

Makes my issue223 kinda redundant, then, don't it?

the wikibook

Oh, and a minor note, I have slightly fleshed out the Understanding Darcs wikibook. Now, you might think that having a wikibook is redundant with either the Darcs manual, or the Darcs wiki, or both, but I would tend to disagree. I'd like you first of all to think of the wikibook not as a Wiki, but a Book. See, we got three things here, a Manual, a Wiki and a Book.

The way I figure, a Manual's job is to be terse and complete. It needs to be a good reference guide, the kind of thing that mechanics can thumb through without wading through a bunch of useful "helpful" stuff. The K+R book is what comes to mind when I think of this. No nonsense, here's everything you need to know. Of course, a Manual can be friendly if it wants, but only as long as said friendliness does not get in the way of its core mission, thumb-through-ability.

Now what's a software Wiki's job? Not to be friendly either! I'm not sure what I'd put down as its core mission, because you know, if anything wikis are meant to be chaotic and messy. No more than neccesary, of course; it's always nice to have someone come in and try to sweep things around and put things in their place. I guess if anything, a Wiki's core mission is to cover the fokelore. In fact, let's not call it Wiki anymore. Abstract over the fact that it's a wiki. A Folklore Repository is meant to know everything that the community knows. It can be friendly if the community is feeling friendly, but really, its main role is sprawl out into all the little niches of Our knowledge (and that's why wikis are ideal for this, because every one of Us can go plug something in).

And now we get to a Book. What's a Book supposed to do (I should call it something else, like a Guide). So scratch that. What's a Guide supposed to do? Be friendly. And that's we don't have yet in the darcs community. We've got the Manual covered (and we rock because our comments are our manual, go David!). We've got the Folklore down, but not alot of Folk and thus, not a lot of lore. But what we're sorely, sorely missing is an actual Guide. And this is where wikibooks comes in. Hyper-text is nice and all, but one thing which makes a document friendly, I think, is it doesn't force you to choose anything. Not even the order that you read stuff. No a Guide should really be telling you, look, ok, of course you can approach this any way you want, but if you listen to the way I tell it, if you follow me, I will tell you a coherent story. I might be full of crap about this, but in order to make a Guide work, you have to make it sequential. Point being, a Guide needs to be a book, not a wiki. You can put hypertext in it to make it richer, but there must be a canonical order for users to fall back on. Of course, then why use wikibooks? Because I want to author this with the community. I don't think I can pull it off myself. What we're producing is not a real Guide, but sort of a compromise between Folklore and a Guide. But then... why Wikibooks? Why not just put the Guide on the darcs wiki? Oh technical reasons. MoinMoin isn't the easiest thing to work with for fancy stuff. I wish there was a latex-based wiki out there. Like good. Well, actually, there's another part to that, in that I want it on wikibooks, because I want editors to look at that thing and think Book (not Wiki). Book as in, let me try to be pedagogical. Not Wiki as in, let me slap down what I know any old way.

There ya go. Three paragraphs of rambling nonsense with Capital Letters liberally sprinkled throughout. I'd better go home and try to do something useful with my time instead.

ssh does indeed invoke a shell

windows, ssh stuff, dates and the mystery bug

Stayed home from work yesterday, giving myself the excuse that I was sick. Probably should have gone to work instead, because it turns out I was feeling ok enough to do a bit of darcs-hacking. Also played hooky a bit this morning (it's 11:06), but overall, I'm glad to have spent time getting this stuff out of the way... clears my head, let's me focus on other things.

windows and weird filenames

A user on IRC was trying to work around issue53 where Windows enforces a bunch of naming conventions like "don't start your filenames with AUX". I don't think I personally am going to do something about this, but my proposal is that, when we are running on Windows, we should treat patches that affect such files as affecting some other file instead, one with a translated name. So if we have a patch that affects AUX.dtd, we should apply the changes to -AUX.dtd or something; and print out a warning saying what we have done and why. This solution at least allows the patches to apply, but it does have some problems of its own, like (1) what if a file with the translated name already exists? (2) what if the user tries to modify the translated file? Do we want to recognise that? [I'd say, we probably should, but rather than let the user record changes, we just say "Whoops! you don't want to touch this file. Please mv it to something safe instead."] Mmmhh. I dunno if this is going to work, or if it's just going to make things super-complicated and introduce a bunch of random bloat. Well, in any case, we should at least detect the problem and tell the user about it. I suppose simply ignoring such files (and printing a warning) is just as good, and much simpler to boot. (If we were to ignore them, we should at least try to handle the mv, though, although that too is complicated)

get --to-match

Whilst trying out the IRC-user's problem on the darcs repository, I ran into this.

% darcs get --to-match='exact "More fixes to unrecord."' ~/darcsImpl/stable
Copying patch 3831 of 3831... done!
darcs: failed to read patch in get_extra:
Sun May 22 13:40:59 GMT 2005  David Roundy 
  * extend revert_interactive test to do a trickier revert.
Perhaps this is a 'partial' repository?

Ouch! I should check the bug tracker and see if we have anything like it.

plink, Windows, ssh stuff

We had decided to reject my new ControlMaster patch because it was fragile, and then we weren't sure about the other patches which were essentially supposed to make Windows shut up when doing ssh stuff (so we don't get spurious plink -O error messages). I finally had a chance to sit down and review these patches. It seems that it is ok for us to apply them independently of the control master stuff. I have resubmitted the patches and made a request for review. Well, all patch submissions are implicitly a request for review, but I wanted to particularly call attention to this bit.

dates and the mystery bug

I had a filed a bug report for a mysterious issue involving the darcs repository inventory. Juliusz looked into it and found that it was due to a cleanDate patch. The basic problem is that PatchInfo.make_filename uses cleanDate to parse the date info in old-school patches. Old school patches write their dates in human-readable format, which is rather useless because it's just an internal representation and harder to parse.

Case in point, the mystery bug. I had submitted a patch to fix issue173 (timezones not recognised correctly)... what the patch does is to correct cleanDate so that dates are converted to UTC before being printed out. I think this is the correct behaviour, because otherwise, timezones are just truncated; which would be very bad because somebody reading the time string in would have little choice but to assume UTC.

So I think my patch is correct: but it breaks old patches, because the patch in question was dated Sun Sep 21 11:57:26 EDT 2003, which is intepreted

 before: 2003-09-21 11:57 (wrong!)
 after:  2003-09-21 15:57 (EDT is UTC-4, so add 4 back)

Unfortunately, the filename generated was using the incorrect time (2003-09-21 11:57). Ick. So what I proposed is that we continue supporting this broken behaviour (it doesn't really matter anyway, it's just what filename we give to it), by using showIsoDateTime.readDate and a small comment saying that this is wrong, but we don't really care.

Anyway, I hope I haven't simply confused myself. I think this analysis of things is correct, maybe the next action is wrong, but I'm pretty sure that's where things went wrong. Sometimes seems that it's impossible to program a computer without being super anal about everything.

patch bundles

I have one particularly bad habit when submitting patches, and that is grouping my patches into thematic bundles, rather than dependency bundles. Why is this bad? It causes confusion! It makes people think that certain patches go together, when in fact the only thing about them is that they are related to common themes, like "date parsing". I need to get a better eye for grouping my patches so that things work out smoother for everybody.

Stayed home from work yesterday, giving myself the excuse that I was sick. Probably should have gone to work instead, because it turns out I was feeling ok enough to do a bit of darcs-hacking. Also played hooky a bit this morning (it's 11:06), but overall, I'm glad to have spent time getting this stuff out of the way... clears my head, let's me focus on other things.

windows and weird filenames

A user on IRC was trying to work around issue53 where Windows enforces a bunch of naming conventions like "don't start your filenames with AUX". I don't think I personally am going to do something about this, but my proposal is that, when we are running on Windows, we should treat patches that affect such files as affecting some other file instead, one with a translated name. So if we have a patch that affects AUX.dtd, we should apply the changes to -AUX.dtd or something; and print out a warning saying what we have done and why. This solution at least allows the patches to apply, but it does have some problems of its own, like (1) what if a file with the translated name already exists? (2) what if the user tries to modify the translated file? Do we want to recognise that? [I'd say, we probably should, but rather than let the user record changes, we just say "Whoops! you don't want to touch this file. Please mv it to something safe instead."] Mmmhh. I dunno if this is going to work, or if it's just going to make things super-complicated and introduce a bunch of random bloat. Well, in any case, we should at least detect the problem and tell the user about it. I suppose simply ignoring such files (and printing a warning) is just as good, and much simpler to boot. (If we were to ignore them, we should at least try to handle the mv, though, although that too is complicated)

get --to-match

Whilst trying out the IRC-user's problem on the darcs repository, I ran into this.

% darcs get --to-match='exact "More fixes to unrecord."' ~/darcsImpl/stable
Copying patch 3831 of 3831... done!
darcs: failed to read patch in get_extra:
Sun May 22 13:40:59 GMT 2005  David Roundy 
  * extend revert_interactive test to do a trickier revert.
Perhaps this is a 'partial' repository?

Ouch! I should check the bug tracker and see if we have anything like it.

plink, Windows, ssh stuff

We had decided to reject my new ControlMaster patch because it was fragile, and then we weren't sure about the other patches which were essentially supposed to make Windows shut up when doing ssh stuff (so we don't get spurious plink -O error messages). I finally had a chance to sit down and review these patches. It seems that it is ok for us to apply them independently of the control master stuff. I have resubmitted the patches and made a request for review. Well, all patch submissions are implicitly a request for review, but I wanted to particularly call attention to this bit.

dates and the mystery bug

I had a filed a bug report for a mysterious issue involving the darcs repository inventory. Juliusz looked into it and found that it was due to a cleanDate patch. The basic problem is that PatchInfo.make_filename uses cleanDate to parse the date info in old-school patches. Old school patches write their dates in human-readable format, which is rather useless because it's just an internal representation and harder to parse.

Case in point, the mystery bug. I had submitted a patch to fix issue173 (timezones not recognised correctly)... what the patch does is to correct cleanDate so that dates are converted to UTC before being printed out. I think this is the correct behaviour, because otherwise, timezones are just truncated; which would be very bad because somebody reading the time string in would have little choice but to assume UTC.

So I think my patch is correct: but it breaks old patches, because the patch in question was dated Sun Sep 21 11:57:26 EDT 2003, which is intepreted

 before: 2003-09-21 11:57 (wrong!)
 after:  2003-09-21 15:57 (EDT is UTC-4, so add 4 back)

Unfortunately, the filename generated was using the incorrect time (2003-09-21 11:57). Ick. So what I proposed is that we continue supporting this broken behaviour (it doesn't really matter anyway, it's just what filename we give to it), by using showIsoDateTime.readDate and a small comment saying that this is wrong, but we don't really care.

Anyway, I hope I haven't simply confused myself. I think this analysis of things is correct, maybe the next action is wrong, but I'm pretty sure that's where things went wrong. Sometimes seems that it's impossible to program a computer without being super anal about everything.

patch bundles

I have one particularly bad habit when submitting patches, and that is grouping my patches into thematic bundles, rather than dependency bundles. Why is this bad? It causes confusion! It makes people think that certain patches go together, when in fact the only thing about them is that they are related to common themes, like "date parsing". I need to get a better eye for grouping my patches so that things work out smoother for everybody.

windows, ssh stuff, dates and the mystery bug