Delphi中的自动垃圾回收器

    在传统的开发语言中,分配的内存必须手动释放。但在对象多处引用的时候要判断具体该什么时候释放还真不是件容易的事情。更有甚者不少程序员只创建对象但根本就不进行释放
    听朋友说C++有自动垃圾回收的库,据说用起来还不错。也曾找过Delphi的自动垃圾回收器,未果。最近在找Delphi的容器类的时候看到decal的介绍中有谈到,decal是商业类库SDL的简化版本,去掉了自动垃圾回收等特性。
    今天去下了decal的帮助来看,里面提到垃圾自动垃圾回收是由Boehm来实现的。Boehm?上网搜索一下,找到了《API for Boehm Garbage Collector DLL》。在Delphi中使用自动垃圾回收。下回来看了一下,使用的就是HP的垃圾回收器(GCJ使用的就是这个垃圾回收器)。在Delphi中使用只是写了几个接口文件,调用DLL中的函数而已。
    看了一下里面带的DEMO,再用内存泄露检查工具测试了一下,似乎还挺有效的。使用起来也很简单,只要将GC放到单元引用的第一个就可以了。
    有把她用到了公司的软件里。虽然上次修正过一次,但还内存泄漏问题还是挺严重的。希望加上自动垃圾回收后能有些作用

Delphi果然没卖成功

    今天在QQ群里听说Delphi卖给了DevCo。DevCo?没有听过。再一打听,原来是从Borland分出来的新公司。
    呵,我就说嘛,Delphi这东西我是实在是想不出谁会买。不是幸灾乐祸,只是事实。Delphi的逝去是一个时代逝去。Delphi的优势是RAD,快速开发。Delphi被广泛的用于C/S模式应用程序的开发。但网络的兴起,java、.net的出现,极速侵蚀了原生开发工具的市场。原本许多C/S模式的用程序现在都该用B/S模式。而对于和操作系统及性能要求相对较高的一些应用程序,Delphi由于自身问题及算法库等相关资料的缺失,一直难敌C++。为此Delphi被推向了高不成低不就的两难境地。Delphi注定了他的相对小众。
    小众就小众吧,除非它不出64位的版本,和32位的系统一起发霉,不然应该挂不了。感觉现在的Delphi世界还算正常。以前的一些Delphi程序还需要维护,少量的新项目还在用Delphi。“老人”走了,却未见来者,要找份Delphi的工作也不至于太难。相比前两年,Delphi的寒冬算是过去了。想当年就没看到几个要Delphi的
    Delphi,我依旧喜欢摆弄,却再也不想将其作为一个职业了。
    周末把代码给整一下,给cnpack提交个代码,也算是为我喜欢的这个开源工具做点贡献吧

SF上的项目整完了

    昨天整了几个release文件到SF上,有release就不至于让人觉得这个项目还是荒废着的了。感觉这个项目的第一步工作应该已经做完了。下面可能又得荒废好长一段时间了,也许等到哪天有兴趣会接着动手吧。
    贴上项目在SF的地址:http://sourceforge.net/projects/crystal-cursor
    大家有兴趣可以去看看,不过程序还很简陋的说,大家别笑话啊
    最近退了好几个QQ群,又加了些python、ROR之类的群。一直不太习惯脚本语言,想来也应该因为长时间使用传统语言的原因吧。加些脚本语言的群,熟悉一下脚本语言的应用。

被403郁闷了一晚上

    今天将代码稍微整理了一下,调整了一下工程结构并在代码里面加了些Licence以及单元说明,好让工程看起来更正规一些。文档方面除了从网上down的那一份GPL就一点都没有了。把代码放上去,好歹算是个开始了吧,其他的东西在日后可以慢慢的处理。
    版本控制方面本想用SVN,结果出了一晚上的403错误。为此我还特意更换了个最新的小海龟,还是未果。baidu、google狂找了一通,问题没解决,倒是看到有位兄台和我遇到同样问题。
    无奈下只能换CVS了。还好,不算太糟糕,文件都正常的放进去了。只是在尝试checkout的时候找不到文件。看SF的说明,添加文件后要等待服务器30分钟一次的刷新。不知道代码是不是也是这样。
    暂时不管这些了,明天再来看看,顺便再整份release的代码和程序出来。

