So tired... skipped work today because i was so so close. But here I am. Checkpoint reached. Got a working prototype of wxdarcs submitted to the list.

Had a long post detailing all the issues I went through, but somehow got lost. That's the trouble with these web tools. You lose stuff so easily.

Tests seem to run slow in gui mode. Can't figure out why.

Bed... at last, I may go to bed.

And go to work tomorrow. Looking forward to doing anything other than my hobby...

So tired... skipped work today because i was so so close. But here I am. Checkpoint reached. Got a working prototype of wxdarcs submitted to the list.

Had a long post detailing all the issues I went through, but somehow got lost. That's the trouble with these web tools. You lose stuff so easily.

Tests seem to run slow in gui mode. Can't figure out why.

Bed... at last, I may go to bed.

And go to work tomorrow. Looking forward to doing anything other than my hobby...

another dateparser error

Tommy Pettersson observed today that the dateparser.sh test was failing on "4 score, 7 years ago". Nothing wrong with the date parser itself. Apparantly, his computer doesn't like dates from 87 years back. Mine doesn't like them from 105 years back. But parsing score of years, as well as expressions like "tea time", "bed time" and "proper bed time" is completely silly and pointless, so I submitted some patches to remove this functionality. Functionality I put in on a whim. Geez. I think half of my patches to darcs are corrections to the other half of my patches.

Tommy Pettersson observed today that the dateparser.sh test was failing on "4 score, 7 years ago". Nothing wrong with the date parser itself. Apparantly, his computer doesn't like dates from 87 years back. Mine doesn't like them from 105 years back. But parsing score of years, as well as expressions like "tea time", "bed time" and "proper bed time" is completely silly and pointless, so I submitted some patches to remove this functionality. Functionality I put in on a whim. Geez. I think half of my patches to darcs are corrections to the other half of my patches.

another dateparser error

no start twice

Yippee! I found it! And this tiny moment of joy has made the whole miserable sniffly headachy weekend (got a cold) worth it.

I ferreted out the problem by making a small wxhaskell demonstrator and trying to figure out what Control.Exception.bracket is all about. As far as I can tell, it doesn't look like more than just a >>= c >>= b, so we can forget about it. The problem is more to do with the start function. Here's what my tester boiled down to:

main = createGui ""

createGui txt = 
 do putStrLnAndFlush $ "opening " ++ txt
    start $ gui txt
    putStrLnAndFlush $ "closing " ++ txt
        
gui txt = 
 do f <- frame [text := "Howdy " ++ txt ]
    closeBt <- button f [ text := "Close" 
                        , on command := close f ]
    spawnBt <- button f [ text := "Spawn"
                        , on command := createGui $ txt ++ "." 
                        ]
    set f [ layout := margin 5 $ column 2 [ widget closeBt
                                          , widget spawnBt ] ]
    putStrLnAndFlush $ "gui created " ++ txt

putStrLnAndFlush x = putStrLn x >> hFlush stdout

This demonstrator allows us to replicate the issue I was having with wxDarcs. That is, you click on the spawn button to create a second window, and if you close the second window, it does not seem to come back. Exactly like yesterday, if you close the first window, you get a bus error. All you need to do to fix this is to realise that start indeed performs some kind of voodoo, and this voodoo is something you may only perform once. It was one of my theories, but I had written some code into Record.lhs to not call start, but it didn't seem to work. Maybe I had just confused myself or something. So, the simple fix is just to change the code so it looks more like this:

main = start $ createGui ""

createGui txt = 
 do putStrLnAndFlush $ "opening " ++ txt
    gui txt
    putStrLnAndFlush $ "closing " ++ txt

This way, when you call that createGui function from within the gui, you're not calling that start function a second time. Woohoo! Then maybe we're not so far from getting wxDarcs out the door so that other people can hack on it and so that I can start working on other stuff.

Yippee! I found it! And this tiny moment of joy has made the whole miserable sniffly headachy weekend (got a cold) worth it.

I ferreted out the problem by making a small wxhaskell demonstrator and trying to figure out what Control.Exception.bracket is all about. As far as I can tell, it doesn't look like more than just a >>= c >>= b, so we can forget about it. The problem is more to do with the start function. Here's what my tester boiled down to:

main = createGui ""

createGui txt = 
 do putStrLnAndFlush $ "opening " ++ txt
    start $ gui txt
    putStrLnAndFlush $ "closing " ++ txt
        
