Visual C++2019での挙動差異

Algorithm4のインスタンスの一部が動きませんでした。
調べたところ、
次の箇所、std::mapの挙動が違いました。
mapがemptyであるとき、0が入ると思っていたのですが、デバッグモードでは、0、最適化を行うと、1が入ってしまいました。

  map[xx]=map.size();
  

言語仕様上、正しい動作は分からないのですが、とりあえず、明示的に次のような対処を行いました。

　int size=map.size();
  map[xx]=size;
  

Runtime自体は、変わっていないようですので、恐らくコンパイラの差異なんでしょう。いつものことですが、コンパイラを変えると何かしら、こうした問題が発生します。

各国祝日の調査

AWS対応は、ほぼCodingが終わりました。
後は、Docker　SDK提供とIAM　Role/Principal等のインタフェース定義対応が残るのみです。

SC3のデスクトップブリッジ対応は、海外から始めようと思います。

そうなると問題は、

１）英語マニュアル
２）ソフトの各国対応

になります。中でも祝日定義をどこから拾ってくるか問題です。

WindowsでAPIであればよいのですが、UWPでもなく、方法としては、次の二つになるかと思います。

１）https://qiita.com/richmikan@github/items/9090407e3ab9cd3e80b2
２）https://hnw.hatenablog.com/entry/2019/04/13/212054

１）は、オンライン　２）は、オフラインになります。要検討です。デスクトップブリッジは、ネットアクセスを許容すると思うので、１）が第一候補です。

とりあえず、SC3日本語マニュアルを作ります。

SC3のプロモーション動画を作りました

3交代正循環を題材にして動画をSC3での動画を作ってみました。

https://youtu.be/0vuGpXbO2Wc

AVIをそのままアップロードしましたが、文句を言われませんでした。

Dockerの勉強

AWS LambdaをいきなりCALLしてもらうのは、難しいかもしれないので、ローカルでデバッグできる環境を提供しようと思いました。必要なのは、C++lambdaが動かせること、ローカルでDynamoｄｂにlambdaがW/Rできることです。

https://github.com/lambci/docker-lambda
https://aws.amazon.com/jp/serverless/sam/

を理解出来れば、そういったキットを提供できるかもしれません。いずれも、Dockerなる仮想化技術が使われているので、Dockerを勉強する必要があります。

本もいくつか買ってみたのですが、このサイトの記事が私的にはよさそうでした。

https://kirohi.com/docker_study_resources

クラウド破産

https://qiita.com/saitotak/items/813ac6c2057ac64d5fef
の記事をみて、

初期設定まとめを参考に
https://qiita.com/tmknom/items/303db2d1d928db720888

ダウンロード本を購入しました。
https://dev.classmethod.jp/articles/review-how-to-prevent-cloud-bankruptcy/

かなり甘かったことを知りました。怖いです。

C++11/C++17へ

AWS用の記述では、C++14 をベースとして、部分的にC++17を使用しています。例えば、WindowsとLinux、スレッド生成一つ取ってもC++11を使えば、共通のstd::thread が使えます。ファイルのアクセスについてもC++17では、filesystemがあり、便利に使えます。ということで、同じ事をやるのに書き換えてWindows/Linux共通で使えるようにした部分が多数あります。

恐らく現リリース最新版129CとAWS開発最新版では、1万行以上記述が変わっています。そのためRegression Testが必要となっています。

このテストが1週間、マニュアル更新に1週間、リリースは、6月中旬を予定しています。

Python Editor の改善

次期リリース予定版(現在開発中のAWS対応版)では、PythonEditor(scintilla)を少し改善しています。Python Editorは、二つのタブになりました。[ソース]と[ソース全体]です。[ソース]は今までのエディタに同じです。

[ソース全体]の方は、ReadOnlyなので書くことはできません。また、最初の状態では、何もありません。

 求解すると、以前の_property.py と現在のソースとが合体したソースを[ソース全体]タブ中に見ることができます。

ここで、故意にエラーを作ってみます。今月：の：を削除して求解してみます。

 当然エラーになります。
●　
行をダブルクリックすると当該行がピンクでハイライトされます。

 

 

 ソース全体は、ソルバーが内蔵しているpython interpreterが認識しているソース全体になります。
従い、今までと違い正しく当該行を表示することが出来ます。
また、pythonソースを記述するのに、外部エディタを参照しながら記述する面倒が少し改善されます。

内部動作として、~property.pyは、以前と同様に出力されています。GUIは、それを拾ってきて、[ソース全体]として表示しています。GUIは、python interpreterの出力する"<string>"をKeywordとして、findしたら、python editorにその後続の(行)を表示されています。

AWS版でも、同様ですが、ファイル出力というインタフェースは利用できません。代わりに
lambda call のresponce payload中にソース全体が返ります。また、求解状況は,ユーザアカウント上の指定する(lambdaがアクセス許可された）テーブル上のStatusに出力されます。Status
は、XXsecに一回更新されます。(streaming modeにしてすると、上記GUI画面の右ペイン相当を得ることが出来ます。)　従い、AWSユーザは、(やろうと思えば)上記GUI動作と同じ処理を行うことが出来ます。