Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 14 2021 14:26
    tomoyanonymous synchronize #68
  • Sep 14 2021 14:26

    tomoyanonymous on new-ast

    fixed tuple parser fixed recursive call allows empty argument and 13 more (compare)

  • Sep 10 2021 04:55
    tomoyanonymous synchronize #68
  • Sep 10 2021 04:55

    tomoyanonymous on new-ast

    fixed foldl logic fixed X expression codes fixed ast_lowering codes and 15 more (compare)

  • Jun 09 2021 09:27
    tomoyanonymous synchronize #68
  • Jun 09 2021 09:27

    tomoyanonymous on new-ast

    fixed compile error on tests (compare)

  • Jun 08 2021 09:26
    tomoyanonymous synchronize #68
  • Jun 08 2021 09:26

    tomoyanonymous on new-ast

    suppressed errors (compare)

  • May 17 2021 09:42
    tomoyanonymous synchronize #68
  • May 17 2021 09:42

    tomoyanonymous on new-ast

    [skip ci]applied new type defin… (compare)

  • May 17 2021 07:08
    tomoyanonymous synchronize #68
  • May 17 2021 07:08

    tomoyanonymous on new-ast

    uncommented assertion made ffi to new type implementa… add ffi to type inference and 2 more (compare)

  • Apr 22 2021 08:48
    tomoyanonymous synchronize #68
  • Apr 22 2021 08:48

    tomoyanonymous on new-ast

    [skip ci] imple new type inferer (compare)

  • Apr 17 2021 16:45
    tomoyanonymous synchronize #68
  • Apr 17 2021 16:45

    tomoyanonymous on new-ast

    [skip ci fixed bug] [skip ci]typeinferer unifier im… (compare)

  • Apr 17 2021 09:49
    tomoyanonymous synchronize #68
  • Apr 17 2021 09:49

    tomoyanonymous on new-ast

    wip new ast parsing [skip ci] succeeded to compile … (compare)

  • Apr 13 2021 07:43
    tomoyanonymous synchronize #68
  • Apr 13 2021 07:43

    tomoyanonymous on new-ast

    impl ast lowering (compare)

TANAKA Shinichi
@t-sin_gitlab
もしやこの前の土曜でちょうど2週間だった説
Tomoya Matsuura
@tomoyanonymous
へい、この2週間かなり死んでました、、、しばらくコードに手をつけてなかったのですが今日やっと再起動し始めました。
TANAKA Shinichi
@t-sin_gitlab
多忙なときってありますからね…人のことはなんにも言えない進捗です…
Tomoya Matsuura
@tomoyanonymous
よーやっと構造体の実装を終えて0.4をリリースしました。https://mimium.org/en/docs/users-guide/language-specification/grammar-rule/#type-alias
TANAKA Shinichi
@t-sin_gitlab
おおーー! :tada:
TANAKA Shinichi
@t-sin_gitlab
https://github.com/mimium-org/mmm-package-example
とても原初のパッケージを作成し、mmmpmからインストールして実行ができるようになりました。
ファイルシステムの抽象化をやろうとしてmmmpm止まっちゃってたので、いったん別ブランチとしmmmpmのmasterは動くところに戻してます。
Tomoya Matsuura
@tomoyanonymous
うおおー、ありがとうございます、試してみよう
Tomoya Matsuura
@tomoyanonymous
最近はずっとここのブランチで作業しています。mimium-org/mimium#68
環境変数を導入するにあたって、シンタックスシュガー付きのAST->要素を減らしたASTの2段構えの構成に変えようと思ってやり始めたら永遠に終わらなくなってしまいました、、、
TANAKA Shinichi
@t-sin_gitlab
うおぉ、ヘヴィーな作業。。。
重めなコミットが積まれていくのを眺めてましたが、これでまただいぶ進化しますね。
TANAKA Shinichi
@t-sin_gitlab
パッケージのサンプル、なぜ mimium-package-example じゃないのか謎になってきたのでリポジトリ名を変更しました。
TANAKA Shinichi
@t-sin_gitlab
構造体を利用してみていたんですが{}の間は改行禁止のようで、もし改行を入れるとしたらyaccのファイルを…
(すみませんまだ完全でないのに送信してしまいました)

たとえば

