Echo November's Note

 在認識modmesh的過程中，包括modmesh本身以及延伸的小實作，幾乎處處可見make及CMake的身影；雖然對它們的認識甚少，但操作的過程中可以隱約感受到make與cmake似乎存在某種相依性，擁有類似的機制。同樣仰賴導演(make, cmake)與腳本(Makefile, CMakeList.txt)，但卻做著不太一樣的事情，好像不只是差了一個C這麼簡單。 ~/git-repo/importation$ ls build CMakeLists.txt pybind11 test.cpp ~/git-repo/importation/build$ cmake .. ~/git-repo/importation/build$ ls CMakeCache.txt CMakeFiles cmake_install.cmake Makefile pybind11 ~/git-repo/importation/build$ make CMake vs make? 這裡 對於make做了些許的整理，make可以用來自動化shell script。CMake之於Make，與make之於shell script，存在了一些相似性。 「CMake 用來產生跨平台的專案建置文件，在 windows 下它會生成 visual studio 的專案檔 (.sln) codeblock eclipse，在 linux 下它會生成 Makefile。」在cmake之前的環境如下： ~/git-repo/importation$ ls CMakeLists.txt pybind11 test.cpp ~/git-repo/importation$ ls build/ (empty) 然後創建build這個directory，這能夠幫助我們將原始文件以及CMake過程的中間產物做做區分，再進行CMake： ~/git-repo/importation$ mkdir build ~/git-repo/importation$ cd build/ ~/git-repo/importation/build$ cmake .. 執行完成後，build底下就會有Makefile： ~/git-repo/importation/build$ ls CMakeCac...

在認識到Linux以前，我鮮少接觸到CLI(Command Line Interface)，也花了些許時間去熟悉。一開始看它也許會感到有些震懾，但並沒有想像中的複雜，單純是將我們習慣使用的GUI(Graphical User Interface)改成CLI，滑鼠改成鍵盤，簡單做了轉換。 sudo apt-get install qt6-default //以superuser身份安裝qt6-default mkdir build/install -p //新增資料夾 cd build/install //切換目錄到build/install rm –rf build //remove文件, recursively. makefile make 以及 makefile讓我們得以自動化我們想執行的command line。比如說modmesh裡面中clean這個target，若是藉由一行一行的command line我們會需要輸入以下的指令， rm -f $(MODMESH_ROOT)/modmesh/_modmesh$(pyextsuffix) make -C $(BUILD_PATH) clean 但如果已經在Makefile中寫好了clean這個target，將一行行的command line寫成了shell script。 .PHONY: clean clean: rm -f $(MODMESH_ROOT)/modmesh/_modmesh$(pyextsuffix) make -C $(BUILD_PATH) clean 我們就可以去藉由make，直接輸入 make clean 去執行我們想要去執行的內容，不用逐步命令。 make clean

 做這個小實驗的當天看到這個梗圖，相當呼應這個主題: 「其它的程式語言對你作力學是沒用的，作計算就三本柱 Python、C++、Fortran 足矣，連 C 都沒什麼用處。」Python在計算的速度上相較於C++非常的緩慢，這個 demo 很清楚地呈現了這件事。 以計算力學為題，python在tool的開發，input的整合上具有優勢，但是在計算效能上的表現不佳，於是就有了許多與python互相支援的foreign function interface(FFI)，如 swig, cython, pybind11。 截python所長，補C++所短 (or vice versa) ，似乎是做出更好的力學程式不可或缺的元素，pybind扮演的角色於是顯現。接下來就簡單用C++寫一個python的module: 1. 寫 .cpp/.h file。 #include <pybind11/pybind11.h> double square(double i){ return i*i; } PYBIND11_MODULE(test, handle){ //Module 的attributes 會在這裡做定義 handle.doc()="This is my doc"; handle.def("sqrt", &square); } 2. 寫 CMakeList.txt。 cmake_minimum_required(VERSION 3.4) PROJECT(pybind_vid) add_subdirectory(pybind11) pybind11_add_module(test test.cpp) //test為建構的module的名稱 test.cpp是它所依據的檔案 3. Build the module。 mkdir build cd build/ cmake .. make 4. 在python中使用前面所建立的module。 ~/git-repo/importation/test$ python3 >>> import test >>> dir(test) ['doc', 'file...

