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 は本

wstcplink を作った。 <https://github.com/ifritJP/wstcplink> これが何かというと、 WebSocket client と TCP client の中継ツールだ。 次のような感じ。 ⇔⇔⇔⇔⇔⇔⇔⇔ Webブラウザ → このツール ← tcp クライアント ⇔⇔⇔⇔⇔⇔⇔⇔ Web アプリケーションとの双方向通信 Web アプリケーションで双方向通信するには、 web socket を使うのが標準だと思う。 (web socket にも課題はあるが、その辺りはここでは触れない。) で、その場合 web socket に対応したサーバが必要になる。 一方で、web socket に対応するのが困難な環境もある。 イマ