Long-standing Bug

Embedded Declarative HTML in C++

2011-11-20T00:00:00+00:00

How about writing that in C++:

Node html
{"html", {{ "lang", "pl" }}, { // tag with attributes
  {"head", { // tag without attributes
    {"title", {
      "Page Title" // text node
    }}
  }},
  {"body", {{ "style", "background-color: #fff;" }}, {
    {"h1", {"Page Title"}},
    {"div", {}} // empty tag
  }}
}};

cout << html;

and getting that:

<html lang="pl">
  <head>
    <title>
      Page Title
    </title>
  </head>
  <body style="background-color: #fff;">
    <h1>
      Page Title
    </h1>
    <div />
  </body>
</html>

Clojure has the Hiccup and Groovy has it's builders for XML/HTML generation. I saw today a presentation with an example of this in Kotlin, with static typing...

I wanted to see if something like this is possible in C++. It turned out that with help of some newest and freshest stuff in C++11 it was pretty straight-forward.

`std::initializer_list`

C++11 introduced the std::initializer_list type which is a neat enhancement to C's intializer lists. C's initializer lists are a way for creating arrays and structs:

int array[] = { 1, 2, 3 };
struct { float a, b; } number = { 0, -1 };

C++'s std::initializer_list is a clever enhancement because it's an runtime object which knows how many elements are in it and are created automatically by the compiler. It's useful in functions and constructors when you want to pass some inlined data structures, for example a function:

int sum(initializer_list<int> numbers) {
  int s = 0;
  // a proper foreach is also a C++11 feature
  for (const int i : numbers) {
    s += i;
  }
  return s;
}

could be used like: sum({1, 2, 3, 4});.

New implementations of STL containers (such as vectors) support that in constructors so you can fill them with data in construction time:

vector<int> nums {1, 2, 3};

Proof'O'Concept

In my humble proof of concept I just extended the use of std::initializer_list. Each node in tree is either:

