omochimetaru

@wjakob Hello I am working in my previous project with nanogui. I am refactoring code and facing this issue again. Please review this PR !

Hi, I am coworker with @sidepelican . We are using vapor and postgres for our company business. We depends on `numeric` type of postgres for accurate amount of money processing...

Thank you for detailed response and review. I agree what you say. I response for each topic below. > 1. ... This is not a bug in NIO, but rather...

Unfortunately yes. I uploaded screen capture on my twitter. Please watch it. https://twitter.com/omochimetaru/status/999463353293520896

This is complex discussion. In sandbox, there are following facts. - [1]: `[Double]` types are at plotting APIs. - [2]: `CGPoint`, `CGAffineTransform` types are at rendering transformation calculation. There is...

Playground上ではパッケージが無いので、numswとPlaygroundsは同じパッケージに無いといけない。つまり、RenderViewControllerからMatrixを使う時、ファイル冒頭に `import numsw` は書かない。 よって、sandboxターゲットでは、numswとPlaygroundsの全てのソースが突っこまれる。 一方、numsw上ではnumswとテストコードは別れているので、テストコードの冒頭には `@testable import numsw` と書く。 これを、sandbox側に取り込んでテストコードを実行しようとすると、 バンドル名が `sandbox` であるため、 `@testable import numsw` がエラーになる。 現状は、このimportを通すため、sandboxにソースで入ってるnumswとは別に、さらにnumsw.xcodeprojで生成されるnumsw.frameworkを突っ込んでいる。つまり、 `numsw.Matrix` と `sandox.Matrix` の両方が入ってる。 sandboxのバンドル名をnumswに変えるのは他の問題が起こりそうなのでやりたくない。

数学関係のクラスが追加されたりしたときに、numsw.xcodeproj側とsandbox.xcodeproj側で2重に対応するのは、対応漏れするとおかしくなりそうなので微妙。 そう考えると、sandbox.xcodeprojからnumsw.xcodeprojを参照させて、numsw.Frameworkを取り込むのが良い。 問題は、sandbox側のPlaygrounds系のソースで、 `import numsw` と書く事になってしまって、肝心のPlaygroundの方で動かなくなってしまう事。 そこで、sandbox.xcodeprojのときだけフラグを立てて、プロプロセッサで `import numsw` が書かれるようにして、Playgroundの時はそれが書かれないようにする。

#38 で対応。

pain -> pane

計算科学だと日本語で仮引数と実引数とも言いますね。 実際に渡す、でも良いですが、関数呼び出し式の引数部分に書く値、と書くと捉えやすいと思います。