4BSD

If you read the article Building LLVM in 90 seconds using Amazon Lambda in 2021, you might wonder whether you can do the same without the author's AMD Ryzen desktop. This blog will show you how I reproduce the results on a $600 ARM64 machine -- Windows Dev Kit 2023.

The software that offloads the compilation tasks to AWS Lambda is called "llama." I forked it to support ARM64. Everything to be discussed here will be using ARM64 -- Windows 11 ARM64, WSL that runs openSUSE Tumbleweed AArch64, Docker image that contains AArch64 binaries, LLVM that generates AArch64 codes, etc.

If you happen to use openSUSE Tumbleweed as well, you can check out the images I uploaded to Docker Hub: lichray/llama-gcc12 for GCC + gold linker and lichray/llama-clang15 for Clang + lld linker; the latter offers only libstdc++. As a jump start, let's give the GCC option a try.

First, clone https://github.com/zhihaoy/llama and switch to the aarch64 branch. Set the GOBIN environment variable to some PATH, go install ./... under the project root. Follow the Getting started guide carefully and bootstrap AWS resources for llama.

Next, make my Docker tag available on your local system with docker pull lichray/llama-gcc12:latest. Then you can create an AWS Lambda in your own account with llama update-function -create -tag lichray/llama-gcc12:latest gcc. The function name "gcc" is a llama default; we will change that when trying out Clang.

Everything is ready. I configure my llvm-project with the following:

env LLAMACC_LOCAL=1 \ cmake -G Ninja \ -DCMAKE_BUILD_TYPE=MinSizeRel \ -DLLVM_ENABLE_PROJECTS="clang" \ -DLLVM_USE_LINKER=gold \ -DCMAKE_C_COMPILER=llamacc \ -DCMAKE_CXX_COMPILER=llamac++ \ -DBUILD_SHARED_LIBS=YES \ -DLLVM_TARGETS_TO_BUILD=AArch64 \ -DCLANG_ENABLE_STATIC_ANALYZER=NO \ -DCLANG_ENABLE_ARCMT=NO \ -B build llvm

To simplify this small example, I didn't set up libc++. The full clang build finishes within 6 minutes with ninja -j 40 -C build/ clang

As you can see, there're warnings. For obvious reasons, the LLVM project guarantees warning-free only when building with Clang, so I'll set up a frustration-free LLVM dev environment next with Clang.

Create an AWS Lambda with my Clang image:

docker pull lichray/llama-clang15:latest llama update-function -create -tag lichray/llama-clang15:latest clang

Export an environment variable to change the Lambda function used by llama (you may want to save that in your shell profile):

# csh setenv LLAMACC_FUNCTION clang

Change cc and c++ commands to match what llamacc and llamac++ use from the image:

update-alternatives --install /usr/bin/cc cc /usr/bin/clang 30 update-alternatives --install /usr/bin/c++ c++ /usr/bin/clang++ 30

Now I can configure:

env LLAMACC_LOCAL=1 \ cmake -G Ninja \ -DCMAKE_BUILD_TYPE=MinSizeRel \ -DLLVM_ENABLE_PROJECTS="clang" \ -DLLVM_USE_LINKER=lld \ -DCMAKE_C_COMPILER=llamacc \ -DCMAKE_CXX_COMPILER=llamac++ \ -DBUILD_SHARED_LIBS=YES \ -DLLVM_TARGETS_TO_BUILD=AArch64 \ -DCLANG_ENABLE_STATIC_ANALYZER=NO \ -DCLANG_ENABLE_ARCMT=NO \ -B build llvm

200 seconds! It's totally not bad, as the original "90 seconds" article used the -O0 flag, which renders the resulting clang executable impractical to use in building clang checks or libc++ later.

And the build costs only 30¢. That is why I moved my dev environment to ARM64. ARM chips are inexpensive, even in the cloud (-20% cost overall). To take full advantage of that, all I did is to make my dev machine consume native artifacts from the cloud.

Caveats

WSL datetime can drift when the host sleeps, disrupting your cached AWS token. Read the comments in this issue to find a solution: #8204

LLVM has a non-owning counterpart to std::function called function_ref1. Similar to std::string_view, which is a non-owning std::string, function_ref serves the purpose of std::function const& in a function parameter list to erase the types of the callable arguments, and is cheap enough to be passed by value -- as small as two pointers, and trivially copyable.

