OCaml Outreachy 實習計畫

目前，有幾組旨在學習 OCaml 的練習：https://github.com/gs0510/ofronds https://github.com/sudha247/learn-ocaml-workshop https://github.com/kayceesrk/cs3100_f19 https://github.com/ocaml-sf/learn-ocaml，來源：http://ocaml-sf.org/learn-ocaml-public https://github.com/ocaml.org，來源：https://ocaml.dev.org.tw/exercises

可能還有更多。每組練習都使用不同的執行框架（例如 Jupyter、Learn-OCaml 或自訂框架）。它們提供了一系列的使用者體驗，從可用的解決方案到候選解決方案測試。實習的主要目標是建立一個通用配置，允許在大多數已知設定中執行每組練習。這將具有以下好處

• 練習不再與特定的設定綁定，它們可以在多個設定中使用 - 學習內容和技術設定之間的鬆散耦合 - 對於學習者：練習組之間的特徵對等、自學、獨特、簡單且快速入門 - 對於教師：專注於練習撰寫，使用通用設定 - 對於社群：更多練習、更容易的啟動、改善 OCaml 的學習曲線。目標不是讓所有專案中的所有練習都出現在所有設定中。相反，目標是展示這樣做是可能的。但是，這將透過將每個練習組中有意義的部分移植到多個設定或分支中來實現（如果需要）。作為設計約束，我們希望在 https://ocaml.dev.org.tw/ 上提供練習。我們考慮自動處理練習組以產生 https://ocaml.dev.org.tw/exercises 頁面。通用設定應允許這樣做，儘管它不是實習的一部分。

查看兩個檔案之間的差異是開放原始碼工作中最常見的活動之一。它發生在審閱提取請求、檢查提交和許多其他情況時。然而，讀取這種差異並不總是容易的。已經製作了許多工具來改善這種情況並使差異審閱更容易：使用顏色來區分新增和刪除的行（傳統上為綠色和紅色）、使用粗體字來將注意力集中在單字級別上已修改行的部分、並排顯示兩個檔案等等。但是，上面提到的大部分改進

• 這些工具是用於檔案的「通用」差異比較。某些檔案可能具有非常長的行，不適合目前的差異輸出格式。- 它們僅限於視力正常的人使用。此專案的目標是在 Git diff 的基礎上開發一個視覺化工具。該視覺化工具是一個終端使用者介面，而本次實習的主要任務是使其對螢幕閱讀器具有高度可存取性。

OCaml 是一種工業級函數式程式語言，已經存在將近三十年。

雖然函數式程式設計本身並不新穎，但它尚未在主流程式語言中佔據主導地位。最近，越來越多的主流語言開始採用函數式程式設計的概念。現在比以往任何時候都更適合擁有各種與函數式程式設計相關的學習材料。

創意程式碼是一種電腦程式設計類型，側重於使用軟體和數位工具生成藝術性、表現性和創造性的輸出。它在遊戲開發等領域有應用。最重要的是，它是一個很棒的教學工具，可為讀者提供視覺輸出。

Joy 是一個小型 Python 創意程式碼函式庫。Joy 大量建基於函數式程式設計概念，而很少參考 Python 語法。

此專案旨在 OCaml 中實作幾何創意程式碼函式庫。它深受 Joy 的啟發。完成後，它將作為在 OCaml 中進行幾何創意程式碼設計的一種手段。

OCaml 是一種功能強大、靜態型別的程式語言，以其效率和表現力而聞名。OCaml.org 作為 OCaml 社群的中心樞紐，提供資源、文件和新聞。在當今的數位時代，使用者期望有更個人化和舒適的網路體驗。其中一個期望是提供深色模式，這已成為網站和應用程式上廣受歡迎的功能。此專案概述了為 OCaml.org 實作深色模式的計畫，以增強使用者體驗並使平台現代化。隨著 OCaml 在各行各業持續受到關注，現代化其線上形象以滿足全球使用者的期望至關重要。

目前淺色模式的樣式和顏色已經存在，因此實作深色模式將需要根據 Figma 設計添加對比的顏色和樣式。同時也會考慮到可訪問性標準，並建立一個可在淺色和深色模式之間切換的按鈕。