a text node (constructor with one string arg)
a tag with attributes (each attribute is a pair of name and value) and children (nested nodes, so it's recursive)
a tag without attributes but with children (if a tag is childless you have to pass an empty children list, otherwise it will be treated as a text node)

For each variant there's a different constructor. That's pretty much it. I've pasted a complete gist at the end of this article. Probably the longest and least interesting part is the render() method, but somewhat obligatory to see if the whole thing works at all.

Without macros!

In C++11, solution is straight-forward and maybe even handsome but I am most curious how it could be done in older versions of C++. I think that initializer_lists and other new features of C++11 (lambdas!) made it possible to create more sophisticated internal DSLs than the one presented here. I actually believe it is now possible to implement something like GUI FTW in C++.

The source code will probaly not be embedded in RSS reader. Read it on my site or on gist.github.com.

Another HTML/JavaScript Slideshow Library

2011-09-23T00:00:00+00:00

There's a bunch of them. Here's another one: the Sroo. My main excuse for creating it was to learn some JavaScript and DOM manipulation. It's probably not very new and original but I've combined some features that sounded sane for me:

Slides are not marked by some CSS classes. Rather than that I prefer to use "semantic" tags, like <h1> or <section>.

This actually makes it work well with content-generation programs, like Jekyll.
Prospectus view is used when your screen is to small, in portait orientation or when JavaScript is disabled.
Standard stuff like auto-scaling, navigation using mouse wheel and keyboard.

There's no support for legacy browsers but there's wide support for current browsers (including IE 9). There's actually only one problem with Opera Mobile (as of version 11.10) which just utterly destroys the layout. I believe it's a bug :P. Serious mobile support is yet to come (with touch support).

Like almost everything I do the project is on GitHub. I'm not providing any CSS themes because I'm a pretty awful designer and I don't want to ruin your presentation :D.

Sound Synthesis & Playback in Clojure

2011-06-20T00:00:00+00:00

I've been playing with sound in Clojure lately so I thought I'd document what I've learned.

This tutorial covers generating simple, clean sounds of desired frequency (sines) and accessing Java Sound API (it's not that scary, really). We'll start with nothing and at the end, we'll even play some melody with synthesized sounds :) (no instruments, pre-recorded samples or whatsoever).

Entry level: know where your repl is.

Fast Facts About Sound

Making some noise is in fact moving particles of air and a speaker does that. And we will move the speaker. From perspective of a programmer playing some sound is changing speaker's position over time. Because on computers nothing is continuous, we can manage it's position in concrete moments only. These moments come at constant rate. So we can imagine that playing a sound is actually feeding our speaker with it's position values regularly.

About those moments: Speaker can move back and forth. It's position is relative to some starting position to which we will refer as position zero. Moving speaker forward is increasing it's position and moving backward is decreasing it's position (actually, it can be the other way around but this time we shouldn't care). So, the speaker's position is a number and it's called a sample.

Technicalia of Sound

Sample has fixed size and it's usually 16 bits. Sample size is limiting our minimum and maximum value. We don't have to bother about what these values are (it'll be handled automatically).

Pace at which samples come to a sound system is usually 48000 Hz (Hz [Hertz] means "ticks/samples per second") or 44100 Hz ("Audio CD" quality) and it's called sample rate. Yes, we need to feed our speaker that fast ;).

Know Your Math

Because this tut is about generating sines I have to say what a sine actually is. Sine is the cleanest type of sound possible. It's also the outcome of universally known sin function.

Someone said that every sound can be torn to several sines. So once we can generate one sine we can synthesize any sound. In this tut we'll generate just one at a time ;) .

Every sine played over time has it's frequency f. It's measured just like sample rate, in Hz. Frequency is a weird number, because it's just inverted period (also called term and abbreviated T: time after it repeats itself):

f = 1 / T
T = 1 / f

It means that sine of 1 Hz frequency have 1 s period and sine of 2 Hz frequency have 0.5 s period and so on.

Period is important because we will generate data only for one pass of a sine and play it in a loop (without any loop involved ;) ).

Some Code At Last!

Now we'll jump right into code. As a basis of generating sine we'll use Math/sin function. It generates sine for period of 2π so we have to scale it to desired period.

(defn sine [sample-rate freq]
  (let [term (/ 1 freq)
        samples (* term sample-rate)      ;1
        factor (/ (* 2 Math/PI) samples)] ;2
    (map #(Math/sin (* % factor))         ;3
         (range samples))))

sine function creates a collection of numbers which are values of speaker position over time (successive samples). Explanation for numbered lines:

Amount of samples depends directly on term and sample rate. Sample rate tells how many samples correspond to 1 sec. So if we take a product of term and sample rate we will get the amount of samples for this frequency.
To scale 2π period to our sample count we will multiply every number from (range samples) by factor.
Actual collection generation using Math/sin function.

Every number in returned collection will be in [-1..1] range. We can check that by just invoking sine (tip: test only with large values of frequencies because small frequencies results in very long sequences):

user> (sine 48000 5000)
(0.0 0.6087614290087207 0.9659258262890683 0.9238795325112867
 0.49999999999999994 -0.13052619222005177 -0.7071067811865475
 -0.9914448613738104 -0.8660254037844386 -0.38268343236508956)

Now we get the idea of generating a sine. The rest of this tutorial is actually just technical stuff, but they're essential to get things working.

Audio Formats

To tell the sound system what we want to play we need to agree on some kind of contract on how our sound data will be formatted. This contract (or protocol if you will) is called an audio format. We'll just focus on most used format nowadays.

An audio format in Java is represented by object of AudioFormat class (which lives in javax.sound.sampled, we'll need some more classes from there, just keep that in mind). Objects of this class serve only as metadata so we'll create one, keep it somewhere and pass it around.

(import '(javax.sound.sampled AudioFormat AudioFormat$Encoding))

(def popular-format
  (AudioFormat. AudioFormat$Encoding/PCM_SIGNED ;1: format
                48000 ;   sample rate
                16    ;   bits per sample (2 bytes)
                2     ;   channels: stereo!
                4     ;2: frame size 2*16bits [bytes]
                48000 ;3: frame rate
                false ;4: little endian
                ))

Again, I'll explain the numbered lines:

PCM_SIGNED is a linear signed and uncompressed format, which means that each sample will be a signed integer.

(AudioFormat$Encoding/PCM_SIGNED means PCM_SIGNED static variable in Encoding class which is inner class in AudioFormat.)
Frame is a complete unit of data for each moment in time (data for all channels). So it's size in our uncompressed format is just a number of bytes for every sample multiplied by number of channels.
Frame rate can be different from sample rate but it doesn't make sense this time.
When we have more bytes than one for a sample, order in which we read them matters. It's so-called endianness. Big endian is reading bytes in forward direction, little endian is reading them backwards. My computer is little endian and I'm sympathizing with him.

How To Actually Play Something?

To make our speakers move we need a medium (as in mediation) that will tell speakers what to do for us. This medium is called a line in other places by analogy with lines in mixers. It can be acquired from AudioSystem class using getLine method. There's a more elaborate explanation on mixers and lines so I won't get into much detail.

(import '(javax.sound.sampled AudioSystem DataLine$Info
                              SourceDataLine))
(defn open-line [audio-format]
  (doto (AudioSystem/getLine
         (DataLine$Info. SourceDataLine audio-format))
    (.open audio-format)
    (.start)))

"Getting a line" is actually querying Java's audio system about line that complies to our needs. Query is an instance of DataLine.Info class. SourceDataLine says that we require a line that we can write to. Names of SourceDataLine and TargetDataLine correspond to how audio system sees it so they mean "source" and "target" not for our program but for audio system. Other parameter to DataLine.Info constructor is an audio format.

Next thing after getting a line is opening it and allowing data to flow through it. This is done by open and start methods respectively.

Then, playing a sound is done by invoking method write(byte[] b, int off, int len) which writes len bytes from b starting at index off. Writing will block until all bytes from b are flushed to sound system buffers.

Phew, now we know where we need to get: we'll generate that byte array for particular line.

According To Contract...

Our sine is not quite ready to push it to speakers yet. We need to satisfy audio format that we defined earlier. To do that we will:

Scale values of sine to maximum and minimum values possible for our sample size. We have 16 bits at our disposal which means we have circa +/- 2¹⁵ range (one bit is stolen for sign).
Tear each sample to bytes according to chosen endianness.
Multiply each sample to conform number of channels.
Pack whole sine to byte array.

Scaling

When coming out from sine function our samples have floating-point values from -1 to 1. We need to scale them to signed integers with values from -2^samplesize-1 to 2^samplesize-1-1. So just mulplying by amplitude of 2^samplesize-1 will do the trick. Actual amplitude will be delivered by amplitude function:

(defn amplitude [sample-size]
  (Math/pow 2 (- sample-size 1.1)))

I subtract 1.1 (not 1) from sample size to avoid dangerous inaccuracy when multiplying two floating-point numbers.

Actual scaling will be done in quantize function:

(defn quantize [amplitude value]
  (int (* amplitude value)))

Fragmentation To Bytes

I do reading integers backward and forward like this:

(defn little-endian [size x]
  (for [b (range size)]
    (-> (bit-shift-right x (* 8 b))
        (bit-and 255)
        unsigned-byte)))

(defn big-endian [size x]
  (reverse (little-endian size x)))

Where unsigned-byte is needed to cheat JVM because JVM supports only signed bytes with values from -128 to 127 and we need signed bytes with values in 0..255 range. Blah. So we cheat like this:

(defn unsigned-byte [x]
  (byte (if (> x 127) (- x 256) x)))

This is one thing that I won't explain here :P. It'd be just too big. It's based on how signed and unsigned numbers look internally.

Repeating Data For Each Channel

OK. This will be very lame stereo. We'll just repeat data for each channel and I do it like this: (take frame-size (cycle bytes)). If you wanna you can modify that code (in fact, you should, wink wink, nudge nudge) and incorporate some fancy space-age surround effect.

Gathering It All Together

Whole pipeline is mirrored in sine-bytes function with each of these steps represented by mapping a function on a collection returned by it's predecessor:

(defn sine-bytes [format freq]
  (let [{:keys [sampleSizeInBits frameSize
                sampleRate bigEndian]} (bean format)
        sample-size (/ sampleSizeInBits 8)
        ampl (amplitude sample-size)
        tear (if bigEndian big-endian little-endian)]
    (->> (sine sampleRate freq)
         (map (partial quantize ampl))    ;1
         (map (partial tear sample-size)) ;2
         (map cycle)                      ;3
         (map (partial take frameSize))   ;3
         (apply concat)                   ;A
         byte-array)))                    ;4

Numbers in comments corresponds to points mentioned before. Line 'A' is responsible for flattening the list of lists to a single list. Output of sine-bytes is what a line needs.

Agent

I've promised that there will be no loop so here it is: whole playing thingy will be handled by an agent. State of our agent will look like this:

{:line    line to write to
 :playing are we are playing or not
 :data    byte array with sound data}

Setting sine data of desired freq will be done by recalc-data:

(defn recalc-data [{:keys [line] :as state} freq]
  (assoc state :data (sine-bytes (.getFormat line) freq)))

For most of the time of agent's life, play-data will run (actually making the noise):

(defn play-data [{:keys [line data playing] :as state} agent]
  (when (and line data playing)
    (.write line data 0 (count data)) ;1
    (send-off agent play-data agent)) ;2
  state)

play-data will write whole data to the line [1], and send itself to agent to play it again [2] (here's how there's no loop but there's a loop). Turns out, agents are nice way to model such continuous I/O asynchronously. We'll start and pause playing by these fns:

(defn pause [agent]
  (send agent assoc :playing false)
  (doto (:line @agent)
    .stop .flush))

(defn play [agent]
  (.start (:line @agent))
  (send agent assoc :playing true)
  (send-off agent play-data agent))

pause is stopping the line to pause immediatly when called. Without this, pause would take effect after whole buffer is played. flush is invoked to flush anything that's left in sound system buffers.

I use send-off to play-data because it's a blocking operation.

Two final fns will automate creating fresh agent and changing frequency on the fly:

(defn change-freq [agent freq]
  (doto agent
    pause
    (send recalc-data freq)
    play))

(defn line-agent [line freq]
  (let [agent (agent {:line line})]
    (send agent recalc-data freq)
    (play agent)))

Testing Section Without Any Interesting Title

Now we can test it. Lets create a line agent playing some nice bass tone.

user> (def a (line-agent (open-line popular-format) 60))

If you don't have a subwoofer or good headphones you'd like to increase the frequency to hear anything:

user> (change-freq a 200)

Also, we can test pausing and replaying the sound.

user> (pause a)
user> (play a)

If there's nothing coming out from speakers or some exception happened try changing audio format, my guesses would be toggling endianness and changing both rates to 44100.

Appendix A: Melody

Maybe simple continuous sound is boring? Let's play a melody! :)

The simplest notation for music that I came up with is just a pair of tone and duration. So a melody is just a sequence of those.

(def mountain-king
  [[0 1] [2 1] [3 1] [5 1]
   [7 1] [3 1] [7 2]
   [6 1] [2 1] [6 2]
   [5 1] [1 1] [5 2]
   [0 1] [2 1] [3 1] [5 1]
   [7 1] [3 1] [7 1] [12 1]
   [10 1] [7 1] [3 1] [7 1]
   [10 2] [-2 2]])

First number of every pair is a distance in semitones from some base tone. The second is a duration of note relative to some base duration.

Function tone-freq will translate tones to raw frequencies. For the value 99 it's 440 Hz which happens to be so-called pitch standard. To get a note an octave higher or lower just add/subtract 11.

(defn tone-freq [x]
  (-> (Math/pow 2 (/ x 11)) (* 440) (/ 512)))

I won't get into details here... It's just scaling values so it's comfortable to use.

Using Thread/sleep is maybe the lamest timing technique you can get on JVM:

(defn play-melody [agent base-tone base-duration melody]
  (doseq [[tone duration] melody]
    (change-freq agent (tone-freq (+ base-tone tone)))
    (Thread/sleep (* base-duration duration)))
  (pause agent))

Now, lets just play it (the awful clipping needs to be addressed in the nearest possible future):

user> (play-melody a 70 400 mountain-king)

If it's too low, try increasing base-tone. If it's to slow, try decreasing base-duration.

That's all. I've put the code here: https://gist.github.com/1034374. Tell me what you think.

WebGLOL

2011-05-22T00:00:00+00:00

I deviated form my Clojure stuff for a while and made something completely different.

I'm learning OpenGL recently. I've made this silly animation once in Java and wanted to see what it takes to port it to CoffeeScript and WebGL.

Don't Even Wonder If That Means Anything ;-)

Click for full window view

If you see a rectangle only it means you have to get WebGL-enabled browser. It probably won't show up in feed readers because they usually block scripts. If you don't have time to grab a browser, here you have a video of Java version (recording is crappy, I'm new to this also):

You can see the source code just by viewing source of this page or on GitHub (files robots.html and robots.coffee).

Thoughts

I have to say that WebGL is hard. There's a lot you have to know before you draw anything. It's bearable thanks to such great resources as Learning WebGL. I've done that animation only after 3 lessons so pace of this tutorial is really good. One more great thing about it is that examples are using very minimal set of external libraries so it's kind of close to the metal. That animation was made with only addition of CoffeeScript. If you don't want to write everything by hand there's Three.js library.

I also gave CoffeeScript a try and it was worth it. I like that very succinct syntax -- my favorite is anonymous function: it's just -> (compared to JavaScript's function(){}). Some functional programming stuff like list comprehensions and destructuring lists are very welcome too. I don't know much of JavaScript so I can't tell how much writing in CoffeeScript was easier but at least it was more enjoyable :) .

CoffeeScript site make learning it easy. There's even a real-time translator to JavaScript so you can play with language in the browser. What's mentioned almost at the very bottom of document is that you don't have to compile *.coffee to *.js files offline. They can be compiled in the browser. Just include coffee-script.js and tag you scripts with type="text/coffeescript".

Reintroducing GUI FTW & Progress Report

2011-05-16T00:00:00+00:00

I meant this post to be a simple translation of this but some things changed that are worth mentioning.

GUI FTW! is a declarative GUI library. I've borrowed concepts from the Web (the good parts). It's kind of little internal DSL for GUI's. You'll stop manually creating boring repetitive code like:

(doto (JFrame.)
  (.setA "A")
  (.setB "B")
  (.addXxxListener (reify ...))
  ...)

Instead all the boilerplate will be generated by GUI FTW! and you'll never need to look at code like that again.

The before-mentioned good parts of the Web include:

a GUI structure tree (say, like HTML but in Clojure),

[JFrame [*id :main-window]
  [JButton [*id :super-button]]]

Cascade Style Sheets (say, like CSS but in Clojure),

[:main-window] [:title "Window FTW!", :visible true]
[:super-button] [:text "Make something happen!"]

hooking functions into events (say, like JavaScript but in Clojure).
```
[:super-button] [:action++performed (fn [state event] ...)]
```

The bad parts would be using XML and JavaScript literally ;) . Actually, the CSS part look and works like original CSS. It just doesn't have those fancy selectors yet.

SWT FTW! (and swing too...)

[1] Well, for toolkits that follow the same pattern that SWT and Swing do.

[2] Notice that swt is just a wrapper around parse-gui and swt-create).

