慘劇啊~~
我賴以維生的工具jEdit 在我的MAC 升級到JAVA update 2 後再也開不起來了.
趕快找解藥啊~~
在APPLE的討論區, 立刻就有人跟我有同樣的下場了:
http://discussions.apple.com/thread.jspa?messageID=8173617
還好那裡高手多, 立刻就有補救的方法.
將/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub 這個檔
copy 到 /Applications/JEdit.app/Contents/MacOS 中, 將此目錄中原來的jedit檔移除(或更名), 把copy過來的檔案改名為jedit即可.
呼~~ 好險, 若沒有了jEdit, 工作起來就極度不順~~
make mrproper
make
make
PS:
上禮拜, 我的virtual platform 程式的基本功能已經能在公司的linux PC上正常的run了. 由於實驗用的PC比較慢, 所以就把程式丟到快一點的工作站上去跑, 結果compile玩後, 一執行, 當場就掛了. 但拿回自己實驗的PC又跑的好好的. 而且家裏的PC也run 的好好的, 一直覺得很納悶, 哪裡出問題了. 比較兩台PC環境, 一台是Fedora Core 5, P4 CPU, 另一台是CentOS 4 , Duo Core的 CPU. 本以為是CentOS 太舊了 , 想說應該不是我程式的問題(心理還是毛毛的)……..後來在我的ASUS NB(Fedora Core 6, Duo Core CPU) 上跑, 一樣掛掉. 就決定一定要把問題找出來. 奮戰超過12小時後, 終於找到問題, 原來是我的程式有race condition的問題, 在快一點的CPU上跑, 就有可能測出bug.
雖然問題解決了, 但是讓我體會到一件事情, 許多人(包過我自己)在程式寫到一個段落後, 在自己的環境下測試OK, 或者是經過許多環境測試都OK. 就信誓旦旦的說, 程式寫完了, 測過了, 沒問題, 但是一旦在某特定環境下出錯, 就直覺是環境的問題, 而不相信自己的程式有錯….
但是事實卻是自己的程式有bug. 通常這類的bug不容易測出來, 也不容易找到癥結點. 但是一但認為自己的程式沒問題, 那就完蛋了, 這個bug可能就用永遠不會被發現了.
所以對自己的程式, 隨時保持懷疑的態度, 有助於提升程式的品質, 即使是大師級的人物, 也可能會犯下小錯而不自知. 唯有不斷的review 自己, 才能把那隻該死的bug抓出來.
Jserv’s blog 的一篇文章
http://blog.linux.org.tw/~jserv/archives/001815.html
真是不得了~~
記得以前用cvs時候, 有這個功能.
但在用svn的時候, 找了好久都沒找到怎麼用, 後來YF兄告訴我用export command即可.
果然, 如下:
svn export http:/xxxxxxxx
即可, 之前我一直朝著checkout command 去找, 難怪找不到有options 可以用.
唉~~ 真是死腦筋, 不懂得變通..
在Fred’s blog 的另一篇文章中『用C呼叫 rand() 每次都回傳相同結果？』學到了一個不錯的技巧喔…嗯嗯, 用srand(time(0)+getpid()); 真是個好方法.
從Fred’s blog中看到一個有關於Coding Style 的連結『Prpoer Linux Kernel Coding Sytle』, 想到最近寫的程式, 為了變數該取什麼名字較容易懂而非常傷腦筋, 就立刻連進去看了一下, 雖然是英文的文章, 英文程度不好的我, 也只好努力的K了一下囉, 嗯嗯, 看來自己的coding style 還要再加強, 尤其是』註解』的地方…是我最需改進的了.
這個連結裡有其它的網友對於上面的coding style有不同意見喔
搞了兩天, 我的超小型RTOS, 在linux(FC5) 下用gcc -O2 的option compile完後, 執行總是會出現segmentation fault. 但是-O0 就ok了. 本以為是我的multi-thread 出問題了, 查了好久, 才發現是在我的RTOS中的context switch(for x86)中會死掉, 跳到不知名的地方去了. 當初context switch 中的code 是參考eCos 改過來的. 想了一想, eCos 似乎只支援i386相容的PC. 難道gcc -O2 的option 會使用i386以外的暫存器, 來做最佳化嗎??
果真, 在Makefile 中gcc 的option 中加入-march=i386 就解決了. 後來測試-march=i486 或i586 也都可以, 但用i686 就會segmentation fault. 嗯嗯, 自從學校學過i386 組合語言後, 再也不知道486 以上的CPU到底多了哪些功能. 只知道變快了, 且i386相容. 看來要最佳化自己的程式, 還是得多了解一下CPU 已經改到啥地步了. 尤其是在我的RTOS, 裡面有部份的code 是跟CPU有關的