In a well-organized C++ code base, the hpp files should always be included using the full path like: #include <modmesh/base.hpp> #include <modmesh/profile.hpp> #include <modmesh/buffer/buffer.hpp> Python import 的module 並不必然要用python撰寫，也可以藉由C++。然而我誤解了這番話的意思，進而混用了 header files 與 modules，以為以下的實驗會成功： import importation #succeed import layer1.importation #succeed import header #failed 以下是python importation 整理過後的資訊： 1. import modmesh 以 modmesh 作為例子 ， import modmesh 我原先同樣是誤會 modmesh.hpp 才是被 python import的對象；但這個對象其實是library(or python package):$(MODMESH_ROOT)/modmesh。如果它已經被 built, 那麼目錄裡頭就會有 __init__.py 以及 .so 。 2. python importation python importation 的機制在於編輯 sys.path. e,g  del sys.path[0] sys.path儲存的是尋找python module的路徑。在這個動作之後，原先若是被import的對象被列在sys.path[0]所儲存的路徑之下，那麼import就會失敗。 3. Module written in C++ 如前所述，Python import 的module 並不必然要用python撰寫，e.g. C++, 它們是透過 import shared library(.so)來被python支援。 C++ and python 的連結可透過 swig, cython, pybind11 等等。在modmesh 中則是使用 py...

這一天是mini-sprint。Sprint的精隨就如同字面上的意思，透過實體會面的方式將問題拋出並且修正，在短時間中加速突破困難，就像衝刺一樣。這一天的內容也涵蓋幾個面向： 1.  Unit testing Unit testing是用來確保程式的品質。與我原先想像不同之處是，100％的unit testing 覆蓋率並非最為理想，100％意味著及便是無傷小雅的修正也會造成testing不通過，然而這並非我們所預期的。而在 modmesh 中，pytest是用來跑unit testing的target。 make pytest 2. Compiler Explorer We get to know that some bugs lies in runtime rather than compile time, and that same numbers of line in C may not be same number of lines in assembly code, so we may benefit from understanding assembly code. I've pasted one of my code to the left, finding the assembly language to the right is nonsense to me, and I went look up for more information, and learned that assembly code is a layer above machine code, where it replace the 0&1 with English; it is also not cross platform. Comparing C with assembly code, C is easier and more efficient in programming, and the running time of the two is roughly the same, therefore it might not be practical to code assembly code. Yet, I have question...

YY: Good to know that you managed to rebuild with pybind11 reinstalled.  Comments: 1. Please search the cmake document for why you should mkdir before building a cmake project.  Similarly, please share the link that provides the information. So at first I went  here .  I get to know: Usage cmake [options] path-to-source cmake [options] path-to-existing-build cmake [options] -S path-to-source -B path-to-build From the  video , the mkdir seems to be what most people do. The reason to why mkdir I supposed is that it helps organize our files, so that files won't be a mess. It helps, but not a necessity. In order to better confirm my words, I did a little experiment on it: cmake -DCMAKE_INSTALL_PREFIX=/ . sudo make install It works as well. So I think the reason to mkdir is that it helps sort our files in an organized way.  While building pybind, there are files being generated, including Makefile; no additional CMakeLists.txt are generated accordingly. ...

Hi, what I tried to reach in the past 2 days was to build the pybind11 from source. At first I failed to find information I expected in the pdf documentation in readme (I focused on the wrong chapter I later found). What I did at first was following the history, I followed them and then tried them myself, and it was like: rm -rf /usr/local/include/pybind cd ~/git-repo git clone (github pybind repository) cd pybind mkdir build/install -p cd build/install cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Release ../.. sudo make install the viewer could be successfully built and run.  The second attempt was following was following the  pdf documentation in readme : mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=/usr/local .. make check -j 4 along with sudo make install followed. Up to this point, I don't quite understand the purpose of `mkdir` before `cmake`, and the reason to why `cmake` and `sudo make install` seems to be the main point to build `pybind11`...

 軟體工程兩件事： 1. 寫腳本-- 也就是寫makefile。 以 modmesh 的makefile作為例子： .PHONY: default default: buildext .PHONY: clean clean: rm -f $(MODMESH_ROOT)/modmesh/_modmesh$(pyextsuffix) make -C $(BUILD_PATH) clean .PHONY: cmakeclean cmakeclean: rm -f $(MODMESH_ROOT)/modmesh/_modmesh$(pyextsuffix) rm -rf $(BUILD_PATH) .PHONY: pytest pytest: $(MODMESH_ROOT)/modmesh/_modmesh$(pyextsuffix) env $(RUNENV) \ .PHONY，根據 這篇文章 的說法它叫做「偽目標」（嗯要慢慢用心體會，要認識的還真不少）依據我目前為止的認知上，冒號之前為target，冒號之後為dependency, i.e, target: dependency，並且會層層向下追朔，以上的例子來看default作為target，dependency則是buildext，此時程式就會再向下追朔，找到buildext作為target之處，向下追朔，或是執行裡頭的指令。 To "build the target"，則如 make pytest 同樣的事情也不見得要透過這樣的方法來進行，i.e, make clean在terminal中藉由以下的指令產生等效的結果： rm -f $(MODMESH_ROOT)/modmesh/_modmesh$(pyextsuffix) rm -rf $(BUILD_PATH) 我想這就是為什麼寫makefile會叫做寫腳本，真的是有異曲同工之妙ㄋ～ 2. 命名檔案 -> Questions: Make and cmake？ Dry-run? VERBOSE?