How is it that in 2000-frickn’-12 that it’s actually more complex to write an ncurses UI then GTK or Qt? I mean, c’mon.

I want a full-blown toolkit with tons of baked in goodies for hacking up simple ncurses UIs, and in an easy way.

Oh an in Python.

I mean, let’s be honest here, writing an app using ncurses is like doing raw X calls in a lot of ways.

I really don’t want this to turn into another side hack of mine, but it might just end up being one.

Oh well :)

For the sake of anyone else who’s fighting their screens, I’ve got a script that will do this (but very very slowly)

setup script

xrandr --output VGA1  --auto
xrandr --output LVDS1 --auto
xrandr --output VGA1  --rotate left
eval "`monconf`"

monoconf script

#!/usr/bin/env python
import subprocess
output = subprocess.check_output(["/home/tag/.bin/mon.ls"])
output = [ item.split() for item in output.split("\n") ]

mons = {}

for mon in output:
    if len(mon) > 0:
        if mon[1] == "connected":
            res=mon[2]
            res=res.split("x")
            for item in res[1].split("+"):
                res.append(item)
            res.pop(1)
            mons[mon[0]] = res

BOTTOM_LEFT = "LVDS1"
TOP_RIGHT="VGA1"

LEFT_WIDTH  = mons[BOTTOM_LEFT][0]
LEFT_HEIGHT = mons[BOTTOM_LEFT][1]

RIGHT_WIDTH  = mons[TOP_RIGHT][0]
RIGHT_HEIGHT = mons[TOP_RIGHT][1]

print "xrandr --output %s --pos 0x%s" % (
    BOTTOM_LEFT,
    (int(RIGHT_HEIGHT) - int(LEFT_HEIGHT)))
print "xrandr --output %s --pos %sx0" % (
    TOP_RIGHT,
    int(LEFT_WIDTH)
)

and the mon.ls command

xrandr -q | grep "^[^\ ].*" | grep -v Screen

All of this is super hacky, but it works.

Use vim? Check out some sweet vim exrc stuff for editing one-line JSON files:

autocmd BufRead,BufNewFile *.json set filetype=json
command Js silent %!jp
command Jc silent %!jcompress
autocmd FileType json Js

jcompress and jp are both on my github. Have fun!

Hello, World!

Today’s hacks come remotely, on the first day of my long trek to Cleveland. As many debian readers know, debian URLs are usually transmitted over IRC or email with some snappy abbreviations. Usually, you’ll see something like:

Feel free to check out information about frob at wiki.d.o/Frob

or something like:

I have uploaded package bar onto mentors.d.n for review

What bugs me most about this is that I have to expand URLs by hand. Which is lame. Enter libolla (a fitting name as well as a graceful nod to my alma mater John Carroll University’s crest).

When LD_PRELOAD’d, it’ll intercept and expand calls to getaddrinfo transparently. It seems to work fine on SSH, and chrome (but I can’t test well, since I’m not on a real line).

This was all hacked up in a few hours I had to spare, and without any sort of internet love, so I’m willing to bet there are some bits that can be cleaned up (after all, the name of the blog is “Peace, Love and C++”, not “Peace, Love and C” - I don’t clam to be a c expert ;) )

So, feel free to fork the project on github (or as I can now do - http://g.c/paultag/libolla)

Now, I just need to find a way to globally pre-load this for apps that I start in my DE. Should be easy enough fiddling with some env-var files.

I’ve whipped up two libs this week, and both have some pretty radical uses. The fist is python-charlie, which can be found on github, which is named in honor of Charlie on the MTA.

This lib will fetch data on the Boston MBTA T (rather, just the Red, Orange and Blue lines), which can actually be super useful in a lot of ways.

I’d love to see some hacks with this data!

The second is php-openstates, a PHP binding into the openstates API. It comes with a nifty little util to get some bill listings, but hopefully, this will mature as teh project grows.

Fork the project on github. Rock on.

Presenting another script from the useless script department — dog!

It has an in-built (and rather quirky) state-machine style parser, which will emit the color defined on entering the new state.

The syntax is stupid easy - and hopefully easy enough to write.

Perhaps (given some time) I’ll turn this into something, well, useful.

Code’s on github, but very buggy and stuff. Also hard-coded.

Enjoy!

Looks like we can root the Nook STR :)

