第十三號艦隊
0%

Posted on Edited on In ,

相信大家都有用過grep來找文字，不過這個ack是專為程式設計師開發的。
從官網下載並安裝

1
2
3
$ curl http://beyondgrep.com/ack-2.12-single-file > ack
$ sudo mv ack /usr/local/bin
$ sudo chmod 755 /usr/local/bin/ack

ack有以下這些特性

  • 預設就搜尋當前目錄
  • 預設搜尋所有子目錄
  • 忽略Metadata資料節，如.svn和.git等
  • 忽略Binary檔
  • 印出找到Pattern的行號
  • 能夠搜尋特定文件類型的檔案 (如Perl/C++)
  • Highlight搜尋結果
  • 支持Perl的Advance Regular Expression

幾個常用的功能

如何只搜尋eat而忽略掉feature和`eating

1
$ ack -w eat

當Pattern中有特殊字元的時候，需要當作Literal chracter被匹配

1
$ ack -Q '$path/$'

放棄搜尋某些目錄

1
$ ack about --ignore-dir=downloads

列出某些特定文件類型的檔案，列出擁有Pattern的檔案名稱

以Makefile為例，可能的檔名有 *.mk, makefile, Makefile
我們想知道這些檔案裡面哪些定義了CFLAGS，就能夠這樣作

1
$ ack --make -l CFLAG

Highlight某些特定Pattern

1
$ tail -f /var/log/syslog | ack --passthru 192.168.1.10

這裡的passthru是不管有沒有匹配到都會輸出。

Update

在網路上釉看到ag這套軟體。用途大同小異。多了一些ack沒有的功能。
可以參考Conquering the Command Line Chapter 2. Ack/Ag

Posted on Edited on In

既然git是個自由度很高的version control system，對於該怎麼工作這件事，也沒有什麼固定答案，除了當SVN那樣子用法之外，還有其他答案，因此就有這篇文章的產生。

Simple Git Workflow

重點只有三個

  • 當要開發New features時，就開一個New feature的Branch，且在上面開發
  • 將New feature的Code合併回master
  • 另外準備一個Branch，用作Deploy/Release用，在這邊發布的Code要經過Well test過的

A successful Git branching model

這是上面那種方式的無敵加強版

  • Mainstream從master移到了develop，master只維持穩定的版本。
  • feature分支一樣是開發New feature，完成之後會合併至develop
  • Release branches: 準備要 release 的版本，只修 bugs。從 develop 分支出來，完成後 merge 回 master 和 develop
  • Hotfix branches: 等不及 release 版本就必須馬上修 master 趕上線的情況。會從 master 分支出來，完成後 merge 回 master 和 develop
    這套流程固然強大，不過太複雜了。
    用git-flow可以幫助簡化一些情況。
    可以參考Git flow 開發流程

Github flow

有鑑於上面那種方式太複雜，又衍生出來的新方式，也是GitHub自己在用的工作流程。感覺很像第一種方式，不過加上了Code review的能力。

Posted on Edited on In , ,

Helgrind 和 DRD

這兩個工具都是Valgrind的一部分，用途也相同，檢查Thread error，不過用的策略不同，可以交替使用檢茶室否有無隱藏的錯誤。
以下是從Binary hacks抄下的範例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#include <pthread.h>
static int count = 1;
void *incr_count(void *p) {
        count++;
        return 0;
}
static pthread_mutex_t m1 = PTHREAD_MUTEX_INITIALIZER;
static pthread_mutex_t m2 = PTHREAD_MUTEX_INITIALIZER;
void *lock_m1_then_m2(void *p) {
        pthread_mutex_lock(&m1);
        pthread_mutex_lock(&m2);
        pthread_mutex_unlock(&m2);
        pthread_mutex_unlock(&m1);
        return 0;
}
void *lock_m2_then_m1(void *p) {
        pthread_mutex_lock(&m2);
        pthread_mutex_lock(&m1);
        pthread_mutex_unlock(&m1);
        pthread_mutex_unlock(&m2);
        return 0;
}
int main() {
        pthread_t t1, t2, t3, t4;
        pthread_create(&t1, NULL, incr_count, NULL);
        pthread_create(&t2, NULL, incr_count, NULL);
        pthread_create(&t3, NULL, lock_m1_then_m2, NULL);
        pthread_create(&t4, NULL, lock_m2_then_m1, NULL);
        pthread_join(t4, NULL);
        pthread_join(t3, NULL);
        pthread_join(t2, NULL);
        pthread_join(t1, NULL);
        return count;
}

裡面有兩個錯誤，一個是count在multi-thread的情況沒有保護，這種情況也可以用下面的thread-sanitizer偵測出來。
另外一種情況就是lock的順序不同，導致Deadlock的情景。
編譯且執行

1
2
$ gcc demo.c -o demo -lpthread
$ valgrind --tool=drd ./demo

輸出太長，列出感興趣的部份

==5172== Possible data race during write of size 4 at 0x600C90 by thread #3
==5172== Locks held: none
==5172== at 0x40065F: incr_count (in /home/hungming/a)
==5172== by 0x4C2DB38: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5172== by 0x4E3BE99: start_thread (pthread_create.c:308)
==5172==
==5172== This conflicts with a previous write of size 4 by thread #2
==5172== Locks held: none
==5172== at 0x40065F: incr_count (in /home/hungming/a)
==5172== by 0x4C2DB38: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5172== by 0x4E3BE99: start_thread (pthread_create.c:308)

上面這編列出可能有data-race的情形。

==5172== Thread #5: lock order “0x600CA0 before 0x600CC8” violated
==5172==
==5172== Observed (incorrect) order is: acquisition of lock at 0x600CC8
==5172== at 0x4C2DFCD: pthread_mutex_lock (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5172== by 0x4006FB: lock_m2_then_m1 (in /home/hungming/a)
==5172== by 0x4C2DB38: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5172== by 0x4E3BE99: start_thread (pthread_create.c:308)
==5172==
==5172== followed by a later acquisition of lock at 0x600CA0
==5172== at 0x4C2DFCD: pthread_mutex_lock (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5172== by 0x40070B: lock_m2_then_m1 (in /home/hungming/a)
==5172== by 0x4C2DB38: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5172== by 0x4E3BE99: start_thread (pthread_create.c:308)

這邊告訴我們lock的順序不對。
更多的使用方法可以參考
Helgrind使用說明
DRD使用說明

thread-sanitizer

thread-sanitizer現在已經是LLVM的一部分，在編譯LLVM的時候就會編譯完成，而GCC 4.8之後也支援thread-sanitizer。
這跟上面的不同是檢查data-race issue。
寫個sample code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <pthread.h>
int Global;
void* Thread1(void* x) {
        Global++;
        return NULL;
}

void* Thread2(void* x) {
        Global--;
        return NULL;
}

int main() {
        pthread_t t[2];
        pthread_create(&t[0], NULL, Thread1, NULL);
        pthread_create(&t[1], NULL, Thread2, NULL);
        pthread_join(t[0], NULL);
        pthread_join(t[1], NULL);
        return 0;
}

這個範例很簡單，可以看出 Global 在不同Thread下操作可能出現問題。
編譯且執行，注意要加上-fsanitize=thread

1
2
$ clang simple_race.c -fsanitize=thread -g
$ ./a.out

同樣列出我們所關心的部份

WARNING: ThreadSanitizer: data race (pid=4441)
Location is global ‘Global’ of size 4 at 0x7f4d31e90ad8 (a+0x0000016caad8)
SUMMARY: ThreadSanitizer: data race ??:0 Thread2

有了Tool之後，從Log分西問題出在哪就便得很重要了。

Posted on Edited on In

在網路上搜尋了一下，發現這功能真是好用。
原先的git submodule缺點不少，一堆批評的聲音。因此之後就有git subtree的誕生，，官方也建議用git subtree解決大部分的問題。

主要應用在兩個場景

引用另外一個Repository的管理

假設在我們的Repository當中，需要引用另一個Repository(如Application需要3rd party library)的內容時，盡其希望其Repository能夠跟著更新，一旦我們對其修改時，也能擁有修改和提交的權利。

第一步： 建立目前Repository跟Sub Repository的關聯性

1
2
$ git remote -f add <name of sub_repo> <address of sub_repo>
$ git subtree add --prefix=<name of sub_directory> <name of sub_repo> <branch> --squash

第一個指令加上-f是建立關聯之後再度進行fetch作業。
而第二個指令加上--squash是要把Sub Repository的history合併成一個。
例如

1
2
$ git remote add -f ai https://github.com/aoxu/ai.git  
$ git subtree add --prefix=ai ai master --squash

第二步： 更新Sub Directory

一旦Sub Repository有人更改之後，我們希望把修改的東西合併到我們 Repository中。

1
2
$ git fetch <name of sub_repo> <branch>
$ git subtree pull --prefix=<name of sub_directory> <name of sub_repo> <branch> --squash

這就類似上面的情況了，一樣給的範例

1
2
$ git fetch ai master  
$ git subtree pull --prefix=ai ai --squash

第三步： 將修改推送到Remote Repository

Push只需要一個步驟

1
$ git subtree push --prefix=<name of sub_directory> <name of sub_repo> <branch>

同樣有個範例

1
$ git subtree push --prefix=ai ai master

如果不用git subtree的話，也有個Subtree merge strategy見仁見智了。

參考資料：

將Sub directory拆成令外一個Repository

這剛好跟上面那個使用奇境相反，使用方式如下

第一步： 先將sub directory的資料建立new branch

1
$ git subtree split -P <sub_directory> -b <branch>

第二步： 準備new repository並且啦取原先repository的branch資訊

1
2
3
$ mkdir <new-repo> && cd <new-repo>
$ git init
$git pull <path of original repo> <name-of-new-branch>

第三步： 建立Remote Repository的關聯並推送到遠方

1
2
$ git remote add origin <git@github.com:my-user/new-repo.git>
$ git push origin -u master

參考資料：

Posted on Edited on In

看了書之後豁然開朗啊，之前還真是個半調子。總結一下使用情境。

從失敗的例子講起

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
struct Obj {
  string name_;
	Obj(const string& name) :name(name_) {}
	~Obj() {}
};
class ObjFactory {
	map<string, shared_ptr<Obj>> lookup_;
public:
	shared_ptr<Obj> get(const string &name)
	{
		auto it = lookup_.find(name);
		if (it != lookup_.end())
			return it->second;
		lookup_[name] = shared_ptr<Obj>(new Obj(name));
		return lookup_[name];
	}
};

這段程式碼最大的問題就是，如果ObjFactory的instance沒被摧毀，所有拿到的Obj都不會被釋放。

用 weak_ptr 取代 shared_ptr

在ObjectFactory的部份不要保存shared_ptr，這樣會增加reference count，用weak_ptr取而代之。需要的話再promotion成shared_ptr。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class ObjFactory {
	map<string, weak_ptr<Obj>> lookup_;
public:
	shared_ptr<Obj> get(const string &name)
	{
		auto it = lookup_.find(name);
		if (it != lookup_.end())
		{
			shared_ptr<Obj> obj((it->second).lock());
			return obj;
		}
		shared_ptr<Obj> instance(new Obj(name));
		weak_ptr<Obj> obj(instance);
		lookup_[name] = obj;
		return instance;
	}
};

看起來沒什麼問題，不過譽到以下這種情況就爛了

1
2
3
4
5
6
7
8
9
10
for (int i = 0; i < 3; i++)
{
	shared_ptr<Obj> s = pFactory->get("HM");
	if (s) {
		cout << "create new obj" << endl;
	}
	else {
		cout << "cannot create new obj" << endl;
	}
}

我們希望看到的是每次都能拿到一個新物件，結果發現只有第一次能成功。原因出在當Obj被摧毀的時候，沒有順便清理掉ObjFactory 當中的lookup_的資料，以致於下一次使用的時候，可以找到上一次殘留的屍體，promtion之後就是一個空的shared_ptr。
解決方法就是使用shared_ptr時，同時自訂一個destructor，除了釋放memory之外，也把map裡面的資料輕空。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class ObjFactory {
	map<string, weak_ptr<Obj>> lookup_;
	void deleteObj(Obj *pObj)
	{
		lookup_.erase(pObj->name_);
		delete pObj;
	}
public:
	shared_ptr<Obj> get(const string &name)
	{
		auto it = lookup_.find(name);
		if (it != lookup_.end())
		{
			shared_ptr<Obj> obj((it->second).lock());
			return obj;
		}
		shared_ptr<Obj> instance(new Obj(name), bind(&ObjFactory::deleteObj, this, placeholders::_1));
		weak_ptr<Obj> obj(instance);
		lookup_[name] = obj;
		return instance;
	}
};

現在看起來正常了，不過街下來這個Case又會遇到問題。

1
2
3
4
{
	shared_ptr<Obj> obj1 = pFactory->get("Obj1");
	delete pFactory;
}

由於在這個block之內，pFactory已經被釋放了，所以那個destructor的this一點都不可靠，因此要把裡面那個this轉成一個shared_ptr。

enable_shared_from_this

enable_shared_from_this就是因此登場的，他可以把this指標所在的位置轉成一個shared_ptr。
而原先的測試部份也必須用shared_ptr管理了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
class ObjFactory : public enable_shared_from_this<ObjFactory> {
	map<string, weak_ptr<Obj>> lookup_;
	void deleteObj(Obj *pObj)
	{
		lookup_.erase(pObj->name_);
		delete pObj;
	}
public:
	shared_ptr<Obj> get(const string &name)
	{
		auto it = lookup_.find(name);
		if (it != lookup_.end())
		{
			shared_ptr<Obj> obj((it->second).lock());
			return obj;
		}
		shared_ptr<Obj> instance(new Obj(name), bind(&ObjFactory::deleteObj, shared_from_this(), placeholders::_1));
		weak_ptr<Obj> obj(instance);
		lookup_[name] = obj;
		return instance;
	}
};
	{
		shared_ptr<ObjFactory> pFactory(new ObjFactory);
		shared_ptr<Obj> obj1 = pFactory->get("Obj1");
	}

Misc

使用shared_ptr會延長ObjectFactory的LifeCycle，如果pFactory已經不在的話，跟本連清理的動作都不用作。
所以程式可以寫成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
class ObjFactory : public enable_shared_from_this<ObjFactory> {
	map<string, weak_ptr<Obj>> lookup_;
	static void deleteObj(const weak_ptr<ObjFactory> &pWeakFactory, Obj *pObj)
	{
		shared_ptr<ObjFactory> pFactory(pWeakFactory.lock());
		if (pFactory) {
			pFactory->lookup_.erase(pObj->name_);
		}
		delete pObj;
	}
public:
	shared_ptr<Obj> get(const string &name)
	{
		auto it = lookup_.find(name);
		if (it != lookup_.end())
		{
			shared_ptr<Obj> obj((it->second).lock());
			return obj;
		}
		shared_ptr<Obj> instance(new Obj(name), bind(&ObjFactory::deleteObj, 
			weak_ptr<ObjFactory>(shared_from_this()), placeholders::_1));
		weak_ptr<Obj> obj(instance);
		lookup_[name] = obj;
		return instance;
	}
};

結論

有本好書真的很重要啊，以前我只會用最粗淺的shared_ptr，對於wear_ptr跟其他特性玩全部熟。有了範例之後至少有個基本認識。
至於程式寫得這麼複雜到令人髮指也是不太好，Garbage collection很大部份可以紓解Programmer的負擔。

Posted on Edited on In ,

其他語言已經有yield的語意了，不過C/C++必須手動模擬。
看了Coroutines in C之後，做了一下實驗。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
int func()
{
	static int i, state = 0;
	switch (state)
	{
	case 0: goto LABEL0;
	case 1: goto LABEL1;
	}
LABEL0:
	for (i = 0; i < 10; i++) {
		state = 1;
		return i;
LABEL1:;
	}
	return -1;
}

測試VC12、GCC和Clang之後，發現GCC要使用C99模式編譯才會成功。
不過美增加一個狀態就得增加一個LABEL，也是蠻麻煩的一件事，後來看到一個作法更好，之前從沒想過能這樣用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
int func()
{
	static int i, state = 0;
	switch (state)
	{
	case 0:
		for (i = 0; i < 10; i++) {
			state = 1;
			return i;
	case 1:;
		}
	}
	return -1;
}

從沒想過switch/case的statement可以這樣用，開了眼界了。

Posted on Edited on In , , ,

在C++11中，可以這樣用已經不是什麼新鮮事了。

1
2
3
4
5
vector<int> vec;
for (int i : vec )
{
    cout << i << endl;
}

如果要在自己的container支援這特性的話，需滿足以下條件。

  • Container必須擁有begin、end函數，這兩個函數必須回傳一個 Iterator 。
  • Iterator必須擁有*、++ (prefix版)、!=這三個operator function。
    以下範例是從C++11 range-based for loops修改而來，加上自己的實驗。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    #include <iostream>
    #include <algorithm>
    using namespace std;
    class IntVector;

    class ConstIter
    {
    public:
    	ConstIter(const IntVector* p_vec, int pos)
    		: _pos(pos)
    		, _p_vec(p_vec)
    	{ }
    	bool operator!= (const ConstIter& other) const
    	{
    			return _pos != other._pos;
    	}
    	int operator* () const;
    	const ConstIter& operator++ ()
    	{
    		++_pos;
    		return *this;
    	}
    private:
    	int _pos;
    	const IntVector *_p_vec;
    };

    class Iter
    {
    public:
    	Iter(IntVector* p_vec, int pos) : _pos(pos)	, _p_vec(p_vec)	{ }
    	bool operator!= (const Iter& other) const
    	{
    			return _pos != other._pos;
    	}
    	int& operator* ();
    	Iter& operator++ ()
    	{
    		++_pos;
    		return *this;
    	}
    private:
    	int _pos;
    	IntVector *_p_vec;
    };

    class IntVector
    {
    public:
    	int get(int col) const { return _data[col];	}
    	int& get(int col) {	return _data[col]; }
      
    	IntVector()	{}



    	Iter begin()
    	{
    		return Iter(this, 0);
    	}

    	Iter end()
    	{
    		return Iter(this, 100);
    	}

    	ConstIter begin() const
    	{
    		return ConstIter(this, 0);
    	}
    	ConstIter end() const
    	{
    		return ConstIter(this, 100);
    	}

    	void set(int index, int val)
    	{
    		_data[index] = val;
    	}

    private:
    	int _data[100];
    };

    int
    ConstIter::operator* () const
    {
    	return _p_vec->get(_pos);
    }

    int&
    Iter::operator* ()
    {
    	return _p_vec->get(_pos);
    }

    int main()
    {
    	IntVector v;
    	for (int i = 0; i < 100; i++)
    		v.set(i, i);
    	transform(v.begin(), v.end(), v.begin(), [](int v) { return v * 2; });
    	for (int& i : v) { i *= 2; }
    	for (const int& i : v) { cout << i << endl; }
    }
    在gcc跟clang都能正常運作，不過到了VC12 Debug Mode就編譯失敗了。
    這是由於Checked Iterator這巷特性。
    最快的解決方案是在前面加上
    1
    2
    3
    4
    5
    6
    #ifndef _ITERATOR_DEBUG_LEVEL
    #define _ITERATOR_DEBUG_LEVEL 0
    #else
    #undef _ITERATOR_DEBUG_LEVEL
    #define _ITERATOR_DEBUG_LEVEL 0
    #endif

Posted on Edited on In , ,

在整理Concurrency programming資料的時候，發現這個部份被我遺漏了，寫點東西免得忘記。
libdispatch 是由蘋果開發的Concurrency framework，如今也可以在FreeBSD上使用。

從FreeBSD Wiki上找來的範例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <dispatch/dispatch.h>

#include <err.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
        dispatch_queue_t q;
        dispatch_time_t t;

        q = dispatch_get_main_queue();
        t = dispatch_time(DISPATCH_TIME_NOW, 5LL * NSEC_PER_SEC);

        // Print a message and exit after 5 seconds.
        dispatch_after(t, q, ^{
                printf("block_dispatch\n");
                exit(0);
            });

        dispatch_main();
        return (0);
}

看到那個 ^{ .... } 區塊的部份就類似於其他語言的Closure，C++11的lambda expression。
至於要編譯這段程式碼，就需要

1
# clang -Wall -Werror -fblocks -L/usr/local/lib -I/usr/local/include -o test test.c -ldispatch

Blocks是Clang的Extension，更多資訊可以參考Programming with C Blocks，GCC不支援，至於libdispatch需要在ports下事先安裝。編譯的時候要記得加上-fblockss。
當然，也可以有無Blocks的版本。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <dispatch/dispatch.h>

#include <err.h>
#include <stdio.h>
#include <stdlib.h>

void
deferred_code(__unused void *arg)
{

        printf("block_dispatch\n");
        exit(0);
}

int main(int argc, char *argv[])
{
        dispatch_queue_t q;
        dispatch_time_t t;

        q = dispatch_get_main_queue();
        t = dispatch_time(DISPATCH_TIME_NOW, 5LL * NSEC_PER_SEC);

        dispatch_after_f(t, q, NULL, deferred_code);

        dispatch_main();
        return (0);
}

編譯的時候就可以拿掉-fblocks了

1
# clang -Wall -Werror -I/usr/local/include -L/usr/local/lib -o test2 test2.c -ldispatch

除了Cuncurrency之外，Closure的觀念也在很多程式語言開枝散葉了。

這個pdf有對libdispatch作個簡單的介紹。
在各語言下都有類似libdispatch這樣的Framework

Posted on Edited on In

雖然大部分時間都在Windows/Linux底下打轉，FreeBSD被我晾在一旁(時間不夠用Orz)
不過趁著FreeBSD 10.0 Release。
把自己的9.1-Release升級到10.0-Releae，並把過程記錄下來。

1
2
3
4
5
6
7
# freebsd-update upgrade -r 10.0-RELEASE
# freebsd-update install -r 10.0-RELEASE
# reboot
# freebsd-update install
# reboot
# uname -ra
FreeBSD freebsd 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

安裝完10.0之後，發現gcc不存在於，全部用clang取代掉了。
另外就是使用 pkgng 來當做新的Package manager，用法就類似於 apt 或 yum。

1
2
3
4
5
6
7
8
9
# pkg update
# pkg search vim
vim-7.4.110_3
vim-lite-7.4.110
vimpager-1.8.3
xpi-vimperator-3.5
# pkg install vim-7.4.110_3
# pkg remove vim-7.4.110_3
# pkg autoremove

更多的使用可以參考pkgng: First look at FreeBSD’s new package manager