3.1 Compiler vs. Interpreter

An interpreter translates some form of source code into a target representation that it can immediately execute and evaluate. The structure of the interpreter is similar to that of a compiler, but the amount of time it takes to produce the executable representation will vary as will the amount of optimization. The following diagram shows one representation of the differences.

Compiler characteristics:

• spends a lot of time analyzing and processing the program
• the resulting executable is some form of machine- specific binary code
• the computer hardware interprets (executes) the resulting code
• program execution is fast

Interpreter characteristics:

• relatively little time is spent analyzing and processing the program
• the resulting code is some sort of intermediate code
• the resulting code is interpreted by another program
• program execution is relatively slow

The above characteristics are typical. There are well-known cases that are somewhere in between, such as Java with it's JVM.

refer from:

http://web.cs.wpi.edu/~gpollice/cs544-f05/CourseNotes/maps/Class1/Compilervs.Interpreter.html

Resource is not public

另外如果使用Theme.Dialog.Alert之類而出現
Error: Resource is not public. (at 'theme' with value '@android:style/Theme.Dialog.Alert')的錯誤，因為在frameworks/base/core /res/res/values/public.xml找不到這個資料

只要加個*改成
  '@*android:style/Theme.Dialog.Alert'
就可以使用了。


refer from:
http://slashgill.blogspot.com/2010/11/theme.html

Login Failed: invalid_key when Android Facebook app is installed

As Sean suggests in his second tack...

I fixed the issue by removing this line (which uses SSO):

    mFacebook.authorize(activity, mAppId, PERMS_NEEDED, new LoginDialogListener(r));

in favor of this line (which does not):

    mFacebook.authorize(
            activity, 
            PERMS_NEEDED,
            Facebook.FORCE_DIALOG_AUTH,   // avoids SSO
            new LoginDialogListener(r));

refer from:

https://github.com/facebook/facebook-android-sdk/issues/191

nVidia BSOD nvlddmkm.sys

I have found and fixed the problem today. This is what appears to happen.
during the installation of the most current drivers 100.65 Vista, an OLD file
nvlddmkm.sys is copied into windows/system32/drivers and not the current one
in the install. As a result the new drivers are attempting to access a file
dated 11/2006 instead of 2/2007 ver 7.15.11.0065 which is in the newest WHQL
driver ver 100.65 vista 32.

Fix: Go to windows/system32/drivers and rename nvlddmkm.sys to
nvlddmkm.sys.old. Go to the nvidia directory and find the file nvlddmkm.sy_
and copy it to windows/system32. Using the cmd window (DOS box) type
EXPAND.EXE nvlddmkm.sy_ nvlddmkm.sys. When the expansion is complete, copy
the new nvlddmkm.sys to windows/system32/drivers and restart the computer.

Your computer should now work properly.

You will notice that any uninstall and reinstall of nvidia drivers will not
remove the old nvlddmkm.sys file and will not overwrite it with the newer
version. You have to do it manually. I do not know why this happens but who
cares as long it is fixed.

Good luck...

"Hohen" wrote:

nvlddmkm.sys 這是NVIDIA的顯卡驅動的文件吧，你入安全模式找到他刪了他，看看能不能開機，要是入到正常模式的話就去下你顯卡最新的FOR win7的驅動吧裝上新的驅動我想應該沒事， 要是你不是一入系統的藍的話那你不用刪直接下最新的驅動裝上看看

refer from:
http://www.vistax64.com/vista-hardware-devices/41867-nvidia-bsod-nvlddmkm-sys.html

android另類結束Activity方法——主動拋出異常

這種方法在網上已經有了部分介紹，但是大部分人不知道怎麼取消Force Close的對話框。「通過重寫Android應用程序的Application基類自己實現 Thread.UncaughtExceptionHandler接口的uncaughtException方法是可以避免出現FC窗口的，用戶感覺直接退出了一樣」。這是網上能找到的說明，這段話讓人看了摸不著頭腦，大部分人不知道怎麼重寫Application基類並實現接口。廢話不多說，直接上代碼！ 首先需要在onCreate中添加此句代碼：Thread.setDefaultUncaughtExceptionHandler(new AntrouApp());表明出現異常由自己來處理。 接下來重寫異常處理類 