GUI FTW works with SWT! It's because it's an abstract library. Neither Swing nor SWT stuff are hard-coded. And GUI FTW needs only one function to be implemented to support another toolkit. [1] And those functions are simple as swt-create. [2]

Reusability

What's created with GUI FTW! is always reusable: you'll get a function to instantiate your GUI as many times as you want to. Also, style sheets are list of function-like objects that applies some properties to objects. You can mix different GUI's with different style sheets at runtime freely. This paragraph is here in case of thought that everything is written using macros flew across someone's mind ;) . Actually, I've tried to minimize use of macros.

More?

I've setup a wiki on GitHub and even wrote a tutorial for GUI FTW!. Here's a couple of links you'd likely be interested in:

Project Page
Wiki
Overview
One Tutorial For All (including Swing and SWT)
Online Docs

What's New?

Since the original announcement in Polish I've added couple of things, most important runtime state handling, support for custom "special properties" and for custom "adders" (Swing only).

State in Sane Manner

After creating a widget you'll get a map wrapped with atom which I call "GUI state". It contains data about identifiers, groups, and root of the widget tree. Any other additional data can be added by user. Every event handler fn will get that state as first argument. You can query state like this:

(-> @state :ids :asdf)    ;; get object with id :asdf
(-> @state :groups :qwer) ;; get list of objects in group :qwer
(-> @state :root)         ;; get root, usually the window

