2017-05-22

gVim menu language setting

A few days ago, I download the lastest(It's 8.0 in May, 2017) Vim.

And when I launch the gVim, the menu text is almost "????".
I have to explain my PC setting. I used to have Japanese menu on my PC.
It is Win10 at this moment.

Seems the VIM has old fashion, it used to use the encode 932 or Shift-JIS or something like that. It shows as "????" for the Kana. I have to force it to show in english.

I found some answers as below:

https://superuser.com/questions/746387/change-menu-ui-language-of-vim-to-english

There is the code you have to add in your .vimrc(or _vimrc in windows)
set langmenu=en_US
let $LANG = 'en_US'
source $VIMRUNTIME/delmenu.vim
source $VIMRUNTIME/menu.vim

2016-08-03

Codd's 12 rules 科德十二定律

Codd's 12 Rules/科德十二定律/コッドの12の規則


Related to Wikipedia 2016/8/2 data
純屬資料收集,順便做一下語言學習


全關係系統十二準則

全關係系統應該完全支持關係模型的所有特徵。關係模型的奠基人埃德加·科德具體地給出了全關係系統應遵循的基本準則。

準則0 The Foundation rule
For any system that is advertised as, or claimed to be, a relational data base management system, that system must be able to manage data bases entirely through its relational capabilities.
一個關係形的關係資料庫系統必須能完全通過它的關係能力來管理資料庫。
準則1 The information rule 信息準則
All information in a relational data base is represented explicitly at the logical level and in exactly one way — by values in tables.
關係資料庫系統的所有信息都應該在邏輯一級上用表中的值這一種方法顯式的表示。
準則2 The guaranteed access rule 保證訪問準則
Each and every data (atomic value) in a relational data base is guaranteed to be logically accessible by resorting to a combination of table name, primary key value and column name.
依靠表名、主碼和列名的組合,保證能以邏輯方式訪問關係資料庫中的每個數據項。
準則3 Systematic treatment of null values 空值的系統化處理
Null values (distinct from the empty character string or a string of blank characters and distinct from zero or any other number) are supported in fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type.
全關係的關係資料庫系統支持空值的概念,並用系統化的方法處理空值。
準則4 Dynamic online catalog based on the relational model 基於關係模型的動態的聯機數據字典
The data base description is represented at the logical level in the same way as ordinary data, so that authorized users can apply the same relational language to its interrogation as they apply to the regular data.
資料庫的描述在邏輯級上和普通數據採用同樣的表述方式。
準則5 The comprehensive data sublanguage rule 統一的數據子語言
A relational system may support several languages and various modes of terminal use (for example, the fill-in-the-blanks mode). However, there must be at least one language whose statements are expressible, per some well-defined syntax, as character strings and that is comprehensive in supporting all of the following items:
  1. Data definition
  2. View definition
  3. Data manipulation (interactive and by program).
  4. Integrity constraints
  5. Authorization
  6. Transaction boundaries (begin, commit and rollback)
一個關係資料庫系統可以具有幾種語言和多種終端訪問方式,但必須有一種語言,它的語句可以表示為嚴格語法規定的字符串,並能全面的支持各種規則。
準則6 The view updating rule 視圖更新準則
All views that are theoretically updatable are also updatable by the system.
所有理論上可更新的視圖也應該允許由系統更新。
準則7 High-level insert, update, and delete 高階的插入、修改和刪除操作
The capability of handling a base relation or a derived relation as a single operand applies not only to the retrieval of data but also to the insertion, update and deletion of data.
系統應該對各種操作進行查詢優化。
準則8 Physical data independence 數據的物理獨立性
Application programs and terminal activities remain logically unimpaired whenever any changes are made in either storage representations or access methods.
無論資料庫的數據在存儲表示或存取方法上作任何變化,應用程式和終端活動都保持邏輯上的不變性。
準則9 Logical data independence 數據邏輯獨立性
Application programs and terminal activities remain logically unimpaired when information-preserving changes of any kind that theoretically permit unimpairment are made to the base tables.
當對基本關係進行理論上信息不受損害的任何改變時,應用程式和終端活動都保持邏輯上的不變性。
準則10 Integrity independence 數據完整的獨立性
Integrity constraints specific to a particular relational data base must be definable in the relational data sublanguage and storable in the catalog, not in the application programs.
關係資料庫的完整性約束條件必須是用資料庫語言定義並存儲在數據字典中的。
準則11 Distribution independence 分布獨立性
A relational DBMS has distribution independence.
關係資料庫系統在引入分布數據或數據重新分布時保持邏輯不變。
準則12 The nonsubversion rule 無破壞準則
If a relational system has a low-level (single-record-at-a-time) language, that low level cannot be used to subvert or bypass the integrity rules and constraints expressed in the higher level relational language (multiple-records-at-a-time).
如果一個關係資料庫系統具有一個低級語言,那麼這個低級語言不能違背或繞過完整性準則。

Ref:
http://computing.derby.ac.uk/c/codds-twelve-rules/
http://www.itworld.com/nl/db_mgr/09022002

https://ja.wikipedia.org/wiki/ゴッドの12の規則

2016-07-03

[翻譯文]開源跨平台開發方法與工具

這是我近年來一直很想好好坐下來寫的一篇文章。我一開始是從開發90年代後期的軟體開始的,並且為我自己取得了一個Borland C++編譯器,藉此我快速地理解在Windows中什麼才是真正在背後實際應該要做的事。一開始我寫了一些小型的命令列應用程式,並且開始嘗試使用圖性介面的應用程式。我好愛創造的過程,也對這套工具的很多地方感到不滿。在那時候,我並沒有真正走進適用簡單的範例之後的過程。

過了一段時間後,我開始對開發網路應用程式感到興趣,並在對Perl感到失望後開始玩弄一個叫做PHP的新語言。我喜歡那些讓我可以非常自由的混合程式碼與HTML,並擁有使用PHP語言來對伺服端機器擁有完整存取權的感覺。我用PHP開發了一些網站,並試著使用不同的方法在可能的狀況下盡可能地將處理丟給JavaScript去做。這些真的很菜,但是將他與資料庫連結這件事讓我成長了很多。我也同時開始處理郵件清單,回答一些問題,並學習我所能知道有關已開發的開源軟體語言的任何事情。

在那之後我有一點分心到Linux身上,封裝應用程式,身為一個Gentoo開發者將那些推送給新的64位元架構。那真的很好玩,而且我學到了很多有關相依性、安全性更新、共享函數庫、以及在撰寫建造系統中許多科學家是處於多麼壞的處境中。經過這個時期,我也學到有關如何成為一個延展的線上社群的一份子,並有機會與很多非常熟練且專業的人共同作業。

C++與原生開發

最終,我理解到我想要開發軟體,而且當我不得不存取硬體時我真的想要使用原生語言來做開發。在那時候我使用Linux作為我的主要作業系統,但是我也必須與那些使用主流的Windows與Mac OS X的人們一起工作。我想讓可以使用我開發的軟體,但不想因為這樣寫三次程式碼。於是我開始調整軟體庫,主要針對KDE以及那些我必須要在Google Summer of Code專案中使用的部分。這就是最近九年左右我在Google Summer of Code專案中所做的事,而且我主要使用同樣的堆疊,增加或是更新函數,來促進合作,開源與跨平台開發。

C++是一個標準化的程式語言,擁有很多強力的開源編譯器與許多延伸編譯器支援,分散於從嵌入式系統到地球上最大的超級電腦中的所有地方。在我的作業中,我們定期將目標放在業界的兩個極端,就像是在桌機/筆記型電腦上的許多作業一樣。我想它仍然是最多元化的語言之一,擁有對比於C語言的高階特性,卻又與基層夠接近可以得到良好的性能。他也可以使用許多通常使用C語言介面擴展的API, 甚至可以在需要的時候與FORTRAN溝通。

跨平台抽象度

C++可以用可攜式的方式撰寫,但是有很多平台專用的API, 工具組,以及語言延伸套件。有很多方式可以建造C++應用程式。我一開始使用簡單的手寫Makefile,但是很快地就發現即使是維護那些簡單的專案也十分的瑣碎且容易出錯。我開始尋找Autotools, 然後轉向SCONS, 在大約是KDE在尋找切換方式前開始跨到CMake。

CMake是一個標記型建造系統生成器,那意味著他並沒有自己直接打造任何東西。你會使用CMake語言去指定你的專案應該要怎麼被建造,並且可以在必要的時候定義特定平台的例外。這也許聽起來有一點瑣碎,但是你可以得到一些十分巨大的回饋——他將為你的環境創建一個編譯系統。如果你想要用Visual Studio,請自便。如果你想要Makefile,很好。如果你偏好新的Ninja系統,你可以用它。我通常使用Ninja與那個叫CodeBlocks的東西來打造我的Qt Creator集成環境。

一旦你有某些可以打造的東西了,你會想要思考如何將視窗介面虛擬化。我也歷經了一點虛擬化,包括Java Swing, GTKMM(C++可以用GTK來替換), wxWidget, 以及一些我想我不願提到。我最後是留在Qt身上了,而他已經慣於擁有一個大缺點是他是在GPLv2版權協議下,而你的代碼必須同樣使用GPL公開,除非你付商業版權的費用。那總是雙重定義,但我從不真的喜歡這個方案。比起其他我試過的方案,他真的是非常好用,並且讓我覺得非常務實且自然,而且它在KDE上有一個很大的友善開源開發者社群。

另一個好事我經常藉由Qt獲得的是原生的視覺外觀。這個虛擬化努力的使用原生的Widget, 檔案對話框、色彩選擇器、諸如此類。就像工具箱進化後,他可以延伸到支援Android與iOS, 並且他在Nokia被Trolltech合併後改為使用LGPL授權。他也與KDE e.V.達成協議確保她永遠都是自由的,這替未來提供了保障。

版本控制,源碼review

我一開始使用CVS,而我們通常在東西被整合進Gentoo與KDE之後會review源碼。他做得很好,但是需要規範開發者留意提交清單上的提交訊息。切換到Subversion之後事情依然很類似,但是工具感覺較為易於使用且擁有更小的單元性(atomicity)。

對我來說,最大的改革是發生在搬到Git的時候。一開始,我們慣於把它用的像是一個簡單的拖拉置換,有能力可以在在上傳前於本機端提交。晚一點我們開始尋找更為整合性的源碼review,試著找出一些解決方案。有一陣子我們使用Gerrit, 但是我從不覺得那個介面夠直觀,我也不喜歡他專注於單一的提交上。

我現在大部分的工作都是使用GitHub或是GitLab, 兩者都擁有強力的焦點在拉取/整合需求上,感覺就像是分支包含了一個或多個的提交。這讓我們分離事情給分別的提交上,而這感覺比較符合直覺,可以發行他們就像他們被開發的目的一樣,而且請求review當它已經準備好被整合了。我喜歡這個等級的粗度,讓我可以切換到單一的提交,了解為什麼發生了一組變更,或是看到分支中的不同點。逐行註解容許我們專注在review上,並讓高層級的討論可以被放在主要頁籤裡面。

自動化構建與測試

跨平台開發中的另一個重要的方面是自動化構建與測試。這也同時讓我們不用進入到構建/封裝的相依性之中,就像我們很少寫那些不會在其他函式庫中重用的源碼。這是另一個CMake提供了非常大的幫助的部分,而我們的做法也時常進化。

我想這是在跨平台開發中一個或是多個困難的方面,而某些平台上會比其他平台更加困難。傳統的做法是使用cron工作分配去自動執行構建起始過程,而控制host上的dashboard腳本主要使用CMake透過CTest去自動建構。他們也會生成建構文件並上傳到CDash.

很多專案都擁有我們稱之為超建構(superbuilds)的某種東西。他們會在我們感興趣的專案最終建構之前自動化建構與專案的相依性階段。他們讓我們可以確定每一件東西都是在正確的旗標與正確的版本下被建造的。他們也會與CPack互動,在某些狀況下創建為不同的平台創建安裝器。CDash將會顯示出建造的概要,被自動創建的安裝器,測試結果,等等的資訊。

總結

跨平台開發是一個挑戰。這很重要,看到你所做的改變的結果在數小時(或者是數天,在最糟的狀況下)推放到其他平台上。一個專案需要考慮到跨平台作為他的流程的一部份,為了獲得最佳的結果。我可以在我們的做法上提到更多,但是這篇文章已經太長了。你可以用原生碼來獲得更好的結果,而且科學應用程式通常擁有數量龐大的額外依賴。一旦你將超級電腦與崁入式裝置混進來,事情就會變得十分有趣。


本文章原文來源: Open source cross-platform development methods and toolsI by Marcus D. Hanwell posted 20 Jun 2016 on opensource.com

GoogleCode-Prettify

SyntaxHighlighter

人気の投稿