SF申请的项目通过审核了

    刚上SF看了一下,项目通过审核了。刚上去看的时候看到项目前面多了个“垃圾桶”我还以为被驳回了。再仔细看一下,原来是将已激活的项目从SF给删除。SF的项目审批速度还挺快的,看上面的审批时间是2006-03-27 15:26(老外的表比我们慢不少)。
    决定先熟悉一下SF的后台管理系统,然后将代码和文档给整理一下。项目既然是放在SF上,那文档什么的最好都用E文吧。可惜的是我的E文实在有些抱歉。决定UI和代码中的注释先用E文吧,至于文档……。先出中文版的,有时间再E文一下。E文拙劣就拙劣吧,反正苦的是看文档的人,我是无所谓了。
    先去熟悉一下SF的后台了

今天去SF申请了个开源项目

    既然搞开源,不管真搞假搞,既然开搞了有些东西还是要做的。首先就得到支持开源的网站去申请个项目,来提供web以及cvs的支持。由于E文问题,本想找个国内的服务商。可是共创的平台郁闷到连个修改个人资料的地方都找不到。GRO更是连注册都无法注册成功。一连注册了两个账号都没能收到确认邮件。
    SF的项目注册还算顺利,只是我的E文太过拙劣,让我自己都觉得有些惨不忍睹。过两天看看审核的情况把。

全面转向Eclipse了

    很长的一段时间里我都是在用eclipse开发,然后再用jbuilder进行调试。原因很简单,eclipse的web开发套件我用的是WTP。WTP这东西有的地方实在是做的太差了。如果你想重头开始个web项目那还好,直接用WTP的向导生成个WEB工程就可以了。但如果是现有的项目,那就没这么方便了。WTP没有提供一个很方便的功能来对已有工程增加wtp的支持,你只能手写。
    以前进行过一次wtp的配置,很不幸,失败了。因此一直懒研究,照旧用JB调试程序。
    最近因为研究springside的原因又研究了一下wtp的配置。呵,发现挺简单的,直接新建一个wtp工程,然后将配置文件改改就可以了,配置文件里属性的含义也都还算清楚。真有些不明白当初怎么会配置不成功。
    在java构建中可以添加文件名过滤功能,WTP却似乎没有相关功能,web目录下的所有文件都被复制到发布目录。
    eclipse的校验真的很讨厌。在工程建好后老是要校验个半天。今天是让它校验了N多遍也没成功完成过一次校验,简直要将人被逼疯,最后将校验关闭后才顺利搞定。
     eclipse的升级也很是个问题。虽然可以在线升级,但在线升级的速度….,小点的插件倒没什么问题,如果插件稍大点那就不知要下后哪年哪月去。而且eclipse的插件在升级后,旧的插件还在,当然,一般eclipse会帮你自动设置为不启用,你只要在插件管理界面卸载就可以了。很不幸,不少插件不能被自动卸载,你得手动去删。
    ………………
    要发牢骚,还可以说一堆eclipse和eclipse插件的坏话。
    既然eclipse以及eclipse的免费插件有这么多的缺点那你为什么还要用?有人说玩开源玩的就是自虐,痛并快乐者。自由免费的代价是,你似乎永远也拥有不了(虽然eclipse也挺商业的,而且已经做的很不错了。)使用商业软件的舒适与便捷。商业软件如果有了什么问题你可以去找厂商,但是免费的东西就没有这么好说话了。既然用免费的东西那就全用免费的吧,慢慢的习惯受虐,不然还真不如去用那些商业软件。反正都要用D版。
    开源?开源首先是种商业模式。这两天一直在想这个问题。也许哪天有兴趣来写写吧。

再谈谈Borland卖IDE

    今天去兔八哥的blog看了看。呵,也在谈论这事。毕竟这对每个Borland用户来说这都是一件大事嘛。回帖一不小心又YY了一堆。
