Ruby の print, puts, p を命令ブロックに変換できるようにする

[takaokouji]

Ruby の print, puts, p を命令ブロックに変換できるようにします。
いずれも say に変換します。
また、現時点では \n や \t などはそのまま表示することにします。

• print("Hello\n") => (Hello\n)と言う
• puts("Hello") => (Hello)と言う
• p("Hello") => (Hello)と言う

ただし、この場合に命令ブロックからRubyに変換するときに、再度、それぞれに戻せるようにします。

• print("Hello\n") <=> (Hello\n)と言う
• puts("Hello") <=> (Hello)と言う
• p("Hello") <=> (Hello)と言う

これが難しいです。Rubyのどのような命令から 「(Hello\n)と言う」
命令ブロックになったのかがわからないためです。

そこで、 print, puts, p のように、再度 Ruby
に戻すときに特別扱いするものは、命令ブロックにコメントを追加することにします。

• print("Hello\n") <=> (Hello\n)と言う + 「@smalruby:puts」コメント

命令ブロックにコメントを追加する機能はあるのですが、GUIではなく、変換処理でコメントを追加する方法はわかっていません。まずはそこの調査からです。

十分に調査して、実装できると判断できてから、Issueを作成します。

[takaokouji]

コメント位置のズレについて

Rubyから命令ブロックに変換するときにy座標を計算するようにしました。しかしながら、以下の理由でコメントの位置が大幅にズレてしまう問題があります：

• ブロックには複数の種類があり、それぞれ高さが異なる
• ブロックの組み合わせによってy座標が変わる
• イベントブロックによってブロックのオフセットが変わり、y=0からの開始ではなくなる

このため、独自の計算方法で命令ブロックの位置を計算することには限界があると考えます。

改善案

以下の案について、コードを解析して実現可能性を調査します。

(1) scratch-blocks のアルゴリズムを再現（優先度: 低）

独自の計算方法を推し進める案です。

• @vendor/scratch-blocks/ に scratch-blocks のソースコードを配置
• https://deepwiki.com/scratchfoundation/scratch-blocks/3.2-block-rendering のレンダリング資料を参考

これらを解析して、ブロックごとに適切なy座標を計算し、コメント位置を決定します。

(2) 命令ブロックの座標計算後に、コメント位置を再計算する

Rubyから命令ブロックに変換後、scratch-blocks が命令ブロックの座標を計算しています（起点ブロックのx,y座標が未設定のため）。

その後のタイミングでコメント位置を再計算する方式です：

• 命令ブロックの座標計算後に適切な hook を追加（イベント発火がベスト）
• そのタイミングで各コメントの座標を更新
• 生成したコメントオブジェクトの参照を保持し、コメント先の命令ブロックの座標を参照

(3) その他

調査を踏まえて、別の案があれば提案します。

---

これらの調査を行い、実装案とともに実現可能性を報告します。

[takaokouji]

調査結果報告

案(2): 命令ブロックの座標計算後に、コメント位置を再計算する ✅ 実現可能

発見

src/containers/blocks.jsx の onWorkspaceUpdate メソッドに、既にRuby変換後のブロック座標を更新するロジックが存在していることを発見しました。

// blocks.jsx:470-483
if (fromRuby) {
    this.workspace.cleanUp();

    this.workspace.getTopBlocks(false).forEach(wsTopBlock => {
        const topBlock = blocks.getBlock(wsTopBlock.id);
        if (topBlock) {
            const xy = wsTopBlock.getRelativeToSurfaceXY();
            topBlock.x = xy.x;
            topBlock.y = xy.y;
        }
    });

    this.updateToolbox();
}

この処理の流れ:

1. Ruby変換後、起点ブロックの座標が未設定の場合を検出
2. workspace.cleanUp() で scratch-blocks がブロックを自動配置
3. ワークスペースブロックの実際の座標を取得し、VM target のブロックに反映

実装案

この既存フックを拡張して、コメント座標も更新します:

if (fromRuby) {
    this.workspace.cleanUp();

    this.workspace.getTopBlocks(false).forEach(wsTopBlock => {
        const topBlock = blocks.getBlock(wsTopBlock.id);
        if (topBlock) {
            const xy = wsTopBlock.getRelativeToSurfaceXY();
            topBlock.x = xy.x;
            topBlock.y = xy.y;
        }
    });

    // コメント座標の更新（追加部分）
    const vmTarget = this.props.vm.editingTarget;
    if (vmTarget && vmTarget.comments) {
        Object.keys(vmTarget.comments).forEach(commentId => {
            const vmComment = vmTarget.comments[commentId];
            if (vmComment.blockId) {
                const wsBlock = this.workspace.getBlockById(vmComment.blockId);
                if (wsBlock && wsBlock.comment) {
                    const commentXY = wsBlock.comment.getXY();
                    vmComment.x = commentXY.x;
                    vmComment.y = commentXY.y;
                }
            }
        });
    }

    this.updateToolbox();
}

利点

• scratch-blocks の既存フックを利用するため、安定性が高い
• scratch-blocks が計算した正確な座標を使用
• コード変更は最小限（約15行追加）
• scratch-blocks 内部のアルゴリズム変更に影響されにくい

---

案(1): scratch-blocks のアルゴリズムを再現 ❌ 非推奨

調査結果

workspace.cleanUp() のアルゴリズムを確認しました:

// scratch-blocks/core/workspace_svg.js
Blockly.WorkspaceSvg.prototype.cleanUp = function() {
    var topBlocks = this.getTopBlocks(true);
    var cursorY = 0;
    for (var i = 0, block; block = topBlocks[i]; i++) {
        var xy = block.getRelativeToSurfaceXY();
        block.moveBy(-xy.x, cursorY - xy.y);
        block.snapToGrid();
        cursorY = block.getRelativeToSurfaceXY().y +
            block.getHeightWidth().height + Blockly.BlockSvg.MIN_BLOCK_Y;
    }
};

ブロック高さの計算 (getHeightWidth()) は非常に複雑で、以下の要素が関係します:

• MIN_BLOCK_Y (通常ブロック): 12 * GRID_UNIT
• MIN_BLOCK_Y_SINGLE_FIELD_OUTPUT: 8 * GRID_UNIT
• MIN_BLOCK_Y_REPORTER: 10 * GRID_UNIT
• ネストされたブロックの再帰的な高さ計算
• グリッドスナッピング

問題点

• アルゴリズムが複雑で、再現コストが高い
• scratch-blocks のバージョンアップで計算方法が変わる可能性
• テストケースが膨大になる

---

結論

案(2)を採用することを推奨します。

blocks.jsx の既存フックを拡張する方法が最もシンプルで安定しています。scratch-blocks が計算した正確な座標を利用するため、ブロック種類やネストの複雑さに関係なく正しい位置が得られます。

[takaokouji]

ディレクティブ形式の決定

コメント位置の問題については案(2)で実装しました。

また、コメント内のディレクティブ形式について検討した結果、以下を採用します：

採用形式（提案C: ハイブリッド形式）

@ruby:CONVERSION_INFO          # Ruby変換情報（頻繁、短縮）
@smalruby:CATEGORY:VALUE       # スモウルビー機能（稀、明示的）

今回の実装

@ruby:method:print
@ruby:method:puts
@ruby:method:p

理由

1. 実用性: 最も頻繁に使う Ruby変換は短く @ruby:
2. 拡張性: その他の機能は明示的に @smalruby:
3. 直感性: スモウルビー = Ruby という認識に合致
4. 柔軟性: 将来の多言語対応も可能

詳細は ADR に記録します。