文章

顯示包含「PySide」標籤的文章

[Qt] PySide 如何 debug 沒有 stack trace 的 Segmentation Fault

-
圖片
雖然 PySide 是 open source 也很好用，但如果我們用 PySide 寫了一些有 bug 的程式，GUI 在做了某個操作後就會無預警 crash 消失不見，只留下哀傷的一行訊息在 console 上： Segmentation fault 現在是要怎麼 debug?  最近我就想用 QTableView + QAbstractItemModel 做一個可以動態新增資料的 table，但是以下的程式碼跑起來就會遇到 segmentation fault (完整的程式碼在文章最下面): from typing import Any, List import sys from PySide2 import QtCore, QtWidgets class DataModel(QtCore.QAbstractItemModel): ... class MainDialog(QtWidgets.QDialog): ... if __name__ == "__main__": ... 看了一下我也不知道問題在哪，我也不太曉得 QAbstractItemModel 哪幾個 functions 是一定要 override 的，現在該怎辦? 解法1: 暫時切換成 PyQt 當我們把一開始的 import 全部換成: from PyQt5 import QtCore, QtWidgets 再跑一次程式，這時候 GUI 不僅不會 crash，console 上還會多一行完整的訊息: NotImplementedError: QAbstractItemModel.index() is abstract and must be overridden Oh 原來我忘記要 override "index" function 了。 解法2: 用 gdb 來 debug 如果遇到提示還不夠明顯的狀況，我們可以用 gdb 來 debug。 等等! gdb 不是給 C++ 用的嗎? 和 Python 有什麼關係? 原來 PySide (Qt for Python) 只是像是用 Python 的殼把 Qt C++ 的程式碼包起來，詳細的運作原理可以參考  Qt for Python/Shibok...
發佈留言
閱讀更多

[Side Project] 用 PySide2 (Qt Python) 實作 Prototype Pattern 與樂譜編輯器

-
圖片
最近讀書會剛好要報 Prototype Pattern，看了一下  Design Patterns: Elements of Reusable Object-Oriented Software 的 prototype 這章節。書中一開始動機說明一個五線譜的 GUI 編輯器，後面 sample code 卻是用像是 toy example 的迷宮，這樣真的兜不攏也看不太懂。 網路上找了一下也沒有人為了 prototype pattern 做五線譜的範例，剛好最近工作上會碰到 PySide2 ，於是我想想，乾脆來把五線譜的範例做出來順便練習一下 Qt 的 QGraphicsView 要怎麼使用，也順便展示 prototype pattern 的優缺點。 Side Project on  GitHub 簡單的樂譜編輯器 GUI Users 可以從左邊拖曳樂譜上的符號到右邊的畫板上，畫板 (canvas) 上的符號也可以事後再進行拖曳、旋轉。 就算簡單也該有的功能 為了讓範例簡單，我就只做了書中提到的 half note 和 whole note，不要加進一大堆其他符號來讓整個 example 複雜化。但相對地我們也不能弄得太簡單太像 toy example 看了沒感覺。 我就多做了幾個比較像 real project 的功能: 拖曳的符號會像是磁鐵一樣 snap to lines/spaces 到最近的五線譜線上或空格(間) 內 拖曳符號時我把預設有的圖示 (indicator) 隱藏，拖曳中 (dragging) 也看的到放開 (drop) 後的樣子 我限制拖曳的符號只能在畫板 (canvas) 中移動，不給使用者拖曳到不見或卡在邊邊一半 Prototype Pattern 優點 1: 可以 Reuse Framework 不用 prototype pattern 我們會怎麼做創 object 的 framework? 我們可能就會創出一大堆平行化的 GraphicTool ( 橘色 的部分) 用來造代表樂譜符號的 Graphic: 書中說 framework 不應該知道 application 任何細節才對，萬一今天 application 改成做遊戲地圖編輯器呢? 難道要創更多 GraphicTool? 那可能我們會先發瘋。 所以 prototy...
發佈留言
閱讀更多

此網誌的熱門文章

[試算表] 追蹤台股 Google Spreadsheet (未實現損益/已實現損益)

