2020年6月3日水曜日

Visual C++2019での挙動差異

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

  map[xx]=map.size();
  
言語仕様上、正しい動作は分からないのですが、とりあえず、明示的に次のような対処を行いました。

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

2020年6月2日火曜日

各国祝日の調査

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

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

そうなると問題は、

1)英語マニュアル
2)ソフトの各国対応

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

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

1)https://qiita.com/richmikan@github/items/9090407e3ab9cd3e80b2
2)https://hnw.hatenablog.com/entry/2019/04/13/212054

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

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

2020年6月1日月曜日

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

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

https://youtu.be/0vuGpXbO2Wc

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

2020年5月31日日曜日

Dockerの勉強

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

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

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

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

https://kirohi.com/docker_study_resources

2020年5月29日金曜日

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月中旬を予定しています。



2020年5月28日木曜日

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動作と同じ処理を行うことが出来ます。