受到 Rust 的「Are we GUI yet?」的啟發，我們希望對 OCaml GUI 函式庫進行相同的工作。類似的工作已針對 OCaml 網頁函式庫完成：「Is OCaml web yet?」（請參閱 pull request）。這項工作將允許未來處理「Are we game yet?」。

這項調查必須考量這些函式庫的目標平台、相依性、(不)相容性、功能、上次更新時間等。OCamlVerse 中有一個清單，但不完整或不夠詳細。先前具有其他語言 GUI 函式庫知識的實習生，也可以將它們與對等的 OCaml 函式庫進行比較。

這項工作必須產生一份在 OCaml.org 上的指南，類似於 「Is OCaml web yet?」頁面。

每個作業系統，即使是 unikernels，都需要一種在重新啟動後保存資料的方式。在 MirageOS 中具備持久性儲存能力絕對是值得考慮加入的功能。開發此功能包括建構用於分割磁碟的函式庫、用於這些分割區的檔案系統，以及從使用者觀點與這些儲存裝置互動的簡單、直觀和程式化的方式。這個專案藉由建構一個用於 GPT 分割的函式庫，將這個願景往前推進了一步。

過去，當 'ppxlib' 在轉換中遇到異常時，它會停止重寫過程，導致之後的重寫器無法被處理。此外，當有多個重寫器失敗時，也無法同時報告多個錯誤，因為只會引發第一個引發錯誤的重寫器，並且編譯過程會在那裡停止。但現在，引發錯誤的重寫器不會阻止前面的重寫器運行，這使得在無上下文階段和所有其他階段都可以引發多個錯誤。

MIDI，即樂器數位介面，是音樂和音訊技術領域廣泛使用的協定。MirageOS 是一個專門用於創建輕量、安全且高效的單核作業系統的函式庫。單核心是高度專業化、針對特定應用設計的單一用途虛擬機器映像，它是用 OCaml 編寫的。該專案專注於實現 rtpMIDI 協定，用於透過乙太網路序列化和反序列化 MIDI 訊息，並實現諸如基於發布者-訂閱者模型的 MIDI 訊息伺服器-客戶端模型等使用案例。

TopoJSON 是 GeoJSON 的擴展，用於編碼拓撲結構。這允許移除冗餘數據並大幅縮減檔案大小。這在瀏覽器中使用數據時通常非常理想。在先前的 Outreachy 實習中，實作了一個新的 OCaml 函式庫，為 TopoJSON 提供 OCaml 函式庫。此專案將以此為基礎，為該函式庫新增更多功能，並提供類似於 geojsone 函式庫的非阻塞、串流編解碼器版本。

OCaml 5.0 即將推出！它將支援共享記憶體平行處理和並行性，這是 OCaml 多年來一直缺乏的。這將伴隨著一套強大的多核心函式庫，適用於並行程式設計。多核心編譯器和函式庫正在積極開發中，並將隨著 OCaml 生態系統朝向多核心發展而持續演進。為了評估 OCaml 編譯器和多核心函式庫中新功能的影響，我們在基準測試套件中提供了一組循序和並行基準測試。雖然循序基準測試包含許多真實世界的應用程式，但更廣泛的並行基準測試將會很有用。此專案需要收集各種地方（例如 https://github.com/ckoparkar/ocaml-benchmarks）提供的並行基準測試，並將其納入基準測試套件中。

TopoJSON 是 GeoJSON 的擴展，用於編碼拓撲。這允許移除冗餘數據並大幅減少檔案大小。這通常非常理想，尤其是在瀏覽器中使用資料時。這個專案旨在擴展 ocaml-geojson 以支援 TopoJSON。

我們目前無法得知提供 v3.ocaml.org 服務的伺服器效能、哪些頁面被造訪最頻繁、是否發生錯誤等等。為了提供一些可見性，我們可以實作一個基本的監控儀表板，以提供以下指標：記憶體、CPU、開啟的檔案描述符；以及以下統計數據（請先檢查是否符合 GDPR 規範！）：請求的 URI、使用者代理、語言、日誌。這個專案主要包含兩個部分：前端和後端。後端包括建置一個高階函式庫來收集資料並取得統計數據。前端將使用此函式庫來顯示指標、統計數據和我們想要收集的其他資料的圖表。