public class AntrouApp extends Application implements Thread.UncaughtExceptionHandler { 
    @Override 
public void onCreate() { 
// TODO Auto-generated method stub 
super.onCreate(); 
} 
@Override 
    public void uncaughtException(Thread thread, Throwable ex) { 
        android.os.Process.killProcess(android.os.Process.myPid());  
Thread.getDefaultUncaughtExceptionHandler().uncaughtException(thread, ex); 
//若沒有處理，則按照系統自己的處理方式處理 
    } 
} 

此方法會強制結束所有的Activity和service，當然也可以在service裡進行，達到後台強制結束任務的目的。在Activity結束後，系統會回到最近為onpause狀態的Activity。


refer from:
http://www.bangchui.org/simple/?t15896.html

證明 數學歸納法

數學歸納法(Mathematical Induction)立論的基礎是來自良序原理(Well-Ordering Property)。
Well-Ordering Property告訴我們：任何自然數的非空子集合會有一個最小的元素。(Every nonempty subset of the set of positive integers has a least element.)

首先我先以矛盾證法證明數學歸納法的合法性(Validity)：

假設已知條件：P(1)為真，且對所有自然數k而言，敘述 P(k)→P(k+1)亦為真。

為證明P(n)對所有自然數n而言恆為真的話，假設存在一自然數n使得P(n)為假。
則根據Well-Ordering Property，讓P(n)為假的自然數集合S是自然數集合N的子集合，它是個非空集合，並存在一個最小的元素，我們稱此元素為m。
我們知道m不會是1，因為已知條件中已給出P(1)為真。
既然m不會是1，那它必定是個大於1的自然數，m-1也會是個自然數。
此外，因為m-1小於m，m已經是S集合中最小的元素了，所以m-1並不屬於S集合；因此知P(m-1)必為真。
所以我們得到了P(m-1)為真，P(m)為假的結論。
根據已知條件：P(k)→P(k+1) (P(k)為真，則P(k+1)亦為真)，我們知道這個結論和已知條件矛盾，因此推得"存在一自然數n使P(n)為假"這個敘述是錯誤的！
也就是說，P(n)對任何自然數n恆為真。得證！


refer from:
http://tw.myblog.yahoo.com/jw!XToZojWTHRI2EfbctdR8ag--/article?mid=1628&prev=1629&l=f&fid=78

OS: Thrashing

在電腦的知識範疇中，談到thrashing前，必需先大略對虛擬記憶體有點瞭解。虛擬記憶體的概念，其實就是將硬碟割出一塊空間，這一部份我們叫他虛擬記憶體（Virtural Memory），而原先的記憶體稱之為實體記憶體（Physical Memory）。　　


當程式要執行的部份，從虛擬記憶體（亦即硬碟）搬至實體記憶體再執行。由於硬碟的空間遠較實體記憶體為大，因此使用虛擬記憶體這種技術，可以讓程式不受實體記憶體容量的限制，此外由於行程（Process，指執行中的程式）只需將部份載入實體記憶體，因此可以讓更多行程同時存於實體記憶體，進而提高CPU的使用率。


　　Thrashing這種現象指的是，欲使用的資料從虛擬記憶體搬至實體記憶體時，實體記憶體可能有一部份需要被置換，這些置換的資料再搬至虛擬記憶體中。然而被置換的部可能馬上又要使用，再從虛擬記憶體搬至實體記憶體，如此週而復始不斷進行搬運的動作，所有時間都花在這些無關緊要的置換搬運，導致CPU的使用率大幅降低。　　
 
現在的電腦可以同時執行很多程式，如此CPU使用率大幅上升，達到最大的利用。然而執行的程式超過一定的數量時，很容易發生thrashing，CPU的使用率反而降低。


refer from:
http://blog.xuite.net/draz/draz/3826515