# cat /proc/cpuinfo
Processor   : ARMv7 Processor rev 2 (v7l)
BogoMIPS    : 796.19
Features    : swp half thumb fastmult vfp edsp neon vfpv3 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part    : 0xc08
CPU revision    : 2

Hardware    : OMAP3621 GOSSAMER board
Revision    : 0005
Serial      : 3[SNIP]

I changed the boot to say “You turn me on” and then my “Peace, Love and C++” Logo (as proof and stuff).

I’ll write all this up later. As for now, time to have some fun!

I know there’s not been updates lately, but that’s due to having issues with glibc. I’ll post some words on that soon. In the meantime, enjoy some synfun images!

In this installment, I’ll cover pseudo code and some layouts I’ve chosen.

Most of this is hacked up quickly, but I expect it’ll work OK.

Package layout

First up, the way a package looks:

package-1.0.syn.tar.gz (sourceball)
   +-> synd/
         +->  meta        (meta data on the archive)
         +->  build       (the build script)
         +->  buildrc     (config flags and so forth)
   +-> package-1.0.tar.gz (original source, pristine)

package-1.0.syn (binary package)
   +-> syn/
         +-> [usr/bin/etc/...]
               +-> ...
         +-> .filesums (MD5 sums of the contents)
         +-> .meta-syn (Metainfo on the package)

package-1.0.syn.logs (logball)
   +-> logs/
         +-> build
         +-> configure
         +-> stage
         +-> synlint     (policy checks)
         +->   ...

package-1.0.syn.sigs (MD5 sigs, GPG clearsigned)

package-1.0.syn.goodies (list of binaries & libraries)
    (JSON)

The “Database”

Here’s my “database” (really a python dict) layout:

Status keys:

UNINSTALLED    = "U"
BORKED         = "B"
HALF_INSTALLED = "H"
INSTALLED      = "I"
HALF_LINKED    = "K"
LINKED         = "L"
REMOVED        = "R"

Package entry:

"package" : {
    "linked" : "1.0",
    "installed" : [
        "4.3" : {
            "status" : "I"
        },
        "1.0" : {
            "status" : "L"
        }
    ]
}

This will let me maintain a boatload of versions (in a sane way) of a single package.

Now that we have the DB basics out of the way, let’s go over some of the easy package manager stuff — installing and linking.

We’re ignoring dependencies at the moment :)

Build Method

A lot of this was stolen (only in principal) from Debian. I like Debian’s method, so I figured I’d take what works and ditch what fails.

First think is the idea of a makefile build script. I called mine “build”.

I don’t like that people edit / override the build script in Debian to do something as simple as add a step or two. As a result, I opted to include an “assist” file. It’s called the “buildrc”, and like everything else, it’s in JSON.

During build, Syn will take these blocks and push them into the env under a standard name. This will let us pass flags / change what’s called for each step of the build file without actually editing the build file.

Similar to the rules file (but yet, also different) the build script contains three core steps:

configure, build, stage

configure’s job is to set up the package for a binary build, this is usually just running configure, some brand of autotools, or setup.py or something.

build’s job is to build the source into whatever format is ready to be installed. In most cases this is the core “make” call, and tons of gcc calls.

stage’s job is to put the files to be installed into the staging directory, to be archived.

The build file (in most cases ) is simply:

#!/usr/bin/make -f
include /usr/share/syn/build/synhelper.mk

The buildrc file:

{
    "configure" : "./configure", 
    "build"     : "make", 
    "stage"     : "make install",
    "ConfigFlags" : [
        "--prefix=/usr"
    ],
    "BuildFlags" : [
        "-j3"
    ],
    "StageFlags" : []
}

Let’s have a look at the included script:

configure::
    $(CONFIGURE) $(CONFIG_FLAGS)
build::
    $(BUILD) $(BUILD_FLAGS)
stage::
    $(STAGE) $(STAGE_FLAGS) DESTDIR=$(S_DESTDIR)

This will run:

Configure: ./configure —prefix=/usr

Build: make -j3

Stage: make install DESTDIR=/tmp/syn/…/syn/

Optionally, you may also include “synpatch.mk” before the synhelper.mk to enable patching support. It will apply all patches in the synd/patches directory against the source during the configure step.

Right now it’s simple. It’s set up as:

configure::
    @echo "Patching source"
    patch -Np1 -i ../synd/patches/*

Works great :)

Eventually, I’ll add support to conditionally patch based on patch headers.

I’ll add more later (when I have more time ;) )