After posting the zeroth part of this series I realised I hadn’t said
anything about the final goal of this exercise. The first post contained code
for choosing one one-line string (String) out of a list of one-line strings
([String]). What I really want is the ability to choose one item out of a
list of items, where each may render to be multiple lines. It would also be
really cool if an item could be collapsed and expanded in the rendering.
This is the first step in my journey towards these loosely specified
requriements.
Rendering items into strings sounds like pretty-printing to me, so I played
around a little with a few pretty-printing libraries. Finally I settled on
the Wadler/Leijen Pretty Printer (Text.PrettyPrint.Leijen). I didn’t
really have any strong reason for choosing it, beyond that it comes with its
own type class whereas the pretty-printing library that ships with GHC
(Text.PrettyPrint.HughesPJ) doesn’t (though there is a package on
HackageDB with a class for it).
I did the smallest change I could think of to add pretty-printing. First the
module needs to be imported of course:
import Text.PrettyPrint.Leijen
Then I added a function to turn a list of items into a document (Doc) where
each item is pretty-printed on its own line:
Since the Python extensions to Epiphany have been removed from the repository I thought it was high time to start playing with what seems to be the replacement to Python extensions: Seed extensions. The first step is of course to get a version of Epiphany that supports Seed extensions. After a few emails on the mailing list I’ve come to a recipe (I’ve done this twice now on different machines to I’m fairly confident it works). I should probably preface this by saying that I run an up-to-date Arch system, if you run something else you might need to do a bit more, or less if you’re lucky
Make sure the following packages are installedi: libsoup, libwebkit, gnome-common, intltool, libffi
Clone the following Git repositories from git.gnome.org: epiphany-extensions, epiphany, seed, gobject-inspection, gnome-js-common, gir-repository
Decide on a $prefix, i.e. where you want it all installed (I use ~/opt/gnome-trunk). Then export the following environment variables:
Then configure, build and install everything. Use the autogen.sh script to create the configuration, and make sure to pass it prefix=$prefix each time. Some of the modules need extra arguments as well. This is the order and extra arguments I used:
gnome-js-common (--disable-seed --disable-gjs)
seed
gnome-js-common (--disable-gjs)
gobject-introspection
gir-repository
epiphany (--enable-introspection --enable-seed)
epiphany-extensions
After that you can put your extensions in ~/.gnome2/epiphany/extensions/. I have two instances of Epiphany installed, a stable from my distro, and the dev version I built myself. I haven’t managed to run them both side by side, but beyond that there seems to be no bad interaction between them.
You might need a few more packages depending on what desktop environment you use. Those were the packages I needed to add to my machine where I run Gnome and do regular non-Gnome development[back]
I haven’t had much free time lately, which means I haven’t written much
non-work code. The only exception is some experiments with a small piece of
Haskell code using the Vty module. Many moons ago I wrote a small piece
of code that let’s the user choose options from a list in a terminal.
Somewhat similar to what you get using dialog --menu ..., but of course a
lot more limited and less good looking.
Anyway, over the last few weeks I’ve slowly expanded it in a direction that
would be useful if I ever get around to work on yet another of those projects
that so far only exist in my head
I’ve kept the transformations in a stack of patches using quilt, and I
thought I’d write a little about them. Not because I think they are extremely useful or even
good in any way, but more because I really need to get back to writing some
blog posts
This is the zeroth post containing the version I put together when I first
came across Vty. It is an executable program so it starts with the familiar
module Main where
Next comes a few modules that have to be imported:
import Data.Maybeimport Graphics.Vty
importqualified Data.ByteString.Char8 as B
The options are, in this version, represented as a list of strings. For now
it’s enough to have a nonsensical list of unique strings.
options =[(show i)++" Foo"| i <-[0..59]]
The main function is as small as possible, two rows, the first creating an
instance of Vty and the second getting the choice and feeding it into
print.
main =do
vt <- mkVty
getChoice vt options >>=print
Of course one would think that geChoice would be the meat of the code, but
it is also short. After getting the size of the terminal it calls
_getChoice, which is the meat of the code. The reason for this split is
the handling of resize events.
The main part of _getChoice is straight forward, first update the terminal,
then wait for an event, and finally handle the event. Unless the user wants
to exit (pressing enter choses an item, pressing escape exits without a
choice) a recursive call is made to _getChoice with slightly modified
arguments.
Probably the most complicated part is the calculation of the top of the list
of visible items. The idea is that if the list has more items than there are
lines in the terminal then the cursor moves down until the middle line, once
there any down movement will result in the list scrolling up. This continues
until the end of the list is visible, at that point the cursor moves down
towards the last line in the terminal. I doubt that explanation makes sense,
hopefully it’ll be clear to anyone who bothers running the code.
_getChoice vt opts idx sx sy =let_calcTop winHeight listLength idx =max 0 ((min listLength ((max 0 (idx - winHeight `div` 2))+ winHeight))- winHeight)_top =_calcTop sy (length opts) idx
_visible_opts =take sy (drop_top opts)indo
update vt (render _visible_opts (idx -_top) sx)
k <- getEvent vt
case k of
EvKey KDown []->_getChoice vt opts (min(length opts - 1)(idx + 1)) sx sy
EvKey KUp []->_getChoice vt opts (max 0 (idx - 1)) sx sy
EvKey KEsc []-> shutdown vt >>return Nothing
EvKey KEnter []-> shutdown vt >>return(Just $(idx, opts !! idx))
EvResize nx ny ->_getChoice vt opts idx nx ny
_->_getChoice vt opts idx sx sy
The final piece is the code that renders the list. The items of the list are
zipped together with a list of integers. Each such tuple is then rendered
into a line((The reason for the line rendering looking so complicated is that
Vty requires each line to be of equal lenght.)), where the line of the
cursor is highlighted. The resulting list of rendered lines is then folded into
a full image.
I read all my email via IMAP, and send all email via external SMTP servers, but at times it’s really useful to be able to run something like /usr/sbin/sendmail to send an email. Many tools depend on it, for me I want reports on cron jobs and I like using darcs send straight to an email address. For this a full-fledged SMTP server like exim/postfix/sendmail clearly is overkill. First I had a quick look at ssmtp but it only allows for a system-wide configuration file. Ideally I’d like “system-mails” (like cron) to be sent via my ISP while more personal emails should be sent via my Google account. After a suggestion on the Arch mailing list I checked out msmtp and it was exactly what I was looking for.
I created /etc/msmtprc with the following contents:
I then found out that [dcron][3] is severely limited; it doesn’t honour MAILTO in crontabs and it’s not possibly to use anything but /usr/sbin/sendmail to send emails. The lack of support for MAILTO is the deal breaker in this case.
Rather than create a symbolic link I modified fcron’s configuration file, /etc/fcron/fcron.conf, to use /usr/bin/msmtp:
sendmail = /usr/bin/msmtp
I also made sure to stick MAILTO=my.email@myisp.com in the system crontab, using fcrontab -u systab -e.
Then I created the file ~/.msmtprc:
defaults
logfile ~/.msmtp.log
# MyISP
account mysisp
host smtp.myisp.com
from my.email@myisp.com
# google
account google
host smtp.gmail.com
from user@googlemail.com
tls on
tls_certcheck off
auth on
user user@googlemail.com
password MySecretPassword
account default : google
Finally I put MAILTO=user@googlemail.com in my user’s crontab.
At first this I wrote this as a comment on my original post, but it grew a bit too long so I decided to post it like this instead.
@Randal, “Static typing is still effectively a syntax check, not a semantic check though.” Now, I think we might have a different understanding of the word “syntax”. I can guess at yours, but my understanding mirrors what’s on Foldoc, that is syntax determines what is a valid string in a program, in this case it determines where a type declaration/definition/statement goes, but not what type declaration/definition/statement is semantically valid in a particular position in a string. That “what” is very much part of the semantics in my mind, it tells the world (me, other users of my library, the compiler) a part of the intention of a function, it tells how something may be used. I gather you are mostly familiar with type systems like Java so what is clearer to you, this declaration:
int add(int i, int j);
or this declaration:
int add(i, j);
In the former the intent of the function is obvious, it adds integers. In the latter it isn’t, does it handle complex numbers? Does it handle matrices? In dynamic languages you’d have to document it somewhere, but there is no consistency check between code and documentation (maybe there are external tools for that though, but why not use the compiler to check?). You would also have to test that no caller of this function can be tricked into calling add with a non-integer.
Also, though your example of “semantic type checking” in the talk is interesting (I simply don’t know if there are any type systems that could deal with it) you completely skip all the cases where the type system can do the job and where it does save on testing and typing. In these cases you would have a proof relating to your use of types in the program, unit testing can never give that proof it can only show you haven’t disproved it yet
If you remain unconvinced then I strongly urge you to read Tom Moertel’s post on providing safe strings, and the assurance you can achieve by using a strong type system in relation to information flow through your program. The same technique has been used in Darcs (watch the video, the bit relevant for this dicussion starts about 43 minutes in).
I urge you to read Kristian’s blog post (linked to in his comment).
If you want a podcast to listen to there’s episode 62 of Software Engineering Radio where Martin Odersky talks about Scala (a statically typed language built on the JVM).
I’d also like to clear one thing up, I don’t dislike dynamic languages and I don’t think that static languages are inherently better. What I do dislike about your talk is that it’s uninformed, presents very narrow arguments and then draws conclusions that are very general and simply don’t follow from the given arguments.
Finally, I really enjoy FLOSS Weekly. You and Leo are doing a fantastic job on it, but since it is where I first heard of your talk (I suspect Industry Misinterpretations might not get a lot of attention outside the Smalltalk community) I really think you should talk to someone from the FLOSS FP community. Get someone who can explain, much better than me, what a modern, advanced, strong, statically typed language will get you. I only have experience with OCaml and Haskell, and there are others, like Scala, all are FLOSS and hopefully it wouldn’t be too much work to find someone knowledgable who’d be willing to set you straight on the dynamic vs static typing issue. I’d be happy to do what I can to help you find someone, just let me know if you are insterested
So, I’m struggling somewhat with the move to Arch. Not that Arch is
problematic in any way, it seems to be me and my “debianised thinking”.
I noticed that the Vim plugins that were packaged for Arch all install in
system directories and hence are imposed on all users. Not a good thing. So,
inspired by Debian’s vim-addons-manager, I hacked up a solution relying
on pacman. Then I packaged two Vim plugins for Arch. The idea was to do
rather than talk, so it wasn’t until after this that I asked for feedback on
aur-general. Just to have the idea shot down
Anyway, after being presented with an existing solution more inline with “the
Arch way” I decided to try it out. I’ve now subscribed to using
GetLatestVimScripts. Brilliant.
Now I need to convince the author of haskellmode to put it on vim.org
and I really ought to get my packages off AUR.
Well, not the most diplomatic title maybe, but listening to Randal Schwartz’ talk “Dynamic Returns” first made me laugh and then made my fingers itch to write him an email addressing the fallacies he is peddling. Anyway, I wrote this large, rather ranting, blog post but then decided to not publish iti.
Randal, my suggestion to you is that you get someone like Don Stewart on FLOSS Weekly (I believe he is based in Portland as well) to discuss how Haskell’s advanced type system can be harnessed to completely remove whole classes of bugs.
![[Digg]](http://therning.org/magnus/wp-content/plugins/bookmarkify/digg.png)
![[Reddit]](http://therning.org/magnus/wp-content/plugins/bookmarkify/reddit.png)
