Confessions of a researchaholic

December 31, 2020

Install IPA file on iOS devices

Filed under: Real — liyiwei @ 5:54 pm

After hours experimenting with macOS VM I found that I can install .ipa files on an iPad from a Windows machine (e.g., AnyTrans).

August 26, 2018

Git research source

Filed under: Real — liyiwei @ 3:53 pm
Tags: ,

Below is a summary of my suggestions of using git to manage research source, based on numerous discussions I have had with my collaborators across multiple projects at multiple institutions.

Always revision control your code. There are multiple options, but at this moment of writing, git beats alternatives such as svn and perforce.

Use github for public repos and bitbucket for private repos.

Start with existing code if feasible. If the code is already under git, use submodule as a component or fork/branch as an extension. Otherwise, convert the code into git, and preserve revision history whenever possible (e.g. github/bitbucket can help you convert svn repos into git repos).

Use multiple branches for different versions of the code, such as stable branch for release or a personal branch for experiments.
Use multiple remotes across organizations and time-frames.
For example, during your internship with a company, use an internal corporate github repo, and sync it with an external bitbucket (private) repo at the end of your internship so that you can continue the project at your school. When you are ready to publish your code, mirror it to a public github repo.
Keep multiple remotes under the same repo for easy management.

For paper drafts, you can create an overleaf git branch for more WYSIWYG-style editing while retaining all the benefits of branching and revision control.

Keep one (or at most a few) sentence(s) at one line, to avoid false alarms from spell checkers (broken sentences) and excessive (line-based) diff by git.
Note that Latex treats line breaks as spaces.

Chongyang Ma (@ Snap Research) has recommendations for industry research code practice.

August 28, 2017

git obliterate

Filed under: Real — liyiwei @ 11:17 am

At the end of trying out BFG to purge a large compiled file from a repo, the following message was displayed:

You can rewrite history in Git – don’t let Trump do it for real!
Trump’s administration has lied consistently, to make people give up on ever
being told the truth. Don’t give up:

So with git, one no longer needs to be a rhetor to change the past.

November 12, 2016

Basis cases

Filed under: Real — liyiwei @ 8:38 pm
Tags: ,

Back in the good old days when I was working as a GPU architect in NVIDIA, we had suites of tests for various stages of GPU development: architecture, RTL, driver, real chips, etc.

Ogtest, consisting of tests written in OpenGL, can be applied to all stages. Each test is written to be as compact as possible, the tests are ordered from simple to complex, and collectively they cover the entire target space (e.g. all applications to run on the target GPU).

For example, the first test is to draw a flat colored triangle, the next is a textured triangle, and the next is called son-of-the-textured-triangle (with two textures instead of just one, if I remember correctly).
I then went on to add a test called daughter-of-the-textured-triangle (I am all in for gender equality) which consists of two textures but exercised a different path through the texturing and shading units (if I remember correctly).

I like to think of these as the basis test cases for the entire target space, analogous to basis vectors in linear algebra.

This applies to all research and development projects. Instead of jumping to debug full-scale applications, it can help to design a set of basis cases first. The process can clarify our thinking, and help us debug and explore algorithm/implementation issues. The basis cases can even be part of the analysis section of a research paper.

August 19, 2016

svn to git migration

Filed under: Real — liyiwei @ 5:02 pm

In the process of migrating some svn repos on my server to git repos on github (public) and bitbucket (private), I found the following migration process works well.

. Import the svn repo to github. It worked for private svn repos that require authentication (as in my case).

. The github repo will be public. If you want a private repo, import the github repo to a private bitbucket repo, and delete the public github repo.

I looked at the revision history and it appears to be well preserved.

I have tried direct import from svn to bitbucket but it did not work, probably due to file system structures of my svn server.

April 8, 2015

Debug your own code

Filed under: Real — liyiwei @ 2:24 pm
Tags: ,

Never, ever, send your code to others and ask them to debug whatever functional or performance issues you have.

That is the most effective way to signal you being a liability rather than an asset. It is like asking others to wipe your ass for you.

Spend time figuring out what is going on inside your own code, and ask specific questions if you need help. Take a look at, a good forum for coding questions.

December 9, 2013

President Obama calls on every American to learn code

Filed under: Real — liyiwei @ 4:34 pm
Tags: ,

On one hand, like math, coding provides some fundamental training that should definitely be learned by everyone.

On the other hand, it is a design problem if everyone has to learn coding just to build or use software tools.