gui txt = 
 do f <- frame [text := "Howdy " ++ txt ]
    closeBt <- button f [ text := "Close" 
                        , on command := close f ]
    spawnBt <- button f [ text := "Spawn"
                        , on command := createGui $ txt ++ "." 
                        ]
    set f [ layout := margin 5 $ column 2 [ widget closeBt
                                          , widget spawnBt ] ]
    putStrLnAndFlush $ "gui created " ++ txt

putStrLnAndFlush x = putStrLn x >> hFlush stdout

This demonstrator allows us to replicate the issue I was having with wxDarcs. That is, you click on the spawn button to create a second window, and if you close the second window, it does not seem to come back. Exactly like yesterday, if you close the first window, you get a bus error. All you need to do to fix this is to realise that start indeed performs some kind of voodoo, and this voodoo is something you may only perform once. It was one of my theories, but I had written some code into Record.lhs to not call start, but it didn't seem to work. Maybe I had just confused myself or something. So, the simple fix is just to change the code so it looks more like this:

main = start $ createGui ""

createGui txt = 
 do putStrLnAndFlush $ "opening " ++ txt
    gui txt
    putStrLnAndFlush $ "closing " ++ txt

This way, when you call that createGui function from within the gui, you're not calling that start function a second time. Woohoo! Then maybe we're not so far from getting wxDarcs out the door so that other people can hack on it and so that I can start working on other stuff.

no start twice

radical departure for wxDarcs

This morning before getting up, I had the sudden thought that I was aiming for something truly pointless in the previous incarnations of wxDarcs. The story goes that wxDarcs was supposed to provide you a change-oriented view your repository instead of a task-oriented one. That is, instead of deciding "I want to do darcs send" and then choosing your patches, you first select your patches and then tell the gui "I want to send these guys".

I realised that there a few headaches that I did not really want to deal with, and the task of building a darcs gui was getting more and more complicated as the days went on. All sorts of stuff I hadn't thought of, like for instance, when you do a darcs send, the only patches the console interface shows you are the ones that don't already exist in the remote repository. You don't get that with the change-oriented view. And also, the business of splitting the commands up so that they are only available in the right contexts would be really annoying to deal with: for example, at first, I only had the Revert in the 'Changes tab, and the Record option in the Whatsnew tab. But that's annoying, because you have to think to go to the Changes tab in order to get a Revert button. What if your brain is hardwired in task-oriented mode? What if you're saying to yourself, ok, I want to send in my changes? You shouldn't have to think, "oh, I need to go look at the changes tab first".

So the original goal was to resurrect the wxhaskell code, and I'm now going to aim more towards that direction. Well... in fact, that's already been long done and that patches are waiting acceptance. My new direction is to make more use of the original wxhaskell code. For instance, when you click on the Record button, all my gui code does is execute the record command, which launches its very own GUI. None of this select-your-patch-and-then-your-operation nonsense.

Here is what it looks like now. It's the same story: you first start out with an empty repository viewer:


When you click open, you get the stardard directory-choosing dialogue from your operating system. You choose darcs repo, what you get is this interface. Notice that I now use the tree widget I had for Whatsnew:


I think this is a clear improvement. Simpler code, simpler user interface, much more down to earth and direct. No more silly tabs. And now, if you click on the Record button, you get the original David Roundy (I assume) gui for Record, this being a result of me giving up on the change-oriented approach to darcs. Oh, and another thing I managed to implement is this business of the --gui flag. Now, there is no distinct wxDarcs main module. If you call darcs with just the --gui flag, or if you call the program as wxDarcs (i stuck a cp darcs wxDarcs in the Makefile), you get the wxDarcs standalone interface.

But here's a major piece of bad news. A huge blocker, and clear evidence that I don't actually know crap about haskell or programming or computers. When I tried to link my buttons to commands is that the commands refuse to relinquish their locks when you close the guis which are associated to them. This means, for example, that you can't Record some stuff, and then Send it, because darcs is always stuck with a lock from Record. It doesn't matter whether you close the window by cancelling or recording, it simply does not come back. Plus, when you close all the windows of wxDarcs, you get a bus error. Yipee.

Totally stumped here. It's as if we never make it out of the function for the inner gui, even when we close the window. The whole record command is wrapped with a withRepoLock, and for some reason, you never get to the closing end of that bracket. Yet you do when you're calling the record gui from the command line. So confused.

This morning before getting up, I had the sudden thought that I was aiming for something truly pointless in the previous incarnations of wxDarcs. The story goes that wxDarcs was supposed to provide you a change-oriented view your repository instead of a task-oriented one. That is, instead of deciding "I want to do darcs send" and then choosing your patches, you first select your patches and then tell the gui "I want to send these guys".

