short day (reg 5h)

Edit 23:16 - Argh! This post was meant for koweynlg, my daily work diary. Not so much for public consumption (like koweycode), but public to keep me honest. Sorry for the noise (and the meta noise).

Got here at 10h, leaving at 18h; various tea and cake breaks in between. Almost done with the REG stuff. Got my tri-text framework setup (more and more scripts, some of them throwaway). I am very grateful for the automation, am thanking past-eric (of 1 week ago) for making the results file generator. Trying to do this by hand [what was I thinking] would have suicide.

Back to reading Grosz and Sidner.

More REG stuff tomorrow. Not done yet.

Edit 23:16 - Argh! This post was meant for koweynlg, my daily work diary. Not so much for public consumption (like koweycode), but public to keep me honest. Sorry for the noise (and the meta noise).

Got here at 10h, leaving at 18h; various tea and cake breaks in between. Almost done with the REG stuff. Got my tri-text framework setup (more and more scripts, some of them throwaway). I am very grateful for the automation, am thanking past-eric (of 1 week ago) for making the results file generator. Trying to do this by hand [what was I thinking] would have suicide.

Back to reading Grosz and Sidner.

More REG stuff tomorrow. Not done yet.

short day (reg 5h)

native speakers wanted

Sorry, this is a little off-topic for koweycode, but we would be interested to have some native speakers participating in a little experiment.

All you have to do is to read some encyclopaedic texts and plug some stuff into drop-down-boxes along the way. There are NO WRONG ANSWERS. We want to see your answers and to learn from them. It only takes a few minutes (but you can do as much of it as you want).

We are now running the second instalment of an experiment in which we ask people to select referential expressions (REs) that refer to the main subject in the context of a simple encyclopaedic text. The idea is to investigate to what extent people agree when choosing REs. The experiment is designed as a multiple choice task, where REs can be selected from a menu. The texts are short and can usually be done in under a minute.

We would like to ask any native speakers of English who have a few minutes to spare to help us complete the experiment. It would be great if participants could do at least three texts, but you can do as many as you like.

There is more information on the experiment website. To participate, simply read the instructions and then click on the 'start experiment' button at the bottom of the page:

http://www.nltg.brighton.ac.uk/home/Anja.Belz/CMSR

Any non-native speakers who would like to try out the experiment can do so at this alternative website:

http://www.nltg.brighton.ac.uk/home/Anja.Belz/TESTDRIVE

We would be very grateful for any feedback, comments and suggestions.
Many thanks for your time,

Anja Belz

Regretfully, this has not been coded up in Haskell. But surely that is forgivable :-)

Sorry, this is a little off-topic for koweycode, but we would be interested to have some native speakers participating in a little experiment.

All you have to do is to read some encyclopaedic texts and plug some stuff into drop-down-boxes along the way. There are NO WRONG ANSWERS. We want to see your answers and to learn from them. It only takes a few minutes (but you can do as much of it as you want).

We are now running the second instalment of an experiment in which we ask people to select referential expressions (REs) that refer to the main subject in the context of a simple encyclopaedic text. The idea is to investigate to what extent people agree when choosing REs. The experiment is designed as a multiple choice task, where REs can be selected from a menu. The texts are short and can usually be done in under a minute.

We would like to ask any native speakers of English who have a few minutes to spare to help us complete the experiment. It would be great if participants could do at least three texts, but you can do as many as you like.

There is more information on the experiment website. To participate, simply read the instructions and then click on the 'start experiment' button at the bottom of the page:

http://www.nltg.brighton.ac.uk/home/Anja.Belz/CMSR

Any non-native speakers who would like to try out the experiment can do so at this alternative website:

http://www.nltg.brighton.ac.uk/home/Anja.Belz/TESTDRIVE

We would be very grateful for any feedback, comments and suggestions.
Many thanks for your time,

Anja Belz

Regretfully, this has not been coded up in Haskell. But surely that is forgivable :-)

native speakers wanted

darcs 2 at last!

I'm sure you've all seen David's announcement: darcs 2.0.0 is out!

what's good

In short, darcs 2.0 is safer and faster.

Particularly, the dreaded exponential-time merge bug has now been largely resolved. Let me say it more carefully: while it may still be possible to run into exponential time merges, our improvements to conflict-handling should make it considerably less common. We hope that nobody ever runs into such a situation in practice.