When creating widgets you either pass state explicitly or a new one is created for you. You can also decide which parts of window share state and which doesn't.

For more info check out last part of Overview on wiki.

Custom "Adders"

I knew that the day will come that I get hit by some Swing or SWT -specific quirk. So I got an issue :) (Thanks to the Reporter, by the way).

Everything is sweet and honey in Swing when you can use method add to add object to its parent. But there are some cases when Swing designers broke that pattern, most notably the JTabbedPane when you have to use addTab method. So now (only in Swing, SWT has different "parenting" scheme) you can set :*adder property to change default behavior. Adder is just a function that takes 4 arguments [parent parent-style child child-style] and does whatever is needed. For JTabbedPane it would be:

(fn [parent parent-style child child-style]
  (.addTab parent (-> child-style :specials :*tab-title) child))

There's also a case of JScrollPane where the setViewportView method should be used. When you want to have scroll controls on JTextArea, you have to wrap a JScrollPane around it. So it sounds like putting text area into scroll pane. So for this scenario we'd write:

[JScrollPane [:*adder (fn [parent _ child _]
                        (.setViewportView parent child))]
 [JTextArea]]

instead of [JScrollPane [:viewport-view (JTextArea.)]] which breaks flow of the tree (and you can't use other goodness of GUI FTW! for the text area object like styles or grouping).

There's a fancy example using those two.

Why Bother the Programmer?

[3] Good luck with that, I live on 10th floor :P.

If you look at my TODO list you will see that I plan to put those quirks in special style sheet in guiftw.swing. I also consider using this style sheet by default in Swing. If you know any other cases that should be included, please let me know, either by creating an issue, mailing me or throwing a brick at my window. [3]

Restarting in English Mode

2011-05-07T00:00:00+00:00

It's time to admit that starting blog about something in it's early days (like Clojure is) in Polish was a failure. In past (almost) year I've developed belief that community should keep together tight. Creating content in Polish doesn't make sense when all Clojurians use English to exchange their knowledge. It's like intersecting two very small sets (Polish & Clojure) -- intersection elements count is very·very small.

I probably write creepy English. But I don't care more than I'm convinced that the more I write the better I write. It's funny (and you don't have to believe me) that I often think in English (in my creepy version). It happens usually when I'm swearing and programming and those two activities usually happen simultaneously ;).

