Jun 18
IUSR咿咿呀呀 eclipse
似乎上个月就注意到eclipse.org上面的Friends of Eclipse的活动了，这活动很简单很直白很粗犷：给钱。捐赠$35及以上给Eclipse基金会就可以成为一枚光荣滴Friend of Eclipse，为期一年——哦，我不确定是这个身份为期一年或者说像基金会所说的只可以使用Friend of Eclipse那个logo一年。
秀下logo：
给我的的感觉是比较矬，一点也不个性化，连捐赠人的名字都不可能出现。
说到名字…不知道为啥我填表单时输入的名字后来不见了，first name和last name均以两个空格代替，而且我填的是英文。刚还跟基金会某联系人抱怨来着（然后发现找错了对象，捐赠的FAQ页面上有关于捐赠问题的特定的联系人，我抱怨给了General inquiries，不看FAQ的后果啊！），看看能不能给改正过来。现在的效果，在donor列表上好像我的名字叫“Life-changing!”一样，其实那只是我的comment…
而在Friends of Eclipse的“wanted”页面上，就好像某个人捐了-$50一样…呃，其实大家都像捐了个负数一样：
看到了“Anonymous”了吧？唉，我是没那个觉悟了，我现在这个情况比anonymous还anonymous…
然后发现我是第294号friend，可以理解为：2，94。
好吧，捐赠完了，成为了Friends of Eclipse一员，除了最上面那个没啥个性的logo以外，还有其他好处么？
有好处那是当然的啦，钱又不是白花的。根据那个wanted页面，所有成为了Friends of Eclipse的用户都可以获得对一个专门提供的下载服务器的访问，速度很快——这个速度既包括下载速度，还包括所有eclipse.org上的eclipse插件的更新速度，据说最多可以比其他镜像早个24小时左右拿到插件（也没啥，通常工作忙起来几乎一定会想不起更新插件的，更别提干着半截活换一个发行版这种有一定风险的事情），还以为可以提前拿到Helios，结果发现在下载页面上一直都是对外可见的。这个是刚下载回来的RC4在努力启动中：
Helios starting up
之所以想捐赠Eclipse，一是因为最近生活和工作上双双郁闷，导致没事儿就疯狂购物以及吃零食，比我家的mother-to-be反应还大；二是因为，就像捐赠的comment写的一样，eclipse对于我来说确实是个比较life-changing的东西，我不会要求它像IDEA一样cool一样智能（虽然现在的eclipse比起几年前可是强了太多了，但还是一点都不cool），也不会要求它能像Visual Studio系列一样速度能稍微快一些（好吧，其实随着功能越来越多和界面越来越花哨，VS现在也慢了很多了，2005、2008和2010哪个都不如以前最钟爱的2003快），也不会要求它像netbeans一样能更新得再带劲儿一些（说真的，netbeans是更新得过于频繁了），eclipse就是现在这个eclipse，不温不火，就像丫老祖宗VisualAge for Java一样的范儿，每次启动它我都能想象一个中老年男迈着四方步的样子。没有太多surprise也许也是件很好的事情。话说早先的时候我的老P3机器跑eclipse还是很要命的，然后为了拿eclipse平时开发以及做毕设还特意买了个牛叉一些的机器，直接跳过P4超线程什么的，在当时对我来说也算比较life-changing的了，微软拿来XP都没能让我换机器。
Friend or Foe??
Update: 刚刚收到Eclipse基金会某人回信，说是因为eclipse.org收到的姓名是unicode字符，最后不了了之没有显示。看来捐赠表单上的first name和last name是被忽略的，用的还是PayPal传的姓名吧。解决了就好，虚荣一下…
Apr 09
IUSR技术文章 eclipse, english, java, linkedin, performance
I did this long ago. Since I’m not required to do it repeatedly, it took me another 15 minutes to get warmed up. This time I’m recording the procedures here as a preparation for tomorrow’s exploration on why the hell that tomcat instance was taking so long to start up.
- JVM arguments: -XrunpiAgent:server=standalone,file=/home/iusr/tc.trcxml,profile=/home/iusr/piAgent.options,filters=/home/iusr/piAgent.filters. It’s convenient to export all this twittering to JAVA_OPTS which is used by tomcat to pass to JVM;
- Adjust the LD_LIBRARY_PATH environment variable to include directory “<eclipse_install_or_ext_point>/plugins/org.eclipse.hyades.execution.<OS>.<CPU_ARCH>_<VERSION>”, e.g., in my Edgy box it’s “/usr/local/eclipse-extension/eclipse.org/tptp/eclipse/plugins/org.eclipse.hyades.execution.linux.x86_4.2.2.v200701141614″;
- Compose the profile configuration, filters configuration. Refer to http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.tptp.platform.doc.user/ref/rsaproffilt.htm and http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.tptp.platform.doc.user/tasks/teprofsa.htm for the proper format.
- Run the java class, of course:)
A profile configuration consists several entries, here’s an example (“^\*.*$” lines stand for comments):
* all | none
MONITOR_MODE = all
* true | false
FILTERS = true
* none | deletes | frees | moves | deletesAndMoves | movesAndFrees
TRACK_GC_EVENT_TYPES = movesAndFrees
* static | relocatable | staticAndRelocatable
ID_STYLE = staticAndRelocatable
* true | false
* OPTIONS = false
TIMESTAMPS = true
METHOD_COUNTS = true
OBJ_ALLOC_IS_ARRAY = true
* none | normal | boundary | contiguous | boundaryAndContiguous
STACK_INFORMATION = contiguous
* true | false
* TICKET = true
* full | none | noObjectCorrelation
TRACE_MODE = full
* true | false
* TRACE_ID_REFS = true
Apparently this configuration requires much work to do, so my CPU got 99% utilized just now:P.
The filters configuration is more straightforward, only a wildcard string indicating the desired packages or classes, another wildcard string indicating the methods, and a directive indicating the whether matching packages or classes are to be included or excluded. Here’s an example:
package = com.*
method = *
mode = INCLUDE
Since some subtle differences amongst different Linux distros and versions, the configuration above varies. I once saw a web page saying it’s necessary to add the directory “<eclipse_install_or_ext_point>/plugins/org.eclipse.hyades.execution.<OS>.<CPU_ARCH>_<VERSION>” not only to LD_LIBRARY_PATH but also to PATH. I haven’t tried this out yet, since adding it to LD_LIBRARY_PATH works every time and appears to be more reasonable. Particularly, if the piAgent failed to get loaded or started, take a look at the output of `ldd <eclipse_install_or_ext_point>/plugins/org.eclipse.hyades.execution.<OS>.<CPU_ARCH>_<VERSION>/libpiAgent.so` to check out if there’s anything dependent missing.
Whoa, I cannot help starting the agent on our main testing machine to find out what the hell contributed to the latencies.
May 07
IUSR技术文章 eclipse
别急着骂我冒充天文爱好者，我说的是Eclipse和其基金会旗下的Callisto项目，或者说是”Callisto并行发布“。
前几天开始，Eclipse 3.2和Callisto这些字眼渐渐变得多起来，本人本着没事儿也要瞎忙的精神装作日理万机的样子无视这些逐渐升温的单词。刚看新闻才知道eclipse 3.2 RC3昨天发布了–呃，应该算是前天了，就去eclipse.org一通考古，才发现了这个Callisto项目，仔细看看，原来是个插件集，而且都只是eclipse.org提供的插件。
按照Callisto主页上的说法，Callisto并行发布并不是提供新插件，而是将10个主要的Eclipse项目同时捆绑发布，以使得一些Eclipse生态系统中的成员更容易将Eclipse集成进各自的产品中。这10个项目是BIRT，CDT，DTP，EMF，GEF，GMF，Eclipse，TPTP，WTP，VE，几乎覆盖了一般的开发需求。
其实我还是不太理解这样做的目的，Callisto主页说是要”消除不同项目的不同版本带来的不确定性，使得Eclipse生态系统中的成员可以尽早开始各自的集成和跨项目、跨产品的测试”。我以前也有过被不同插件的不同版本搞的焦头烂额的经历，但自从3.0以后更多的依赖Update Manager来安装插件，这种情形已经很少见了，即使出现也很容易解决。Callisto发布当然更进一步的保证了运行在发布版中的各个插件的有效，所以它的价值应该体现在Eclipse生态系统中依靠提供插件集成产品的厂商和刚学会使用Eclipse的初学者身上，有了这么一个省心的捆绑发布，也许会有更多厂商来尝试做插件集成，有更多其他IDE的用户逐渐转移到Eclipse上吧。
这个月的《程序员》里有一篇采访Milinkovich和Kellman的文章，里面记者提的一个问题也是我很久以来的问题：如果eclipse.org的各个项目发展的十分完善，那那些靠提供插件和插件集成的公司还能依靠什么盈利？不只是公司，很多开源或免费的插件项目已经或多或少的受到eclipse.org的项目影响。比如原先开发J2EE应用时大家都首选Lomboz，而现在我知道的很多人都转向了WTP–当然这也和Lomboz后来发展实在有些缓慢有关。eclipse.org是eclipse平台的老家，也许人们觉得这地方出来的插件和项目有种”官方”的感觉，根红苗正，更放心一些？不过我认为eclipse.org不会把所有的插件项目赶上绝路，因为eclipse.org提供的插件一直以来给人的感觉都是更general一些，绝大部分都是支持那些在JCP有一席之地的技术，而不会涉及到其他一些常用的框架，比如Hibernate、Tapestry等等，这种情况下，hibernate.org提供的Hibernate Tools和支持Tapestry开发的Spindle等等自然还会有很大的发展空间。
刚才在Eclipse 3.2 RC3中使用Update Manager更新Callisto所覆盖的插件时截了张图，权以结尾。
Technorati : eclipse
Update:
看来我是没能理解Callisto Simultaneous Relase。这个一方面帮助用户整理出一份稳定的功能比较全面的发行版，一方面也解决了eclipse.org上面的一些项目长久依赖Eclipse项目的升级站点的问题——可能听起来有些别扭，只要弄清楚Eclipse和GEF、EMF等等一样是属于Eclipse基金会旗下的项目就应该能明白了。刚才在看Eclipse wiki时看到这篇Callisto Coordinated Update Sites稍微明白了一些。eclipse.org上的一些项目，比如GEF，一直以来没有自己的升级站点（Update Site），而是通通放在eclipse项目下（区别一下eclipse项目和大家约定俗成的eclipse IDE等等）的升级站点。有一个bug提议也是指出了GEF的这个不便之处，认为作为eclipse.org上的独立项目，把GEF扔在eclipse项目下显然不合适——虽然GEF项目和eclipse项目之间的确是独立的，但是在update manager里升级Eclipse SDK（或者其他什么名字）时GEF总在其中。
GEF现在已经有了自己的升级站点了，也许是拜这位老兄的bug提议所赐——这个bug提议是2006年2月17日提交的，我试着下载http://download.eclipse.org/tools/gef/updates/site.xml的时候可以看到服务器返回的Last-Modified: Wed, 12 Apr 2006 15:08:14 GMT，再下载比较稳定的发行版的site.xml：http://download.eclipse.org/tools/gef/releases/update-site/site.xml，可以看到Last-Modified: Tue, 28 Feb 2006 15:32:06 GMT。嗯，说明不了什么，只能说明现在GEF下载方便多了
而如果想省事儿的话，还是用Callisto Simultaneous Relase的Update Site好了。
RSS
Recent Comments