+++ b/src/compiler/mimium.yy
@@ -306,9 +306,9 @@ typeargs:  typeargs ',' types { $1.emplace_back(std::move($3));
                                 $$ = std::move($1); }
       |    types { $$ = std::vector<types::Value>{$1};}

-structtype: LBRACE strutypeargs RBRACE { $$ = types::Struct{std::move($2)}; }
+structtype: LBRACE opt_nl strutypeargs opt_nl RBRACE { $$ = types::Struct{std::move($2)}; }

-strutypeargs : strutypeargs ',' strutypearg { $1.emplace_back(std::move($3));$$ = std::move($1); }
+strutypeargs : strutypeargs ',' opt_nl strutypearg { $1.emplace_back(std::move($3));$$ = std::move($1); }
             | strutypearg {$$ = std::vector<types::Struct::Keytype>{$1}; }
 strutypearg : SYMBOL TYPE_DELIM types { $$ = types::Struct::Keytype{std::move($1),std::move($3)}; }

みたいな変更するとよい感じなんでしょうか。いま屋外でLLVMがなくビルドして試せないのでイメージの相談です。

TANAKA Shinichi
@t-sin_gitlab
音楽つくろうとしてみてたんですがパッケージマネージャについて、曲あるいは作品をパッケージとして公開したい場合にパッケージ名の被りを許したい気持ちがしますね。あるいはタイトルやジャンルによるインストールが必要なのかもしれないです。
https://github.com/t-sin/mimium-ambient-song/
Tomoya Matsuura
@tomoyanonymous
はい、もしくはカンマの後に改行を入れるのをトークナイザーレベルで許してしまってもよいかもしれません。
演算子の直後は改行許しても文法的破綻はしないはずなのでどこかで導入しようかなと思ってました

そもそも実はstructの初期化は

hoge = {field1 = 100,field2 = 200}

見たくフィールド名を明示する方が型判定の処理がしやすいので仕様変えちゃおっかなあと迷ってるとこだったりします

Tomoya Matsuura
@tomoyanonymous
ちなみに新ASTの実装は後MIRの生成まで行けば出来そうな感じです。まだ山ほどテストとバグとりが出てきそうですが。。。
Tomoya Matsuura
@tomoyanonymous
そんで今週のMTGもライブの準備がちょっと忙しく、お休みです・・・
TANAKA Shinichi
@t-sin_gitlab
仕様変えちゃうのいいですね。
多忙の件、お察ししておりました。気長にやりましょうー
TANAKA Shinichi
@t-sin_gitlab
mmmpmかなり滞らせてしまってますね…
Tomoya Matsuura
@tomoyanonymous
いやーこちらこそすいません、、色々手元では牛歩ながら進んでいるんですが、全然pushできてなくて。
パッケージマネージャに関してはここ数日ちょっとアーキテクチャこうしたらいいのではと考えてることがあって、ちょっと図を作ってみました
Screen Shot 2021-07-30 at 13.24.07.png
要するに、パッケージマネージャが解決したファイルパスを返却するのではなく、読み込んだソースファイル自体を返却する方式の方が、コンパイラをファイルシステムから可能な限りagnosticな実装にできるのではないかという話なんですが(そもそものメインのファイルシステムの読み込みの時点でまあファイルシステム依存しちゃあいるのですが)。今後読み込むソースの数が増えたときに並列処理に通用するかとか、あとAoTコンパイルしたバイナリキャッシュの扱いどうすんだみたいな話もありますが。
TANAKA Shinichi
@t-sin_gitlab
なるほどなるほど。たしかにこちらのほうがよいですね。
コンパイラにファイルシステムを意識してもらうのはコンパイル以外のことをする感じになりますものね…
Tomoya Matsuura
@tomoyanonymous
多分、Webに移植した時とかにこういう分割されたモジュールどう引っ張ってくるかとかも同じように問題になってくるんですよねー。その辺はFaustのWebIDEとかもあんまりきちんと解決されてないように見えますね
TANAKA Shinichi
@t-sin_gitlab
たしかに。
コンパイラに渡すものって、ソースコードを何かしら構造化した形(内容とモジュール名と…のような)で渡すイメージであってます?
Tomoya Matsuura
@tomoyanonymous
はい、ソースコードそのものをテキストデータとして、後モジュールのメタデータ、みたいなんを、送るんで全然いんじゃないかなーと.何かしらプロトコルを考える必要はありそうですが
TANAKA Shinichi
@t-sin_gitlab
了解です! 認識合いました!
Tomoya Matsuura
@tomoyanonymous
現実的には、一度キャッシュがllvm-irとして保持されてたらそいつを渡す、みたいなこともできそうですね。ただllvm-irにしちゃうと関数の方情報とかが一部失われちゃうから、それも含めて何かキャッシュのフォーマットを考えないとダメかもですねえ。というか、ソースコードから、C言語におけるヘッダーファイル相当の部分だけを抜き出す処理みたいなことか。
TANAKA Shinichi
@t-sin_gitlab
ヘッダーファイルたしかに。エクスポートされたもののシグネチャ一覧というかそんなやつですね。
TANAKA Shinichi
@t-sin_gitlab
パッケージマネージャで行う依存関係の解決あたりはトポロジカルソートが必要になりそうなので、そのあたりも勉強しておかねば。