I found this to be very useful. To pass the callable arguments, we do need a vocabulary type (John Lakos can elaborate this better), that is One type for One set of mathematical values, to define the interfaces among the modules and to reduce the template code bloat. std::function does represent the types of the callable arguments in terms of what they do rather than what they are, but it's surprising that passing these arguments may result in allocating memory. Meanwhile, I do find that std::function generates more code than the actual logic that I wrote, thus it defeated the benefit of reducing code bloat.

I generalized the idea of function_ref into what I called signature -- a transparent Callable invoker -- the way you pass in the callable argument will affect how this argument being called. For example, given void g(signature<void()>), if you have a function object f behaving differently when being called as an lvalue or an rvalue, g(f) and g(std::move(f)) will behave differently as well. It's a small change in the implementation, but a big change in the semantics.

The other features I added:

overloading (g(signature<R(int)>), g(signature<R(char)>))

void-discarding (signature<void(int)> to discard the return type)

INVOKE (pointer-to-members, plus void-discarding actually)

unwrap std::reference_wrapper (a tiny optimization)

signature<R(Args...) noexcept>

The last one will be fully available after "noexcept in the type system"2 being implemented in the compilers. Right now we use a FAKE_NOEXCEPT macro (expanded to volatile -- as a placeholder having nothing to do with volatile) and only support function objects. The exact functionality of this specialization is that the noexcept-invocability of the callable arguments are checked at compile time and signature<R(Args...) FAKE_NOEXCEPT> will be awarded a noexcept operator(). Notably, this variant can all be used wherever a non-noexcept one is expected.

That's it. The code is available on github3, tested with GCC 5 and Clang & libc++.

I miss noexcept-propagating std::invoke and invoke<R> (to optionally discard the return value) in the standard.

The function_ref class template. LLVM Programmer’s Manual. http://llvm.org/docs/ProgrammersManual.html#the-function-ref-class-template ↩︎

Make exception specifications be part of the type system, version 5. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0012r1.html ↩︎

Partial meta function application is critically useful. For example, if you want to test a list of types whether they are implicitly convertible to a known type T, basically you need to "bind" T to is_convertible. With Boost.MPL, it would be:

using F = std::is_convertible<mpl::_1, T>;

_1 is a meta placeholder[1], which is conceptually same as that to std::bind, but works with meta functions. However, while the result of std::bind still supports operator(), now the F above can only be called with mpl::apply<F, Arg>. Such a calling convention change also affects meta algorithms' implementation. Although Boost handles it very well, it can hardly be a cross-library solution.

Here is a simple thought: use currying[2] instead of partial application. Currying starts with a simple interpretation of a multi-argument function:

f(a, b, c, ...) => f(a)(b)(c)...

In the world of currying, there are only unary functions, and a multi-argument function is just a function returning another unary function, and applying such a function, in effect, is to bind an argument. Mapping these to C++, I get:

is_constructible<T1, T2, T3> => curried<is_constructible, 3>::call<T1>::call<T2>::call<T3>

The second argument of curried is the number of arguments you want to curry; defaults to 2. There we have the construct to make any argument "free to bind", and the next step is to make an argument at any position "ready to bind":

flipped<curried<F, 3>, 3>:call<T3>::call<T1>::call<T2>

flipped switches the Nth argument of a curried function to the next call position; N defaults to 2 (you may have noticed that these two functions are just generalized curry and flip in Haskell). Now we are able to bind any argument, any where.

The last issue is that a meta algorithm might expect normal multi-argument functions, not curried ones. Basically, we need uncurry. Here is the shining part: wherever useful, there is an ::apply typedef in addition to ::call to give you the "automatically" uncurried meta function:

flipped<curried<F, 3>, 3>:call<T3>::apply<T1, T2>

Now the advantage of this system is quite clear: the calling convention is not changed -- after done processing the meta function, ::apply or ::call is just the processed meta function. For the example at the beginning, it would be

using F = flipped<curried<std::is_convertible>>::call<T>;

, then drop F::call to wherever need a template. If you want to know more, here is a tiny meta programming library[3] I wrote based on this system.

Links:

[1] Handling Placeholders, from "A Deeper Look at Metafunctions". http://www.artima.com/cppsource/metafunctions2.html

[2] Currying. https://en.wikipedia.org/wiki/Currying

Python does not have a traditional C-like for loop or a Pascal-like counted for loop; the "Pythonic" solution is to use the iterator-based for-in loop with an xrange (renamed into range in Python 3) iterator:

>>> for i in xrange(1, 6): ... print i, ... 1 2 3 4 5

Like in C++, it gives a half-open range.

I think this is a good approach, since it offers a higher abstraction compared to a handmade for loop in C; you don't need to run a state machine in head to know where the loop stops because there is no states at all.

C++11 range-based for[1] can also make use of iterators, so it's fairly easy to write a factory to generate an underlying object which gives you those iterators:

for (auto i : xrange(1, 6)) std::cout << i << ' ';

You can find more examples at https://github.com/lichray/xrangexx/blob/master/example.cc .

Different from the one in Python, my version does not have the step argument, because range-for only uses != to compare the iterators even they support random access (as a result, looping across a range [a, b) where a > b results in an undefined behavior). There is nothing wrong from the point of view of genericity, and practically it's easier to get things right when using an adjacent input range and multiplying each value with a factor inside the loop.

The header file also includes a utility, rxrange, to generate a reversed xrange, providing the same argument -- exactly as same as what you get with reversed(xrange(a, b)) in Python. C++17 is probably going to have the Range[2] concept and some range adaptors, but I think it's still worth to have a shorter spelling, like rbegin(...) vs. reverse_iterator<T>(begin(...)).

Links:

[1] Range-based for loop (since C++11) http://en.cppreference.com/w/cpp/language/range-for

One of the most criticized "feature" in C++ is that, a constructor which may accept one argument IS an implicit conversion function from the argument type T to the class type U. For example:

struct A { A(int, int = 4) {} }; void f(A) { } f(3); // f(A) is called

Such a "feature" is terribly bad. It looks like something designed to disable the compilers' type checking and to mess up the overloading set. But, all the criticisms are targeting the "implicit" aspect of this feature. I haven't seen an argument to criticize the "conversion" part.

My argument is, for short,

Implicit conversion makes sense.

Explicit conversion makes no sense.

Let's define a type as a set of all the possible values and a set of all the possible operations which deal with the values. Now, say if we have two types, int and list<long>, is that possible to convert an int n to a list<long>? Oh, maybe a list of n zeros. But wait, why zeros? And, what if I expect a {n}? See? If we allow one possible value set to be converted to an arbitrary possible value set, the semantics of the conversions are arbitrary and multiple, but the explicit conversion can only carry one semantics.

So that's why I say explicit conversion makes no sense. To express the meaning of an arbitrary conversion, the conversion function has to be named in some way to connect the two types involved, like list<long>::from_size(n), while an explicit conversion function is only named in a meaningless way (list<long>(n)).

But in one situation, a conversion is not arbitrary, and it can be safely and implicitly established from type T to U, if the possible value set of T is a subset of U's. Actually, C++ understands this theory, and that is why C++ allows an object of a derived class to be implicitly converted to an object of the base class, since an object of a derived class is supposed to be able to be used anywhere in place of an object of the base class.[1]

As you can see, the problem is not caused by "implicit"; the problem is caused by "conversion" -- mixing the conversion semantics into the constructors is a design error in C++.

So here are my suggestions:

Use implicit conversion for its well-defined semantics;

Prefer named functions/factories[2] over constructors.

Notes:

[1] Unfortunately, such a mechanism is broken if the derived class has a different representation, which results in a type punning, which simply breaks the type safety. However, pointer conversions and pointer to member conversions work.

After variadic template being supported by VC++ Nov 2012 CTP, the feature which will blow away most of our old code is supported by all of the major C++ compilers, and the next topic is how we use it well. A frequently raised question is that, how to expand a pack of arguments, like an std::tuple, to a function. Like, instead of writing

std::lock(l1, l2);

we want

std::tuple<std::mutex, std::mutex> t; vlock(t);

Now we already know the solution: the "indices trick"[1] -- to expand a variadic indices, not the arguments.

template <size_t... I> struct indices {}; template <size_t N, size_t... I> struct build_indices : build_indices<N - 1, N - 1, I...> {}; template <size_t... I> struct build_indices<0, I...> : indices<I...> {}; template <typename Tuple> using tuple_indices = build_indices<std::tuple_size<Tuple>::value>; template <typename Tuple> using tuple_indices = build_indices<std::tuple_size<Tuple>::value>; template <typename Tuple, size_t... I> void _vlock(Tuple&& t, indices<I...>) { std::lock(std::get<I>(std::forward<Tuple>(t))...); } template <typename Tuple> void vlock(Tuple& t) { _vlock(t, tuple_indices<Tuple>()); }

