nim

**デフォルトの名無しさん** · 2018/09/28(金) 00:10:24.24

>>30
AV女優？

**デフォルトの名無しさん** · 2018/09/28(金) 07:58:16.83

>>33
わかってていってんだろ

**デフォルトの名無しさん** · 2018/09/28(金) 12:33:53.60

Version 0.19.0がリリースされました。
https://nim-lang.org/blog/2018/09/26/version-0190-released.html

**デフォルトの名無しさん** · 2018/09/28(金) 15:46:07.59

GUI は何がおすすめ？

**デフォルトの名無しさん** · 2018/09/30(日) 18:50:57.10

math モジュールの round バグってんな
こんなのもバグってるとか使い物にならないだろｗ

**デフォルトの名無しさん** · 2018/10/01(月) 07:05:34.25

roundに関してはNimのgithubのissueにもあるんだけど、floatの精度のせいでroundした値がfloatで正確に表せられない場合があるんだよ。
https://github.com/nim-lang/Nim/issues/9082
詳しく知りたかったら、現代の殆どのPCで浮動小数点数を扱うのに使われているieee754という標準規格について調べてね

**デフォルトの名無しさん** · 2018/10/06(土) 22:16:11.18

echo(convert("こんにちは、", "Shift_JIS", "UTF-8"))
Windowsだとこうしないと日本語が表示されない

**デフォルトの名無しさん** · 2018/10/06(土) 22:34:07.06

ソースと端末表示をUTF-8にすればいいだけじゃ

**デフォルトの名無しさん** · 2018/10/07(日) 00:51:21.65

windowsでシステムロケールUTF-8にしたい
chcp65001は禁止で

**デフォルトの名無しさん** · 2018/10/09(火) 21:51:59.30

readline(stdin)が多バイト文字を受け付けない

**デフォルトの名無しさん** · 2019/04/17(水) 04:51:18.35

つんつん

**デフォルトの名無しさん** · 2019/04/17(水) 13:09:18.13

nim終了のお知らせ

Bosque Programming Language
https://www.microsoft.com/en-us/research/project/bosque-programming-language/

> The Bosque programming language is designed for writing code that simple, obvious, and easy to reason about for both humans and machines.

https://github.com/Microsoft/BosqueLanguage

**デフォルトの名無しさん** · 2019/04/17(水) 18:38:09.52

なんやわからんけど波括弧書くのいやや～

あめ ◆P0jSlC5fJs · 2019/04/17(水) 18:54:10.48

>>44
研究用、ゴミ
ドザによる荒らし

**デフォルトの名無しさん** · 2019/04/17(水) 21:27:04.52

うるせーよ雑魚コテハン

**デフォルトの名無しさん** · 2019/04/17(水) 21:27:30.51

雑魚コテハンは死ねや

◆P0jSlC5fJs · 2019/06/08(土) 18:55:31.57

0.20.0 リリース
https://nim-lang.org/blog/2019/06/06/version-0200-released.html

**デフォルトの名無しさん** · 2019/06/17(月) 03:05:34.50

開発が止まっているLuaJITの代わりにこれを使いたい

**デフォルトの名無しさん** · 2019/06/18(火) 05:06:07.86

じゃ使えばいいじゃん。

**デフォルトの名無しさん** · 2019/06/18(火) 11:00:03.52

nimがCにトランスパイルできるとしても
nimを通してクラス設計とかしたらその分のオーバーヘッドは残りますよね？

**デフォルトの名無しさん** · 2019/06/18(火) 12:35:30.19

そもそもそういう用途じゃない

**デフォルトの名無しさん** · 2019/06/18(火) 12:45:57.35

どういうことですか？
C並の性能を出すためにあるものではないと？

Nimでカーネルを書くとか無理なのかなーと思ってたんですが
実際やるわけじゃないけど、いまのところ

**デフォルトの名無しさん** · 2019/06/18(火) 12:48:21.44

C++でカーネル書いたひとはいるね

**デフォルトの名無しさん** · 2019/06/18(火) 14:22:47.46

実際Linuxカーネルのコードは疑似OOPだみたいな説明を見かけたので
NimやC++で書いても良いのかもしれない。
個人的にCへのトランスパイラとしてのNimにひじょーに興味がある

**デフォルトの名無しさん** · 2019/06/18(火) 14:25:52.94

https://forum.nim-lang.org/t/2261
>So let's say that implementing your game in Nim instead of C++ means 20% larger binary sizes, 20% more RAM usage, and 20% more CPU/GPU usage.

NimよりC++の方が速いって言ってる。
ベンチだと真逆なのに

**デフォルトの名無しさん** · 2019/06/18(火) 14:44:50.57

続き読んだら他の人が否定してた

**デフォルトの名無しさん** · 2019/06/19(水) 01:56:19.31

nimはgcを使っている。でもCへのトランスパイルができる。
gcということはメモリ解放が暗黙的ということだろう。
Cでは明示的に解放する必要がある。

どうやって解放タイミングを調べてるんだ？
GC言語から非GC言語へのトランスパイルがなぜ可能なのか？

**デフォルトの名無しさん** · 2019/06/19(水) 02:09:28.92

var name: string = readLine(stdin)

なんでvarと書きつつstringと型指定するのか
変な言語仕様だな
string name =
でいいだろ

**デフォルトの名無しさん** · 2019/06/19(水) 02:10:39.50

var name = readLine(stdin)

型推論だっていってるけどこれ可読性低下してる
string name = readLine(stdin)
これがベスト

**デフォルトの名無しさん** · 2019/06/19(水) 02:52:19.54

nimでデバドラ作ったりできるんだろうか

**デフォルトの名無しさん** · 2019/06/19(水) 02:57:44.38

https://forum.nim-lang.org/t/2541
Nim also can produce a program that will be put in an embedded system. In such environment, usually there is no OS or only primitive OS, and Nim produced program have higher chances to access hardware directly.

できそうだ
Nimは流行りそうな気がする
なんで組み込みでC++なんか使ってるんだ

**デフォルトの名無しさん** · 2019/06/19(水) 04:14:19.61

