今回は珍しくソフト系のネタではなく、3D プリンタ系の話です。 FDM 式は面倒が少ない 3D プリンタを購入するにあたり、事前に色々と調べた結果、 光造形式ではなく FDM 式にしました。 FDM 式を選んだ主な理由は 「面倒が少ない」 です。 光造形式の洗浄・二次硬化はどうしても面倒に感じました。 またそれ以外にも光造形式の以下の点が気になり、FDM 式を選択しています。 レジンの匂い 多くのレジンが無駄になってエコ(economy,eco

go は GC で heap メモリを管理している。 Java の場合、最大 heap サイズを指定し、 そのサイズを越えた場合は OutOfMemoryError になる。 最大 heap サイズが指定されていない場合はデフォルトのサイズが利用される。 なお、Java でメモリフルが発生する際は、 最大 heap サイズがデフォルト設定のまま、というケースが多い。 まぁ、ここでは Java の話は置いておいて、 go での heap 制御ってどうなの？と、いうのが今回の話。 GOGC と GOMEMLIMIT go の heap メモリ制御は、 java のような予め決められた heap

LuneScript は、 Golang (1.16 以降)へのトランスコンパイルを対応しています。 また、LuneScript は Generics に対応しています。 一方で、 Golang は version 1.18 から Generics に対応しています。 つまり、 LuneScript は Golang が Generics 対応する前から Generics を利用できていました。 では、 Generics を利用していた LuneScript のコードを どうやって Generics 対応前の Golang にトランスコンパイルしていたかというと、 Generics の型パラメータの値を interface{} に変換して処理を行なっていました。 Java でいうところの autoboxing のようなことを変換時にやって

LuneScript Web Frontは今迄 fengari を利用していましたが、 golang の wasm で動かせるようにサポートしました。 その際に golang の wasm の利用方法について調べたことをまとめておきます。 golang の wasm 基本的なことは以下の公式ドキュメントをみてください。 <https://github.com/golang/go/wiki/WebAssembly> 最低限のステップをまとめると、以下の手順になります。 以下の環境変数を指定して WASM 化したいプロジェクトをビルドします。 これで main.wasm に WASM 化したコードが出力されます。 $ GOOS=js GOARCH=wasm go build -o main.wasm 以下の wasm_exec.js をコピーします。 $

<http://localhost:1313/posts/2020/2020-08-01-lunescript-man-hour/> 以前 LuneScript の工数を考えたが、今回は別の面から工数を考えてみる。 ソフトウェア開発分析データ集2020 <https://www.ipa.go.jp/ikc/reports/20200930.html> 上記のリンク先の資料「ソフトウェア開発分析データ集2020」の p.84 に、 新規開発の SLOC 生産性の表「A1-2-1 SLOC 規模別 SLOC 生産性(新規開発)」がある。 この表には、コード規模毎に最小、最大、平均の SLOC 生産性が載っている。 このデータから LuneScript の工数を計算する。 LuneScript の工数 LuneScript の現在の規模はコメント含んで約 56 Kline。 SLOC は本