I don't mean that I'll stop to write in Polish (jak na przykład teraz). I'm just inverting proportions and English will be default. I'll translate some of Polish contents (such as I'll reintroduce GUI FTW! to the World).

Dr Jekyll and His Drugs to Rescue

I am actually using Makeblog again :)

I've abandoned my Makeblog project and use Jekyll instead. Makeblog worked just fine for me but I just don't have time to develop it more (I'd rather put these hours to GUI FTW! project). Jekyll is very well put application. It's elegant, have server and auto modes (so changes in sources are compiled on the fly), and what's also important: it integrates with GitHub pages well (so I keep only sources in my repo). It uses nice Liquid template engine, one of pros is that you can use it not only in layouts but also in posts.

This change can possibly broke atom feed so I'm sorry if you got spammed by my old posts.

So here it is: Long-standing Bug in English. Let's see what will happen :) .

Zdarzenia w GUI FTW

2011-04-04T00:00:00+00:00

Tradycyjnie w Swingu bądź SWT żeby obsłużyć zdarzenie musimy utworzyć nową implementację jakiegoś interfejsu, np. MouseListener a potem go zarejestrować w obiekcie, którego zdarzenia nas interesują:

button.addMouseListener(new MouseListener() {
    public void mouseClicked(MouseEvent event) {
        //... obsługa zdarzenia
    }
    public void mouseEntered(MouseEvent event) {
        //... obsługa zdarzenia
    }
    public void mouseExited(MouseEvent event) {
        //... obsługa zdarzenia
    }
    public void mousePressed(MouseEvent event) {
        //... obsługa zdarzenia
    }
    public void mouseReleased(MouseEvent event) {
        //... obsługa zdarzenia
    }
});

Jeśli obchodzi nas tylko jedno zdarzenie, wygodnie jest dziedziczyć po klasie MouseAdapter, która implementuje wszystkie metody jako puste, wystarczy więc zaimplementować jedną metodę:

button.addMouseListener(new MouseAdapter() {
    public void mouseClicked(MouseEvent event) {
        //... obsługa zdarzenia
    }
});

Jak widać, trzeba się sporo opisać zanim dotrze się do miejsca, gdzie umieści się właściwy kod, nawet w wersji z adapterem. Jeśli jest możliwe napisanie kodu krótszego i przynajmniej tak samo dobrze wyrażającego co chcemy osiągnąć to moim zdaniem warto.

Jak to wygląda w GUI FTW!?

Obsługę zdarzeń wrzucamy do arkuszy stylów. Wygląda to tak jak każda inna właściwość (tekst, kolor, itd.) poza tym, że nazwą właściwości jest specyfikacja zdarzenia a wartością jest funkcja która je obsłuży. Dzięki temu zyskujemy również na wszystkich zaletach arkuszy stylów, np. można obsłużyć zdarzenia z wielu obiektów na raz.

(stylesheet [[:cos :drugie-cos] [:text "Coś!"
                                 <spec-zdarzenia> <funkcja>]])

Specyfikacja zdarzenia

GUI FTW! musi znać dwie rzeczy: nazwę interfejsu *Listener i jedną metodę do zaimplementowania -- nazwę zdarzenia. Trzeba to podać w takiej formie:

<nazwa interfejsu>+<nazwa metody>

Czyli np. mouse+mouse-clicked albo action+action-performed. Odpada dzięki temu spora część zbędnego kodu z pierwszego przykładu. Widać coś jeszcze: np. w mouse+mouse-clicked słowo mouse powtarza się. Ponieważ występuje to dość często dodałem skrót: jeśli napiszemy ++ zamiast + możemy pozbyć się zbędnego słowa.

mouse++clicked -> mouse+mouse-clicked -> MouseListener.mouseClicked

Dlaczego nie uniwersalne `on-click` albo `on-mouse-over`?

Takie rozwiązanie na pewno byłoby intuicyjne dla osób początkujących. Nie widzę jednak sensu gdy mouse++clicked jest wystarczająco wymowne. Poza tym powodowałoby zwiększenie kodu w GUI FTW! specyficznego dla bibliotek, które obsługuje (w tym momencie Swing i SWT).

Dzięki temu, że GUI FTW! wymaga podania nazwy interfejsu i metody, możliwa jest obsługa zdarzeń wymyślonych przez programistę na poziomie równym z tymi wbudowanymi w Swing bądź SWT.

Funkcja obsługująca

W tym momencie funkcja obsługująca zdarzenie ma jeden argument: zdarzenie, które wystąpiło. Może to być zarówno funkcja anonimowa jak i nazwa funkcji zdefiniowanej w innym miejscu.

Przykład

Rozwinę lekko przykład z poprzedniego wpisu (utrzymując poziom hellołłorldowy). Dla przypomnienia struktura interfejsu:

(def window
  (swing
    [JFrame [*id :okno-ftw]
     [JButton [*id :przycisk-omg]]]))

Do arkusza styli dodamy obsługę zdarzenia:

(def sheet
 (stylesheet
  [:okno-ftw] [:title "GUI FTW!"
               :size ^unroll (300 200)
               :visible true]
  [:przycisk-omg] [:text "To jest przycisk!"
                   :mouse++clicked
                   (fn [event]
                    (JOptionPane/showMessageDialog nil "GUI FTW!"))]))

Pełny kod tego przykładu znajduje się tutaj.

Niech się stanie GUI FTW!

2011-03-20T00:00:00+00:00

Ponieważ uwielbiam programowanie deklaratywne brakowało mi od dawna czegoś deklaratywnego do tworzenia GUI. Kod tworzący GUI jest zawsze bardzo nudny i powtarzalny: "stwórz obiekt, ustaw jego tekst, ikonę, dodaj akcję na klik (wcześniej stwórz obiekt implementujący odpowiedniego listenera), ew. stwórz obiekty-dzieci, bla bla bla".

Projektanci stron internetowych od początku mają do dyspozycji HTML i CSS, które są jak najbardziej deklaratywne w swojej naturze. Dodatkowo treść określa się osobno od tego jak ma wyglądać. Model ten zaczyna wychodzić poza przeglądarki, np. XAML w .NET albo pliki layoutów w Androidzie. Wszystkie znane mi do tej pory tego przykłady opierają się na XML-u i dodatkowym programie generującym kod w trakcie kompilacji.

Ostatnio pracuję nad podobną biblioteką dla Clojure. Są jednak dwie główne różnice:

Tak jak dla programistów Javy naturalnym językiem do opisu danych jest XML tak dla programistów Clojure tym językiem jest Clojure.
Moja biblioteka jest jedynie biblioteką, nie wymaga dodatkowych programów generujących (powiedzmy) kod Javy z XML-a.

Ad 1. Składnia Clojure to tylko struktury danych: listy, wektory i mapy o wybornej składni. Grzechem byłoby używać w takiej sytuacji XML-a. Całe parsowanie robi za mnie Clojure więc mogę martwić się już tylko znaczeniem tego co siedzi w środku. Zarówno drzewo GUI (analogia do HTML) jak i style (CSS) definiowane są za pomocą kodu w Clojure.

Ad 2. Dzięki magicznym technikom metaprogramowania (makrom) mogę wchodzić w drogę kompilatorowi Clojure i generować kod tuż przed kompilacją zamiast generować kod programem i dopiero potem wywoływać kompilator. Dlatego całą funkcjonalność można spakować do pliku jar i używać jak każdej innej biblioteki. Ułatwia to także programowanie interaktywne z użyciem REPL.

Co, gdzie, jak?

Teraz nieco więcej o samej bibliotece. Nazwałem ją GUI FTW! a pobrać ją można stąd: http://github.com/santamon/GUIFTW. Jest dostępna także na Clojars więc wystarczy dodać [guiftw "0.1.0-SNAPSHOT"] do zależności projektu aby jej użyć. Polecam poeksperymentować z przykładami w katalogu src/guiftw/examples, które są również mocno obkomentowane w formie tutoriala.

GUI FTW! nie jest kolejnym toolkitem obok SWT i Swinga -- jest deklaratywną nakładką na nie. Tzn. GUI FTW! można używać do tworzenia interfejsów używając jednego albo drugiego pod spodem. Do tego zostało napisane na tyle abstrakcyjnie, że można łatwo dopisać obsługę kolejnego toolkitu. Ułatwi to przesiadkę programistom Javy, którzy znają jedno albo drugie. Poza tym, pisanie kolejnego toolkitu nie jest po prostu celem tego projektu.

Banalny przykład

Strukturą GUI jest drzewo, którego węzeł składa się z nazwy klasy, listy właściwości oraz z jego węzłów-dzieci.

(def window
 (swing
   [JFrame [:title "GUI FTW!"
            :visible true]
    [JButton [:text "To jest przycisk!"]]]))

Wewnątrz listy cech można używać dowolnych nazw, które mają swoje settery w danej klasie. Np. :title tłumaczone jest na wywołanie metody setTitle, :default-close-operation na setDefaultCloseOperation itd.

Aby zdefiniować style osobno musimy nadać elementom identyfikatory:

[JFrame [*id :okno-ftw]
 [JButton [*id :przycisk-omg]]]

a osobno w tzw. arkuszu stylów zdefiniować cechy obiektów:

(def sheet
 (stylesheet
  [:okno-ftw] [:title "GUI FTW!"
               :size ^unroll (300 200)
               :visible true]
  [:przycisk-omg] [:text "To jest przycisk!"]))

Składnia styli składa się z par list: najpierw lista identyfikatorów, druga lista jest listą właściwości jak poprzednio. ^unroll jest potrzebne dla setterów, które mają więcej niż jeden parametr. Lista poprzedzona ^unroll zostanie rozwinięta na wszystkie jego parametry zamiast wywołać setter z listą jako parametrem. Czyli otrzymamy odpowiednik setSize(300, 200) zamiast setSize((300, 200)).

Makro swing zwraca funkcję, która utworzy chciane GUI, więc window będzie funkcją. Parametrami tej funkcji jest ew. obiekt nadrzędny (jeśli nie tworzylibyśmy okna tylko jakiś podrzędny element, może być nil) oraz dowolna ilość arkuszy styli. Utworzenie okna będzie więc wyglądało tak:

(window nil sheet)

Arkuszy może być więcej, możemy także podać inny komplet. Możemy też utworzyć wiele okien wywołując powtórnie tę funkcję. Zwrócony zostanie element na korzeniu drzewa.

Analogiczny przykład w SWT użyłby klas specyficznych dla SWT i przede wszystkim makra swt zamiast swing.

Co dalej

Zacząłem pisać dokumentację. Jest dostępna w kodzie bądź przez doc w REPL-u. Przydałaby się też dokumentacja on-line w stylu tej dla samego Clojure.

W tym momencie można stworzyć GUI, ostylować go i podpiąć zdarzenia (o czym będzie następny wpis). Brakuje całej części "stanowej", w szczególności wyciąganie z drzewa interesujących nas elementów. Mam również pomysł, by podpinać wartości (np. tekst pola tekstowego) dwustronnie pod clojure'owe atomy, refy, agentów itp. Pozwoliłoby to na spięcie GUI i np. pamięci transakcyjnej.

Błąd młodego parsownika

2010-09-03T00:00:00+00:00

Parsownik -- osoba pisząca parsery.
(Termin zawdzięczam mojemu bratu.)

Od pierwszego wpisu tutaj minęły 2 tygodnie. Najlepsze jest to, że zacząłem pisać następny wpis już następnego dnia po wystartowaniu bloga. Cały wpis powstał bez sprawdzania czy kompiluje się ładnie do HTML-a. Po ukończeniu skompilował się, niestety źle. Bardzo źle. Tagi przeplatały się w nieprawidłowy sposób, np. gwiazdka gdzieś wcześniej w którymś paragrafie i gwiazdka gdzieś dalej w wypunktowaniu powodowały otoczenie to tagiem <b>. Co dawało np. takie wyjście:

... <p> ... <b> ... </p>
<ul> <li> ... </b> ...

Mój parser działał ogólnie tak, że miał listę par: wyrażenie regularne + funkcja, która wywoływana była na tekście do którego zostało dopasowane to wyrażenie. Aby zapobiec złemu przeplataniu się tagów wyrażenia ozdobników (takich jak pogrubienie, pochylenie, podkreślenie; do tego używam pojedynczych znaków, np: /asdf/ → <em>asdf</em>) stały się bardzo skomplikowane. Mam na myśli coś takiego (@ to odpowiednik dla znacznika <code>):

r"(?<!<|\w|[@])\@(?=\S)([^@]+)(?<=\S)\@(?=\W)"

Nie jestem specjalistą od wyrażeń regularnych ale użycie ich wydawało mi się bardzo obiecujące. Szczególnie łatwo było na początku ;).