The best thing with the implementation I referred is that, it works with any type supporting the "tuple-like" protocol, e.g., std::pair, std::tuple, and std::array. The last one is very interesting since it provides both the tuple-like access and the STL container interfaces.

However, std::array has a tiny problem: its size template parameter has to be explicitly specified:

std::array<std::mutex, 2> t {};

So how about to use a native array instead? A trivial and evil approach is to specialize std::get, std::tuple_size and std::tuple_element before the definition of _vlock:

// unused specializations are omitted namespace std { template <size_t I, typename T, size_t N> auto get(T (&a)[N]) -> T& { static_assert(I < N, "out of range"); return a[I]; } template <typename T, size_t N> class tuple_size<T[N]> : public integral_constant<size_t, N> {}; } std::mutex t[] = { {}, {} }; // bad example... vlock(t);

However, to open the std namespace is not permitted by the standard. If you consider these specializations to be helpful, maybe you can submit a proposal to LWG.[2]

Links:

[1] The indices trick http://loungecpp.wikidot.com/tips-and-tricks%3Aindices

To enable perfect forwarding in C++11, you need a template parameter T paired with a function template parameter T&&. Scott Meyers calls it `Universal Reference'[1] because, by combining the special deduction rule (14.8.2.1/3) and the reference collapsing rule (8.3.2/6), you will get a lvalue reference or an rvalue reference corresponding to the expression category of the actually argument of the call. However, a problem was raised on comp.lang.c++:[2]

template<typename T> void foo(T&&, T&&);

A first impression is that, T&& is still a `universal reference'. But, the call foo(1, a) fails since T con't be deduced to both int and int&. So this is the problem of our faked `universal reference': in C++03, there is no way to have a cv-qualified or reference type deduced for T, but now, a lvalue reference is allowed, while the type comparison rule is unchanged.

We can simulate the rule by hand:

template <typename T1, typename T2> void foo(T1&&, T2&&, typename std::enable_if<std::is_same< typename std::remove_reference<T1>::type, typename std::remove_reference<T2>::type>::value>::type* = 0) {}

However, despite of its cryptic verbose grammar, the big problem is: what if we add more parameters, like T3? A new SFINAE template is needed:

template <typename...> struct common_deduced_type; template <typename T> struct common_deduced_type<T, T> { typedef T type; }; template <typename T> struct common_deduced_type<T&, T> { typedef T type; }; template <typename T> struct common_deduced_type<T, T&> { typedef T type; }; template <typename T> struct common_deduced_type<T&, T&> { typedef T type; }; template <typename T1, typename... T2> struct common_deduced_type<T1, T2...> { typedef typename common_deduced_type<T1, typename common_deduced_type<T2...>::type>::type type; };

Similar to std::common_type, but without implicit conversion, just removing the lvalue reference then to compare. The trick fix the unpaired prefect forwarding pretty well,

template <typename T1, typename T2, typename T3, typename T4> void foo(T1&&, T2&&, T3&&, T4&&, typename common_deduced_type<T1, T2, T3, T4>::type* = 0) {}

but a modified type comparison matching the new deduction rule can be more straightforward.

Links:

[1] Universal References in C++11—Scott Meyers http://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers

Andrei's ScopeGuard[1] idiom has been implemented by lots of people with the std::function plus a lambda, though most of the time what they need is just a:

unique_ptr<FILE, decltype((fclose))> fguard(fp, fclose);

However, no matter how the ScopeGuard is implemented, it is a code smell to use it as an ad-hoc RAII replacement. The cleanup logic is always the same, and the same code should be refactored. The original article by Andrei already pointed out the main purpose of ScopeGuard: to ease the implementation of the transactional operations to gain the strong exception safety. A rollback logic is specific to a business logic, which are seldom `refactorable'.

So that is why I design the interface of a ScopeGuard like the following:

// creates an automatically named guard defer ( <exps | statements> ); // creates an guard with a <name> defer ( <exps | statements> ) namely ( <name> );

And, to support the cascading undo operations, multiple guards can be disabled within one statement:

defer (op1; op2) namely (undo1); /* operations may fail */ defer (op3; op4; op5) namely (undo2); /* more operations may fail */ undo1 = undo2 = false; // commit