-
圖片
在 Dcard 上發了一篇文結果引起超多網友回應想要看試算表，我就來整理一下我追蹤台股用的 Google 試算表給大家。 這個試算表我目標是以 "簡單" 為主，底下我也會講解公式的運作原理，希望大家能以此試算表輕鬆擴充自己想要的功能。 功能 未實現損益 (Unrealized Gain/Loss 表) 不管同一支股票是不是有部分已經賣出，只要你還持有未賣出的股票這邊都看的到。 已實現損益 (Realized Profit/Loss 表) 我過去的績效如何? 在這個表一目了然。 未實現損益: 詳細資料 (Unrealized Stats 表) 我還持有多少股? 每股市值多少? 每股的成本是多少? 在這個表可以快速追蹤。 手機友善 (Mobile Friendly) 我為了在手機上也可以快速看我想看的資訊，把 "Unrealized Gain/Loss" 做成比較窄的版型。 只要下載 Google Sheets app 打開試算表就可以了。 Google Spreadsheet 連結 Google Drive 連結 Stock Tracking 使用方式 請先點 "檔案" -> "建立副本"，copy 一份試算表到你自己的 Google Drive 將 "Current Price" 表單中填上你想要追蹤的股票代號和名稱 將 "Transactions" 表單中刪除範例資料，但請務必留下第 2 列 (因為有公式)，然後慢慢往下填入你的資料 Step 1: 檔案 -> 建立副本 Step 2: 新增/刪除股票代號和名稱 (紅框圈起處)，灰色底欄位代表有公式 Step 3: 在 "Transactions" 表填入資料到白色底欄位 (紅框圈起處)，灰色底欄位代表要讓公式自動計算 未實現損益的正確算法 其實在發 Dcard 文之前我自己也像 另外一個表單 犯了同樣的錯誤，就是只有在股票全部賣光光 (持有 0 股) 後計算的未實現損益才會正確。還沒全部賣光怎麼辦? 難道就不顯示了嗎? 飲料的例子 只要股票中途賣出一部分，目前還持有部分股票的話，感覺計算就突然變得很複雜。但不用怕，我們來用飲料當作股票舉個超簡單的例子 (1 杯=1...
閱讀更多

用 100% code coverage 讓自己設計品質好的軟體

-
前言 很多敘述都是說 100% code coverage 雖然可以達成，但是會花非常多時間，所以往往 project 的 code coverage 都設定在 80-90% 左右。 但這前提是 source code 非常亂的情況下，才是 true。 現在我習慣讓新 projects 達到 100% code coverage，並不會多花時間，反而減少了許多 bugs，而且整體上程式碼也變得非常好讀，甚至讓任何新人進來看都看得懂。 我用一個簡化的 python 例子來描述怎麼做到這件事。 100% 不合理的案例 現代化的軟體通常少不了與外部軟體的整合，所以我們可以設計一個簡單化的 application: 用 REST API 取得某個使用者的發文 把 raw data 轉成 application 內部 data 用一些邏輯去搜尋發文 就會寫出下面這樣的程式碼，看似簡單: # complex_find.py from dataclasses import dataclass import requests @dataclass(frozen=True) class Post: id: int title: str body: str def find_posts_with_keyword(user_id: int, keyword: str) -> list[Post]: # Get a list of posts with REST API base_url = "https://jsonplaceholder.typicode.com/posts" params: dict[str, int] = {"userId": user_id} response = requests.get(base_url, params) try: response.raise_for_status() except requests.HTTPError as e: raise RuntimeError(f"Failed to call API with params: {params}") fr...
閱讀更多

[LeetCode] 用更簡單的方式分析與解決 #11 Container With Most Water

-
圖片
幾乎所有解答不管中英文都在講兩邊指針移動的演算法，難道就沒有其他解法? 我今天就來用一個很簡單的分析讓原本會超時 (TLE) 的暴力解法可以被 Accepted。 最大的容器有什麼特徵? 每個測資都一定有一個最大的容器，假設我們最後找到最大的容器好了: 我就想了一下，左邊什麼情況不會發生? 左邊有機會有更高的牆嗎? 不會，不然你早就找到更好的解答了: 因為不管怎樣左邊一定會凸出去一塊綠色的部分，那我們一開始找到的根本不是最佳解。 所以如果你找到最大的容器，左右邊絕對都不會有更高的牆: 可是演算法怎麼設計? 對啦，我們知道左右邊不會有更高的牆，可是我們還是要把解答找出來啊！演算法怎辦? 我們知道暴力解就是把每個可能性都 try 過，就會有兩個 for loop 一左一右試試看每種面積，我們就可以這樣寫: #include <algorithm> class Solution { public: int maxArea(std::vector<int> height) { int maxArea = 0; for (int left = 0; left < height.size(); left++) { const int heightLeft = height.at(left); for (int right = height.size() - 1; right > left; right--) { const int heightRight = height.at(right); const int width = right - left; const int minHeight = std::min(heightLeft, heightRight); const int area = minHeight * width; maxArea = std::max(area, maxArea); } } return maxArea; } }; 只是我第二層的 index 是從右往左，但只是和一般的作法方向相反而已，每種可能性都還是會試過，所以沒差。 這丟上去當然會超...
閱讀更多