—————————————
    近两年来Delphi已经日先颓势,广大的Delphi用户纷纷转向JAVA或.NET。广大的老用户走了,新用户又未能很好的成长起来,致使Delphi社区的技术实力大大下将。这一点看一下Delphi的论坛的整体技术水平就可以知道了。Delphi的没落也许更多的是一个时代的没落,传统的win32及C/S程序开发的没落。在我看来Delphi的没落似乎是注定的。最近虽然还是常玩玩Delphi,不过更多的只是玩玩而已。相见不如怀念。
    C++Builder的版本号一直都和Delphi同步,但随着Delphi7的出现C++Builder7却久久为见,似乎Borland已经将C++Builder给挂了。在经过痛苦的等待之后C++BuilderX出现了。C++BuilderX本该是一个很有前途的东西。C++BuilderX整合了N多开源的东西,支持交叉编译(好像是吧,不太记得了)。发布的时候曾宣了N多新特性,还宣称要用C++将VCL进行重写。不过在预览版出现的时候连RAD都没带。大家都在想,预览版嘛,可以理解。但在正式版出来的时候还是老样子。不带RAD的C++Builder还是C++Builder?我想C++BuilderX一定让不少C++Builder用户从期待到绝望。尽管如此C++Builder还是一个不错的东西,至少思路还不错。C++BuilderX提供了与ANSI/ISO C++和C99标准完全兼容的全新编译器和C++平台开发架构,该架构允许开发人员直观地构建并交付跨平台应用而无需对编译器进行扩展。C++BuilderX如果能借助开源的力量也许会有不错的前景。不过Borland毕竟不是IBM。
    如果说Borland说要卖掉Delphi,我想我不会惊奇。让我没想到的是Borland居然连JBuilder也给卖了。JBuilder是个优秀的开发工具,他有着eclipse所没有的容用性。不过eclipse有着他最大的优势,免费,以及开源社区的支持。想起以前看到的一句话,如果JBuilder不是因为卖得这么贵的话也许很过后来的IDE都不会出现,其中包括eclipse和IDEA。
    抛弃了IDE的Borland期待着一次涅磐,但Borland能否修成正果?没有了IDE的是否还是Borland?
    希望Borland走好,更希望那些离开了Borland的IDE们走好。

Borland要把开发工具部给卖了

    这两天对Delphi社区影响大的无疑就是这个消息了。现在的我已经成功的转到JAVA开发下面了,Delphi对我来说更多的是业余时消遣的玩具。对Delphi的一些新动向虽然也会去了解,却也不是很感兴趣。最近Dephi的发展主要都是放在.net和IDE的扩展上。但我只只用Delphi的win32开发,至于IDE方面,我已经被D7的IDE虐习惯了。在安上Moldermaker和cnpack之后感觉还不错。
    尽管如此,Borland出售开发工具部门还是一件大事,毕竟玩了这么多年的Delphi,而且现在还在用Borland的JBuilder。
    即使没了Jbuilder我们还可以使用eclipse,JAVA还会发展,但Delphi?相对其他开发语言来说Delphi应该说是封闭的,Delphi一直都是在Borland的掌控中发展。没了Borland谁来支持Delphi。
    就我看来Delphi的前景是暗淡的。Delphi的优势主要体现在传统的win32环境中的RAD开发。但就目前的情况来看win32的开发已经开始走下坡路了。实际上现在的Delphi开发人员就已经流失的很厉害了,比如我。在.net开发方面。delphi可以使用vcl来开发。vcl固然是个很优秀的东西,但毕竟已经是个老古董了。现在的.net的设计已经很完善,完全没必要多此一举的封装一下。
    borland的工具开发部门谁买?
    windows平台卖给MS?怎么可能。MS自己有完备的.net和win32开发工具,再买这个也多余。买过来消灭竞争对手?只有打不过的时候才会这么做。现在Borland都这样了已经犯不着用这一着了。
    JAVA平台卖给IBM。尽管我不得不承认JBuilder是个很不错的东西。但我想IBM还是不太可能会要。IBM是个精明的商人。IBM用开源模式成功的将eclipse推向了java开发工具的巅峰,将jbuilder给做了。jbuilder IBM就是买过来也没什么用。买来送给开源组织?怎么可能。我倒是挺希望SUN吧Jbuilder给买过去。虽然sun是java标准的制定者,但sun的IDE就一直没有流行起来,以前是jbuilder,现在是eclipse。netbean和jbuilder都是基于swing的。如果sun能将jbuilder中的优势整合到netbean中应该能出现个不错的东西出来。对我这样一个对eclipse颇有微词的人来说,我还是很希望能出现个这么样的东西的。
    不管怎么说,还是希望Borland给自己的开发工具们找个好买家吧。

在jbuilder中集成vim和explore

    昨天说到jbuilder的外部工具,本来想将jbuilder中集成vim和explore的方法贴一下,只可惜机器上没安jbuilder,现在来贴一下吧。
    主菜单Tools->Configure External Tools…
    打开外部工具管理窗口。然后要做的就是add外部工具了。
    Title:外部工具添加后显示在jbuilder菜单上的名称。
    Program:要运行的程序。
    Paremeters:外部工具的运行参数。
   
    对于vim的配置,标题就去取gvim吧。程序,当然就直接填写入vim的完整路径了。下面就是参数了。对参数的设定,jbuilder提供了不少环境变量。这里我们需要的是当前文件的文件名($FilePath)。
    要集成资源管理器,在程序栏目填写上explorer,参数当然就选当前文件的路径了($FileDir)。