Compared with Go's `defer' keyword, my deferxx[2] does not support `recover' since the exception in C++ is not reenterable. Compared with Boost.ScopeExit, deferxx ships with a built-in commit flag and a cleaner grammar (especially, without the ugly extra semi-colon after the curly braces). Compared with D's scope guard statement, deferxx is not exception-sensible, since the exception in C++ is not detectable (std::uncaught_exception() does not distinguish an exception propagating across a destructor from an exception thrown from the scope)[3]. However, I don't think it's a good idea to turn every failure into an exception. And, coincidentally, the success return code and errno of the C library functions are 0, so that you can just assign those values to the guards ;)

Links:

[1] Generic<Programming>: Change the Way You Write Exception-Safe Code — Forever. http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758

[2] A Go's defer-like syntax scope guard idiom in C++11. https://github.com/lichray/deferxx

XTerm is a UTF-8 -only terminal emulator when being compiled with the wide char support and running under a non-utf8 locale (like zh_CN.GB18030), and it invokes an external program, `luit`, to perform the encoding conversion. The good part of such a design is that we only need to care about the Unicode code points. For example, XTerm's default double-click selection is character class based, so the alpha-num and '.', '/' are not grouped together, but typically, we want an escape-safe shell argument to be selected. So I add the following to ~/.Xresources

XTerm*charClass: 43-47:48,58:48,64:48

to assign assign all (except '=', which I don't want it in practice) of the non-metachar in csh to the class ALNUM. However, any wide characters are also safe w/o escaping. Since we only work with the code points, a simple patch will do the trick, https://gist.github.com/2872752 , by removing the sub-classifying on the Chinese/Japanese characters.

And, obviously, a font using ISO-10646 mapping always works:

XTerm*font: -*-lucidatypewriter-medium-*-*-*-18-*-*-*-*-*-iso10646-* XTerm*boldFont: -*-lucidatypewriter-bold-*-*-*-18-*-*-*-*-*-iso10646-* XTerm*wideFont: -*-wenquanyi bitmap song-bold-*-*-*-17-*-*-*-*-*-*-* XTerm*forcePackedFont: False

Note that the 'wenquanyi bitmap song' font has no bold version now; this one is generated by gbdfed and only supplies 12pt/100dpi/iso10646.

The -iso10646- tags on the normal fonts enable the Unicode line-drawing charactors[1]. However, the bad part of the 'external conversion' design comes: luit is not just a wrapper to iconv; it's an ISO-2022[2] interpreter at the same time, and ISO-2022 happens to conflict with vt102's alternate charset sequences, \E-(0 and \E(B (don't ask me why ncurses' NCURSES_NO_UTF8_ACS option, which is already set by luit, does not work here -- see the title). And XTerm's vt102 parser does not allow some non-standard escape sequences, like ^N/^O, to enable/disable the line-drawing characters.

So we need to force XTerm to recognize a customized escape sequences pair, like

# ~/.termcap # This requires a hack to the XTerm code, to make it accept DLE as ESC. xterm-iso2022|XTerm CJK:\ :eA@:as=^P(0:ae=^P(B:tc=xterm:

while using a customized

XTerm.termName: xterm-iso2022

Fortunately, XTerm's textbook-style, state transition table based vt102 parser is easy to hack: https://gist.github.com/2892430 .

Special note to the FreeBSD users: If you use sudo, you have to link your .termcap to /root/ -- the ncurses on FreeBSD reads the termcap info from the kernel, not /etc/termcap; only the user-supplied ones work.

Links:

[1] Box-drawing character: Unix, CP/M, BBS. https://en.wikipedia.org/wiki/Box-drawing_character#Unix.2C_CP.2FM.2C_BBS

After listened a talk on the threading support in C++11 on the Chicago Code Camp 2012, I did some research on the new threading facilities. Here are some notes.

There are two main classes, std::thread and std::mutex. For std::thread, you can pass a callable object *with* its parameters to it, in the form of std::thread(Callable&&, Arg1, Arg2...). Note that the argument list needs to be specified in the std::bind form. Like, if you want to pass a reference to your thread, you need to wrap your variable with std::ref or std::cref. C++11 also comes with an async programming facility, std::future<T>, built upon std::thread. Google it.

The synchronization facilities include std::unique_lock- a movable RAII wrapper to std::mutex, and std::condition_variable. The APIs are very carefully designed. For example, when condition_variable::wait_for() takes only the lock and the timeout argument, it returns cv_status::timeout or no_timeout; when the optional predicate function presents, it returns true or false. Such a design clearly distinguishes the semantics.

Recently, I did some cleanup to nvi2's string operations. Here are some notes.

First, we need a definition to the "C string". This is very important since some libc functions do not really work with the C strings. A C string is a NUL-terminated byte sequence[1]. Further more, a function which works with the C strings must always terminate its result with '\0'. Otherwise, the function is regarded to work with the "fixed width strings"[2], or, raw memory.

strncpy(3) has been criticized a lot for the inconsistency between its name and its behavior. Sometimes, it terminates its result; but if the supplied buffer is not big enough, strncpy will just fill the buffer, and wish it can simplify the succeeding truncation handling. However, since the behavior itself is "politically wrong", this API is error-prone.

The problem is caused by the length argument. If it is the length of the string, in such a case, memcpy(3) makes more sense and gives more efficiency. If the argument is the size of the buffer, since you probably not be able to resize the buffer, the buffer must be NUL-terminated. In such a case, strlcpy(3) should be used instead.

The similar problem also happens to strncat(3), and there is also a strlcat(3). But wait... When the last time you use str*cat? If you do want the performance, memcpy is still the best choice; and if you want a clean logic, you can always use snprintf(3), or my favorite asprintf(3) if you are not tied to an existing buffer.

Don't be fear of the dynamic allocation, which may be the only approach if you have to handle an input with an unlimited length, like, a very long line. getline(3) perfectly replaces fgets(3) here. getline(3) manages a reusable dynamically allocated buffer, so that you only need to free(3) it once after you've finished reading all the lines. Ah, yes, the GNU readline(3) should be criticized here -- you have to call free(3) for each line you read -- time to switch to the BSD editline(3) API.

Links:

[1] Nul-terminated string. https://en.wikipedia.org/wiki/Null-terminated_string

When I'm watching animations or galgames, I occasionally post interesting screenshots to Twitter. I always use Xv (http://www.trilon.com/xv/), a very old image manipulation software. Hopefully it supports PNG. However, I have two requirements that it does not meet. First, it's not simple enough for me to save a deflate-9 compressed PNG; you always have to choose a quality. Second, sometimes I want to highlight the interest part on a screenshot; Gimp can do it, but it's way too slow and complicate.

So I wrote a Python script, savescr.py (https://github.com/lichray/savescr) to take screenshots with ImageMagick's import command. Call the script without an argument will take a screenshot with window frame/border; use the -n option to exclude them. The whole GUI is a standard Gtk2 FileChooserDialog, with a scrollable preview widget embedded. Later, I added the commenting toolbar to the preview widget: you choose from 6 predefined color, and draw on the screenshot with a predefined transparency; the brush size is 12pt (DPI related). Right click on the screenshot or click on the selected color again will go back to the scrolling mode.

The graphic part is done by Cairo. I learned a lot about Cairo during the development but I have only one thing to say about how to use it - just redraw everything :(

You might already be using some lightweight display managers, like SLiM, LightDM. But if you did not configure them completely, you might never actually log into your system. Just try a `lastlogin` command on a terminal, and see the last time you logged in on display :0.

A typical non-X terminal involves 3 parts: getty(8), login(1), and a shell. getty serves at the terminal, calls login(1) to authenticate the user. After that, login(1) records the login event and calls the user's login shell.

A login event is recorded using utmp/utmpx, wtmp/wtmpx, and lastlog. In other word, if a login process failed to update these, your login is not "noticed" by the system.

A display manager, should perform the similar circle. XDM is known to do everything correctly, as well as GDM, which reinvented the wheel:) SLiM needs to be configured https://wiki.archlinux.org/index.php/Slim#Login_information_with_SLiM , but fails to setup the user's environment variables without pam_env.so, which is unavailable under FreeBSD... Ubuntu's chosen LightDM  https://bugs.launchpad.net/ubuntu/+bug/871070 , well, as usual, no luck...

I chose XDM since it's correct enough. I replaced its login logo with Yui's "stoppu" :)

If you have a small C/C++ project using libedit,

~/devel/myshell> ls builtin.cc command.cc editline.h parser.c shell.cc myshell.cc builtin.h command.h main.cc parser.h shell.h myshell.h

How do you prepare the Makefile for it? CMake? Then you have to write a CMakeLists.txt file first. GNU autotools? I hope you know how to use them.

With ccconf, https://github.com/lichray/ccconf, to get a Makefile is as simple as

~/devel/myshell> ccconf -edit ==> Configuring for myshell ==> myshell depends on library: libedit.so - found ==> Writing Makefile ... done

Yes, you've done! Options start with `-` are regarded as shared libraries, and options start with `+` are passed to `pkg-config`. For example,

ccconf a.out -m +gtk+-2.0 CFLAGS+='-Wall'

Music Play Daemon (MPD) is my favorite solution to play music -- I use more professional tools to manage the music library, but prefer the cheapest way to control the playback.

I'm too lazy to move my mouse, so no GUI MPD clients. Curses-based client? It occupies a terminal. And it's quite hard to switch playlists/directories in a curses UI. I just want something works in the terminal, like mpc, and switches directories with completion.

I wrote the following tcsh recipe to use mpc more efficiently:

# fill in your music directory path set MPD_BASE = "$HOME/Music/" # and the feedback format set MPD_FMT = '[%title%[ by %artist%]]|[%file%]' alias p 'mpc toggle -q' alias s 'mpc stop -q' alias sf 'mpc shuffle -q' alias n 'mpc -f "$MPD_FMT" next | head -1' alias c 'mpc -f "$MPD_FMT" current' alias o 'mpc crop >& /dev/null || mpc -q clear; \\ [ "\!*" ] && mpc load \!* > /dev/null && \\ mpc -f "$MPD_FMT" play | head -1' alias a 'echo \!:1 | sed s@/\$@@ | tr -d \\\n | \\ xargs -0 mpc ls | mpc add && mpc -f "$MPD_FMT" play | head -1' alias + 'mpc -q volume +5; mpc volume' alias - 'mpc -q volume -5; mpc volume' complete o 'p/1/`mpc lsplaylists`/' complete a p@1@D:$MPD_BASE@

My GSoC2011 project, "Multibyte Encoding Support in Nvi" is ready for testing. This project creates a multibyte fork of the BSD-licensed nvi editor, with only one more dependence, libiconv, comparing to nvi-1.79, which presents in the FreeBSD base system currently, and the libiconv is already included in FreeBSD-current's libc. Updates & features are available at http://wiki.freebsd.org/ZhihaoSoC2011 .

If you want to join the test, you need a -current src tree and a -current base system built WITH_ICONV=1.

First, download the patch from https://github.com/downloads/lichray/nvi2/nvi2-freebsd-2011-08-17.diff.gz

Second, gunzip it, cd to the src tree (e.g., /usr/src) and patch the src tree with

patch -p0 < ${patch_to}/nvi2-freebsd-2011-08-17.diff

Then cd to usr.bin/vi under the src tree,

make WITH_ICONV=1

Now you can run the new nvi with ./nvi . If you want to replace the system vi with this one,

make WITH_ICONV=1 install

*NOTE*

MuPDF http://mupdf.com/ is a part of the Ghostscript project. I considered it as the fastest existing PDF reader (while producing high-quality rendering result). An evidence which made me switch to it from any other poppler-based PDF reader[1] is, such a reader takes several seconds to render every page, which contains complex PDF vector graphics[2], in one of my math books, while MuPDF can render the whole book instantly.

MuPDF is also fast when displaying pages. It's the only existing PDF reader that makes use of Xshm. And it only uses built-in fonts when a PDF asks for an local font -- this also protects MuPDF from improper fontconfig configurations.

About a month ago, I got the maintainership of mupdf in the FreeBSD ports[3]. Recently, I made two patches to make the MuPDF easier to use.

Scroll hack. Allows j, k and mouse to scroll across page boundary.

DPI detection. Instead of using a hardcoded DPI, obtain it from X.

These patches apply to mupdf-0.8.165. You can get them from CVSWeb: http://www.freebsd.org/cgi/cvsweb.cgi/ports/graphics/mupdf/files/

The original ideas come from an Archlinux package[4]. Thanks 范宇航 for sent me the link.

Links:

[1] Like evince, zathura. Poppler engine is based on Xpdf. http://freedesktop.org/wiki/Software/poppler

[2] "... for rendering page, Evince is much slower than acroread, especially for the complicated documents." http://live.gnome.org/Evince/ComparingEvinceAcroread

[3] http://www.freshports.org/graphics/mupdf/