Fedora 25 includes wayland as the default display backend and this time around
it actually looks to be a decent replacement. However my xmodmap config that I
have carried around for years at this point was not going to work anymore.
xmodmap even being deprecated for xorg is not likely to be ported to wayland so
the option remaining is to dig into the madness that is xkb.
Devoted some time today to figure out how to add a "fake" parent to a commit in
git. It's quite easy once you discover there is something called grafts in
A graft can be created be adding a line to .git/info/grafts which is simply
a list of commit-shas. The first identifies the commit to modify and the
following is what the parents of that commit should be. The following adds a
second parent to the commit <commit> that currently have <parent1> as it
A small update on the earlier dulwich post. Jelmer pushed a fix
to the redundant parse issue and using this version the time consumed is
roughly cut in half. Was really hoping for more as the tree should be parsed
once instead of 3 times now. I still have to rule out the repository simply
growing even more from the last post.
This version ran somewhere just short of 30s with a warm fs cache. Two take
aways: something is seriously wrong and my git repo is quite the beast.
One thing the above code does is waste time reading objects that will never
be used, like the blobs. Well, except for the isinstance check. A second
version that avoids reading anything but trees cuts it down to 2-3 seconds.
With the glaring mistake out of the way it starts to get tricky to cut down
the time consumption further. using tree._entries.iteritems() rather than
tree.iteritems() shaves off another 100 ms but nothing exciting.
One tree stands out by taking about 70 ms alone to process. It's a folder
with close to 20k subfolders. I narrow it down with some code to only read
this tree and get about the same time measurement. 67 ms to load the tree and
34 more to iterate over it with a simple pass. A check with the profiler
reveals that _deserialize of the Tree class stands for most of the time
followed by parse_tree which is directly called by the first and oddly
enough both have a call count of 3.
Stumbled upon statebox while looking for
answer on how to manage a set of members (keys in other buckets) with regards
to riak`s eventual consistency. I like the approach because it solves the
resolution for the generic case rather than doing something custom for each
possible conflict in the application. It does this by putting some restrictions
on what operations you may do on the data, most set like operations are cool.
One of the core concepts is that every operation is idempotent, and this is
where it breaks down for me as I explicitly don't want some operations to be
repeatable. Removing a member from the set in my use case implies it will be
added to a set stored at another key. If I could remove it twice it could be
added to two different sets, and that can't happen.
I'm currently looking into doing a variation where instead of using only
repeatable operations I only use reversible operations. E.g you can't add
something to a set that is already in there as that operation would not be
possible to reverse without knowing the previous state already.
today at work. The widget is a kinda silly information box that display some
content in a iframe and the issue turned out to be that you can't set the
height of a iframe in mobile safari. It was solved by adding overflow: auto
and a -webkit-overflow-scrolling all in all not very interesting.
What I did enjoy was the absolutely horrid hack I used to get my console logs out of the ipoon.
And then I could see my console.log's and errors that occurred in the access
log of the python3 -m http.server I was using to serve the page already.
There's so many cool ways this could be improved and someone has probably
already created a full library to do this. But I have a feeling I will leave
this as a one of hack with the only trace being this here post.
Found myself setting up quite a few symlinks in one of our repos at work today.
It all followed a simple pattern where a current link was set up to point to
to folders with a particular name. The link was to be setup in multiple places
in the folder structure.
So, quickly started typing out a find -exec command but the escaping got
really messy quickly. After some tinkering I ended up piping the find output to
a while read loop that did the work. And I did not have to worry about