Przedstawione podejście miało poważne wady:

za każdym razem przetwarzany był cały tekst,
wyrażenia widziały go jako sam tekst a nie jako strukturę,
w praktyce dopuszczalne było przeplatanie się znaczników HTML j/w.

Ogólnie całość sprawiała wrażenie jakby trzymała się na rzęsach :P. Ciągłe dopasowywanie regexpów mogło się szybko skończyć kodem spaghetti... Jednym słowem...

Porażka :D.

Mogłem spodziewać się tego po przeczytaniu tego wątku na Stack Overflow. Dotyczył on parsowania HTML-a więc najpierw pomyślałem, że moja wymarzona składnia nie jest aż tak trudna do przetworzenia.

Wróciłem do Stack Overflow jak mój parser zaczął nawalać...

Pyparsing

Have you tried using an XML parser instead?
-- Will

Wow. To mi dało myślenia. Oczywiście nie chodziło o użycie parsera XML-a ale śladem "gotowych, dobrze sprawdzonych rozwiązań" trafiłem na pyparsing.

Pyparsing jest (dla mnie, laika z tego tematu :P ) parserem dowolnie zdefiniowanej gramatyki. Od np. ANTLR-a różni się tym, że gramatykę definiuje się za pomocą wyrażeń w Pythonie (używając zwykłych operatorów takich jak + czy |) zamiast tradycyjnego EBNF.