I realised that there a few headaches that I did not really want to deal with, and the task of building a darcs gui was getting more and more complicated as the days went on. All sorts of stuff I hadn't thought of, like for instance, when you do a darcs send, the only patches the console interface shows you are the ones that don't already exist in the remote repository. You don't get that with the change-oriented view. And also, the business of splitting the commands up so that they are only available in the right contexts would be really annoying to deal with: for example, at first, I only had the Revert in the 'Changes tab, and the Record option in the Whatsnew tab. But that's annoying, because you have to think to go to the Changes tab in order to get a Revert button. What if your brain is hardwired in task-oriented mode? What if you're saying to yourself, ok, I want to send in my changes? You shouldn't have to think, "oh, I need to go look at the changes tab first".

So the original goal was to resurrect the wxhaskell code, and I'm now going to aim more towards that direction. Well... in fact, that's already been long done and that patches are waiting acceptance. My new direction is to make more use of the original wxhaskell code. For instance, when you click on the Record button, all my gui code does is execute the record command, which launches its very own GUI. None of this select-your-patch-and-then-your-operation nonsense.

Here is what it looks like now. It's the same story: you first start out with an empty repository viewer:


When you click open, you get the stardard directory-choosing dialogue from your operating system. You choose darcs repo, what you get is this interface. Notice that I now use the tree widget I had for Whatsnew:


I think this is a clear improvement. Simpler code, simpler user interface, much more down to earth and direct. No more silly tabs. And now, if you click on the Record button, you get the original David Roundy (I assume) gui for Record, this being a result of me giving up on the change-oriented approach to darcs. Oh, and another thing I managed to implement is this business of the --gui flag. Now, there is no distinct wxDarcs main module. If you call darcs with just the --gui flag, or if you call the program as wxDarcs (i stuck a cp darcs wxDarcs in the Makefile), you get the wxDarcs standalone interface.

But here's a major piece of bad news. A huge blocker, and clear evidence that I don't actually know crap about haskell or programming or computers. When I tried to link my buttons to commands is that the commands refuse to relinquish their locks when you close the guis which are associated to them. This means, for example, that you can't Record some stuff, and then Send it, because darcs is always stuck with a lock from Record. It doesn't matter whether you close the window by cancelling or recording, it simply does not come back. Plus, when you close all the windows of wxDarcs, you get a bus error. Yipee.

Totally stumped here. It's as if we never make it out of the function for the inner gui, even when we close the window. The whole record command is wrapped with a withRepoLock, and for some reason, you never get to the closing end of that bracket. Yet you do when you're calling the record gui from the command line. So confused.

radical departure for wxDarcs

three tabs

Merged a good chunk of code together tonight, and combined two of the user interfaces. This is what wxDarcs looks like now. When you first open it, you get a single tab with a bunch of disabled buttons:


Hopefully, it should obvious enough that you need to open a repository. When you do, the interface gets a little fancier:


The two tabs, "Whatsnew" and "Patches" are the same as yesterday.

All of the buttons now do something, though not something very useful. They display the following dialogue box:


I'm hoping that some of these commands won't be too difficult to implement. It should consist mostly of de-anonymising the business end of the darcs commands. For example, the Record command calls with_selected_changes_to_files with a bunch of arguments and a huge lambda term starting with \ (skipped,chs) ->. The idea is that the anonymous function is supposed to be run on the whatever patches the user selects via the SelectChanges.lhs code. It seems like we could assign a name to this lambda term, say, something like "record_job" and invoke that from the standalone GUI.

Merged a good chunk of code together tonight, and combined two of the user interfaces. This is what wxDarcs looks like now. When you first open it, you get a single tab with a bunch of disabled buttons:


Hopefully, it should obvious enough that you need to open a repository. When you do, the interface gets a little fancier:


The two tabs, "Whatsnew" and "Patches" are the same as yesterday.

All of the buttons now do something, though not something very useful. They display the following dialogue box:


I'm hoping that some of these commands won't be too difficult to implement. It should consist mostly of de-anonymising the business end of the darcs commands. For example, the Record command calls with_selected_changes_to_files with a bunch of arguments and a huge lambda term starting with \ (skipped,chs) ->. The idea is that the anonymous function is supposed to be run on the whatever patches the user selects via the SelectChanges.lhs code. It seems like we could assign a name to this lambda term, say, something like "record_job" and invoke that from the standalone GUI.

three tabs

wxDarcs widget progress

More gui code coming together. It's really weird. I actually very much dislike working on graphical interfaces (maybe), but I spend so much time working on them and writing about them that you'd think i did it for fun or something. Maybe just a desire for things to be correct, but this kind of stuff is so outside of my zone of competence.