In the current state of computer science, it remains unclear (at least to me) which parts are fundamental materials and which parts are design artifacts. The former can be distilled into general teaching curriculum while the latter should be fixed.

Ideally, an entrepreneur with core knowledge in math and programming should be able to create his or her own applications without having to write a single line of code.
This is already happening in certain domains such as mobile app development.

July 5, 2013

SVN post commit email notification

Filed under: Real — liyiwei @ 1:33 pm
Tags: ,

To some of my collaborators who have recent troubles with svn auto notification:

Instead of the usual spam run on my svn mail server, this time the issue seemed to come from over-zealous spam filtering. That is beyond my control, so I did a workaround.
(See below for more details if interested.)
The only difference is that you will see only yourself as the email recipient instead of everyone else on the cc list.
But this is probably a good thing as it can discourage the temptation to reply all through email.

Let me know if you still see issues.

Setup guide

Here is a quick guide on setup for linux. I will let you search online for other systems and more details.

. Under the “hooks” directory of your repository, there should already be a file named “post-commit.tmpl”. Copy it to a file named “post-commit”, and set x permission for ug. As the name implies, this is the file that will be automatically evoked after commit.

. There should already be a line similar to the following at the end of that post-commit file. All you need to do is to set the proper directory for and append proper email list.

/usr/share/subversion/hook-scripts/ “$REPOS” “$REV” -s “Project Name”

. Alternatively, you can also use in lieu of The former will give you more options while the latter is simpler. For, use the following line instead of the line above:

/usr/share/subversion/hook-scripts/mailer/ commit “$REPOS” “$REV” “$REPOS”/hooks/mailer.conf

You also need to put a mailer.conf file under the same directory.
Below is a simple basic setup that works well for me.


# This command will be invoked with destination addresses on the command
# line, and the message piped into it.
mail_command = /usr/sbin/sendmail


# This is not passed to the shell, so do not use shell metacharacters.
# The command is split around whitespace, so if you want to include
# whitespace in the command, then ### something ###.
diff = /usr/bin/diff -u -L %(label_from)s -L %(label_to)s %(from)s %(to)s

# The default prefix for the Subject: header for commits.
commit_subject_prefix = Project Name

# The default To: addresses for message. One or more addresses,
# separated by whitespace (no commas).
# NOTE: If you want to use a different character for separating the
# addresses put it in front of the addresses included in square
# brackets ‘[ ]’.
to_addr =

# If this is set, then a Reply-To: will be inserted into the message.
reply_to =

# Specify which types of repository changes will create
# diffs for. Valid options are any combination of
# ‘add copy modify delete’, or ‘none’ to never create diffs.
# add: generates diffs for all added paths
# copy: generates diffs for all copied paths
# which were not changed after copying
# modify: generates diffs for all modified paths, including paths that were
# copied and modified afterwards (within the same commit)
# delete: generates diffs for all removed paths
generate_diffs = add copy modify

# A revision is reported on if any of its changed paths match the
# for_paths option. If only some of the changed paths of a revision
# match, this variable controls the behaviour for the non-matching
# paths. Possible values are:
# yes: (Default) Show in both summary and diffs.
# summary: Show the changed paths in the summary, but omit the diffs.
# no: Show nothing more than a note saying “and changes in other areas”
show_nonmatching_paths = yes

My workaround

The mail filter appeared to be rejecting and considering as spam some automatic notifications with multiple recipients. So a quick workaround is to send out emails once at a time to individual recipients. This can be easily achieved via as follows:

for person in
/usr/share/subversion/hook-scripts/ “$REPOS” “$REV” -s “Project Name” $person

For, you will need separate conf files for individual recipients. This does not look very convenient to me.

January 26, 2013

Why my site is not worth hacking

Filed under: Real — liyiwei @ 7:49 pm
Tags: ,

A friend of mine, who is currently a grad student in a prestigious CS department, told me that his PhD adviser is pretty keen on the cyber security thing. Like, he will fuss about unencrypted project servers.

I do not encrypt my server. It is not nearly as popular a target as my friend’s department, and I simply do not think it is worth hacking. Allow me to do a quick breakdown of the content of my site:

90% are project ideas killed by myself.

9% are not killed, but papers rejected by reviewers.

1% are neither killed nor rejected, but so poorly written that reviewers, who are experts in my field, asked for 3 revisions to be able to understand.

I hope I have saved your time. Have a good day.

Theme: Rubric. Get a free blog at