Rogach on Scala

I began to become quite enamored with Haskell recently. At the very least, even if you can't use it on your current projects - because of the boss, because of legacy code, or because you just can't understand it well enough - you can always use it as an endless source of brain-teasers and puzzles. Also, since I'm recently switched to XMonad , at least some knowledge of haskell is a must. By the way, I'm extremely happy with XMonad, but that is a theme for a separate blog post :) Currently, I'm exploring various typeclasses ( State , Reader , Arrow , etc) and sometimes try to code some small snippets using them. For example, to practice using State monad, I implemented a method to extract a tree from graph using  DFS . Obviously, in such operation you need to maintain set of visited nodes somewhere, thus State seems to be a good fit. Here's the code in Haskell, and the same code in Scala (written in more "traditional" style): import qualifie...

A while back I tried (and succeeded) compiling Scala 2.9.2 with increased limit on tuples. Some time has passed, Scala 2.10 came out, and due to the recent advent of macros there could be some possibility in lifting the limit entirely - there is a thorough discussion on mailing list, but it doesn't seem to be anywhere close. So, for time being, I updated my duct-tape solution for Scala 2.10. The following script is the automated solution for generating new scala distribution with bigger tuples: git clone git://github.com/scala/scala.git scala-tuplicity cd scala-tuplicity git checkout v2.10.0 export ANT_OPTS="-Xmx8192m -Xss25M -Xms4096M -XX:MaxPermSize=512M" VERS="-Dbuild.release=true -Dversion.number=2.10.0-tuplicity -Dmaven.version.number=2.10.0-tuplicity" ant build sed -i 's/\(val MaxTupleArity, .*\) 22/\1 55/' src/reflect/scala/reflect/internal/Definitions.scala ant build sed -i 's/22/55/' src/library/scala/runtime/ScalaRunTime.scala ant...

Scala enforces upper limit on number of elements tuple can have. And if you try to go over that limit, you are greeted with friendly compiler message: "Implementation restriction...". At the first sight, that seems quite logical - after all, if in your code you need to write "tup._69", you are surely in a lot of trouble. But it is not so simple! The same restriction exists for number of function arguments, and, more importantly, number of elements in case classes. It just so happens that over time, people created amazing libraries that allow us to do truly spectacular things. Incidentally, sometimes those libraries require case classes with more arguments. One example of such a library is ScalaQuery, a library which enables us to write type-safe database queries. It maps tuples and case classes to database rows, which, combined with 22-limit, effectively restricts your database tables to 22 columns (including id and scaffolding!). I ran into that ...

As many people out there, I read web feeds frequently. Usually, I read them each morning, and then each evening. But some time ago (20 days ago, to be exact), I got flooded by problems, and had to stop reading them. But the feed reader still sat there, accumulating stuff... Over 20 days, it accumulated 3,100 feed items! It took me one full day  to read through them. Just think about it - it is an equivalent of spending 1-2 hours each day just to clean the flood of incoming feed items. Clearly, it had to stop somehow. On the course of my "reading marathon", I noticed that I do not read many feeds (Slashdot, Lifehacker, Habrahabr) "cover-to-cover". Instead, I just look at the headlines - and in most cases (90-95%) dismiss the item without reading, since I'm not interested. So today, I embarked on the quest to clean up my feed list. I deleted the ones, that delivered non-interesting content (0 valuable items in the last 10-15), or were just dead. In the...

Everybody says that Java applets are dead (and there are talks to revive them with JavaFX 2). But it seems they are still not dead, at least from my point of view - since I maintain an applet for one of my customers. Basically, that applet processes .svg  files. And it would be convenient for user just to do double-click on a file and get the applet to start with that file. I solved this problem as follows: applet accepts a parameter in it's launch url, and file association in Windows launches Internet Explorer with the file name as parameter in that url. Here's the code to establish such file association: assoc .svg=SvgGraphicsFile ftype SvgGraphicsFile=C:\Program Files\Internet Explorer\iexplore.exe "www.someplace.ru/index.html?file=" "%1" And this is how I extracted that file name from applet url: // first, in our Applet class, we get the url, from which app was launched val docBase = getDocumentBase() // then, we parse it object Loader { def lo...

Sometimes it is funny to gather some statistics about your activities - how much time you spend reading, how much time you spend programming, etc. There is a Gnome panel app specifically for that purpose - Project Hamster . It does it's job well, but not well enough - it still requires you to manually specify start and end of each task, and I often forget to do that. But why do we need a full-blown app for such simple thing? I really think that we can mine most of the needed information simply by analyzing the focused window properties (actually, just two of them - process, that owns that window, and title of window). For example, when the main window is from "evince" program, then I'm probably reading some book, if it is Emacs or terminal, I'm coding, if Opera - most probably reading feeds. Window title is needed only in specific cases, when you can't differentiate based on the program executable name - sadly, most of python programs fall into this cat...

Sometimes you need to run some code after the subclass initialization - for example, if it is a library class that users extend and you need to check their configuration. The simple solution will be simply to obligate user to call some method in your class after he is done, but it looks redundant, prone to error, and not beautiful overall. It turns out that Scala has no obvious mechanism for this, so I needed to go through some hoops to achieve the needed effect. My idea was to use the DelayedInit trait  (which is deprecated now, sadly) in order to get the initialization bodies for the parent class and subclasses, then execute them in "delayedInit", and count the amount of times it executed. Since I can get the number of superclasses for any given class, I can just execute the after-init code when I've seen enough initialization bodies. I wrapped this into a trait for easier reuse. Note that if your class extends some other non-trait, you'll need to override ...