https://forum.nim-lang.org/t/3223
>Basically, 10 OS for 10 CPUs would contain 100 sets of C source code, that get bundled up over in csources.git

どうやらNimが適切なCソースコードを作成するには
ターゲットのCPUとOSを指定する必要があり、
その組み合わせ全てに何かファイルを用意する必要がある。

これじゃダメだな・・・

**デフォルトの名無しさん** · 2019/06/19(水) 04:24:41.25

勘違いした。ダメってことはないか
Nimコード自体は環境非依存、Cコードにするとき環境依存、ということか

**デフォルトの名無しさん** · 2019/06/19(水) 14:31:42.44

LLVMω

**デフォルトの名無しさん** · 2019/06/21(金) 05:13:28.08

Nimってめちゃすごなんじゃないかなあ
細かい言語仕様で嫌いなところがあるけど

**デフォルトの名無しさん** · 2019/06/21(金) 14:29:00.17

漏れも D がすごいと思ってた時期があるよ

**デフォルトの名無しさん** · 2019/06/21(金) 14:55:07.18

>>61
name : string := readLine(stdin)
のほうがいい。

**デフォルトの名無しさん** · 2019/06/22(土) 05:26:38.53

https://nim-lang.org/
The Nim compiler and the generated executables support all major platforms like Windows, Linux, BSD and Mac OS X.

executablesは機械語？Cコード？
いずれにせよ環境依存してると思うけど、大抵のプラットフォームをサポートしてます、ってどういうこと？
大抵のプラットフォームに向けてトランスパイルできますってこと？

**デフォルトの名無しさん** · 2019/06/22(土) 09:58:00.49

You Nim で Tensorflow が使えるアプリ造っchina YO

**デフォルトの名無しさん** · 2019/06/24(月) 09:23:40.70

>>69
var name : string = readLine(stdin)
＃nameは変更可能
let name : string = readLine(stdin)
#nameは初期化後は変更不可
というletとvarに違いがある。
型推論使ったほうがコード読みやすい、書きやすいという人もいるんだよ。
readLineの戻り値の型はstringに決まってるんだから毎回型を書く必要ないと思うけど

**デフォルトの名無しさん** · 2019/06/24(月) 09:43:12.98

>>70
NimはC言語に変換してからgcc等のCコンパイラを呼んで実行ファイルを作るんだよ。
C言語は大抵のプラットフォームで使える言語だからマルチプラットフォーム化しやすい。
なので一度書いたNimコードをそれぞれのプラットフォーム上でコンパイルするかクロスコンパイルするだけでだいたいは動く。
けどNimから出力されるCコードは特定のCコンパイラ、OS、CPU向けに書かれているので、それだけでマルチプラットフォームな実行ファイルは作れないらしい。
Nimの標準ライブラリのソースコードを読むとOS、CPUによる違いを吸収するためのコードがときどきあるよ。

**デフォルトの名無しさん** · 2019/06/24(月) 09:53:12.36

Nimのソースコードのcompiler/extccomp.nimにNimが対応しているC/C++コンパイラの情報がまとまっていて、compiler/platform.nimにはOSとCPUの情報がまとまってる。

**デフォルトの名無しさん** · 2019/06/24(月) 11:40:11.26

https://github.com/nim-lang/Nim/blob/devel/compiler/extccomp.nim
https://github.com/nim-lang/Nim/blob/devel/compiler/platform.nim
https://github.com/nim-lang/Nim/wiki/Consts-defined-by-the-compiler

**デフォルトの名無しさん** · 2019/06/24(月) 15:58:18.33

>>59
NimのGCについてはここに情報がある。
メモリ確保時にいらなくなったメモリを走査して解放しているらしい。
https://nim-lang.org/docs/gc.html

NimでGCを使わずにメモリ管理する話もある。
https://github.com/nim-lang/Nim/wiki/Destructors,-2nd-edition

>>71
Nimで実装されたTensorflowに相当するらしいlibrary
https://github.com/mratsim/Arraymancer

**デフォルトの名無しさん** · 2019/08/11(日) 11:51:35.55

2次元配列って、
var a: array[10,array[10,int]] とか書くしかないの？

**デフォルトの名無しさん** · 2019/09/24(火) 21:02:48.66

nim1.0でた～～

**デフォルトの名無しさん** · 2019/09/25(水) 05:43:15.78

Version 1.0 released
23 September 2019 The Nim Team
https://nim-lang.org/blog/2019/09/23/version-100-released.html

Nim Programming Language Hits Stable Milestone With v1.0 Release
https://www.phoronix.com/scan.php?page=news_item&;px=Nim-1.0-Programming-Language

**デフォルトの名無しさん** · 2019/09/25(水) 06:16:02.11

ついでにwandboxのnim
ttps://wandbox.org/permlink/npG9hbKwZyKQTXgI?source=post_page-----5d0f58d21e7e----------------------

**デフォルトの名無しさん** · 2019/09/25(水) 10:58:52.25

**デフォルトの名無しさん** · 2019/09/26(木) 04:03:18.19

1.0おめでとう！
ちなみに

echo NimVersion
echo(NimVersion)
NimVersion.echo

は同じ意味のコードだよ。Uniform Function Call Syntaxってやつだ

**デフォルトの名無しさん** · 2019/10/27(日) 16:17:57.05

windows 10
Nim 1.0.2 入れてみた
tdmgcc は前から使ってて gcc は既に path 通してあったので

nim 側はファイル展開しただけで何もしなくても良かった
(nim.cfg の書き換え(書き足し)も不要だった)
path 通さなくても
C:\nim\bin\nim c hogehoge
で動いた

**デフォルトの名無しさん** · 2019/10/27(日) 16:18:39.88

あと
日本語の参考書籍ってなんか出てる？

Nim in Action とかはどうだった？

**デフォルトの名無しさん** · 2019/10/30(水) 20:48:12.27

>>83
最近のは勝手に gcc 入れてくれるよ。

**デフォルトの名無しさん** · 2019/11/06(水) 15:17:56.57

HANDLEもこっそりtypedefに_PTR変えたんだっけ

**デフォルトの名無しさん** · 2019/11/06(水) 15:20:05.05

