公告: 暂停新用户注册
因垃圾注册用户过多，本网站暂停新用户注册。
CN Erlounge III - Topic征集
重要时间点
- 讲师注册及Topic征集截止日期：2008-11-25
- 普通参会者报名截止日期： 2008-12-1
- 讲师投稿截止日期：2008-12-9
- 详细会议议程安排公布：2008-12-13
- 会议日期：2008-12-20 ~ 2008-12-21
CN Erlounge III - Topic征集
为了对会议的议题有所把控，我们修改了下会议的规则，将讲师注册（Topic收集）和讲师投稿分为两个阶段，而不是原先的一个时间段。讲师注册（Topic收集）的截止时间提前到了 2008-11-25。投稿截止时间不变。
Topic范围
讲师的议题是否必须限定和 Erlang 相关呢？答案是否定的。我们都关注 Erlang，但不能也不想限制自己的眼界，Erlang 决不是我们唯一。只要你的议题和 Erlang 关注的问题域相关，和分布式、多核相关，就没有“跑题”。Erlang 社区应该是睿智的、包容的。
讲稿建议
- 内容有深度，而不是泛泛而谈。忌局限于一个事实或者一个实践，但是没有任何结论。
- 内容有一个Focus的问题域。告诉大家你要解决什么问题，它又是如何被解决的。
- 如果能够结合一个实际的应用实践，那是最棒不过了。
Erlang China 大会 - CN Erlounge III - 发起
详细信息参阅： http://ecug.org/
欢迎大家四处传播此消息。 :)
—-
CN Erlounge III - 发起
- 时间：2008-12-20 ~ 2008-12-21，为期2天
- 地点：上海（详细地址待确定）
- 人物：面向 Erlang 中国社区，但不排斥其他任何对 Erlang、分布式、多核等话题感兴趣的人。
- 议题： Erlang 语言相关技术、Erlang 应用、Erlang 与其他语言协作、分布式、多核等等。
- 会议主持：ECUG 会务组
会议形式
- 多数时间由交流会讲师针对某个 Topic 进行论述，其他人提问（Q&A）方式交流。
- 留出一小段时间，安排沙龙式的对等交流机会。
会议规则
- 会议的讲师报销来回路费和住宿（投稿并申请成为讲师）。
点击这里可以查看已经确定的讲师名单。 - 任何人可报名免费参与听讲（注册并申请参加本会议）。
注：由于场地限制，我们可能没法接受所有的与会申请，请谅解。
重要时间点
- 普通参会者报名截止日期： 2008-12-1
- 讲师报名&投稿截止日期：2008-12-9
- 详细会议议程安排公布：2008-12-13
- 会议日期：2008-12-20 ~ 2008-12-21
TPL: Text Processing Library (tpl-1.0.00)
文本处理 (Text Processing)
文本处理其实就是IO。故而文本处理通常可分为两块：一块是I，一块是O。I是指把文本Parse为内存数据结构（DOM），O则相反。
联想：XMLParser是I（将XML文本变为DOM），而XSLT是O（将DOM变为文本）。
I典型的模块有：
- xxxParser（如HTMLParser，XMLParser，JsonParser, etc）
- RegExp（正则表达式，非特定目的的Parser）
O典型的模块有：
- XSLT
- CTemplate (google)
- Format: printf, etc.
问题域： TPL关注什么？
TPL顾名思义，是文本处理库（或者你也可以理解为文本处理语言Text Processing Language，因为尽管它依附于C++语言，但是实际上你使用它时并不按照C++的思维考虑问题）。
TPL目前主要关注文本处理中I的问题。即将文本Parse为内存数据结构（DOM）。
TPL可以做什么？
TPL有很强的适应性。可以做简单的如进行文本分割，复杂的可以做一个语言的编译器。TPL的典型使用场景：
- 字符串分割
- 信息抽取（Information Retrieval）
- 命令行分析（Command Line Analyzer）
- 编译器（Compiler）
- …
TPL-1.0.00
TPL的核心目前主要包含：
- tpl/RegExp.h - 正则匹配文法
- tpl/Emulator.h - 一个通用虚拟机 (从根本上来讲，虚拟机和文本处理并无相关，但是一般虚拟机用于实现一门语言，而实现一门语言必然需要进行文本处理)
TPL的扩展组件，包括:
- tpl/c/Lex.h - C/C++词法
- tpl/boost/Lambda.h - TPL与Boost Lambda的粘合剂
- tpl/ext/Calculator.h - 计算器辅助模块（计算器定义：一门简单语言，它不能定义由用户来定义函数/过程，但可以有变量）
TPL的样例
See http://winx.googlecode.com/svn/trunk/tpl/examples/.
目前 tpl/RegExp.h （正则库）相关的样例有：
- simplest: 最简单TPL样例，类似Hello, world!
- grammar: 还是简单样例，稍微加了点复杂性。
- urlparams: 用TPL分析url参数。即prop1=val1&prop2=val2&prop3=val3…
- calculator: 用TPL实现一个计算器。支持+-*/、()、sin/cos/pow/max
- removecomments: 删除C++代码中的注释。
- removecomments2: 还是C++代码中的注释。但是使用了tpl/c/Lex.h扩展模块。
- includefiles: 提取C++源文件中的include文件列表。可改善下做代码依赖关系的定性分析。
目前 tpl/Emulator.h （虚拟机）相关的样例有：
- emulator: 演示我们的虚拟机汇编指令。
- variant: 演示虚拟机的类型系统。
TPL工程主页及下载地址
发布ScopeAlloc
最近发布了一个比AutoFreeAlloc还好用的GC Allocator：ScopeAlloc。欢迎探讨。
参见：http://cpp.winxgui.com/cn:a
另外，考虑到StdExt库的通用性比WinxGui库强，我决定将其独立发布。
喜欢Erlang的三大理由
- erlang严谨的，有严格的理论基础。但erlang同时也是务
实的，他不是实验产品。这和我发布的winx库理念一样：务实。 - 一点都不喜欢防御式编程，所以看到erlang的fail fast理念，眼睛一亮。这几天实践下来，更是爱不释手。
- 也许你在乎erlang不能提供array的便利。但是想象一下
，当我们有成千上万个单体（进程）在跑时，我们还会过分在意单体的 速度吗？在计算机的power越来越强时，我更关注的是单体间如何 协调，如何提供持续服务。 要想实现正真意义上的人工智能，我的观念，必须有无穷多个可以独立 计算的单体（细胞），他们之间通过消息相互指令，而又保持独立 。所以只有类似erlang这样的工作机制，才有可能实现 “人工智能”。另外array在数据海量的情况下，弊端立即凸显 。所有基于array的数据结构，如hash_map等 ，遭遇严重的性能瓶颈。所以，最好的数据结构，还是表处理。
关于array性能瓶颈的注解：
- 我在做电子表格的存盘时，因为用到了mfc的CMap（是一个HashMap），在大文件存盘时失去响应。使我头一次对HashMap的效率产生质疑。
- 去年这个时候，我在C#中，尝试了向一个Dictionary（是一个HashMap）加入1亿条整数，花了整整一天时间没有完成，最后Kill进程告终。改用C++的std::map（红黑树），1小时搞定。后在C#改用OrderedDictionary（应该也是红黑树），2小时搞定（之所以比C++慢，是C++的map::insert操作以inline提供的缘故）。
当然HashMap也并非真的一定会在海量数据时很慢。如果我们可以预测数据集的大小，HashMap肯定还是比红黑树快。但是问题就在这个前提。我们可以准确预知未来吗？我们不能。所以HashMap要想获得好的性能，很累。但是如果我们采用树结构，我们获得的性能是稳定的，可以预测的。
VisualFC0.75发布
发布VisualFC0.75，使用了新的基于树状的管理页面并修正上一版(0.72)在VS2005/VS2008下加载的错误。 阅读这篇文章的其余部分 »
开源，选择Google Code还是Sourceforge？（修订版）
一年前，我写下了“开源，选择Google Code还是Sourceforge？”，如今，Google Code又今非昔比了。抽时间好好整理了下，写一篇更新版，以免误导他人。下文也着重会就这一年来Google Code变化部分进行说明。
概要
提起Google Code，我需要很惭愧地承认一点，我一开始的时候“把它看扁了”。初接触Google Code的时候，我简单地认为，Google Code只是一个半成品，从各方面的功能来讲，似乎远不能够与Sourceforge的完备相比。但是，随着对Google Code了解的深入，我不能不承认我错了，Google Code再一次证明“简单是美”的法则：Google的服务似乎永远是看似简单（甚至让你觉得不够用），而实则非常完备。
如果你有开源的计划，或者已经开源，或者你有私人的项目希望有个完备的平台去管理它，那么本文值得你一读。到目前为止，我主导或参与了以下开源项目：
- WinxGui: 项目管理员。如今Hosting在Google Code上（http://code.google.com/p/winx/）。
- WTL: 项目成员。Hosting在Sourceforge上（http://www.sourceforge.net/projects/wtl/）。
- VisualFC: 项目成员。是WinxGui的第三方可视化平台。Hosting在Google Code上（http://code.google.com/p/visualfc/）。
- DocX: 项目管理员。限于精力未维护。
- ECUG: 项目管理员之一。不是一个普通意义上的项目，而是Erlang China User Group（Erlang中国用户组）。Hosting在Google Code上（http://code.google.com/p/ecug/）。
- Erlana: 项目管理员。这是一个类似Google Analytics的项目。Hosting在Google Code上（http://code.google.com/p/erlana/）。
选择Google Code，还是Sourceforge？从上面的介绍来讲，我的倾向已经很明显了。当然总体来讲，两者各有各的优势。而从进入的门槛来讲，使用Google Code会比Sourceforge容易很多。
Google Code的优势与劣势
Google Code的优势
- 速度第一。Google的服务以快速著称，Google Code亦不例外。当你上传新的Release时，你会特别感受到这一点。
- 操作简洁。如果Sourceforge和Google Code提供了同样的功能，那么我可以毫不思索的讲，Google Code比Sourceforge快捷易用。我们后文将详细比较各个功能。
Google Code的劣势
- 容易被盾。以我的经验，Google Code被盾比较频繁。这导致我有时无法浏览Bug列表，发布新的Release等等。所幸的是，Google Code的SVN连接从来没有出现访问障碍。因此这不算太大的问题。另外，按Google Code的说法，有些功能可以在命令行进行，而不需要到Web上，但是我本人尚未进行详细的验证。
- 100M的容量限制。让人振奋的是，原先Google Code限制每个项目的SVN空间大小不能超过100M，目前已经取消该限制。不过可惜发布的所有Release总大小仍然不能超过100M。
- 数据统计功能强大但复杂且不实用。原先Google Code基本无数据统计功能。而如今，Google Code集成了对Google Analytics的支持，借助Google Analytics的强劲功能，使得它的统计功能一下子变得比Sourceforge还要强悍！但是，为什么我这里仍然称Google Code的数据统计功能不足呢？这是因为，对于一个Project而言，你的Release的下载情况是一个关键参考量。而Google Code恰恰由于Google Analytics的统计方式缺陷，只能统计了html页面的访问量，而无法统计zip包的下载量。虽然Google Code也引入了DownloadCount概念（例子参见http://code.google.com/p/winx/downloads/list）。但是仅仅提供一个下载总数，相对Sourceforge而言，还是弱了点。
Sourceforge的优势与劣势
Sourceforge的优势
- 更多的受众，已经形成第一开源社区。简单统计结果表明，Sourceforge上大约每5分钟就有一个新的Release。也就是说，一天大约有300个新的发布（这不是精确的统计，只是简单估算）。
- 功能更加完备。目前来看，Google Code在功能上并不比Sourceforge成熟。如果Google Code是一个完整、快捷、功能足够的平台，那么Sourceforge则是一个方方面面均已经相当完备的开发平台。
Sourceforge的劣势
- 操作繁复，速度较慢。
详细功能对比
下面我们展开来对比一下两者的功能：
- 建立帐号。Google Code只要你有Gmail帐号即可。Sourceforge要求你进行注册。而且你发现，Sourceforge的注册流程十分罗嗦。
- 建立项目。Google Code只要你简单填写一下项目的相关信息（http://code.google.com/hosting/createProject），仅一个页面即可完成申请。而Sourceforge的新Project申请流程是繁复的，有很多的下一步，并需要你阅读一些英文细节。另外，你的项目并不马上生效，而是需要进过审批。不出意外的话，在申请之后的第二天再上Sourceforge，你的项目应该通过审批了。
- 代码管理。Google Code仅支持SVN库，Sourceforge支持SVN和CVS。原先Google SVN限制在100M内，现在已经去除该限制。你可以邮件订阅代码库发生的变化（当然，Sourceforge也可以）。
- 代码库的权限管理。Google Code的代码库权限管理非常简单，在你登陆后，http://code.google.com/hosting/settings 将显示Google Code为你自动生成的随机密码。通过你的用户名和这个随机密码，你就可以访问SVN代码库，对其进行修改。sourceforge推荐使用putty套件，详细参考sourceforge上的说明，总的来说，相当繁复。
- 发布版本。Google Code限制所有Release包不能超过100M，单个Release不能超过10M。Sourceforge尚未见到明确的限制。
Google Code发布一个新的Release流程，仍然只需要一个页面即可完成。你只需要选择上传的文件，并为该文件加一些预定义的标签（用于告诉别人你的Release支持的平台或其他信息，这些标签Google Code已经预定义部分，项目管理人员亦可以定义），确认即开始上传。特别地，如果一个Release被打上 Featured 标签，那么它将出现在项目首页。
Sourceforge的流程则比较复杂：- 通过ftp上传你要发布的文件。上传地址：ftp://upload.sourceforge.net/incoming，这个过程匿名进行。上传的文件在你后续的步骤中进行“认领”，如果某个包长时间没人认领，Sourceforge将清理之。
- 进入Sourceforge。用你的Sourceforge帐号登陆。
- 进入项目主页，进入Admin -> FileReleases。
- 选择已有的Package或者新建Package，向该Package中添加一个Release。在你的项目发布的文件比较多（不是发布的历史版本多，而是一次发布的文件多，你可能希望对他们进行归类）时，Package可以更加有条理地管理这些文件。
- 为该Release添加ReleaseNote和ChangeLog。确认。
- 认领你上传到ftp上的文件。打上勾，确认即可。
- 为你发布的文件添加说明（支持的平台、包的格式及其他规格）。
- 如果有人关注这个项目的Release，最后一步，你可以向这些人发送信息，告诉他们发布了新的Release。这一步很有意思，是Google Code不能做到的。
- Bug报告。Google Code中的issues，Sourceforge的tracker。Google Code的issues定制性非常好，并可对issues的变化进行订阅。
- 论坛。Google Code中并不直接提供论坛功能，当然，这是因为它推荐你使用强大的Google Groups。Sourceforge则除了提供给用户的论坛（并把用户论坛分为两个，一个讨论产品功能的，一个属于头脑风暴型的开放式讨论），也提供开发者专用的论坛（对非项目成员不可见）。
- Project Web。这一点上两者各有千秋。
Google Code中没有提供项目主页，而是颇具创意的提供了一个Wiki Pages。值得一提的是，Google Code的Wiki借用SVN来管理版本，构思巧妙之极（详细参见“Unix搭积木思想与Google Code Wiki”）。由于Google Code的SVN支持邮件通知功能，Wiki顺理成章地继承了该功能。
在Google Code上做个wiki页面，然后到source上看看，会发现上面多了wiki目录。进去后，你就就可以看到你的wiki页面源代码被放到了这里。这样做的好处是，你不只是可以在线编辑wiki页面，还可以本地用任何工具修改它。我这样做了。
Sourceforge提供了项目主页，项目主页的地址是：”项目名.sourceforge.net”。你可以利用这个网址来宣传项目、提供项目信息。这个空间是是php+mysql的，并且你可以通过远程Shell控制，极其灵活。
- 团队成员管理。Google Code你可以通过添加其他Gmail帐号为项目成员（Members）或管理员（Administers），但似乎还不能进行更加详细的权限管理。Sourceforge提供了非常精细的项目成员的权限管理。
- 下载与访问统计。Google Code内置了Google Analytics的支持，并简单提供了Release的下载计数（DownloadCount）。Sourceforge提供了最近7日、最近2个月、年、全部访问/下载统计。非常详细。
- 软件截图（ScreenShots）。可以让用户迅速获得项目的第一印象，吸引眼球。Google Code无此功能。
VisualFC下载和安装(WTL WinxGUI可视化开发环境)
简介:
VisualFC完全支持WTL WINXGUI,提供VS60/EVC4/VS2005下的安装插件,支持WTL和WinxGUI的功能包括Message(Event),Notify,Command,DialogResize,,DialogFont,DDX/DDV,UpdateUI等.
一、下载
VisualFC最新版本下载： vfc0.71b_bin.zip
WTL的VS60向导下载：app60wiz ，WTL80目前不提供vs60向导，这个是wtl7.1版本自带的。
WTL的VS60中文向导下载：app60chswiz ，这是我翻译wtl7.1版本，生成中文资源和菜单，欢迎大家使用。
FreeCode更名为VisualFC
FreeCode更名为VisualFC，以便为WINX/WTL提供更好的可视化代码插入功能。大家有好的建议或意见请发送至visualfc at gmail.com。