Liuw's Thinkpad

看到类似这样的代码。

char **arr;
int len;
arr = produce_array(&len);
/* 此时生成了有len个元素的含有内容的数组。用一次free来释放？ */
free(arr);

原来看到free()那里，觉得会有问题，我的想法是要为每一个char *分别malloc内存，所以需要有len次free。其实不然，C语言太灵活了，不要被自己原来固有的想法束缚了才好。完全可以通过一次malloc申请到所有的空间，再活用这些空间。

/* 设有 n 个以 NULL 结尾的字符串放在 data 中，它们的总长为 dlen */
char **produce_array(int *len)
{
  char **ret;
  int i;

  *len = n;
  ret = malloc(sizeof(char *) * n + dlen);
  ret[0] = (char *)(ret + n);
  memcpy(ret[0], data, dlen);
  for (i = 1; i < n; i++)
    ret[i] = ret[i-1] + strlen(ret[i-1]) + 1;

  return ret;
}

目前我们组内对开发的管理还十分初级。Wiki刚刚开始用，没有用trac、bugzilla之类的工程控制工具，只用了Mercurial进行了版本控制，交流主要靠每周例会。

学生开发组织，我觉得是比较难做到规范化开发的。一则因为外围工具的学习成本高，项目等不及；二则因为学生组织与公司不一样，至少不会因为开发流程不规范而被fire掉。在学校里面，老板要的是效果、演示，不管你用什么方法去做。

在目前开发的过程中，也出现了一些问题。原来使用Mercurial的原因，就是一个DVCS看起来更适合我们项目。组内对于Xen都处于摸索的状态，需要做大量的实验，会产生大量的commit。使用svn的话，必须等到特性稳定之后才可以commit，不合适。

当然，实际使用过程中，我们仍然保持有一个“主”版本库，其中含有稳定的代码。原则上来说，主版本库更新之后，每个人都应该与之保持同步。

现在问题来了，大家都没有及时与主版本进行同步，所以现在diverge得越来越远了。到时再想merge的话，conflict将是一个很头痛的问题。但是用svn的话，这种情况就不会出现了。

当然，只要DVCS的使用者注意同步，这也不会是什么大问题。CVCS的好处是，这个步骤是强制的，不能有意无意的略过，大家必须保持一致。

现在我已经预见到以后merge会遇到的痛苦了。

UPDATE：和小胖聊了一下，发现其实还是工作流的问题。人是活的，工具是死的。工作流做好了，活用branch，CVCS也可以解决“不稳定的新特性commit”的问题。所以最现实的，就是把工作流做好。我们缺的不是工具，而是完整的工作流。

看久了眼花, originally uploaded by liuw18.

光谷会展中心6楼的大厅天顶，看久了会眼花。

看此照片，久了之后会发现天顶凸出来了……

New release, new features.

New stubdom target domb.

Working Dom0 daemon dombd, responsible for communicating with DomB.

Usable domain builder inside DomB.

Coming soon…

一个多月了，没地方发泄，不想到淫淫上扯。

就在这里记录一下吧。

该做的都做了，听天由命吧。