誤爆った

**デフォルトの名無しさん** · 2019/11/09(土) 00:06:35.30

Nim playground
https://play.nim-lang.org/
次スレから>>1に入れといてよ

しかしver1到達したのに全然盛り上がらんのなお前ら

**デフォルトの名無しさん** · 2019/11/09(土) 03:28:50.22

https://wandbox.org/
こちらでもNim使えますよ。

**デフォルトの名無しさん** · 2019/11/10(日) 11:17:11.92

>>85
distフォルダにmingwの7z玉入れておけば、オフラインでのインストールもできるね。

**デフォルトの名無しさん** · 2019/11/10(日) 11:25:43.54

>>84
日本語の書籍はないが、原著のドキュメントは割とわかりやすい。docs/tut1.htmlから読み始めるといいかもしれない。
NIAは評判が良いらしいのと、製本版を買うと電子書籍版が無料で付いてくるらしい。

国内でのNimの翻訳は有志が約二名ほど作業しているが、まだ始まったばかり。時間かかりそうだね。

**デフォルトの名無しさん** · 2019/11/18(月) 09:38:29.23

DLLのCの関数を呼ぶ方法はいくつかあるようですが
なぜいくつもあるのでしょうか？
どれが一番効率が良いのかとか新しいのかとか判りにくい

**デフォルトの名無しさん** · 2019/11/18(月) 15:24:43.91

単純にdll内の関数を呼びたいならdynlibプラグマを使うのが一番楽。
少し低レベルな機能が必要ならdynlibモジュウルにあるプロシイジャアを使えばいいんじゃなかろうか

**デフォルトの名無しさん** · 2019/11/18(月) 17:09:32.08

成る程。

**デフォルトの名無しさん** · 2019/12/10(火) 23:17:13.67

nimに対応したソースコード可視化ツールってある？

**デフォルトの名無しさん** · 2019/12/12(木) 17:09:11.38

nimってあまりかっこよくないね

**デフォルトの名無しさん** · 2019/12/13(金) 23:01:47.25

Cにコンパイルしてからコード解析ツールに。

**デフォルトの名無しさん** · 2020/03/25(水) 04:10:40.05

nimコードはトランスパイルする前ならクロスプラットフォームなんだろうか？

**デフォルトの名無しさん** · 2020/03/27(金) 15:59:22.92

こんないい言語なのに結局欠点はCに依存してる点

**デフォルトの名無しさん** · 2020/03/27(金) 16:10:13.08

あんまり本出ないね
むしろチャンスか

**デフォルトの名無しさん** · 2020/03/27(金) 22:55:09.53

あの糞マクロ以外大して面白みのない言語だしなぁ

**デフォルトの名無しさん** · 2020/04/07(火) 05:01:02.90

逆にマクロの完成度高い言語ってなに？

**デフォルトの名無しさん** · 2020/04/07(火) 07:46:31.57

common LISP

**デフォルトの名無しさん** · 2020/04/07(火) 14:00:10.17

Schemeは？

**デフォルトの名無しさん** · 2020/04/07(火) 19:47:26.61

nimのマクロは完成度高いと思う。でも完成度高いマクロという存在自体が糞。

**デフォルトの名無しさん** · 2020/04/08(水) 12:06:55.28

MACRO-80

**デフォルトの名無しさん** · 2020/04/10(金) 23:13:42.18

>>102
糞マクロを褒めてるのであって
逆じゃないと思うんだが

**デフォルトの名無しさん** · 2020/04/10(金) 23:14:33.21

>>101>>105が同じってことだろ
common lispなんてはるかに糞になるし

**デフォルトの名無しさん** · 2020/04/10(金) 23:15:34.44

マクロならrustのが定評あると思うが

**デフォルトの名無しさん** · 2020/09/19(土) 22:27:13.04

小数の配列作りたいんだけどやり方教えてください。
[0.0, 0.1, .. 0.9, 1.0] みたいな。

Python なら hoge = [i/10 for i in range(11)] かな。気持ち悪いけど。

**デフォルトの名無しさん** · 2020/09/22(火) 12:29:56.17

lc[i*0.1 | i<-0..10 ]

**デフォルトの名無しさん** · 2021/01/10(日) 21:59:51.09

>>69
var name = readLine stdin
var name = stdin.readLine
で完結してるよ、型推論で>>72にも言った通り型を何回も書く意味がない。付け加えれば()カッコも
要らない。第一引数クロージャーのラムダ式で言えばカッコが必要ないのに書く意味が無い。そして
varとletとは不変性だが、rustやVの様にたかがGCを搭載したく無いだけで、どこでもmut mutして
プログラマに負担を強いるより良い（あくまで個人の感想です）
さらに、procとfuncも、片方が純関数なのはキーワードとして明示できる統一性としてありだね。
まあpragmaが多すぎる気もするけど、if likely(true)/unlikely(false)の様にCPUキャッシュ分岐予測に
直接関与出来る高級言語としては、他に類を見ない。GCが嫌ならOFFに出来るし、そして重い
Stop the Worldが嫌ならそれをしないGCに変えることが出来る、言語としては機能が多くて
Goの様に究極なシンプル（なのに統一性が微妙）じゃ無いけど、こりゃ良いわ
var name = stdin.read LineEnum

**デフォルトの名無しさん** · 2021/01/10(日) 22:14:35.92

付け加えるとHaskellみたいなproc() = の宣言が微妙キモいけどfunc(): T =があるから、まあ妥当だね
rubyの様なreturnを書かないのは良い。result=xは便利だけど微妙....でそこまでやるならOptionと
Future、そして例外を統一して欲しかったな。
普通にtry: except: finally:があるのも点数が高い。Araqが言う様に例外と(Label)goto based exceptは
ほとんど同じ何だから、今どきの言語が例外が無いのはおかしい。まあ他を悪く言う気はないけど
Goの様に意味合い的に同じでfinallyに対応するdeferがあるのも良いよね

**デフォルトの名無しさん** · 2021/01/12(火) 15:33:30.76

超時空ロングパス

**デフォルトの名無しさん** · 2021/01/12(火) 15:57:17.72

