WOP-35 two wheels mouse under Linux

If you have WOP-35 two wheels mouse you might this a bit interesting. I had this time very long time ago before "evdev" becom a default driver for any input device. It worked as a charm for me with "mouse" driver. But since that big "xorg.conf file blow" I've lost my second wheel. Moreover it both wheels scrols almost identically but both of them sometimes skip when I scroll.

I tried evtest program and found that it reports second wheel in a same event but with different value +/- 2 rather than first one +/- 1. I thought that is the end of second wheel, but... Behold /etc/X11/xorg.conf.d/24-input-mouse-wop35.conf I have:

# Looks like evdev doesn't report second wheel (ignore it)
Section "InputClass"
    Identifier      "Disable evdev-driven ImExPS/2 mouse"
    MatchProduct    "ImExPS/2 Generic Explorer Mouse"
    MatchDriver     "evdev"
    Option          "Ignore" "true"
EndSection
    
# Configure "mouse" driven WOP-35
Section "InputClass"
    Identifier      "ImExPS/2 mouse"
    MatchDevicePath "/dev/input/mouse*"
    MatchProduct    "ImExPS/2 Generic Explorer Mouse"
    Driver          "mouse"
    Option          "Protocol"  "ExplorerPS/2"
    Option          "Emulate3Buttons" "no"
    Option          "ZAxisMapping" "4 5 6 7"
    Option          "Buttons" "9"
    Option          "CorePointer"
EndSection

Adding async in Bash

Today I had to wait for a pretty long time to get photos of hand-written pages converted to djvu/pdf with my small script. And the first idea was to get it make use of my 4 cores. First think was about using existing job control, but unfortunately it is too weak. So here is changes I had to do to get it to work:

True polymorphic functions in C#

If you ever saw Haskell polymorphic functions you'll never forget that great feeling of full abstraction from who may implement typeclasses that you restrict your argument/result on. Of course OOP gives opportunity to taste some bit of that feeling when we create functions which works with base types and they naturally handles all descendant, but the way they do it is run-time polymorphism and for C# that always require heap allocated objects. Sample in this post doesn't produce box/unbox even in IL while leaving structs private (and thus in maintainable state). After JIT/AOT even if code is in separate assemblies Main() from app will cause specialization of VisitAll from library which will cause specialization of PokeVisitor from app.

Vala bindings

No man who didn't tried to implement .vapi interface to C-library could fully understand me. I've gone a pretty short path through this hell and already hit so many issues...

Static field construction doesn't even happen for [Compact] classes (bye-bye RAII for library init/cleanup).

[CCode (lower_case_csuffix = "xxx")] - just makes nothing (btw, you can specify any properties and they just would be ignored).

struct don't allow other types declaration inside of it (have no idea what is the reason for that).

string get_driver(); and string dirver { get; } - is totally different things even that C-names for generated code are the same (be careful when uses them in .vapi). First one causes returned string to be freed, but second does nothing (you can try with any type). Nothing special mentioned in documentation.

After narrowing sample and putting it into .vala file you notice that get_dirver() { return "XXX"; } returns g_strdup() of returned value, but dirver { get { /* ... */ } } returns value directly.

To sort that out - you have to use all your charm to squize out of Google several letters in mail-list. 3 years and Google can't find documentation, small wiki page or blog post...

So now we are aware of the fact that default meaning owned/unowned might change depending on context. That makes sense when you want spend minimum effort (not only lines of code, but thinking) to bring another external library to Vala. But that small thing might make harm to your mind. We know that we should write string driver { owned get; } if you want caller to be responsible for removing object.

    [Compact]
    [CCode (cname = "char", free_function = "cpufreq_put_driver")]
    public class Driver : string {
    }

    [SimpleType]
    [Immutable]
    [CCode (cname = "unsigned int", cprefix = "cpufreq_")]
    public struct Cpu : uint {
        public Driver driver { owned get; }
    }
 

But if that would be all problems, I have had, I wouldn't write this post at all...

Unboxed arrays in Haskell

There is a great idea of Data.Ix implemented for nice and fast Data.Array.Unboxed and others. That allows to form arrays, matrices and other schemas (even triangles) of data access. To gain that flexibility we separate storage implementation (i.e. continous sequence of bytes) from indexing schema implementation.
But sometimes we need a way to access more complex objects and still have that magic Unboxed storage. I.e. instead of accessing single object we need two of them. Once again mighty of Haskell type system comes to save us. Just add another index axis and hide it in the same way how Ix do.

Hand-made allocator

Today I was asked at interview to write my own allocator in ANSI C. Pretty strange task as for me. You need some time to debug and doing that at paper is awful. So I've put simple single-listed allocator without merging free space. And of course I forgot to hanle some simple cases.

Let's see how it should look:

Code path securing

I'd like to highlight difference in the way we secure code/calculation path in Haskell and C++

Since in Haskell we have no any creation/calculation we use type-level protection by injecting polymorphic object ("token") that should be passed (actually type is passed) to each function that requires access to our secure type (with phantom type "token")