Windows Terminal の 設定 「見分けがつかないテキストの明るさを自動的に調整する」 で、黒背景に暗い青字とか暗い赤字のテキストカラーが調整されて見やすくなる
tag: windows-terminal, mintty, freebsd14, xterm-256color, windows11, windows10
Windows Terminal の 設定 > PwerShell > 外観 > 見分けがつかないテキストの明るさを自動的に調整する を ON にすると、黒背景に暗い青字とか暗い赤字のテキストカラーが調整されて見やすくなる。 ハイコントラスト寄りに調整するようで、これはいい機能だ。 TERM=xterm-256color設定で使っている人は是非。
ちなみに、MSYS2 (Git for Windowsにもついてくる) の mintty.exe は、デフォルトでこの手の機能がついているのか、カラーテキスト(ls --colorとか)が最初から見やすい。
余談だが、FreeBSD 14.0-RELEASE では terminfo の設定が変わったらしく、 TERM=xterm-256color 設定にて mintty / windows terminal 経由でターミナルを表示した場合でも emacs 上で表示位置がズレて違うところを編集することは無くなったっぽい。 こちらも地味に助かる。
ChatGPT APIに10ドル課金してみた
tag: chatgpt
ChatGPTのAPI契約はしてたんだけど、人力で質問文を書いて時々 gpt-3.5-turbo API を投げる程度ではAPI課金額は $0 のままだった。
API課金実績が少なくとも $1 (後に $0.5 に緩和) は無いと、API呼び出し時のモデル名に gpt-4 を指定できない。 ( https://help.openai.com/en/articles/7102672-how-can-i-access-gpt-4 )
gpt-3.5-turbo API の値下げ発表が相次ぎ、もはやウチからの gpt-4 API の呼び出しは絶望と思われた...。
がしかし、 https://platform.openai.com/account/billing/overview Billing settings の所に Buy Credits ボタンができて、APIを無理に呼ばなくても課金できるようになった。
上のボタンからとりあえず $10 ほど課金。
１日ほど放置した後に実験開始。 gpt-4 API 呼び出しに成功。やったぜ。
これから時々gpt-4 APIを使って料金がどうなるか試してみる予定。
gpt-3.5-turboでは課金まで行かなかったがgpt-4なら料金も高いし実用的だし課金まで届くだろう。
p.s. 12/6
ChatGPT-4 プロンプト例。
JavaScriptのフレームワークであるVue.js バージョン3 のコンポーネント の Options API の書き方を使って、シンプルなストップウォッチ型のタイマーを実装するVueコンポーネントのサンプルコードを示して。
おお。 Vue.js のバージョン3 の コンポーネント ( Options API ) の書き方でソースのサンプルが出てくる。 一部間違ってたけど。 それにしても新しいネタも出力してくれると便利だな。
Vue 3 APIのデフォルトが Composition API に変わったらしい
tag: vue
しばらく見ない間にえらく変わったモンだ。
ちょっと練習。
Options API だと method: の下に function 定義を書いていたのが、 <script setup> の中に普通に関数定義を書く雰囲気になるのかな。
手元のソースの量が多いと移植が大変だな。
そういえば、この手の定型書き換えタイプの移植はChatGPT-4が得意と聞いたことがあるな。。
npmのpackage.jsonのscriptsで環境変数(NODE_ENV)を設定するとき、cross-envを使ってWindowsでもLinux,Macでも動くようにする
tag: cross-env, npm, package.json
2024-03-05 追記。cross-env はあやしいコードが含まれていたらしく npm から消去されていて、使用できなくなっている。
以下、元ネタのまんまだけど一応メモ。
Linux,Macなら
package.json(使用前)
"scripts": {
"test":"NODE_ENV=test jest"
}
Windowsなら
package.json
"scripts": {
"test":"set NODE_ENV=test&&jest"
}
このようにプラットフォームを意識して書きわける必要があった。
そこで、cross-env を使用する。
npm install --save-dev cross-env
package.jsonにて以下のように記載できるようになる。
"scripts": {
"test":"cross-env NODE_ENV=test jest"
}
オレwiki用 Vue 3 のビルドシステムを vue cli から vite に変更
tag: vue, vue3, vite, vite5, wiki
久しぶりに Vue 公式のクイックスタート ( https://ja.vuejs.org/guide/quick-start.html ) を見たら環境が色々変わっていたので追従してみた。
結果として一番大きく変えたのは vue cli から vite へのビルドシステム変更関連になった。
その他変更したのは HTML(厳密にいえばJSP)の中の <script type="module"> の記述と、その中の import の記述の周辺。
Vue 3 への移行は実施済みだったので、Vue関連のモジュールはoptions APIの書き方のままでOKだった。
■豆知識:JavaScriptのモジュールについて。
■豆知識:ES6 Module の使い方
■環境
■参考:各種公式リンク
■Viteの特徴
■設定ファイルの比較参考用の Vue + Vite ダミープロジェクトを作る
手順としては、最初に比較参考用のダミープロジェクトを作る。
# Vue公式のクイックスタート手順に従い、vue + vite プロジェクトを作成。 npm create vue@latest # 入力パラメータは以下。 TypeScriptは使う。 ESLintは使う。 Prettierは使う。 Project name: ... vue3-vite-proj Add TypeScript? ... Yes Add JSX Support? ... No Add Vue Router for Single Page Application development? ... No Add Pinia for state management? ... No Add Vitest for Unit Testing? ... No Add an End-to-End Testing Solution? ... No Add ESLint for code quality? ... Yes Add Prettier for code formatting? ... Yes # 画面に表示されたコマンドを実行。 cd vue3-vite-proj npm install npm run format npm run dev # 追加で使用するライブラリをインストール。 npm install --save axios npm install --save lodash npm install --save-dev "@types/lodash" npm install --save-dev cross-env
■設定ファイル:package.json
自アプリ用のpackage.jsonを調整。
{
"name": "vue3-vite-proj",
"version": "0.0.0",
"private": true,
"type": "module",
"main": "./dist/kjwikig-lib.umd.js",
"module": "./dist/kjwikig-lib.es.js",
"exports": {
".": {
"import": "./dist/kjwikig-lib.es.js",
"require": "./dist/kjwikig-lib.umd.js"
}
},
"dependencies": {
"axios": "^1.6.2",
"lodash": "^4.17.21",
"vue": "^3.3.11"
},
"description": "A Wiki System written by JSP/Servlet. The Wiki data are stored in local file system.",
"devDependencies": {
"@rushstack/eslint-patch": "^1.3.3",
"@tsconfig/node18": "^18.2.2",
"@types/lodash": "^4.14.202",
"@types/node": "^18.19.3",
"@vitejs/plugin-vue": "^4.5.2",
"@vue/eslint-config-prettier": "^8.0.0",
"@vue/eslint-config-typescript": "^12.0.0",
"@vue/tsconfig": "^0.5.0",
"cross-env": "^7.0.3",
"eslint": "^8.49.0",
"eslint-plugin-vue": "^9.17.0",
"npm-run-all2": "^6.1.1",
"prettier": "^3.0.3",
"typescript": "~5.3.0",
"vite": "^5.0.10",
"vue-tsc": "^1.8.25"
},
"scripts": {
"dev": "vite",
"build-dev": "run-p type-check \"build-dev-only {@}\" --",
"build": "run-p type-check \"build-only {@}\" --",
"preview": "vite preview",
"build-only": "cross-env NODE_ENV=production vite build --mode production",
"build-dev-only": "cross-env NODE_ENV=development vite build --mode development",
"type-check": "vue-tsc --build --force",
"lint": "eslint . --ext .vue,.js,.jsx,.cjs,.mjs,.ts,.tsx,.cts,.mts --fix --ignore-path .gitignore",
"format": "prettier --write src/"
}
}
■設定ファイル:vite.config.ts
// vite.config.ts
import { fileURLToPath, URL } from 'node:url'
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
// https://vitejs.dev/config/
export default defineConfig({
// ブラウザでの実行時に process.env.NODE_ENV が未定義だと言われると困るので定義しておく。 export named モードだとprocessが未定義だといわれる。
// named
// define: { 'process.env.NODE_ENV': '"production"' },
define: { 'process.env.NODE_ENV': '"development"' },
plugins: [
vue(),
],
resolve: {
alias: {
// テンプレートをmountするHTMLから取得する場合、vue の alias を vue/dist/vue.esm-bundler.js にする。
vue: "vue/dist/vue.esm-bundler.js",
'@': fileURLToPath(new URL('./src', import.meta.url)),
}
},
build: {
outDir: './dist/', // ビルド成果物の生成先。project rootからの相対パスを指定。
// libraryモードの指定。vite build 時のみ動作。
lib: {
entry: fileURLToPath(new URL('./src/main/vue3composition/main.ts', import.meta.url)), // エントリポイント
name: "KjwikigLib", // グローバル変数として公開するライブラリの変数名。UMDの時に使うのかな？
formats: ['es', 'umd'], // 生成するモジュールの形式を配列形式で指定。デフォルトは ['es', 'umd']。
// fileName: 'kjwikig-lib', // 出力ファイル名のprefixを指定。
fileName: (format) => `kjwikig-lib.${format}.js`, // ファイル名をアロー関数形式で指定することもできる。
},
// https://rollupjs.org/configuration-options/ rollup のオプション指定
rollupOptions: {
// ライブラリーにバンドルされるべきではない依存関係を
// 外部化するようにします
// external: ['vue'],
output: {
// export モード。デフォルトはauto。auto指定の場合は export default にするか export named にするか自動判定。
exports: 'named',
// entry / chunk / assets それぞれの書き出しファイル名の指定。
// index.html モードで指定するとファイル名末尾のハッシュ名を出なくしてファイル名を固定化できる。
// libraryモードで使うと es と umd のファイル名が同じになるので良くない。
// entryFileNames: `kjwikig-lib-entry.js`,
// chunkFileNames: `kjwikig-lib-chunk.js`,
assetFileNames: `kjwikig-lib-style.css`,
// 外部化された依存関係のために UMD のビルドで使用する
// グローバル変数を提供します
// globals: {
// vue: 'Vue',
// },
},
},
},
})
■設定ファイル:tsconfig.jsonなど
比較参考用のダミープロジェクト(Vue + Vite)の設定をそのまま使用。
■ライブラリ側：src/main/vue3composition/main.ts
// テスト用関数
import { samplefunc, createVue3AppSample } from "./samplefunc";
// 個別に export する書き方。 (named export)
export { samplefunc, createVue3AppSample };
■vite用index.htmlファイルからの呼び出し
<html>
<script type="module">
// export named の場合のインポート方法
import { samplefunc } from "/dist/kjwikig-lib.es.js"
console.log(samplefunc("hoge"));
<script>
</html>
■JSP(HTML)ファイルからの呼び出し
<script type="module">
import { samplefunc } from "<%=request.getContextPath()%>/js/kjwikig-lib.es.mjs"
obj2 = samplefunc;
console.log("object type is: " + obj2);
console.log(samplefunc("hoge"));
</script>
emacs wanderlust 肥大化する~/elmo/cacheを制御するelmo-cache-expire-by-size
tag: emacs, wanderlust, elmo
長期間 emacs 上の Wanderlust を使っていると、~/.elmo/cache が肥大していく。
キャッシュ削除は M-x elmo-cache-expire-by-size として数値を入力することで実行されるのだが、~/.wl に書いておくことで Wanderlust 起動時に毎回実行することができる。
以下を ~/.wl に記載する。
;; wanderlust elmo キャッシュサイズ抑制設定 ;;Cache expiration age(days) days since last access, i.e atime. (default: 50) (setq elmo-cache-expire-default-age 40) ;;Cache expiration disk size(kilobytes) (default 30000) (setq elmo-cache-expire-default-size 10000) ;; elmoキャッシュの削除処理を実行 (elmo-cache-expire-by-age 40) (elmo-cache-expire-by-size 10000)
OpenAIライブラリ v1.0系 型がかなり定義されたっぽい
tag: openai, chatgpt
pythonのopenaiライブラリ(ChatGPT API呼び出しに使用)がNov. 9あたりに結構変わっていたのを今更発見。
型定義が色々追加されていた様子。ちまちまと対応。
Intel Core Ultra
tag: NPU
Intelが公開した資料によれば、Stable Diffusion v1.5を利用したベンチマークで、 すべてをCPUで処理すると43.3秒だった画像生成の処理が、 GPUを利用すると14.5秒、 すべてをNPUで処理すると20.7秒になる。
ちなみに、ウチで実行すると Stable Diffusion v 2.0を利用した画像生成で、float32を使った場合、 CPU(Ryzen 5 5600X)で処理すると4分32秒だった画像生成の処理が、 GPU(GeForce RTX 3060 12GB)を利用すると10秒になる。
ウチの場合Intel資料と比べると画像生成のCPU実行に6倍時間がかかっている。 Ryzen CPUで動かすためにfloat32使っているから2倍の時間がかかるところまではわかるけど、残りの3倍速はどこから来ているんじゃろ？ Intel系のCPUだとEコアもStable Diffusion演算できるのかな？ (Ryzen 5 5600XでStable Diffusion計算すると、CPU使用率が50%で頭打ちになるので、Coreあたり1個しか使える演算器が無いっぽい挙動になる。)
NPUはメインメモリを共有して使うのか。まあ仕方ないね..。
float16使用の場合、ウチのGPU(GeForce RTX 3060 12GB)だと画像生成速度は5秒になり、それに対してNPUは20.7秒。
ミドル級グラボ搭載デスクトップ機に比べて4倍遅いのは用途によっては厳しいけど、専用メモリを持たないNPUにしては頑張っている方かもしれん。 ウチのGPUの場合、画像生成でメインメモリ側にあふれるような画像サイズを生成すると、ガクッと速度が落ちてCPUの倍速程度になっちゃうし。
しかし Core Ultra の方も max power で 115W ってもうノート用じゃない気がするｗ
dokuwikiというのがあるらしい
tag: wiki
記法はmarkdownとはちょっと異なる独自系。markdown記法を可能にするpluginもあるらしい。
PHP 7.2以降で動作。データベースは使わないらしい。
Emacs情報サイトのメモ
tag: emacs
Org-mode面白いなｗ
一部で熱狂的な信者が居るあの org-mode のことか？
色々なパッケージが出てきているんだな。全然しらんかった。
いつも巡回している各種ニュースサイトの更新が止まると年末を感じる...。