この言語がJsと比較で優れてる点ってあるの？

**デフォルトの名無しさん** · 2021/01/13(水) 08:29:44.80

JavaScript？であれば、JavaScriptはECMAScriptのバージョンとともに型無しのダックタイプから
クラス定義で見られるように型を導入して大規模コードを書く際に静的な安全性を求めてきた、
言語的な特徴でもあった動的なメソッド上書きやapply/callは悪とみなされつつ、改良が進む。
TypeScriptもその特徴であろう、altJSあるいはJSX派生と呼ばれる一種の方言が多量に誕生した
一方でJavaScriptの遅さや１言語依存からwasmが考え出されて多くのコンパイラでwasm開発が
できるようになった。Nimも例に漏れずJSバックエンド及びwasmコンパイルが可能である。
Rustもwasm開発はそうだがJSバックエンドは無い、Goもwasmは出来るがサイズが大きい
NimはGoに比べても型チェックが厳しい、Rustはそれに借用いわゆるボローチェックがそれに
加わるRustもそうだが型安全性はばつぐんだ

**デフォルトの名無しさん** · 2021/01/14(木) 18:15:15.39

jsって割と底辺だと思うから
Nimはそれより上だろ

**デフォルトの名無しさん** · 2021/02/25(木) 19:45:58.25

1.4.4 age

**デフォルトの名無しさん** · 2021/04/17(土) 20:22:19.25

1.4.6 age

**デフォルトの名無しさん** · 2021/04/30(金) 20:42:36.52

Windows defenderでウイルス判定される

**デフォルトの名無しさん** · 2021/05/01(土) 12:24:15.54

それはどうしようもない
https://forum.nim-lang.org/t/7830

**デフォルトの名無しさん** · 2021/05/10(月) 13:57:34.01

頼むからもう少し流行ってください。Dropトレイト、Rcトレイトと戯れてあいつのコードを直したくない

**デフォルトの名無しさん** · 2021/05/10(月) 15:07:45.08

明日に向かって吠えろ

**デフォルトの名無しさん** · 2021/05/13(木) 14:29:40.54

Software Design に記事持ち込め

**デフォルトの名無しさん** · 2021/05/15(土) 12:35:34.04

https://www.akiradeveloper.com/post/give-up-nim/

**デフォルトの名無しさん** · 2021/05/19(水) 07:49:19.67

2015年2月なんて大昔だろ…Version 0.11頃の話、貼る奴w

**デフォルトの名無しさん** · 2021/05/19(水) 07:53:15.04

間違えた。
2月だから0.11さえ出てないわ、0.10.2…

**デフォルトの名無しさん** · 2021/05/26(水) 22:06:31.04

>>120-122
バージョン1.4.8がリリースされました
2021年5月25日ニムチーム

Nimチームは、Nim1.4の4番目のパッチリリースであるバージョン1.4.8を発表できることを
嬉しく思います。バージョン1.4.8は、1か月のハードワークの結果であり、23のコミットが
含まれており、最も重要なバグが修正され、ORCメモリ管理がさらに改善されています。
すべてのユーザーにバージョン1.4.8をアップグレードして使用することをお勧めします。

リリースのハイライト
develブランチと同様に、v1.4.8はcsources_v1を使用して構築されています。つまり、
AppleM1チップで使用できます。
バージョン1.4.6は、いくつかのウイルス対策ソフトウェアでいくつかの誤検知を引き
起こしました。私たちのテストによると、これはv1.4.8では発生しないはずです。

**デフォルトの名無しさん** · 2021/06/24(木) 16:12:27.31

なんか結局流行らなかったな
2019ごろはちょっと来そうな雰囲気出してたのに

**デフォルトの名無しさん** · 2021/06/24(木) 16:13:02.76

今でも一番書いてて気持ちいい言語ではあるけど

**デフォルトの名無しさん** · 2021/06/24(木) 17:25:26.02

Luaといい勝負？

**デフォルトの名無しさん** · 2021/06/27(日) 14:10:40.69

Luaの理念は、簡素、高効率、高移植性(simple, efficient, extensible)、現在はpowerfulとかに変えた。
JITもあるが型の概念が希薄で基本はNativeではない。GCあり、プロトタイプベースのOOPSもC/C++の
相互運用も図られているが、主な用途は本体のプログラムを拡張するスクリプト、ゲームの拡張や
３Dモデリングソフトなどの拡張。