Idealnie dla mnie. Wystarczyło zrozumieć filozofię działania, przeczytać krótką i przystępną instrukcję oraz czasem zajrzeć do dokumentacji API.

Prosty przykład

Skoro jesteśmy przy moich pogrubieniach za pomocą gwiazdki i pochyleniach za pomocą ukośnika, proponuję prosty, rekurencyjny przykład.

Najpierw wersja nierekurencyjna:

# -*- coding: utf-8 -*-
from pyparsing import *
from pprint import pprint

undecorated = OneOrMore( # tłumaczy się samo przez się
                         Word( # słowo (przynajmniej 1 znak) złożone z:
                               alphanums)) # litery i cyfry

bold = "*" + undecorated + "*"   # prawda,
italic = "/" + undecorated + "/" # że proste? :)

# metoda parseString() służy do... parsowania napisów
pprint(bold.parseString("*asdf*").asList())
pprint(italic.parseString("/qwer/").asList())

Wynikiem tego będzie:

['*', 'asdf', '*']
['/', 'qwer', '/']

Jak widać, pyparsing dzieli łańcuch na kawałki określone w gramatyce (tokeny). Domyślnie omija też ew. białe znaki pomiędzy nimi.

Rekurencyjny przykład będzie nieco dłuższy. Ponieważ Python nie pozwala na używanie niezdefiniowanych symboli pyparsing załatwia to klasą Forward, która umożliwia najpierw zadeklarowanie elementu a później podanie jego definicji za pomocą operatora <<.

# -*- coding: utf-8 -*-
from pyparsing import *
from pprint import pprint

undecorated = OneOrMore( Word(alphanums))

bold = Forward()
italic = Forward()

expression = OneOrMore( undecorated | bold | italic )