Other key points are improved the hashed inventory and pristine cache which darcs more robust (you no longer have to worry about third party tools like Eclipse or Unison messing things up by mucking around with darcs internals), the ssh-connection mode which speeds up SSH-issues a lot and kills the typing-your-password-ten-million-times issue dead (at most you'll have to type it in twice).

what's bad

On the one hand, darcs 2.0.0 should be much smoother and faster for most users. On the other hand, people with large repositories (e.g. GHC-sized) might find certain operations to be somewhat slower. David does not (yet) have ideas on how to make things better for such users, and is even recommending them to switch to something else. If you've got a repository of darcs' size (over 5000 patches, 6 years, 131 contributors) or smaller, you should continue using darcs, because we still think it works better: we're still the only ones around to offer deep cherry picking... something which we think would be hard to do without radically changing the way other VCSes work. If you would like to prove us wrong, please do so and we would be most grateful!

Also, taking advantage of darcs 2 will require you to upgrade your repository to the darcs-2 format (see darcs convert), which unfortunately, is not compatible with older versions of darcs. People with new repositories should definitely start using this format. People with old repositories should probably do so at the earliest convenient moment, although this means your users will have to upgrade. Please switch to the new format. It will make everybody's lives easier.

The final piece of bad news: we're going to have to shift to a lighter weight development model, something which puts less strain on David and the rest of the contributors. The consequences are that patches might get less review [one maintainer and not two], and that you'll be seeing less of David on the mailing lists. The good news in the bad news is that our lighter weight development model is now being supported by increased automation of the administrative stuff. For example, our bug tracker is now integrated with the darcs repository so that it automatically knows when a ticket has been resolved by a patch. This increased automation gives us extra rigour and more time to think about making darcs better. The only thing we need is more of us. If you want a place to hone your Haskell, Perl or C... or if you think you know a thing or two about user interfaces, please spend some time with us.

to sum up...

Have you been hesitating to try darcs out? Well, now is a good time to do so, as our killer bugs have been fixed as well as the kind of minor nuisances that get most of us. Or... are you looking for something to work on? Uncle David needs you!

[note: Thanks to David Roundy for comments on a draft of this post]

I'm sure you've all seen David's announcement: darcs 2.0.0 is out!

what's good

In short, darcs 2.0 is safer and faster.

Particularly, the dreaded exponential-time merge bug has now been largely resolved. Let me say it more carefully: while it may still be possible to run into exponential time merges, our improvements to conflict-handling should make it considerably less common. We hope that nobody ever runs into such a situation in practice.

Other key points are improved the hashed inventory and pristine cache which darcs more robust (you no longer have to worry about third party tools like Eclipse or Unison messing things up by mucking around with darcs internals), the ssh-connection mode which speeds up SSH-issues a lot and kills the typing-your-password-ten-million-times issue dead (at most you'll have to type it in twice).

what's bad

On the one hand, darcs 2.0.0 should be much smoother and faster for most users. On the other hand, people with large repositories (e.g. GHC-sized) might find certain operations to be somewhat slower. David does not (yet) have ideas on how to make things better for such users, and is even recommending them to switch to something else. If you've got a repository of darcs' size (over 5000 patches, 6 years, 131 contributors) or smaller, you should continue using darcs, because we still think it works better: we're still the only ones around to offer deep cherry picking... something which we think would be hard to do without radically changing the way other VCSes work. If you would like to prove us wrong, please do so and we would be most grateful!

Also, taking advantage of darcs 2 will require you to upgrade your repository to the darcs-2 format (see darcs convert), which unfortunately, is not compatible with older versions of darcs. People with new repositories should definitely start using this format. People with old repositories should probably do so at the earliest convenient moment, although this means your users will have to upgrade. Please switch to the new format. It will make everybody's lives easier.

The final piece of bad news: we're going to have to shift to a lighter weight development model, something which puts less strain on David and the rest of the contributors. The consequences are that patches might get less review [one maintainer and not two], and that you'll be seeing less of David on the mailing lists. The good news in the bad news is that our lighter weight development model is now being supported by increased automation of the administrative stuff. For example, our bug tracker is now integrated with the darcs repository so that it automatically knows when a ticket has been resolved by a patch. This increased automation gives us extra rigour and more time to think about making darcs better. The only thing we need is more of us. If you want a place to hone your Haskell, Perl or C... or if you think you know a thing or two about user interfaces, please spend some time with us.

to sum up...

Have you been hesitating to try darcs out? Well, now is a good time to do so, as our killer bugs have been fixed as well as the kind of minor nuisances that get most of us. Or... are you looking for something to work on? Uncle David needs you!

[note: Thanks to David Roundy for comments on a draft of this post]

darcs 2 at last!

wxHaskell 0.10.3 is out!

As you may have noticed in Jeremy's announcement, wxHaskell 0.10.3 is now available for download. This version offers the following key improvements over 0.9.4:

• Support for Unicode builds of wxWidgets
  
• Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 retained if
  you compile from source)
  
• Support for building with GHC 6.6.x and 6.8.x
  
• Parts of wxHaskell are now built with Cabal
  
• Profiling support
  
• Smaller generated binary sizes (using --split-objs)

At the moment, wxHaskell works with wxWidgets 2.6 (the previous stable release, still widely available). But we're working to get you wxWidgets 2.8 support as soon as we can.

In the meantime, here's a screenshot of the wxFruit paddle-ball example running on my Mac. (Thanks to shelarcy for putting up the package!)


This was painlessly installed with the help of cabal-install. You don't have to use cabal-install -- the wxHaskell sourceforge site includes binaries -- but it may make your life easier for dealing with dependencies. The only caveat you might want to know about when using Cabal to install wxHaskell and its companion libraries are that wxcore should be installed as root, i.e. sudo cabal install wxcore.

As you may have noticed in Jeremy's announcement, wxHaskell 0.10.3 is now available for download. This version offers the following key improvements over 0.9.4:

• Support for Unicode builds of wxWidgets
  
• Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 retained if
  you compile from source)
  
• Support for building with GHC 6.6.x and 6.8.x
  
• Parts of wxHaskell are now built with Cabal
  
• Profiling support
  
• Smaller generated binary sizes (using --split-objs)

At the moment, wxHaskell works with wxWidgets 2.6 (the previous stable release, still widely available). But we're working to get you wxWidgets 2.8 support as soon as we can.

In the meantime, here's a screenshot of the wxFruit paddle-ball example running on my Mac. (Thanks to shelarcy for putting up the package!)


This was painlessly installed with the help of cabal-install. You don't have to use cabal-install -- the wxHaskell sourceforge site includes binaries -- but it may make your life easier for dealing with dependencies. The only caveat you might want to know about when using Cabal to install wxHaskell and its companion libraries are that wxcore should be installed as root, i.e. sudo cabal install wxcore.

wxHaskell 0.10.3 is out!