https://github.com/HazeyamaLab/setup/issues/14
江端智一のホームページ
https://github.com/HazeyamaLab/setup/issues/14
を参考にさせて頂いて、実験中です。
大変申し訳ありませんが、ほぼ丸パクりさせて下さい。これから、頻繁に見る必要があり、万一ページがexpiredされたら青冷めますので。
hoge.go
というファイル名のPrintHoge
関数を C 言語から呼べるようにします。
C
をインポートする//export XXXX
を書く (普通、//とするとコメントなんだけどなぁ)package main
import (
"C"
"fmt"
)
//export PrintHoge
func PrintHoge() {
fmt.Println("hoge")
}
func main() {}
main
関数がないとエラーになるので、空で良いので書いておきます。
-buildmode=c-archive
オプションをつけてgo build
します。
$ go build -buildmode=c-archive hoge.go
すると、hoge.a
アーカイブとhoge.h
ヘッダが生成されます。
生成されたヘッダをインクルードして、Go 言語の関数を呼びます。
生成されたアーカイブと一緒にコンパイルします。
$ gcc -o hoge hoge.a main.c
ところが、
$ gcc -o hoge hoge.a main.c
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w6
4-mingw32/bin/ld.exe: C:\Users\ebata\AppData\Local\Temp\cc1F3Mbe.o:main.c:(.text
+0xe): undefined reference to `PrintHoge'
collect2.exe: error: ld returned 1 exit status
が出てきて、「変だなー」と思いつつ、色々調べてみたのですが、hoge.aを一番最後にしたら、動きました。
$ gcc -o hoge main.c hoge.a$ ./hogehoge
■外部から強制的に書き込もうとすると失敗します
ubuntu@ip-172-26-7-19:~/codes/xxxxxxx_ride_hailing_go$ docker ps
095fe60f02cc nginx:1.15-alpine "nginx -g 'daemon of…" 8 weeks ago Up 22 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp xxxxxxx_ride_hailing_go_nginx_1
でもって、
ubuntu@ip-172-26-7-19:~/codes/xxxxx_ride_hailing_go$ sudo docker cp fullchain.pem 095fe60f02cc://etc/nginx/conf.d/
Error response from daemon: Error processing tar file(exit status 1): unlinkat /etc/nginx/conf.d/fullchain.pem: device or resource busy (失敗します)
しかし、dockerの中に入って、
ubuntu@ip-172-26-7-19:~/codes/xxxxxx_ride_hailing_go$ docker exec -i -t xxxxx_ride_hailing_go_nginx_1 sh
で内側から、killすると、dockerごとダウンして、なんとも悩ましい、にわとりと卵の関係になってしまいます。
■解決方法
ubuntu@ip-172-26-7-19:~/codes/xxxxxxx_ride_hailing_go$ sudo docker cp fullchain.pem 095fe60f02cc://etc/nginx/conf.d/fullchain.pem.new
ubuntu@ip-172-26-7-19:~/codes/xxxxxxx_ride_hailing_go$ sudo docker cp privkey.pem 095fe60f02cc://etc/nginx/conf.d/privkey.pem.new
でもって、 (今後は、new2, new3, new4 とか、どんどん増やしていく)
ubuntu@ip-172-26-7-19:~/codes/xxxxxxx_ride_hailing_go$ vi nginx.conf
をして、
———————————————————
ssl_certificate /etc/nginx/conf.d/fullchain.pem.new;
ssl_certificate_key /etc/nginx/conf.d/privkey.pem.new;
———————————————————
と書き換える。
さらに、
docker-compose.yml の最後の行に、
volumes:
- "./nginx.conf:/etc/nginx/conf.d/default.conf"
- "./fullchain.pem:/etc/nginx/conf.d/fullchain.pem.new"
- "./privkey.pem:/etc/nginx/conf.d/privkey.pem.new"
も変える。
でもって、 docker-compose stop; docker-compose start をすれば、新しい鍵で動き出します。不細工ではありますが、プログラムは動くようになります。
■ところで今思いついたんだけど、いい方法がありました。
現在は、fullchain.pem.new と、privkey.pem.new で動いているのだから、fullchain.pem と、privkey.pemは、rm できるはず。
で、cp fullchain.pem.new fullchain.pem, cp privkey.pem.new privkey.pem として、さらに、nginx.confの設定を元に戻せば、fullchain.pem と、privkey.pem の名前を使えるはずです
(まあ、動いているので、今は、このままにしています)
■もっと、いい方法がありました。
docker-compose.yml の最後の行に、
volumes:
- "./nginx.conf:/etc/nginx/conf.d/default.conf"
- "./fullchain.pem:/etc/nginx/conf.d/fullchain.pem"
- "./privkey.pem:/etc/nginx/conf.d/privkey.pem"
の3行を加えれば、Dockerの外側に、最新の"fullchain.pem"と、"privkey.pem"を置いておけば、自動的にDockerコンテナの中に取り込まれます(今、そうなっている)
Go言語をVSCodeを使ってデバッグをしようとするとすると以下のメッセージが出てきて、困っていました。
"Failed to continue: Check the debug console for details."
が消えなくて、困っていたのですが、
// +build ignorepackage main
の "// +build ignore"を消したら、消えました。
go run xxxx.go で起動すると、「このアプリの機能のいくつかがwindows defenderファイアウォールでブロックされています」が出てきます
素直に、go build xxxxx.go として、exeファイルを作って、実施すれば、出てこなくなります。
swigを使ってgoとc++をブリッジをやっているのですが、そうなると、コンパイルオプションの
gcc xxxx xxxxx -I c:\users\ebata\json\include
というような、力づくが使えないです。
まあ、色々やり方はありますが、一番簡単なのは、Windows10のコントロールパネルから、"CPATH" を作って、 ダイレクトに"c:\users\ebata\json\include"を書き込むのが簡単です。
スマートとか、かっこいいとか、汎用性とか、そういうことは、考えないのが良いです。
まず、何も考えないで以下のプログラムを実行
// go run main2.go
package main
import (
"fmt"
)
func subPerson(i int) {
fmt.Printf("Now... sub_person(%v)\n", i)
}
func person(i int) {
fmt.Printf("Now... person(%v)\n", i)
go subPerson(i)
}
func main() {
for i := 0; i < 5; i++ {
go person(i)
}
}
当然、何も表示されれない。go routineが起動する前に、main()が終了してしまうから
なので、最後のスレッドが完了するまでは待機するようにする
// go run main2.go
package main
import (
"fmt"
"sync"
)
func subPerson(i int) {
fmt.Printf("Now... sub_person(%v)\n", i)
}
func person(i int, wg *sync.WaitGroup) {
defer wg.Done() // WaitGroupを最後に完了しないといけない。
fmt.Printf("Now... person(%v)\n", i)
go subPerson(i)
}
func main() {
var wg sync.WaitGroup
for i := 0; i < 5; i++ {
wg.Add(1) // goルーチンを実行する関数分だけAddする
go person(i, &wg)
}
wg.Wait()
}
$ go run main2.go
Now... person(0)
Now... sub_person(0)
Now... person(4)
Now... sub_person(4)
Now... person(2)
Now... person(3)
Now... sub_person(3)
Now... person(1)
ただ、これの場合、subPerson()が実行されないまま終了することがある。例えば、、上記の場合、sub_person(1)が実施されずに終了してしまっている。
なので、subPerson()の終了を持って、main()の終了とするようにすると、こうなる。
// go run main2.go
package main
import (
"fmt"
"sync"
)
func subPerson(i int, wg *sync.WaitGroup) {
defer wg.Done() // WaitGroupを最後に完了しないといけない。
fmt.Printf("Now... sub_person(%v)\n", i)
}
func person(i int, wg *sync.WaitGroup) {
subWG := wg
//defer wg.Done() // WaitGroupを最後に完了しないといけない。
fmt.Printf("Now... person(%v)\n", i)
go subPerson(i, subWG)
}
func main() {
var wg sync.WaitGroup
for i := 0; i < 5; i++ {
wg.Add(1) // goルーチンを実行する関数分だけAddする
go person(i, &wg)
}
wg.Wait()
}
結果は、以下の通りとなり、問題なし。
$ go run main2.go
Now... person(0)
Now... person(1)
Now... sub_person(1)
Now... person(4)
Now... sub_person(4)
Now... sub_person(0)
Now... person(2)
Now... sub_person(2)
Now... person(3)
Now... sub_person(3)
Let's Encrypt certificate expiration notice for domain "sea-anemone.tech"
ドメイン "sea-anemone.tech "のLet's Encrypt証明書期限切れのお知らせ。
Hello,
こんにちは。
Your certificate (or certificates) for the names listed below will expire in 19 days (on 29 Mar 21 23:38 +0000). Please make sure to renew your certificate before then, or visitors to your web site will encounter errors.
以下の名前に対するあなたの証明書(または複数の証明書)は、19日後(29 Mar 21 23:38 +0000)に期限切れとなります。それまでに証明書を更新しないと、あなたのウェブサイトにアクセスした際にエラーが発生します。
We recommend renewing certificates automatically when they have a third of their total lifetime left. For Let's Encrypt's current 90-day certificates, that means renewing 30 days before expiration. See https://letsencrypt.org/docs/integration-guide/ for details.
私たちは、証明書の有効期間の3分の1が経過した時点で、証明書を自動的に更新することをお勧めします。現在のLet's Encryptの90日証明書の場合、期限切れの30日前に更新することになります。詳細は https://letsencrypt.org/docs/integration-guide/ をご覧ください。
sea-anemone.tech
For any questions or support, please visit: https://community.letsencrypt.org/ Unfortunately, we can't provide support by email.
ご質問やサポートについては、次のサイトをご覧ください: https://community.letsencrypt.org/ 残念ながら、電子メールによるサポートは行っておりません。
For details about when we send these emails, please visit: https://letsencrypt.org/docs/expiration-emails/ In particular, note that this reminder email is still sent if you've obtained a slightly different certificate by adding or removing names. If you've replaced this certificate with a newer one that covers more or fewer names than the list above, you may be able to ignore this message.
特に、名前を追加または削除してわずかに異なる証明書を取得した場合にも、このリマインダーメールが送信されますのでご注意ください。この証明書を、上記のリストよりも名前の数が多かったり少なかったりする新しい証明書に差し替えた場合は、このメッセージを無視することができるかもしれません。
If you are receiving this email in error, unsubscribe at:
誤ってこのメールを受信している場合は、以下の方法で配信を停止してください。
http://delivery.letsencrypt.org/track/unsub.php?u=30850198&id=f76fe707fe6142509a23d40dde02c153.3i5yYrnKlNWIWqOs%2Fn8YMBMPOVU%3D&r=https%3A%2F%2Fmandrillapp.com%2Funsub%3Fmd_email%3Dt%252A%252A%252A%252A%2540g%252A%252A%252A%252A.%252A%252A%252A
Please note that this would also unsubscribe you from other Let's Encrypt service notices, including expiration reminders for any other certificates.
これにより、他の証明書の期限切れのお知らせなど、Let's Encryptの他のサービスのお知らせも配信停止となりますので、ご注意ください。
Regards,
The Let's Encrypt Team
Let's Encryptチーム
C++でJSONを扱わなければならなくなりました。
blog.livedoor.jp/tek_nishi/archives/10216517.html
に、
JSON for Modern C++ を紹介するよ!ブログに書いた書いたと思い込んでてまったく触れてなかった...このJSON読み書きライブラリは他のライブラリに依存しておらず、json.hppをインクルードするだけというお手軽さながら、JSONオブジェクトをめっちゃ気楽に扱えるようにしてくれます。
なん・・だと・・。インクルードするだけ・・ 採用決定!!
となりました。
で、早速、
$ git clone https://github.com/nlohmann/json.git
をして、
// g++ test_json.cpp -o test_json -I json/include/
#include <stdio.h>
#include <string.h>
#include <nlohmann/json.hpp>
#include <iostream>
int main(int argc, char **argv){
using json = nlohmann::json;
json j;
j["pi"] = 3.141;
j["happy"] = true;
j["name"] = "Niels";
j["nothing"] = nullptr;
j["answer"]["everything"] = 42;
j["list"] = { 1, 0, 2 }; // [1,0,2]
j["object"] = { {"currency", "USD"}, {"value", 42.99} }; // {"currentcy": "USD", "value": 42.99}
std::cout << j << std::endl; // cout
return 0;
}
をした後、
>g++ test_json.cpp -o test_json -I c:/Users/Ebata/json/include (git cloneが展開された場所にjson/includeというディレクトリができているので、そこをダイレクトに指示する)
を行い、./test_json を実施したら、
さくっと動きました。
では、次にこのJSONをUDP通信で飛ばしてみます。
この↑のプログラムを前提とします
■C++送信プログラム (キモは、std::string jj = j.dump(); です)
// g++ test_send_json.cpp -o test_send_json -I C:/Users/Ebata/json/include/ -lwsock32 -lws2_32 (Windows版)
#include <stdio.h>
#include <string.h>
#include <nlohmann/json.hpp>
#include <iostream>
#include "simple_udp_win.h" // https://wp.kobore.net/江端さんの技術メモ/post-1959/
//#include "simple_udp.h"
//simple_udp udp0("0.0.0.0",12345); // これはWindowでは動かない
//simple_udp udp0("192.168.0.8",12345); // これは使わない方がいい
simple_udp udp0("127.0.0.1",12345); // ホストOSのUDPの受信側
int main(int argc, char **argv){
using json = nlohmann::json;
json j;
j["pi"] = 3.141;
j["happy"] = true;
j["name"] = "Niels";
j["nothing"] = nullptr;
j["answer"]["everything"] = 42;
j["list"] = { 1, 0, 2 }; // [1,0,2]
j["object"] = { {"currency", "USD"}, {"value", 42.99} }; // {"currentcy": "USD", "value": 42.99}
std::cout << j << std::endl; // cout
std::string jj = j.dump(); // これが重要(これを見つけるのに時間がかかった)
udp0.udp_send(jj);
return 0;
}
■C++受信プログラム (キモは、json j = json::parse(rdata); です)
// g++ test_recv_json.cpp -o test_recv_json -I C:/Users/Ebata/json/include/ -lwsock32 -lws2_32
#include <stdio.h>
#include <string.h>
#include <nlohmann/json.hpp>
#include <iostream>
#include "simple_udp_win.h" // https://wp.kobore.net/江端さんの技術メモ/post-1959/
//#include "simple_udp.h"
//simple_udp udp0("0.0.0.0",12345); // これはWindowsでは動かない
//simple_udp udp0("192.168.0.8",12345); // これは使わない方がいい
simple_udp udp0("127.0.0.1",12345); // これを使うのが無難
int main(int argc, char **argv){
using json = nlohmann::json;
json j;
udp0.udp_bind();
while (1){
std::string rdata=udp0.udp_recv();
j = json::parse(rdata); // これが重要(これを見つけるのに時間がかかった)
// j = json::parse(rdata.c_str()); これでも動くようだが
std::cout << j << std::endl; // cout
}
return 0;
}
さて、そろそろ詰めに入ろうか。
■GOのJSONのUDP受信プログラム(上記の「C++送信プログラム」と対向で動くもの)
// test_recv_json.go
// go run test_recv_json.go
// golangによるjsonのudp受信"だけ"するプログラム
package main
import (
"encoding/json"
"fmt"
"net"
)
type Message struct { // とりあえず3つ
Pi float64 `json:"pi"`
Happy bool `json:"happy"`
Name string `json:"name"`
}
func main() {
addr, _ := net.ResolveUDPAddr("udp", "127.0.0.1:12345")
sock, _ := net.ListenUDP("udp", addr)
var j Message
i := 0
for {
i++
buf := make([]byte, 1024)
rlen, _, err := sock.ReadFromUDP(buf)
if err != nil {
fmt.Println(err)
}
str := string(buf[0:rlen])
fmt.Println(str)
// 受信したメッセージをJSON形式に格納する
json.Unmarshal(buf[0:rlen], &j)
// JSONに格納したデータを見る
fmt.Println(j)
fmt.Println(j.Pi)
fmt.Println(j.Happy)
fmt.Println(j.Name)
}
}
■GOのJSONのUDP送信プログラム(上記の「C++受信プログラム」と対向で動くもの)
// test_send_json.go
// go run test_send_json.go
// golangによるjsonのudp送信"だけ"するプログラム
package main
import (
"encoding/json"
"fmt"
"log"
"net"
)
type Message struct { // とりあえず3つ
Pi float64 `json:"pi"`
Happy bool `json:"happy"`
Name string `json:"name"`
}
func main() {
addr, err := net.ResolveUDPAddr("udp", "127.0.0.1:12345")
if err != nil {
log.Fatal(err)
}
conn, _ := net.DialUDP("udp", nil, addr)
if err != nil {
log.Fatal(err)
}
var j Message
j.Pi = 3.1415
j.Happy = false
j.Name = "Ebata"
s, _ := json.Marshal(j)
n, err := conn.Write(s) // WriteToUDPを使ってはならない
fmt.Printf("dial send: bytes=%d to=%s\n", n, addr.String())
}
以上
これが出ると、流石にパニックになる。
なんどリスタートしても状況が改善されないことがある。
コンピュータの再起動もやったし、
を繰り返したりした。
しかし状況が改善されない。
そして、世界には、「これ」に関する情報がほとんどない。
現状、Dockerなしでの仕事は考えられないので、かなり青ざめた。
ところが、これが意味不明に「突然直る」ことがある
ということで、私から私への提案であるが、
何か別の仕事をしながら、時々、"Restart Docker" を試してみる
を、提案する(エンジニアとしては、かなり腹立たしい対応であることは分かっているが)
焦って再インストールしたり、
https://github.com/docker/for-win/issues/7677 に記載されているような
I have made the following steps and was able to start docker successfully:
1)run "cmd" with administrator rights
2) type Regedit and enter
3)In registry editor find this folder Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE
4)inside this folder you can find "FDVDenyWriteAccess" this rule click on it choose modify and replace value data 1 with 0 , then restart docker and wait for it.
のような方法は、少なくとも1日待って、駄目だったら、試すくらいの気持ちでいよう。
合言葉は、
で、行こう。
========
続編
Docker Desktop for Windowsのメモリ管理やら、面倒なことを弄って、そして、論文やら報告書やらで、1月近く放っておいたら、全く動かなくなった。こいつは、構ってやらないと動かなくなるらしいです。
このアイコンの帆の部分が出なくなって、「docker desktop is runnning」の状態のまま続いて、もうウンともスンとも言わないらしいです。
ここのところ、Windows10を軽量化する為に、色々カルトな設定をしていたので、その中の一つが、Dockerのご機嫌を損ねた可能性があります
Hyper-V 周りがあやしい、と思って、管理者モードで立ち上げた、PowerShellから、
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
なんぞを打ち来んで、待つこと10分。
無事終って再起動したのだけど、全く改善がありません。
ずっとこんな感じ。
『再インストールするしかないのかな』と暗い気持ちになっているところに、この記事を見付けました。
要するに、
というのをやればいいらしいようです。色々失うものがありそうですが、(間違いなく、Dockerのイメージは消えるだろうが)、この際『かまわん』と腹をくくって、Windows10でのやり方を試みました。
からSetttingで、てんとうむしみたいなアイコンをクリックします。
すると、「Reset to factory defaults」というのがあるので、これを押下します。
まあ、結果的に、これでdocker for Windowsは動き出すようです(前述のHyper-Vとかも関係あるかもしれません)。
ただ、
ディスクスペースを開けるのに"docker system prune"は便利だが、濫用しないこと。docker-compose buildが再び上手く動くという保障はないぞ
みたいに、何もかも「真っ白」になるので、その覚悟はして下さい。
まあ、「Dockerを再インストールするよりはいいよね」というくらいに追い込まれた時の最後の手段として使って下さい。
========
パソコンを立ち上げ直すたびに、"Reset to factory defaults"をしないと動かないので、Dockerを再インストールしましたが、状況が改善されません。
ほとほと困っていますが、Docker Imageを毎回作り直している訳にもいきません。
で、この問題を解決する手段として、経験的に分かったことを書き下します。
(1)Docker Desktopはまともに起動するのに、PC起動後10分程度かかる(ような)気がします。
(2)もし「エントツの出てこないクジラ」のアイコンが出てきて手が打てないような状況になっていれば、[タスクマネージャ]→[詳細]→Docker Desktop.exe、その他 Dockerと名前のついているのを全部殺す。
(3)メニューから、手動で、"Docker Desktop"を起動する。
これで動き出すことがあるようです。もう、「良い悪い」といっている場合ではないので、私は、Docker desktopの自動起動のオプションを外して、手動で立ち上げることにしました。なお、手動で立ち上げても、上記の対応が必要となることがあります。
まあ、何かの拍子に直ることを期待しましょう。