# Domyślnie wszystkie elementy odnalezione przez pyparsing
# zwracane są jako jednowymiarowa lista, Group stworzy
# listę zagnieżdżoną dla tego dopasowania
bold << Group("*" + expression + "*")
italic << Group("/" + expression + "/")

pprint(expression.parseString("""
czysty tekst
/krzywo/ *grubo*
/*krzywo grubo*/ */grubo krzywo/*
*grubo /krzywo i jeszcze raz *grubo*/*
""").asList())

Tym razem wyjście wygląda tak:

['czysty', 'tekst',        # czysty tekst
 ['/', 'krzywo', '/'],     # /krzywo/
 ['*', 'grubo', '*'],      # *grubo*
 ['/', ['*', 'krzywo', 'grubo', '*'], '/'], # /*krzywo grubo*/
 ['*', ['/', 'grubo', 'krzywo', '/'], '*'], # */grubo krzywo/*
 ['*', 'grubo',
  ['/', 'krzywo', 'i', 'jeszcze', 'raz',
   ['*', 'grubo', '*'],
   '/'],
  '*']]

Ostatni kawałek jest szczególnie ciekawy. Zostawiam go do samodzielnego przeanalizowania :P. Dla mnie to była eureka, która pozwoliła mi dalej popchnąć projekt :)

Oba przykłady umieszczone są w jednym pliku. Plik ten posiada jeszcze jeden cukierek dla osób wnikliwych ;). Przedstawiony przykład jest uproszczeniem analogicznego kodu z mojego parsera.

Takie drzewko jak w ostatnim listingu możemy już dowolnie przetworzyć manipulując listami, albo użyć metody setParseAction(fn) na każdym zdefiniowanym elemencie gramatyki, gdzie fn to funkcja. Jeśli fn zwróci jakąś wartość to element w drzewie zostanie zastąpiony tą wartością.

Podsumowanie

Nowy parser pozbawiony jest wad poprzedniego, przede wszystkim:

działa,
jest bardziej przewidywalny,
kod jest bardziej przejrzysty,
jest łatwiej rozszerzalny.

Polecam przyjrzeć się pyparsing jeśli mamy potrzebę/chęć przetworzenia jakiegoś tekstu i piszemy w Pythonie. Jeszcze raz podaję adres do samouczka oraz do dokumentacji API. Pyparsing ma bardzo fajną licencję (MIT), "róbta co chceta ale pochwalcie się od kogo ściągaliście" :P ) i jest dość popularne, co znaczy, że powinna być dostępna w Twojej Ulubionej Dystrybucji ;).

Intro

2010-08-16T00:00:00+00:00

Witam serdecznie. O blogu, który by się tak nazywał, działał i wyglądał myślałem od jakiegoś czasu. Będę pisał o własnych zainteresowaniach, skupiając się zapewne w głównej mierze na języku Clojure. Mam dwa pomysły na pracę mgr, których, dopóki nie dorosną, nie zdradzę.

Wygląd strony jest minimalistyczny; mam nadzieję, że jeśli nie przypadnie komuś do gustu to przynajmniej nie będzie przeszkadzał w dostępie do treści.

Makeblog

Na potrzeby bloga napisałem kilka skryptów do generowania stron off-line. Kilka zalet takiego rozwiązania (porównując np. z Wordpressem):

strony ładują się szybciej, nie ma odwołań do bazy danych,
mogę użyć dowolnego edytora do edycji stron/wpisów,
całą treść trzymam u siebie na dysku, zmiana hostingu jest dzięki temu uproszczona.

W tym momencie strona hostowana jest na GitHubie, co mi bardzo odpowiada: synchronizacja treści przez gita, cud-miód :).

Makeblog używa składni podobnej do org-mode'a. Dzięki temu mogę pisać wpisy w czystym tekście, polecam zobaczyć plik źródłowy tego wpisu oraz plik Syntax, którego używałem do testowania parsera. Schematy stron używają bardzo prostej składni (podmiany z $).

Skąd taka nazwa?

Proste: Makeblog używa programu make do śledzenia, które pliki mają być zaktualizowane. Skrypty do parsowania tekstu i indeksowania są napisane w Pythonie. Dlaczego nie w Clojure? Może więcej o Makeblogu w następnym wpisie.

Projekt jest hostowany na GitHubie: http://github.com/santamon/makeblog.

Braki i niedoróbki

Problemy te nie dotyczą aktualnego wyglądu strony, która używa innych czcionek.

Póki co zauważyłem problemy z renderowaniem czcionek pod Windowsem (gdy używa się ClearType, pod Safari z renderowaniem "makowym" wygląda b. dobrze). Dlatego na Viście i 7 zostaną użyte kroje systemowe (nowe kroje wprowadzone z Vistą, nie ma ich w innych OS-ach, więc na Linuksie zostaną użyte te zagnieżdżone). Na XP jeszcze nie wiem co zrobić. Zobaczymy po testach (nie mam komputera z XP pod ręką ostatnio).

Brakuje kilku istotnych łebdwazerowych funkcji, czyli tagów i RSS-a lub Atoma. Jest w moim TODO ;).

Efekty uboczne programowania

2010-01-07T00:00:00+00:00

Wpis archiwalny z mojej starej strony.

Pliki png w pełnej rozdzielczości mają po 2-4,5 MB.

Efekt niedokończonej optymalizacji odświeżania obrazu

One Makefile To Rule Them All

2009-06-07T00:00:00+00:00

One Makefile to rule them all, One Makefile to find them,
One Makefile to bring them all and in the batch compile them
In the Land of Unix where the Shells lie.