一方、Nimは「Efficient, expressive, elegant」（効率的、表現力豊か、エレガント）であり、型は厳格。
関数、あるいはプロシージャ呼び出しも厳密。Goにあるinterface{}のようなものは無く、Cというか
リンケージ指定、オブジェクトコピー方法、インライン展開など明示するような言語と一体化されたプラグマ。
言語と一体化されたマクロ・テンプレート。状況で選べるGC、例外try-catchとdeferを全否定をしない。
RustのようにGCを排除したためプログラマに押し付けた借用チェックは無い。
Goよりも小さくて速いGC、それによる速度低下は最小限、Rustは学ぶ価値が確かにあるが非常に高い敷居。
Nimは非常に低い敷居(Goほどではないが）、表現力はC/C++そのもの、限りなく抑え込まれたタイプ量。

**デフォルトの名無しさん** · 2021/06/27(日) 20:05:41.95

そんなにヒドいかな？

**デフォルトの名無しさん** · 2021/08/21(土) 08:23:43.68

Nimにガベージコレクション(GC)有りは事実なのですが、
NimはオプションでGC無しにできるので、
Nimバージョン：1.5.1でRustのボローチェッカー
に似た「View types」が実装されれば
GC無しで、View types参照の有効性を検証する
ことによってメモリ安全性を保証しつつ高速化して
C/C++/Rustの代替に出来ますか？

**デフォルトの名無しさん** · 2021/08/21(土) 08:47:50.25

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

**デフォルトの名無しさん** · 2021/08/21(土) 22:20:40.33

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 08:04:08.99

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/10/02(土) 12:07:48.96

いつの間にかJetBrainsのプラグインが出てたね。今更気がついたよ
これもかなり良いんじゃない？
https://plugins.jetbrains.com/plugin/15128-nim

**デフォルトの名無しさん** · 2021/10/27(水) 21:47:06.11

const str = [0, 1, 2, 3, 4]
for i in 0||str.high: echo str[i]
# nim --passC:"-fopenmp" --passL:"-fopenmp" c main.nim

**デフォルトの名無しさん** · 2021/10/28(木) 12:20:10.25

>>92
Cの関数だけでもいろいろなコンパイラーにより規約が違うから、ダイナミックなリンケージを非常に素直に
書ける言語はこれくらいだと思う。rustもFFIで呼べるけど
https://ja.wikipedia.org/wiki/呼出規約

**デフォルトの名無しさん** · 2021/10/29(金) 07:15:01.84

Nim言語の開発者が$100k相当のBitcoinの寄付を受け取ったことが話題になっています。
www.reddit.com/r/programming/comments/qg2srd/nim_receives_100k_in_bitcoin_donations/

**デフォルトの名無しさん** · 2021/11/11(木) 20:14:42.95

>>99
公式での処理系は基本的にはC/C++のトランスコンパラですがJSのトランスコンパラとしても動作します。
言語的には依存している分けではなく、gccやclangの最適化の恩恵を受けるためにあえてそのようにして
いるようです。
また直接バイナリを吐き出す別のコンパイラarnetheduck/nlvmもあります。CrystalやRust、Swiftなどの
LLVMバックエンドと同じです。コンパイル時間を短縮しllvmバイナリとして僅かに小さくなります。

**デフォルトの名無しさん** · 2021/11/22(月) 17:33:11.29

RustよりC++より速いんですか？　始めてみようかな

**デフォルトの名無しさん** · 2021/11/22(月) 20:36:44.15

いろんな意味で早いと思う

**デフォルトの名無しさん** · 2021/12/17(金) 19:10:05.51

Version 1.6.2 released
https://nim-lang.org/blog/2021/12/17/version-162-released.html

**デフォルトの名無しさん** · 2022/02/10(木) 01:19:39.92

Version 1.6.4 released
https://nim-lang.org/blog/2022/02/08/version-164-released.html

**デフォルトの名無しさん** · 2022/03/29(火) 04:55:27.78

1.6.x系だけDLしようとするとマルウェア警告出るんだけどこれ大丈夫なんかね

**デフォルトの名無しさん** · 2022/03/29(火) 14:58:47.55

Nimの公式サイトから入手したものなら大丈夫なはず。
Nimに含まれている実行ファイルやNimでコンパイルしたプログラムがアンチウィルスソフトウェアに誤検出される問題は多くの人々から報告されている。
Nim言語でマルウェアを書いてる人がいるせいで誤検出さるようになったらしい。
アンチウィルスソフトウェアは悪いことしないプログラムでもマルウェアと似たようなビットパターンを見つけるとマルウェアとみなすっぽい。

**デフォルトの名無しさん** · 2022/03/29(火) 15:37:13.13

>>148
なるほどね？
サンキュー😉👍🎶

**デフォルトの名無しさん** · 2022/03/29(火) 20:54:07.21

マルウェアと誤検知されたくなければnimで開発しない方が無難か。

**デフォルトの名無しさん** · 2022/03/31(木) 21:33:49.63

多くの人が使っているプログラムでない限り誤検出される可能性はある。
C++使ってたころにビルドが完了してすぐに誤検出されことがあったし。

**デフォルトの名無しさん** · 2022/03/31(木) 21:54:44.97

そういうどっちもどっち論じゃないだろ。>>148は有意に誤検知が多いと言っているように見えるが。

**デフォルトの名無しさん** · 2022/04/01(金) 11:47:01.52

Nimコンパイラ自体がマルウェア扱いだからな。

**デフォルトの名無しさん** · 2022/04/03(日) 00:58:55.13

Nimを書き初めて1ヶ月...procの第一引数に設定したオブジェクトにprocがバインドされる謎構文にはたまげたけど書き味がいいし気に入ったなあ

**デフォルトの名無しさん** · 2022/04/03(日) 10:37:31.39

>>154
ちょっと誤解しているようだけど、a.foo()って書いたら自動的にfoo(a)に変換されるだけだよ。
第一引数の型にそのprocがバインドされるわけじゃないよ。
X.nim:
type
　Foo* = object
　　x: int
proc foo*(f: Foo) = echo f

Y.nim:
import X
proc bar*(): Foo = Foo()

Z.nim:
import Y
#X.nimをインポートしてないとfoo()は呼べないよ
bar().foo()

**デフォルトの名無しさん** · 2022/04/03(日) 10:53:58.62

Nimではプロシージャの呼び出し方が何通りかある。
echo("Hello")
# Command invocation syntax
echo "Hello"
# Method call syntax
"Hello".echo
"Hello".echo()
# Generalized raw string literals
# 引数が文字列リテラル一個のときのみ
echo"Hello"

**デフォルトの名無しさん** · 2022/04/03(日) 20:20:01.30

>>155
なるほど👀
それでも変わった感じですよねえ

**デフォルトの名無しさん** · 2022/04/09(土) 11:44:54.12

>156
Method call syntax はスマートだから他言語でも流行ってほしいところ。
特にPythonは真っ先に採用して欲しいわ。

**デフォルトの名無しさん** · 2022/04/22(金) 04:37:03.66

あまり何通りもあるのはperlみたいになりそうでよろしくないな。

**デフォルトの名無しさん** · 2022/05/05(木) 20:58:23.76

Version 1.6.6 released
https://nim-lang.org/blog/2022/05/05/version-166-released.html

**デフォルトの名無しさん** · 2022/05/06(金) 17:32:07.42

>>160
急にコンパイルできなくなって困ってたら
vccexe,exeがトロイ認定受けて削除されてた…
MSはnimをトロイだとみなしてるのか

**デフォルトの名無しさん** · 2022/05/08(日) 11:28:42.79

>>161
前に一回同じ現象出たわ
コンパイル失敗するしWindows Defenderはうるさいしで何かやらかしたかと思った

**デフォルトの名無しさん** · 2022/05/18(水) 23:08:10.33

ニンニン

**デフォルトの名無しさん** · 2022/06/14(火) 14:49:13.90

二ムってドイツ製？

**デフォルトの名無しさん** · 2022/06/22(水) 00:08:54.72

Araqってたしか国籍は南米じゃなかったか

**デフォルトの名無しさん** · 2022/06/22(水) 00:28:49.96

>>164
すまんドイツ人だったわ
顔面からずっと南米の人だと思ってた

**デフォルトの名無しさん** · 2022/07/26(火) 18:12:34.65

ニンニン

**デフォルトの名無しさん** · 2022/07/26(火) 18:15:36.24

浣腸

**デフォルトの名無しさん** · 2022/07/27(水) 03:59:11.24

Aliasing restrictions in parameter passingかview typesが実装されればNimもRust並にメモリ安全になると思うんだけど。
みんなはどう思う？
https://nim-lang.org/docs/manual_experimental.html#aliasing-restrictions-in-parameter-passing
https://nim-lang.org/docs/manual_experimental.html#view-types

**デフォルトの名無しさん** · 2022/07/28(木) 11:23:58.38

>>169
むしろ--mm:orcならRustよりNimのほうが循環もGCするだけメモリ安全だし、リリースビルドでオーバーフローチェックが意味不明にoffになり、言語仕様としてループindexにunsignedを使うRustのどこが安全なのかと小一時間。
まあNimでのdangerコンパイルと似てるし、構文上まだ危険な超絶ハック表現が出来てしまうので素人にはオススメ出来ない諸刃の剣。だけどsqlパッケージの文字列前提を絶対変えてほしい

**デフォルトの名無しさん** · 2022/07/28(木) 14:19:26.27

RustのBorrow Checkerはメモリリークを防ぐものではないからね

**デフォルトの名無しさん** · 2022/07/29(金) 02:16:03.41

nimの言語的とか技術的な弱点や欠点って何？

**デフォルトの名無しさん** · 2022/07/29(金) 03:05:46.34

templateまたはmacroの第一引数がuntypedだとmethod call syntaxが使えない。
method call syntaxでgenerics parameterを指定するときにfoo.myproc[:int]()みたいな感じで[]の中の初めに':'を付けないといけない。method call syntaxを使わないときは':'は不要。
という感じでmethod call syntaxにちょっとした罠がある。

**デフォルトの名無しさん** · 2022/07/29(金) 12:18:00.08

macroが全く別言語になってる錆やその他諸々よりも、ちゃんと言語の最小サブセットになってるからまだマシ

**デフォルトの名無しさん** · 2022/07/29(金) 13:08:45.89

なるほど

**デフォルトの名無しさん** · 2022/09/10(土) 16:11:58.36

win10 x64 nim-1.6.6 x64 です
(A)
var hoge = newSeq[uint16](16)
# hoge[...] に wchar_t の文字列 L'\x0' 終端がある (サロゲートとか無い状態で 4文字分)
echo convert(cast[string](hoge[0..3]), "utf-8", "utf-16")
(B)
var fuga = newSeq[char](16)
# fuga[...] に char の文字列 '\x0' 終端がある 4文字分
echo cast[string](fuga[0..3])

(B)の方は期待通り 4文字分出力されるのですが
(A)の方はなぜか 2文字くらいで切れてしまいます
echo convert(cast[string](hoge[0..7]), "utf-8", "utf-16")
と修正すると 4文字出ましたが何か腑に落ちません

**デフォルトの名無しさん** · 2022/09/11(日) 06:48:19.18

>>176
そもそも何をしたいの?
windowsで日本語を表示したいだけならutf8を使ってればOk
デフォルトでNimのコマンドラインプログラムを実行するとchcp 65001コマンドを実行したときのようにコードページをutf8に変更される。
chcp 65001を実行してもちゃんと日本語が表示されるようにターミナルを設定しよう。

utf16なテキストをutf8に変換して表示したい場合はできるだけcast使わないようにコードを書こう。
castは危険なのでできるだけ使わないようにしよう。
(castはビットパターンが同じまま別の型と見なす変換なので実装詳細を知らずに使ってるとうまく動かない)
最初からstringに文字列を格納するようにするとか、ループで一文字づつstringにコピーすればcastは避けられると思う。

**デフォルトの名無しさん** · 2022/09/11(日) 15:33:59.58

上の例とは若干違いますが
var u16 = newSeq[uint16](8)
for n in 0..7: u16[n] = cast[uint16](65 + n)
u16[7] = 0
echo u16 # -> @[65, 66, 67, 68, 69, 70, 71, 0]
echo convert(cast[string](u16), "utf-8", "utf-16") # -> ABCD
let u8 = cast[ptr UncheckedArray[array[16, uint8]]](u16[0].addr)[0]
echo u8 # -> [65, 0, 66, 0, 67, 0, 68, 0, 69, 0, 70, 0, 71, 0, 0, 0]

ABCD のところが ABCDEFG にならないのがなんでかなーというのも
同様の現象が原因だろうと思います

**デフォルトの名無しさん** · 2022/09/11(日) 15:42:19.33

echo convert("\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x00\x00", "utf-8", "utf-16")
これは
ABCDEFG
と出力されます

**デフォルトの名無しさん** · 2022/09/11(日) 15:48:12.92

>>178 の例で
var u16 = newSeq[uint16](16)
と定義しておくと(他は変更無し)(後半は0で埋まってる)
ABCDEFG
と表示されます

**デフォルトの名無しさん** · 2022/09/11(日) 15:48:57.35

まあ cast に何を期待してるんだと言われればそれまでなんだと思いますが腑に落ちませんでした

**デフォルトの名無しさん** · 2022/09/11(日) 19:01:47.42

nimってIDEやデバッガは近いうちに計画されてるの？
vscodeでもいいんだけど、ちゃんとしたデバッガは欲しいな
条件付きブレークポイントやコンテナの中身が見れる程度でいいんだが

**デフォルトの名無しさん** · 2022/09/11(日) 19:50:17.68

>>182

vscodeのプラグイン
nimsaem.nimvscode + webfreak.debug ではだめか？

**デフォルトの名無しさん** · 2022/09/11(日) 22:55:03.70

やっぱりその組み合わせか
どうにも使いづらいんだよねぇ
言語仕様は理想に近いんでもっと流行ってほしいんだが、これまでの情勢からあまり期待できなさそうだな

**デフォルトの名無しさん** · 2022/09/12(月) 01:44:56.16

>>181
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcast

**デフォルトの名無しさん** · 2022/09/12(月) 01:47:29.58

>>181
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcastしてるの？
そうでないならcast使うのはやめたほうがいいよ。

**デフォルトの名無しさん** · 2022/09/12(月) 02:10:20.86

>>181
seqやstringのデータ構造を理解しcastが何をしているか理解すれば納得できると思うよ
https://github.com/nim-lang/Nim/blob/devel/lib/system/seqs_v2.nim
https://github.com/nim-lang/Nim/blob/devel/lib/system/strs_v2.nim
そもそもseq[uint16]からstringへcastしてる時点でもうデタラメなんだよ。

**デフォルトの名無しさん** · 2022/09/12(月) 02:17:45.60

>>182
NimにGDBでデバッグできるようにするプラグインが付属していて
gdbでブレークポイントをおいたり変数の中身を表示したりできます。
https://internet-of-tomohiro.netlify.app/nim/gdb.ja.html

**デフォルトの名無しさん** · 2022/09/12(月) 20:00:29.06

>>178 >>180
var u16 = newString(16)
for n in 0..7: u16[n * 2] = cast[char](65 + n); u16[n * 2 + 1] = '\0'
u16[14] = '\0'
echo u16 # -> A B C D E F G
echo convert(u16, "utf-8", "utf-16") # -> ABCDEFG

**デフォルトの名無しさん** · 2022/09/12(月) 22:26:15.30

>>189
castは極力使わないほうがいいのでビット演算使ってu16の値をcharに変換したほうがいいよ。
お手本コードを投稿しようとしたらcloudflareが悪意あるコードと勘違いしてブロックされた

**デフォルトの名無しさん** · 2022/09/12(月) 22:30:11.19

こんな感じです
ｌeｔｃ=６５u１６ + n
u１６[n * ２] = ｃｈar(ｃ and 0xｆｆ'u１６)
u１６[n * ２ + 1] = ｃｈar(ｃ shr ８)

**デフォルトの名無しさん** · 2022/09/13(火) 11:55:15.89

>>176
これ観ろ
https://khchen.github.io/winim/winstr.html

**デフォルトの名無しさん** · 2022/09/13(火) 12:06:13.19

言語仕様としてはモダンな言語の中で1番わかりやすいし
Rustで書くほどでもない軽いスクリプトとかならNimで良いんだけど流行らんなあ
やはり個人開発者の言語が流行ることはもうないのか

**デフォルトの名無しさん** · 2022/09/13(火) 15:06:32.01

>>189 >>192
ありがとうございました

**デフォルトの名無しさん** · 2022/09/13(火) 16:00:02.06

アク禁？

**デフォルトの名無しさん** · 2022/09/13(火) 16:03:11.36

var ws = newWideCString(8) # ws.len == 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
# ws.len == 8
ws[7] = Utf16Char(0) # ws.len == 7
echo ws # ABCDEFG
と比べて

**デフォルトの名無しさん** · 2022/09/13(火) 16:05:36.05

なぜ拒否られる？

**デフォルトの名無しさん** · 2022/09/13(火) 16:06:26.54

驚き最小の法則ですね
var s = newString(8) # s.len == 8
for n in 0..7: s[n] = ｃｈａｒ(65 + n)
# s.len == 8
s[7] = '\0' # s.len == 8
echo s # ABCDEFG

**デフォルトの名無しさん** · 2022/09/13(火) 16:07:15.32

判ったｃｈａｒだけダメなんね

**デフォルトの名無しさん** · 2022/09/13(火) 16:09:20.44

驚き最小の法則
var ws = newWideCString(8)
echo ws.len # -> 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
echo ws.len # -> 8
ws[7] = Utf16Char(0)
echo ws.len # -> 7
echo ws # ABCDEFG
と比べて
var s = newString(8)
echo s.len # -> 8
for n in 0..7: s[n] = ｃｈａｒ(65 + n)
echo s.len # -> 8
s[7] = '\0'
echo s.len # -> 8
echo s # ABCDEFG

**デフォルトの名無しさん** · 2022/09/13(火) 16:11:32.87

インド人もびっくり

**デフォルトの名無しさん** · 2022/09/13(火) 19:05:39.59

Win土人
Nim土人

**デフォルトの名無しさん** · 2022/09/16(金) 10:37:25.88

proc testfunc(x: cint): cint {.exportc, cdecl, dynlib.} =
return x
と描かれたソースを
nim c --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されて
import ctypes
ctypes.cdll.LoadLibrary('./hoge.dll').testfunc(123)
と実行出来たのですが
nim cpp --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されているはずなのに
LoadLibrary のところで
FileNotFoundError: Could not find module '(fullpath)\hoge.dll' (or one of its dependencies).
Try using the full path with constructor syntax.
と言われてしまいます
多分 or one of its dependencies が引っ掛かっているのではないかと思うのですが
何が足りないのでしょう？ stdc++ の shared library ?

**デフォルトの名無しさん** · 2022/09/16(金) 10:57:11.84

libstdc++-6.dll
をコピーしてみましたがだめでした

**デフォルトの名無しさん** · 2022/09/16(金) 11:30:30.18

nimpy
nimodule

**デフォルトの名無しさん** · 2022/09/16(金) 13:53:03.44

>>203
objdumpっていうプログラムを使えばどのdllを使っているか見れるよ。
使い方忘れたからググってね。
Nimをインストールしたときにgccもインストールしてればそのときにobjdumpも一緒にインストールされる。
他にも依存しているdllを見れるツールは色々あるけど

**デフォルトの名無しさん** · 2022/09/16(金) 16:11:50.14

>>206
windows用にもobjdumpあんの？

**デフォルトの名無しさん** · 2022/09/16(金) 16:24:53.42

windows で nim 入れるときに一緒に入った mingw64 の中に objdump がありました

**デフォルトの名無しさん** · 2022/09/16(金) 16:34:58.81

>>206
objdump -p hoge.dll | findstr "dll"
で出て来たのが
libgcc_s_seh-1.dll
libstdc++-6.dll
kernel32.dll
msvcrt.dll
でした
libstdc++-6.dll
だけではなく
libgcc_s_seh-1.dll
も必要でした
無事動作しましたありがとう

**デフォルトの名無しさん** · 2022/09/18(日) 09:51:11.78

>>200
https://github.com/tauplus/nim_doc_ja/blob/master/nim-meory_ja.md#%E6%96%87%E5%AD%97%E5%88%97%E3%81%A8%E3%82%B7%E3%83%BC%E3%82%B1%E3%83%B3%E3%82%B9Strings-and-seqs

**デフォルトの名無しさん** · 2022/09/22(木) 10:36:47.71

import nimpy
import nimpy/py_lib as lib
initPyLibIfNeeded()
let wx = pyImport("wx")
let app = wx.App()
let frm = wx.Frame(nil, -1, "Hello, work!")
discard frm.Show()
discard app.MainLoop()

簡単杉感嘆

**デフォルトの名無しさん** · 2022/09/22(木) 15:46:35.23

こんなのや
https://github.com/khchen/wNim
こんなのも
https://github.com/simonkrauter/NiGui

**デフォルトの名無しさん** · 2022/09/23(金) 15:49:32.66

セルフホスティングくらいでけるのか？

**デフォルトの名無しさん** · 2022/09/23(金) 16:54:42.46

>>213
セルフホストってどういう意味で言ってるかは知らないけど
Nim forum自体がNimで実装されてるよ。
https://github.com/nim-lang/nimforum

**デフォルトの名無しさん** · 2022/09/23(金) 20:37:31.28

プログラミング言語でセルフホスティングっていったらコンパイラが自身の言語で実装できることだろうよ
しかしできたとしてトランスパイラをセルフホスティングと呼んでいいのか

**デフォルトの名無しさん** · 2022/09/23(金) 22:00:58.25

出力がC言語か機械語かの違いぐらいだしトランスパイラだとしても普通にセルフホスティングって呼ぶよ

**デフォルトの名無しさん** · 2022/09/23(金) 22:27:48.78

https://github.com/nim-lang/Nim
ここにNim言語のコンパイラがあるけどソースコードはNim言語で書かれている。
gccなどのCコンパイラとgitがあればソースコードからビルドできる。
ソースコードからビルドするときはまず古いバージョンのNimコンパイラをC言語に変換したものをダウンロードしてCコンパイラでビルドする。
それでビルドしたNimコンパイラで最新のNimコンパイラをビルドする。

**デフォルトの名無しさん** · 2022/09/24(土) 20:13:52.60

わりとどうでもいいな

**デフォルトの名無しさん** · 2022/09/25(日) 02:56:32.67

Cコンパイラは一般的にC言語で実装されているが、どうやってCコンパイラをビルドするのか
あらかじめビルド済みのCコンパイラを持ってきてビルドする
ではそのビルド済みのCコンパイラはどうやってビルドされたというのか

**デフォルトの名無しさん** · 2022/09/25(日) 08:27:58.95

たぶん世界で最初のC言語はアセンブリかB言語かフォートランか何か別の言語で書かれていたんじゃないの?

**デフォルトの名無しさん** · 2022/09/26(月) 14:35:28.98

BigBangは未だ仮説だ

**デフォルトの名無しさん** · 2022/09/28(水) 12:46:44.72

toSeq(0..360|24).map(rad)
と描くと
Error: type mismatch: got <SteppedSlice>
と言われて怒られたので
toSeq(0..360).filter(x => x mod 24 == 0).map(rad)
で描き治したら一応動く訳だが
0..360|24
観たいに描く方法は？

**デフォルトの名無しさん** · 2022/09/28(水) 13:40:07.41

iterator `|`(x: HSlice; y: int): int =
みたいな演算子のイテレータを定義すればいいじゃん。

**デフォルトの名無しさん** · 2022/09/28(水) 17:12:46.81

nim 1.6.8 出た

**デフォルトの名無しさん** · 2022/09/29(木) 21:45:04.30

ウィ

**デフォルトの名無しさん** · 2022/10/02(日) 11:50:55.49

>>223
iterator items(s: SteppedSlice): int =
var c = s.a
while c <= s.b:
yield c
c += s.step

を定義したらイケました
有賀豚

**デフォルトの名無しさん** · 2022/10/16(日) 04:20:39.65

ニンニン

**デフォルトの名無しさん** · 2022/10/22(土) 14:42:48.48

本日のNimConf2022期待age

**デフォルトの名無しさん** · 2022/11/02(水) 12:51:11.01

1，2ヶ月くらい前に
Nim言語のマニュアル日本語訳がOSDNのページにアップされていて
これで5年後には結構人気が出るかもと喜んでいたら
突然ページが消滅してショックだった

キャッシュを探したけど発見できないので
コピー持ってる人がいたらどこかにアップしてもらえらばありがたいです
(ライセンス上問題が無ければですが)

**デフォルトの名無しさん** · 2022/11/02(水) 22:26:34.03

古いキャッシュならInternet Archiveにあった
https://web.archive.org/web/20201128232605/http://nim-lang-081.osdn.jp/
https://web.archive.org/web/20200928154858/http://nim-lang-081.osdn.jp/docs/manual.html

まあキャッシュ古すぎて更新追いついてないけど

**デフォルトの名無しさん** · 2022/11/02(水) 22:33:40.08

https://ja.osdn.net/users/megumi_engines/projects/
このひとがオーナーになってるプロジェクトの1つみたいだけど、Twitterのアカウントも消えちゃってるね
プライベートが忙しくなったのかな

**デフォルトの名無しさん** · 2022/11/03(木) 15:08:48.38

Last Update: 2022-09-21 01:12
Nim プログラミング言語 - 非公式日本語版 (翻訳活動終了)に関する活動はすべて終了しました。リポジトリの再公開予定はありません。

理由はよう判らん
githubにfork無かったかな