程式語言通常會提供某種元編程方法，以便在最後的編譯步驟之前預處理程式碼，例如，以巨集或範本的形式。OCaml 編譯器沒有提供完整的內建巨集系統，但 OCaml 解析器確實提供用於預處理目的的語法：屬性和擴展點。我們 - OCaml 社群 - 還有一個官方框架，稱為 ppxlib，可以基於該語法編寫預處理器（稱為 PPX）並將它們整合到編譯過程中。但是，編寫和提供重要的 PPX 給 OCaml 開發人員是 OCaml 社群的責任。我們注意到，將最重要的 PPX 放在官方 PPX GitHub 組織下（與 ppxlib 相鄰）會很有幫助。開發人員可以輕鬆找到它們；開發人員可以信任它們；它們編寫良好且衛生，因此開發人員可以將它們用作編寫其他 PPX 的指南。在這個專案中，您將編寫一個或一些這些官方標準 PPX。

在 OCaml 的 VSCode 擴充功能中支援 .eml 檔案。OCaml 網頁框架 Dream 使用 .eml 檔案將 HTML 嵌入 OCaml 檔案中。目前，在 VSCode 中開啟這些檔案，使用官方的 OCaml VSCode 擴充功能，將不會為 .eml 檔案提供任何語法高亮或診斷，因為它們不受支援。該專案的目標是首先在擴充功能本身中加入對語法的支援，然後最終在第二步中加入對 OCaml 語言伺服器 (LSP) 中語言的支援。

Opam 是 OCaml 程式碼的基於原始碼的套件管理器。這個專案包括撰寫一個新的 Web 客戶端，用於呈現來自 opam 套件資料庫的輸出。在 opam.ocaml.org 上有一個 JSON 端點，它提供了有關套件的資訊，這些資訊將提供有關套件的中繼資料。我們可以擴展此 JSON 中繼資料以包含所有 opam 套件（不僅僅是前 10 名），並使用它來支援該網站的搜尋前端。這可能包括將資料呈現為 GraphQL 端點，前端使用 GraphQL 查詢該端點。

通常，編譯器的輸出訊息對機器來說比較難以讀取，因此找到警告、錯誤等及其來源會比較耗時。藉由為編譯器訊息產生結構化輸出，其他工具可以更容易地與它們互通，並在訊息之上提供工具。

使用程式碼覆蓋率工具改進編譯器測試流程。核心 OCaml 系統有一個大型的測試套件，如果能看到系統的哪些部分被更積極地測試，哪些部分沒有，將會非常有幫助。這將有助於開發人員了解在哪裡需要添加新的測試，並在提高覆蓋率的過程中，可能會發現尚未探索的錯誤並加以修復。這可能會有助於使 OCaml 及其函式庫更加可靠。

MirageOS（請參閱 http://xenproject.org/developers/teams/mirage-os.html、http://www.openmirage.org/）是一種以 OCaml 撰寫的型別安全單核心（unikernel）。它會產生高度專業化的「設備」虛擬機，這些虛擬機直接在 Xen 上執行，而無需中間的核心。MirageOS 應用程式通常透過雲端上的多個通訊核心實例執行。目前，這些實例難以管理；我們希望探索使用常見的公有雲 API（例如 Amazon EC2 和 Rackspace 公開的 API）來管理這些分散式運算的策略。首先，我們需要為 (例如) EC2 和 Rackspace 建立純 OCaml API 綁定（需要純粹性以確保可移植性）。然後，這些 API 綁定可用於為單核心提供作業系統級別的抽象。例如，傳統虛擬機可能會熱插拔一個 vCPU；而 MirageOS 應用程式會使用雲端 API 請求「建立虛擬機」並將新實例「連接」到現有網路。我們應該能夠透過在叢集環境中使用此類 API 來啟動數千個「CPU」。除了幫助 Xen/Mirage 之外，公有雲 API 綁定對於其他環境中的其他人也非常有用，這是一個不錯的附加效果。