環境:
Ubuntu 9.10
Opera 10
輸入法:ibus
解決方法:
編輯 /usr/bin/opera,在 OPERA_BINARYDIR 之下加上
export QT_IM_MODULE=XIM
,然後重新啟動就行了。
Just thinking more…
環境:
Ubuntu 9.10
Opera 10
輸入法:ibus
解決方法:
編輯 /usr/bin/opera,在 OPERA_BINARYDIR 之下加上
export QT_IM_MODULE=XIM
,然後重新啟動就行了。
我承認,這標題下的很爛,但一時也想不到更好的。
情況是這樣的,我第一個硬碟已經裝了 Linux,這時候我卻想裝 Windows,是故,我只能裝在第二個硬碟上。Windows 非常機車,如果第一個硬碟沒有 NTFS 的 partition 是不給你裝的。這時候只能先拔第一個硬碟的電源,把 Windows 裝到第二個硬碟上之後,再重新把第一個硬碟的電源裝回去。
接下來,因為不想老是在 BIOS 裡切換開機順序,所以把腦筋動到 grub 上。根據 grub 的 manual,只要利用 map 就行了,但我還是試了好一陣子,後來才發現是順序的問題,我試的時候把 map 放到最前面去了。正確的順序是這樣的:
title Windows XP root (hd1,0) makeactive map (hd0) (hd1) map (hd1) (hd0) chainloader +1
這樣就可以不用在 BIOS 裡切換開機順序了。如果你不是用第二個硬碟,而是第3個或第四個硬碟,只要類推為 hd2、hd3 即可。
我用的是 Ubuntu。
用 wine 安裝程式以後,Wine 選單裡會多出該程式的項目,但移除程式以後,這些項目還存在,即便你之前有備份 .wine,將備份檔案回存了,也不會有用。關鍵在於 wine 其實是把這些選單項目放在 $HOME/.config/menus/applications-merged 下,所以只要把該刪除的項目從這個資料夾下刪除即可。
2009/10/14 補充:$HOME/.local/share/applications/wine/Programs 下的也要記得刪掉,否則會出現在”其他”選單裡…
懶得動筆。
來統計一下截至目前為止看了幾片好了,嗯,69,還不賴,只要在這季衝完31部片子,就可以達到2009年百片的目標。(謎之聲:X的,最好是可以做的到!!)
如果你正好用的掃描器跟我一樣是 Mustek BearPaw 1200TA 或者是開啟 xsane 遇到 gt68xx:libusb 錯誤時,你可以試著到這裡:SANE GT68xx Backend Homepage 去下載適當的 .usb 檔案。下載以後,把它複製到 /usr/share/sane/gt68xx 目錄下,變更權限為 a+r,然後重新開啟 xsane,這樣就能正常使用掃描器了。
差點就要去挖西班牙文的維基百科了,還有英文維基百科有收 Nocturna 這條目。
boo 應該是在 0.8 以後吧,就提供了 macro 這個新的關鍵字,用來寫 macro,之前的寫法相當麻煩,需要先繼承 AbstractAstMacro,然後overwrite Expand 這個方法。
新的 macro 關鍵字簡化了一些功夫,macro 之後接的是名稱,下面的 block 就是描述要怎麼去替代,block 的最後再傳回 Ast.Block 即可。
大致的寫法就像這樣子:
[python]
macro Msg:
args=Msg.Arguments # macro 名稱其後加上 .Arguments,表示取得 macro 後面的參數
# [| |] 是相對簡便的語法,表示這裡面是個 Ast.Block,也就是程式區塊,而 .Body 則表示是 macro 下面的 block
# 注意:[| 後與 |] 前一定要分行,否則會有錯誤
return [|
$(Msg.Body)
|]
[/python]
寫法相當簡潔,不過在寫的時候,卻很容易讓人碰壁。最大的原因是用法誨澀,以上面的 Msg macro 來說,當 Msg 123 的時候,Msg.Arguments[0] 的型態照理應該是 Int32 才對,但實際上卻是 Ast.IntegerLiteralExpression,型態已經全然是 Compiler AST tree 裡的型態,macro 裡要取用變數、或產生 block也很容易造成困擾,這對於不玩 compiler 的人來說,是相當高的門檻。再者,文件的缺少也是很重要的因素,官方對於這方面的文件非常缺少(比較少人玩 Boo 也是一個主因)。
但是,這對於創造新的語法來說,卻是相當的便利,這也就是一般常說的 DSL,你可以針對某個特定領域來創造適合的語法。網路上能找到的例子,也多半如此。
boo 的 macro 跟 C/C++ 的 macro 很類似,都是在編譯時期就被替代為實際的代碼。不過 C/C++ 只做簡單的替換,boo 的 macro 則是會在編譯時期時進行編譯並且執行、進行替換。
#
# dontimes.boo
#
import System
import Boo.Lang.Compiler
macro DoNTimes:
n = DoNTimes.Arguments[0] as Ast.IntegerLiteralExpression
print n.GetType().ToString() # n is IntegerLiteralExpression
print DoNTimes.Body.GetType().ToString() # DoNTimes.Body is Block
blocks = Ast.Block() # create new block add DoNTimes.Body n times.
for i in range(Convert.ToInt32(n.ValueObject)):
blocks.Add( DoNTimes.Body )
return blocks
DoNTimes 3:
print "foo"
print "Press any key to continue . . . "
Console.ReadKey(true)
使用 booi 來執行,你會看到下面的訊息,foo 被印了三次:
Boo.Lang.Compiler.Ast.IntegerLiteralExpression Boo.Lang.Compiler.Ast.Block foo foo foo Press any key to continue . . .
那這跟用 for 迴圈來跑有什麼不同?
首先用 booc 來編譯:booc -t:exe dontimes.boo,在編譯的時候,你會發現第9行跟第10行的訊息被印了出來:
Boo.Lang.Compiler.Ast.IntegerLiteralExpression
Boo.Lang.Compiler.Ast.Block
這證明了 boo compiler 會在編譯時,把 macro 的部份先拿出來編譯,然後在編譯的時後去執行 macro,對程式碼進行替換。然後你會發現執行 dontimes 的時候,只印了 foo 三次。
用 reflector 來看,可以看到:
private static void Main(string[] argv)
{
Console.WriteLine("foo");
Console.WriteLine("foo");
Console.WriteLine("foo");
Console.WriteLine("Press any key to continue . . . ");
Console.ReadKey(true);
}
代碼只有三行Console.WriteLine(“foo”);,這很清楚的說明了 booc 在編譯時,就把 macro 的內容替換進去了。
進度緩慢!突然有今年完成不了看百片的目標的預感!
網路上能看到的,多半都是自己編譯 tarball…
deb file:///opt/mono_debs ./
接下來就可以用 apt-get update、apt-get upgrade 來更新了。
理論上,這樣就可以更新了,但是事實上,因為 dependency 的關係,apt 會試圖安裝舊的 2.0.1 的 deb 來滿足相依性而導致應用程式有問題。
最好,也循上述的方法,把相關的基底 gtk-sharp2、xsp、gecko-sharp、mono-addins…等套件也重新 build 一次,這樣出現問題的情況應該會減少許多。
我個人建議,要用最新的 mono 還是衝 Karmic (9.10) 吧,這樣會省事很多。