今回も引き続き 3D プリンタ系の話です。 3D プリントの出来 3D プリントの出来は次の要素で決まります。 3D プリンタの性能 フィラメントの性能 スライサーの性能、パラメータ どんなに良い 3D プリンタやフィラメントを使っても、 スライサーの性能が悪い、 スライサーのパラメータの設定が正しくない場合、 意図したプリントは出来ません。 Ultimaker cura 3D プリンタでオブジェクトをプリントするには、 3D オブジェクトを積層データ形式に変換する必要があり

今回は珍しくソフト系のネタではなく、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 をコピーします。 $