As of 2016-02-26, there will be no more posts for this blog. s/blog/pba/

Dear blog,

I’ve just realized that you and me have never had a talk before, this is our first. Sadly, this wouldn’t go well.

Everything has its time, sooner or later, it will come to an end. Unfortunately, It’s the time for you.

Blogger might not be the perfect platform for people like me and blogs like you, but it’s stable and you only get hiccups from me. Sorry about those.

I’d spent a lot of time to design you and to write on your, 102 commits in private repository for the template and 260 commits for posts. I can’t say you look pretty in other’s eyes, but surely you are in mine.

You were born on 2010-04-16, 5 years and 316 days ago. This is post number 1,794 and the very last number.

So long, it’s been nice with you.

yjl

Note

This is a note currently nothing about about the programming, but the use of C project.

1   $HOME/.local installation with Autotools

Normally, project with GNU Autotools, you can build and install to specified location, for example

% ./configure --prefix=$HOME/.local
% make
% make install

Which installs the files to $HOME/.local other than commonly default /usr/local. On most distributions, you shouldn’t have issues with /usr/local installation, not just the executables, but also the libraries, pkg-config, linking, they all should be configured system-wide.

However, it’s not the case for user home installation, you will need to take some steps to ensure things can be found.

1.1   pkg-config

export LD_LIBRARY_PATH=$HOME/.local/lib
export PKG_CONFIG_PATH=$HOME/.local/lib/pkgconfig:/usr/lib64/pkgconfig

LD_LIBRARY_PATH makes sure any shared libraries are linked during the compilation can be found when you execute the program.

PKG_CONFIG_PATH isn’t for additional paths, so you still need to provide the system pkg-config locations.

1.2   configure

When startup, continues sources prefix/share/config.site, if found, prefix is either default or one you specify with --prefix. In my case, it is $HOME/.local/share/config.site and I have the following content:

CPPFLAGS=-I$HOME/.local/include
LDFLAGS=-L$HOME/.local/lib

They will make sure the header files can be found and linker knows there the shared libraries are stored.

Note

Because I wrote a super long description for this video, I had to split this part out and put it on my blog, or YouTube would tell me my description is too long, which I totally agreed.


1   Making the video

Normally, this is the last one, but for the video, I bumped it up to first.

  1. My record scripts

    • setup-record.sh

      Setting up terminal window for 1280x720 recording region, and adjust my primarily tmux window, so they won’t overlay one on another, but this one for Raincat doesn’t need a terminal window.

    • record.sh

      It records the video. I will choose the FPS, sometimes I need to change the size.

    • re-encode.sh and merge.sh

      record.sh records raw images if not with audio, so the raw video needs to be re-encoded before uploading to YouTube. If I record multiple parts, I need to merge them into one.

    • grabbing a screenshot for video thumbnail, typically the title screen if any.

  2. Writing the description

    • titling the video
    • collecting information about the project, the version, programming language and major dependencies, author, license, etc
    • checking out links, RTFM again, etc.
    • putting all stuff together and write
  3. Making a thumbnail

    If the screenshot already has the title in it, then just use it; if not, put a text overlay on it.

  4. Uploading the video

    • tagging the video
    • adding to appropriate playlists
    • turning on monetization, set up record date
    • re-reading my description
    • double checking everything
    • pushing the publish button
    • checking YouTube video manager, just to be sure

2   Choosing one to make

There are good and suitable projects, but sometimes I don’t have one in my queue list. It normally would be one I like and it has good and necessary stuff to show on video.

3   Searching for new projects

I mostly search in GitHub:

  1. gh-trend.py: it searches GitHub trending projects within the programming languages that I am interested in.
  2. search results with my user script and user style for GitHub. I search for specific keywords every day, with help from my user script and style, I can quickly go through without clicking on things I won’t be interested or already checked.

I also search with Google Image.

I was doing my thing when Not Ready To Make Nice (2006) came up, which won 3 categories of 49th Grammy Awards in 2007, Record of the Year, Song of the Year, and Best Country Performance by a Duo or Group with Vocal.

Last time I listened to this song was years ago and I really had forgot about it. Now listening to it without checking out the MV, I still remembered some smearing actions.

https://i.ytimg.com/vi/pojL_35QlSI/maxresdefault.jpg

This is notes for me to remember how to use GHC and Cabal to install and remove stuff I install.

1   Rant, first

I know nothing about Haskell, but so far, after going through pages, I think it’s safe to say there is no such thing in Haskell world as package management, at least for GHC (Glasgow Haskell Compiler). You can install package using Cabal, but uninstall is a pain-in-the-ass, I thought Perl is annoying.

You can --unregister a package with ghc-pkg — library package, not one installs executable — but none of the actual library files are removed, you have to manually remove them or find some scripts to help you. And there is no --uninstall in Cabal, even it does install package for you.

Both ghc-pkg and Cabal are simply not package managers.

So, if your system package manager has Haskell packages, use it to install and uninstall system-wide. If you insist to install at user home or other places, then use Cabal sandbox. Or you can just remove the ~/.ghc and ~/.cabal once they have got too many junks, and start over.

2   Cabal sandbox

2.1   Installing

% SANDBOX=/path/to/somewhere
% export PATH="$SANDBOX/.cabal-sandbox/bin:$PATH"
% mkdir -p "$SANDBOX"
% cd "$SANDBOX"
% cabal sandbox init
% cabal install <package|path>
% <command>

I would suggestion just cd /tmp and use there as sandbox location. It will work well with uninstalling, that is to sandbox delete on /tmp. And if you use tmpfs on /tmp, you don’t even need to bother cleaning up..

2.2   Uninstalling

% rm -rf "$SANDBOX"
# cd "$SANDBOX" && cabal sandbox delete  # $SANDBOX still exists