Anyway, so here's what I have so far. When you first launch wxDarcs, you get two buttons:


When you click on "Open repository", you get a standard directory selection dialogue:


If you select a folder, it opens up the repository viewer, which has two tabs, an unrecorded patches tab, and a recorded patches tab. Here are the unrecorded patches (what's new) :


And the recorded patches (Patches) -- this is implemnted wrong, but I don't care; my job here is to get the prototype running, remember?


That's all. Remember that the buttons don't actually do anything.

Also, the 'pull' command does not enter this model... maybe you select pull from a menubar or a toolbar, and it adds a new tab. Maybe it opens a new window, or something.

Now, I had some worries last night about keeping the patch display up to date. To keep things simple and prevent things from going horribly wrong, I make the following two recommendations:

1. all commands should cause the repository gui to reload complete, thus displaying the new set of what's new and recorded patches
2. only one repository may be open at a time

This will be pitifully unsophisticated, very far from what I first proposed in my mail. I'm really hoping that this getting the ball rolling will lead us to a nice powerful GUI for darcs, one day.

More gui code coming together. It's really weird. I actually very much dislike working on graphical interfaces (maybe), but I spend so much time working on them and writing about them that you'd think i did it for fun or something. Maybe just a desire for things to be correct, but this kind of stuff is so outside of my zone of competence.

Anyway, so here's what I have so far. When you first launch wxDarcs, you get two buttons:


When you click on "Open repository", you get a standard directory selection dialogue:


If you select a folder, it opens up the repository viewer, which has two tabs, an unrecorded patches tab, and a recorded patches tab. Here are the unrecorded patches (what's new) :


And the recorded patches (Patches) -- this is implemnted wrong, but I don't care; my job here is to get the prototype running, remember?


That's all. Remember that the buttons don't actually do anything.

Also, the 'pull' command does not enter this model... maybe you select pull from a menubar or a toolbar, and it adds a new tab. Maybe it opens a new window, or something.

Now, I had some worries last night about keeping the patch display up to date. To keep things simple and prevent things from going horribly wrong, I make the following two recommendations:

1. all commands should cause the repository gui to reload complete, thus displaying the new set of what's new and recorded patches
2. only one repository may be open at a time

This will be pitifully unsophisticated, very far from what I first proposed in my mail. I'm really hoping that this getting the ball rolling will lead us to a nice powerful GUI for darcs, one day.

wxDarcs widget progress

standalone gui

Had some trouble in the beginning with the standalone gui - it seemed to be calculating every single patch in the repository or something, not just the unrecorded changes. Don't really understand how everything works underneath, but using withRepoLock fixed the issue.

Here is a view of the standalone gui so far:



Doesn't look like much different, but notice the buttons on the bottom. The idea here is that the standalone gui is something you launch without a repository in mind. Either you choose a repository, or it selects the previous one you loaded (we can talk about this some more). It presents you with a list of unrecorded modifications, as well as a list of patches in the repo. These will likely be in two seperate tabs, each with its own set of buttons. Only the first tab is implemented, and even that is not complete. For instance, the buttons are not yet active.

I think i'm starting to get bored with this project and might think about looking for a new hobby. I dunno. All this gui coding stuff is tedious, makes it feel more like work than play. We'll see. Maybe some random burst of inspiration will strike. But I'll at least aim to get a minimal version of this standalone gui running, and send it as a patch. Maybe once it's out the door, the joyfulness of hobby hacking will come back on its own. Or maybe going to FOSDEM will help.

Had some trouble in the beginning with the standalone gui - it seemed to be calculating every single patch in the repository or something, not just the unrecorded changes. Don't really understand how everything works underneath, but using withRepoLock fixed the issue.

Here is a view of the standalone gui so far:



Doesn't look like much different, but notice the buttons on the bottom. The idea here is that the standalone gui is something you launch without a repository in mind. Either you choose a repository, or it selects the previous one you loaded (we can talk about this some more). It presents you with a list of unrecorded modifications, as well as a list of patches in the repo. These will likely be in two seperate tabs, each with its own set of buttons. Only the first tab is implemented, and even that is not complete. For instance, the buttons are not yet active.

I think i'm starting to get bored with this project and might think about looking for a new hobby. I dunno. All this gui coding stuff is tedious, makes it feel more like work than play. We'll see. Maybe some random burst of inspiration will strike. But I'll at least aim to get a minimal version of this standalone gui running, and send it as a patch. Maybe once it's out the door, the joyfulness of hobby hacking will come back on its own. Or maybe going to FOSDEM will help.

standalone gui