Webに移植した時とかにこういう分割されたモジュールどう引っ張ってくるかとかも同じように問題になってくるんですよねー

この文章の意味がいま完全理解されました! たしかにこの意味でも、コンパイラのコアはファイルシステムに依存するべきではないですね。

TANAKA Shinichi
@t-sin_gitlab
mimiumのパッケージってソースコードだけでなくwavファイル(インパルス応答とか?)が含まれる可能性が高そうなので、GitHubホストはキツい場面ありそうですね。昨日気付きました。
Tomoya Matsuura
@tomoyanonymous
アセット管理は悩ましいとこですね。git lfs使えばある程度はなんとかなりますがわりとすぐ有料になったはず&インストールさせる必要あるのが少しだるいという。バイナリファイルを意識したバージョン管理システムは大概ゲーム向けとかのプロプライエタリなものばっかりなのもつらいとこですね
datプロトコルという、もともと生物学系のとでかいデータ扱うように作られた完全p2pの面白いプロトコルがありまして、diffとかはきちんと取らないけどバージョン管理はできるというものなので、後々これ導入してみたいなとは思ってたり https://en.m.wikipedia.org/wiki/Dat_(software)
TANAKA Shinichi
@t-sin_gitlab
git lfsは制限があったんですね! そうするとアセット類は、将来的にはGitHubに置かずに自前ホストしたほうがよさそうですね…。
それにしてもdatなるものが。これすごいですね。たしかに後々によさそうです。
TANAKA Shinichi
@t-sin_gitlab
RustのVST3ラッパーを触っていたら一瞬mimiumで書いたオシレータやエフェクト等をVST3にコンパイル(?)するようすを幻視したのですが、過去のmimium資料でそういう記述を見たきがします(雑談
Tomoya Matsuura
@tomoyanonymous
vstにコンパイルというか、JITでDSP作るはラッパーを頑張って作れば現時点での仕様でもそんなに不可能ではないんですよね(もちろんRustから触るには一旦CのAPIを定義しなくてはならんのですが)
今本格的にRustに実装を移す構想を考えてるんですが、構文がすでにRustと似ている分、パーサを手動で実装せずに手続きマクロでRust上に直接DSLとして構築できてしまうんでは?ということを考えています https://techracho.bpsinc.jp/yoshi/2020_12_24/102304
TANAKA Shinichi
@t-sin_gitlab
なるほどそうか、ランタイムのラッパー部分がVSTなものをつくればよいだけですね。いけそうです(がんばれば)。
そしてなんとなく雰囲気を感じてましたがRustへ移行するのですね! Rustのproc macro強力なので、できそうですね…!
Tomoya Matsuura
@tomoyanonymous
どのみち本格的な実装は博士論文ひと段落してからになると思うのですが、一度Rustの快適さに触れてしまったらもう戻れる気がしませんね、、、文法含めて割と再検討しているところです。
TANAKA Shinichi
@t-sin_gitlab
ですね。Rustすごくよいですよね。
博論のほう応援しています! ぼくのほうも本格実装後の貢献や賑やかしができるよう、コンピュータ音楽やらデジタル信号処理やらの研鑽を積んでおきます。