Watcher conflicted in Kibana+Sentinl 6.5.4, need help

System Details
Versions

Type
Version

Kibana
6.5.4

Elasticsearch
6.5.4

Server OS
CentOS 7

Browser
Chrome

Original Install Method

[ Y ] Release pkg link
[ ] Gulp
[ ] Source
Other:

Bug Details
We are setting up 2 watchers, it works fine(we can receive the 2 alert emails) while press the "Execute" button to run the two watchers one by one. But run it automatically only one email was received.
Bug Description
Steps to Reproduce

Setup Watchers
Waiting for 1 minute for the scheduled alarm.

Expected Behavior
Sample of data you have in Elasticsearch
{
  "took" : 17,
  "timed_out" : false,
  "_shards" : {
    "total" : 141,
    "successful" : 141,
    "skipped" : 138,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 44.244545,
    "hits" : [
      {
        "_index" : "filebeat-2019.08.07",
        "_type" : "doc",
        "_id" : "tsh7aWwBW-Y8NskMssoe",
        "_score" : 44.244545,
        "_source" : {
          "@timestamp" : "2019-08-07T00:30:04.095Z",
          "fields" : {
            "app_name" : "cs-uat"
          },
          "prospector" : {
            "type" : "log"
          },
          "host" : {
            "os" : {
              "platform" : "centos",
              "version" : "7 (Core)",
              "family" : "redhat",
              "codename" : "Core"
            },
            "id" : "bcf234af050a42eb89165efa9318d654",
            "containerized" : true,
            "name" : "kvm-10-115-5-136",
            "architecture" : "x86_64"
          },
          "beat" : {
            "name" : "kvm-10-115-5-136",
            "hostname" : "kvm-10-115-5-136",
            "version" : "6.5.4"
          },
          "message" : """2019-08-07 08:30:03 [cn.com.gome.cs.web.jobs.alert.ComputeAlertJob_Worker-1] ERROR cn.com.gome.cs.web.jobs.alert.ComputeAlertJob - 计算任务执行状态汇总：	2019-08-07   状态：正常	基础数据导入任务: 已完成	负卖预处理任务: 已完成	库存销售基础数据全量预处理任务: 已完成	3c建议数计算任务: 已完成	传统区域预测计算任务: 已完成	传统建议数计算任务: 已完成	样机报表计算任务: 已完成	选品满足率任务计算任务: 运行中	""",
          "source" : "/app/service_logs/cs/error/cs-error.log",
          "offset" : 3108,
          "input" : {
            "type" : "log"
          }
        }
      }
    ]
  },
  "aggregations" : {
    "dateAgg" : {
      "buckets" : [
        {
          "key_as_string" : "2019-08-07T08:30:00.000+08:00",
          "key" :<PHONE_NUMBER>000,
          "doc_count" : 1
        }
      ]
    }
  }
}

Full Watcher JSON
watcher1:
{
  "actions": {
    "email_html_alarm_2637e8e2-26b9-418d-9046-f1e5b0a21ea2": {
      "name": "计算任务完成",
      "throttle_period": "1m",
      "email_html": {
        "stateless": false,
        "subject": "计算任务执行完成",
        "priority": "high",
        "html": "
当前时间：{{payload.currentDatetime}}

{{payload.title}}

{{payload.alarmStatus}}

{{#payload.messages}}
{{.}}
{{/payload.messages}}

",
        "to"<EMAIL_ADDRESS>        "from"<EMAIL_ADDRESS>      }
    }
  },
  "input": {
    "search": {
      "request": {
        "index": [
          "filebeat*"
        ],
        "body": {
          "query": {
            "bool": {
              "must": [
                {
                  "range": {
                    "@timestamp": {
                      "gte": "now-360000m/m",
                      "lte": "now/m",
                      "format": "epoch_millis"
                    }
                  }
                },
                {
                  "match_phrase": {
                    "fields.app_name": {
                      "query": "cs-uat"
                    }
                  }
                },
                {
                  "match_phrase": {
                    "source": {
                      "query": "/app/service_logs/cs/info/cs-info.log"
                    }
                  }
                },
                {
                  "match_phrase": {
                    "message": {
                      "query": "?计算任务执行状态汇总?"
                    }
                  }
                }
              ]
            }
          },
          "size": 500,
          "aggs": {
            "dateAgg": {
              "date_histogram": {
                "field": "@timestamp",
                "time_zone": "Asia/Shanghai",
                "interval": "1m",
                "min_doc_count": 1
              }
            }
          }
        }
      }
    }
  },
  "condition": {
    "script": {
      "script": "payload.hits.total > 0"
    }
  },
  "transform": {
    "script": {
      "script": "var reg = /[1-9]\\d{3}-(0[1-9]|1[0-2])-(0[1-9]|[1-2][0-9]|3[0-1])\\s+(20|21|22|23|[0-1]\\d):[0-5]\\d:[0-5]\\d/; payload.currentDatetime = reg.exec(payload.hits.hits[0]._source.message)[0]; var msgRegExp = new RegExp('ComputeAlertJob - ', 'g'); msgRegExp.test(payload.hits.hits[0]._source.message); var messages = payload.hits.hits[0]._source.message.trim().substr(msgRegExp.lastIndex).split('\t'); payload.title=messages[0]; payload.alarmStatus=messages[1]; payload.messages=messages.slice(2);"
    }
  },
  "trigger": {
    "schedule": {
      "later": "every 1 minutes"
    }
  },
  "disable": false,
  "report": false,
  "title": "计算任务执行完成",
  "save_payload": false,
  "spy": false,
  "impersonate": false
}

watcher2:
{
  "actions": {
    "email_html_alarm_2637e8e2-26b9-418d-9046-f1e5b0a21ea2": {
      "name": "计算任务完成",
      "throttle_period": "1m",
      "email_html": {
        "stateless": false,
        "subject": "计算任务执行完成",
        "priority": "high",
        "html": "
当前时间：{{payload.currentDatetime}}

{{payload.title}}

{{payload.alarmStatus}}

{{#payload.messages}}
{{.}}
{{/payload.messages}}

",
        "to"<EMAIL_ADDRESS>        "from"<EMAIL_ADDRESS>      }
    }
  },
  "input": {
    "search": {
      "request": {
        "index": [
          "filebeat*"
        ],
        "body": {
          "query": {
            "bool": {
              "must": [
                {
                  "range": {
                    "@timestamp": {
                      "gte": "now-360000m/m",
                      "lte": "now/m",
                      "format": "epoch_millis"
                    }
                  }
                },
                {
                  "match_phrase": {
                    "fields.app_name": {
                      "query": "cs-uat"
                    }
                  }
                },
                {
                  "match_phrase": {
                    "source": {
                      "query": "/app/service_logs/cs/info/cs-info.log"
                    }
                  }
                },
                {
                  "match_phrase": {
                    "message": {
                      "query": "?计算任务执行状态汇总?"
                    }
                  }
                }
              ]
            }
          },
          "size": 500,
          "aggs": {
            "dateAgg": {
              "date_histogram": {
                "field": "@timestamp",
                "time_zone": "Asia/Shanghai",
                "interval": "1m",
                "min_doc_count": 1
              }
            }
          }
        }
      }
    }
  },
  "condition": {
    "script": {
      "script": "payload.hits.total > 0"
    }
  },
  "transform": {
    "script": {
      "script": "var reg = /[1-9]\\d{3}-(0[1-9]|1[0-2])-(0[1-9]|[1-2][0-9]|3[0-1])\\s+(20|21|22|23|[0-1]\\d):[0-5]\\d:[0-5]\\d/; payload.currentDatetime = reg.exec(payload.hits.hits[0]._source.message)[0]; var msgRegExp = new RegExp('ComputeAlertJob - ', 'g'); msgRegExp.test(payload.hits.hits[0]._source.message); var messages = payload.hits.hits[0]._source.message.trim().substr(msgRegExp.lastIndex).split('\t'); payload.title=messages[0]; payload.alarmStatus=messages[1]; payload.messages=messages.slice(2);"
    }
  },
  "trigger": {
    "schedule": {
      "later": "every 1 minutes"
    }
  },
  "disable": false,
  "report": false,
  "title": "计算任务执行完成",
  "save_payload": false,
  "spy": false,
  "impersonate": false
}

Screenshots (if relevant)
Errors in Browser Console (if relevant)
action Throttled for 1m

Kibana logs and/or server output (attached if relevant)
{"type":"log","@timestamp":"2019-08-07T12:28:54Z","tags":["plugin","debug"],"pid":146118,"message":"Checking Elasticsearch version"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"cluster disabled"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"reloading watchers..."}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","get_elasticsearch_client"],"pid":146118,"message":"auth via Kibana server elasticsearch plugin"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","get_elasticsearch_client"],"pid":146118,"message":"auth via Kibana server elasticsearch plugin"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","get_elasticsearch_client"],"pid":146118,"message":"auth via Kibana server elasticsearch plugin"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"deleting orphan watchers: 492c8930-a482-11e9-afa9-bbef3681f19d"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"deleting orphan watchers: sentinl-watcher"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"scheduled watcher 492c8930-a482-11e9-afa9-bbef3681f19d, to run every every 2 minutes"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"scheduled watcher sentinl-watcher, to run every every 1 minutes"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"clearing watcher sentinl-watcher"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"scheduled watcher sentinl-watcher, to run every every 1 minutes"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"clearing watcher sentinl-watcher"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"scheduled watcher sentinl-watcher, to run every every 1 minutes"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"clearing watcher sentinl-watcher"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"scheduled watcher sentinl-watcher, to run every every 1 minutes"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"clearing watcher sentinl-watcher"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"scheduled watcher sentinl-watcher, to run every every 1 minutes"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"clearing watcher sentinl-watcher"}
{"type":"log","@timestamp":"2019-08-07T12:28:55Z","tags":["debug","Sentinl","scheduler"],"pid":146118,"message":"scheduled watcher sentinl-watcher, to run every every 1 minutes"}
{"type":"log","@timestamp":"2019-08-07T12:28:57Z","tags":["plugin","debug"],"pid":146118,"message":"Checking Elasticsearch version"}
{"type":"log","@timestamp":"2019-08-07T12:28:58Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"\"getConnections\" has been called."}
{"type":"ops","@timestamp":"2019-08-07T12:28:58Z","tags":[],"pid":146118,"os":{"load":[0.0029296875,0.02294921875,0.04541015625],"mem":{"total":16658313216,"free":1369247744},"uptime":5377695},"proc":{"uptime":584.166,"mem":{"rss":344215552,"heapTotal":246517760,"heapUsed":226617376,"external":1893020},"delay":1.323716163635254},"load":{"requests":{"5601":{"total":0,"disconnects":0,"statusCodes":{}}},"concurrents":{"5601":1},"responseTimes":{"5601":{"avg":null,"max":0}},"sockets":{"http":{"total":0},"https":{"total":0}}},"message":"memory: 216.1MB uptime: 0:09:44 load: [0.00 0.02 0.05] delay: 1.324"}
{"type":"log","@timestamp":"2019-08-07T12:28:58Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Received Kibana Ops event data"}
{"type":"log","@timestamp":"2019-08-07T12:28:58Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Received Kibana Ops event data"}
{"type":"log","@timestamp":"2019-08-07T12:28:59Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"Event is being forwarded: connection"}
{"type":"log","@timestamp":"2019-08-07T12:28:59Z","tags":["trace","legacy","service"],"pid":146118,"message":"Request will be handled by proxy GET:/s/ipc/api/sentinl/time."}
{"type":"response","@timestamp":"2019-08-07T12:28:59Z","tags":[],"pid":146118,"method":"get","statusCode":200,"req":{"url":"/api/sentinl/time","method":"get","headers":{"host":"<IP_ADDRESS>:5601","connection":"keep-alive","accept":"application/json, text/plain, */*","kbn-version":"6.5.4","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl","accept-encoding":"gzip, deflate","accept-language":"zh-CN,zh;q=0.9"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl"},"res":{"statusCode":200,"responseTime":3,"contentLength":9},"message":"GET /api/sentinl/time 200 3ms - 9.0B"}
{"type":"log","@timestamp":"2019-08-07T12:28:59Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"Event is being forwarded: connection"}
{"type":"log","@timestamp":"2019-08-07T12:28:59Z","tags":["trace","legacy","service"],"pid":146118,"message":"Request will be handled by proxy POST:/s/ipc/api/sentinl/list/watchers."}
{"type":"response","@timestamp":"2019-08-07T12:28:59Z","tags":[],"pid":146118,"method":"post","statusCode":200,"req":{"url":"/api/sentinl/list/watchers","method":"post","headers":{"host":"<IP_ADDRESS>:5601","connection":"keep-alive","content-length":"0","accept":"application/json, text/plain, */*","origin":"http://<IP_ADDRESS>:5601","kbn-version":"6.5.4","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl","accept-encoding":"gzip, deflate","accept-language":"zh-CN,zh;q=0.9"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl"},"res":{"statusCode":200,"responseTime":11,"contentLength":9},"message":"POST /api/sentinl/list/watchers 200 11ms - 9.0B"}
{"type":"log","@timestamp":"2019-08-07T12:28:59Z","tags":["plugin","debug"],"pid":146118,"message":"Checking Elasticsearch version"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["info","Sentinl","scheduler"],"pid":146118,"message":"watcher sentinl-watcher: executing"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["info","Sentinl","watcher sentinl-watcher"],"pid":146118,"message":"executing"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["warning","Sentinl","watcher sentinl-watcher"],"pid":146118,"message":"Siren federate: \"elasticsearch.plugins\" is not available when running from kibana: Error: Unknown config key: investigate_core.clusterplugins"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["debug","Sentinl","watcher sentinl-watcher"],"pid":146118,"message":"condition: {\n  \"script\": {\n    \"script\": \"payload.hits.total > 0\"\n  }\n}"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"Event is being forwarded: connection"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["info","Sentinl","watcher sentinl-watcher"],"pid":146118,"message":"successfully applied condition"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["debug","Sentinl","watcher sentinl-watcher"],"pid":146118,"message":"transform: {\n  \"script\": {\n    \"script\": \"var reg = /[1-9]\\\\d{3}-(0[1-9]|1[0-2])-(0[1-9]|[1-2][0-9]|3[0-1])\\\\s+(20|21|22|23|[0-1]\\\\d):[0-5]\\\\d:[0-5]\\\\d/; payload.currentDatetime = reg.exec(payload.hits.hits[0]._source.message)[0]; var msgRegExp = new RegExp('ComputeAlertJob - ', 'g'); msgRegExp.test(payload.hits.hits[0]._source.message); var messages = payload.hits.hits[0]._source.message.trim().substr(msgRegExp.lastIndex).split('\\t'); payload.title=messages[0]; payload.alarmStatus=messages[1]; payload.messages=messages.slice(2);\"\n  }\n}"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["info","Sentinl","watcher sentinl-watcher"],"pid":146118,"message":"successfully applied transform"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["debug","Sentinl","get_elasticsearch_client"],"pid":146118,"message":"auth via Kibana server elasticsearch plugin"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["debug","Sentinl"],"pid":146118,"message":"processing action"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["info","Sentinl","watcher sentinl-watcher"],"pid":146118,"message":"successfuly executed"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["trace","legacy","service"],"pid":146118,"message":"Request will be handled by proxy GET:/s/ipc/api/sentinl/time."}
{"type":"response","@timestamp":"2019-08-07T12:29:00Z","tags":[],"pid":146118,"method":"get","statusCode":200,"req":{"url":"/api/sentinl/time","method":"get","headers":{"host":"<IP_ADDRESS>:5601","connection":"keep-alive","accept":"application/json, text/plain, */*","kbn-version":"6.5.4","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl","accept-encoding":"gzip, deflate","accept-language":"zh-CN,zh;q=0.9"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl"},"res":{"statusCode":200,"responseTime":3,"contentLength":9},"message":"GET /api/sentinl/time 200 3ms - 9.0B"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["info","Sentinl"],"pid":146118,"message":"processing html email"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"Event is being forwarded: connection"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["trace","legacy","service"],"pid":146118,"message":"Request will be handled by proxy GET:/s/ipc/api/sentinl/set/interval/%7B%22from%22:%22now-15m%22,%22to%22:%22now%22,%22mode%22:%22quick%22%7D."}
{"type":"response","@timestamp":"2019-08-07T12:29:00Z","tags":[],"pid":146118,"method":"get","statusCode":200,"req":{"url":"/api/sentinl/set/interval/%7B%22from%22:%22now-15m%22,%22to%22:%22now%22,%22mode%22:%22quick%22%7D","method":"get","headers":{"host":"<IP_ADDRESS>:5601","connection":"keep-alive","accept":"application/json, text/plain, */*","kbn-version":"6.5.4","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl","accept-encoding":"gzip, deflate","accept-language":"zh-CN,zh;q=0.9"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl"},"res":{"statusCode":200,"responseTime":2,"contentLength":9},"message":"GET /api/sentinl/set/interval/%7B%22from%22:%22now-15m%22,%22to%22:%22now%22,%22mode%22:%22quick%22%7D 200 2ms - 9.0B"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"Event is being forwarded: connection"}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["trace","legacy","service"],"pid":146118,"message":"Request will be handled by proxy POST:/s/ipc/api/sentinl/list/alarms."}
{"type":"log","@timestamp":"2019-08-07T12:29:00Z","tags":["debug","Sentinl","get_elasticsearch_client"],"pid":146118,"message":"auth via Kibana server elasticsearch plugin"}
{"type":"response","@timestamp":"2019-08-07T12:29:00Z","tags":[],"pid":146118,"method":"post","statusCode":200,"req":{"url":"/api/sentinl/list/alarms","method":"post","headers":{"host":"<IP_ADDRESS>:5601","connection":"keep-alive","content-length":"0","accept":"application/json, text/plain, */*","origin":"http://<IP_ADDRESS>:5601","kbn-version":"6.5.4","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl","accept-encoding":"gzip, deflate","accept-language":"zh-CN,zh;q=0.9"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:5601/s/ipc/app/sentinl"},"res":{"statusCode":200,"responseTime":11,"contentLength":9},"message":"POST /api/sentinl/list/alarms 200 11ms - 9.0B"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from kql collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from rollups collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from kibana_stats collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from kibana collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from kibana_settings collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from spaces collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from canvas collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from infraops collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from reporting collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","stats-collection"],"pid":146118,"message":"not sending [kibana_settings] monitoring document because [undefined] is null or invalid."}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Uploading bulk stats payload to the local cluster"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["license","debug","xpack"],"pid":146118,"message":"Calling [data] Elasticsearch _xpack API. Polling frequency: 30001"}
{"type":"log","@timestamp":"2019-08-07T12:29:01Z","tags":["license","debug","xpack"],"pid":146118,"message":"Calling [monitoring] Elasticsearch _xpack API. Polling frequency: 30001"}
{"type":"log","@timestamp":"2019-08-07T12:29:02Z","tags":["plugin","debug"],"pid":146118,"message":"Checking Elasticsearch version"}
{"type":"log","@timestamp":"2019-08-07T12:29:03Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"\"getConnections\" has been called."}
{"type":"ops","@timestamp":"2019-08-07T12:29:03Z","tags":[],"pid":146118,"os":{"load":[0.0029296875,0.0224609375,0.04541015625],"mem":{"total":16658313216,"free":1367941120},"uptime":5377700},"proc":{"uptime":589.168,"mem":{"rss":344936448,"heapTotal":247566336,"heapUsed":227280472,"external":1911732},"delay":1.6519355773925781},"load":{"requests":{"5601":{"total":5,"disconnects":0,"statusCodes":{"200":5}}},"concurrents":{"5601":1},"responseTimes":{"5601":{"avg":5.8,"max":11}},"sockets":{"http":{"total":0},"https":{"total":0}}},"message":"memory: 216.8MB uptime: 0:09:49 load: [0.00 0.02 0.05] delay: 1.652"}
{"type":"log","@timestamp":"2019-08-07T12:29:03Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Received Kibana Ops event data"}
{"type":"log","@timestamp":"2019-08-07T12:29:03Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Received Kibana Ops event data"}
{"type":"log","@timestamp":"2019-08-07T12:29:04Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"Event is being forwarded: connection"}
{"type":"log","@timestamp":"2019-08-07T12:29:05Z","tags":["plugin","debug"],"pid":146118,"message":"Checking Elasticsearch version"}
{"type":"log","@timestamp":"2019-08-07T12:29:07Z","tags":["plugin","debug"],"pid":146118,"message":"Checking Elasticsearch version"}
{"type":"log","@timestamp":"2019-08-07T12:29:08Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"\"getConnections\" has been called."}
{"type":"ops","@timestamp":"2019-08-07T12:29:08Z","tags":[],"pid":146118,"os":{"load":[0.0029296875,0.02197265625,0.04541015625],"mem":{"total":16658313216,"free":1368166400},"uptime":5377705},"proc":{"uptime":594.171,"mem":{"rss":345104384,"heapTotal":247566336,"heapUsed":227407016,"external":1909701},"delay":2.009134292602539},"load":{"requests":{"5601":{"total":0,"disconnects":0,"statusCodes":{}}},"concurrents":{"5601":1},"responseTimes":{"5601":{"avg":null,"max":0}},"sockets":{"http":{"total":0},"https":{"total":0}}},"message":"memory: 216.9MB uptime: 0:09:54 load: [0.00 0.02 0.05] delay: 2.009"}
{"type":"log","@timestamp":"2019-08-07T12:29:08Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Received Kibana Ops event data"}
{"type":"log","@timestamp":"2019-08-07T12:29:08Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Received Kibana Ops event data"}
{"type":"log","@timestamp":"2019-08-07T12:29:10Z","tags":["plugin","debug"],"pid":146118,"message":"Checking Elasticsearch version"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from kql collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from rollups collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from kibana_stats collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from kibana collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from kibana_settings collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from spaces collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from canvas collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from infraops collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"Fetching data from reporting collector"}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","stats-collection"],"pid":146118,"message":"not sending [kibana_settings] monitoring document because [undefined] is null or invalid."}
{"type":"log","@timestamp":"2019-08-07T12:29:11Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Uploading bulk stats payload to the local cluster"}
{"type":"log","@timestamp":"2019-08-07T12:29:12Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"Event is being forwarded: connection"}
{"type":"log","@timestamp":"2019-08-07T12:29:12Z","tags":["plugin","debug"],"pid":146118,"message":"Checking Elasticsearch version"}
{"type":"log","@timestamp":"2019-08-07T12:29:13Z","tags":["debug","legacy","proxy"],"pid":146118,"message":"\"getConnections\" has been called."}
{"type":"ops","@timestamp":"2019-08-07T12:29:13Z","tags":[],"pid":146118,"os":{"load":[0.0029296875,0.021484375,0.04541015625],"mem":{"total":16658313216,"free":1367244800},"uptime":5377710},"proc":{"uptime":599.173,"mem":{"rss":345088000,"heapTotal":247566336,"heapUsed":227515776,"external":1917722},"delay":1.5739517211914062},"load":{"requests":{"5601":{"total":0,"disconnects":0,"statusCodes":{}}},"concurrents":{"5601":2},"responseTimes":{"5601":{"avg":null,"max":0}},"sockets":{"http":{"total":0},"https":{"total":0}}},"message":"memory: 217.0MB uptime: 0:09:59 load: [0.00 0.02 0.05] delay: 1.574"}
{"type":"log","@timestamp":"2019-08-07T12:29:13Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Received Kibana Ops event data"}
{"type":"log","@timestamp":"2019-08-07T12:29:13Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":146118,"message":"Received Kibana Ops event data"}
{"type":"log","@timestamp":"2019-08-07T12:29:15Z","tags":["plugin","debug"],"pid":146118,"message":"Checking Elasticsearch version"}

Any additional information

Your actions is being throttled. Are your two actions parallel?
action Throttled for 1m

Try set this to 1s to see if it makes a difference.

After set throttle_period to 1s, it works for ONLY the 1st trigger.  Are you saying this issue is because of we are setting the same query body?

Yes I am using  two actions in parallel.

@lmangani
Yes I am using two actions in parallel.
After set throttle_period to 1s, it works for ONLY the 1st trigger. Are you saying this issue is because of we are setting the same query body?
Could you please help to advise the fix ? Thanks.

@lmangani We found this issue happens only when create watchers in custom spaces other than default, looks similar to issue #735 . @lmangani


Ingredient Search component

I'm not including screenshots this time, please play around on the Home page! The "Search" button is functional insomuch that it will request data from Spoonacular and go to the "search" page with that data. If you want to test that part, check out lines 24-26 in routes > home.jsx:
.then((data) => {
        navigate("/search", { state: { recipes: data } })
      })

you can console.log the returned data and view your browser's developer tools to see the returned data. By default, spoonacular returns the first 10 recipes with matching criteria.

maybe background of options match logo?


Default Alignment of Locals, Globals and Statics

Update ARM64 ABI documentation with default layout alignment done by Microsoft VC++ for locals, globals and statics based on their size.

@prjoseph : Thanks for your contribution! The author, @, has been notified to review your proposed change.

@corob-msft : Thanks for your contribution! The author, @, has been notified to review your proposed change.


B-19975-KB-INT

Agility ticket
Original INT PR
Summary
Small UI change requested
How to test

As a customer with an approved PPM, create trip, set, and expense documents. Take a screen shot or notate the values. Submit.
As a closeout counselor, view the move and review the documents. Alter different amounts of stuff and approve/exclude (do not reject, as this will send the shipment back to the PPM Document submission stage) and confirm review is complete when you reach the end.
As a customer, view your move and confirm you can now see a "View Closeout Feedback" button. Click that and find yourself at the Feedback review page. Compare the values/adjusted values to the values you input. Check that it works as AC requests, that it accurately reflects the white paper, and try and break it.
Confirm that the total amounts next to the header are no longer displayed in parens and instead displayed like this

Warnings

:warning:
This PR does not include changes to unit tests, even though it affects app code.

  Generated by :no_entry_sign: dangerJS against 9f6af3de83004954496fa1187c35c70e0d085e7e

Actually just noticed the Happo errors. do we maybe not need the '-' could that be the issue?

Nevermind, I see what the dash is for now.  not sure why the last 2 Happo issues are popping up though, that's strange.


gpl: slowdown when activating multi-threading

Description
This issue was discovered while addressing non-determinism with GPL when multi-threading was activated (https://github.com/The-OpenROAD-Project/OpenROAD/issues/5360).
I tested the GPL runtime using secure-CI (multiple designs) and locally via a GCP server with Nangate45/Swerv. The tests indicate that activating multi-threading results in the same runtime or, in some cases, even slows down GPL.
I believe the slowdown is due to too many context switches with minimal gain in parallelism, as the loops that use multi-threading typically perform simple mathematical operations.

It was mentioned that the OMP parallel loops inserted in GPL were implemented by Antmicro developers, who claimed they improved runtime. TODO: Investigate the code added using GitHub blame; are there any runtime reports available?
Investigate which loops are causing the slowdown. Measure runtime.

Suggested Solution
No response
Additional Context
No response

I suggest you look at the PR as they often include data there.  There may have been multiple changes.

This is the PR: https://github.com/The-OpenROAD-Project/OpenROAD/pull/4580.
Hi @kbieganski, do you still see improvements in runtime for gpl with MT?

It could be the case that the MT only helps on larger designs, and is a net negative on designs below a certain size threshold.

I haven't observed a slowdown caused by multi-threading on 3_3_place_gp in ORFS:
ibex

Threads
Min [s]
Max [s]
Median [s]
Relative median

1
49.90
51.29
51.05
1.04

8
48.06
49.41
48.88
1.00

ariane133

Threads
Min [s]
Max [s]
Median [s]
Relative median

1
930.71
940.08
935.91
1.29

8
719.30
727.28
725.57
1.00

black_parrot

Threads
Min [s]
Max [s]
Median [s]
Relative median

1
1417.57
1432.21
1424.02
1.25

8
1134.33
1146.48
1139.92
1.00

This is on a version of OpenROAD from June.

I believe the slowdown is due to too many context switches

If you're observing too many context switches, perhaps you're running more threads than physical cores? Set your -threads (NUM_CORES in ORFS) to the number of physical cores you have. By default it uses nproc which, unfortunately, reports the logical cores.


fix: cache snapshot & add option deps

fix #22
Adding the deps option is to allow users to manually control whether to detect changes in the keys (references), saving the trouble of using useMemo. This might be a better default behavior, but it could introduce a breaking change.

Thanks. Release in 0.8.0


AppWindow Presenter related samples

Issue type
sample request
Which version of the app?
WinUI 3 Gallery
Description
I found different behaviors of OverlappedPresenter between Windows 10 and 11. I would like to see a complete sample about different settings on those.
Something like creating a new window (just like the current acrylic/mica window sample), with default presenter parameters in it. Adjusting those parameters would change the properties of the AppWindow.Presenter that it is currently on, like IsMaximizable, IsMinimizable, IsModal etc.  I saw swapping Presenter is also supported, maybe add a comboBox for that as well.
Related issue: #1551
I would like to contribute if this is a good idea
Screenshots
No response
Windows version
No response
Additional context
No response

Great idea, would this be part of multiple windows page?

It's better as a standalone page, I think. It's more about AppWindow and AppWindowPresenter api.


newer picard versions have "too many file open" issues with demultiplexing

ran into a problem when converting into unmapped bam files. need to investigate eventually, but for now will have to create a container using picard version that brian was using.
https://github.com/broadinstitute/picard/issues/1714

also old versions of picard are not immune to having too many file handles open (hence why i had to use SORT=false)


Question - getting error with angular2-esri-loader with when trying to use js.arcgis.com/3.20/

I created a cli Angular4 app, i followed the 'How to use angular2-esri-loader in an angular-cli application' instructions. It works fine when i run it with esri 4.x version but when i try to switch to 3.x i get a 404 Not Found error when retrieving 'http://js.arcgis.com/3.20/esri/views/MapView.js.' I can tell that the file doesn't exist, my question is do i need to make additional changes to get the esri loader to work with the esri 3.x version?

The API at v4 is different in several ways from v3. There isn't any concept of a "MapView" in v3. Please see:
https://developers.arcgis.com/javascript/latest/guide/migrating/index.html#views
and also the quick start code for v3:
https://developers.arcgis.com/javascript/3/

I realized the MapView and other differences as soon as i posted the question. Got it working, thank you!


DefaultMatchStrategy does not exist

Unfortunately there's no DefaultMatchStrategy module nowhere in the repo.

Hey @kanes115 ! Sorry about that... it is a typo/wrong module in the docs...
THe correct one is this: https://hexdocs.pm/joken_jwks/JokenJwks.DefaultStrategyTemplate.html#content
I have to update the docs there. Thanks for pointing out

Yes, I know it's a docs issue :) Thanks

Fixed on 1.4.0.
Thanks once again for pointing it out @kanes115


Add support for SortedSet

Add support for SortedSet in ListArrayType.
Ideally it would pull comparator info from annotations, but I'm not sure how to get that from within the TypeDescriptor.

Thanks, I merged it.

@vladmihalcea Is it possible to pull annotations from within the TypeDescriptor?

@markwoon Check out the setParameterValues from JsonJavaTypeDescriptor .


Upgrade to v4.36.1

Fixes #2189
Fixes #2186
Upstream diff: https://github.com/pulumi/terraform-provider-aws/compare/upstream-v4.35.0...upstream-v4.36.1

Resource "aws:simpledb/domain:Domain" missing
Function "aws:index/getCallerIdentity:getCallerIdentity" missing
Function "aws:globalaccelerator/getAccelerator:getAccelerator" missing
Type "aws:globalaccelerator/getAcceleratorIpSet:getAcceleratorIpSet" missing
Type "aws:globalaccelerator/getAcceleratorAttribute:getAcceleratorAttribute" missing

@danielrbradley , did you look into these missing entities, particularly the resource? Seems like they're still present in your PR?

Is this expected? I would have expected a much smaller footprint of commits in the diff link you mentioned?

@viveklak the nubmer of commits is fine - it's just a side-effect of how long ago we did the fork
@thomas11 I think the removals need investigating for sure. Wouldn't be too worried about the examples, but worth sanity checking if that was from a source change

Resource "aws:simpledb/domain:Domain"

Appears to have been moved to the new framework - we'll need to revert. This has been removed on line 2080 of internal/provider/provider.go

Function "aws:index/getCallerIdentity:getCallerIdentity"

This has been removed on line 914 of internal/provider/provider.go

Function "aws:globalaccelerator/getAccelerator:getAccelerator"

I had to revert changes here - it's possible that there was also a reference to it that was removed - aws_globalaccelerator_accelerator on line 668 of internal/provider/provider.go

Type "aws:globalaccelerator/getAcceleratorIpSet:getAcceleratorIpSet" missing
Type "aws:globalaccelerator/getAcceleratorAttribute:getAcceleratorAttribute" missing

These are most likely just knock-on changes from the resources/data sources which I'd hope get resolved when the above get fixed.

@thomas11 I'm hopeful this will sort us out. It looks like the docs are back - probably were removed because they used aws.getCallerIdentity which was missing, so it skipped the docs generation.


Add multi-select context menu to experiments webview

Now that we have a context menu available in the experiments webview we need to extend it to handle actions on multiple selected rows:

More details and flows in the Figma spec and probably in https://github.com/iterative/vscode-dvc/issues/1562.
The only action that I can think of that is applicable to a list of selected experiments is "remove" but I could be wrong.

@maxagin @shcheklein  @mattseddon The context menu is disabled when any experiment is running.
Should the row selection be disabled as well?

@maxagin
https://user-images.githubusercontent.com/1231848/173673046-6440ca24-c01f-4d34-b51c-95aefb88224f.mov

Great work @wolmir  ! Tiny comment: When you add the select style you may consider not using the border (top/bottom) at all, as they are moving the other rows :) - unwanted movement.

I think that if the exp is running I still want to be able to remove it, but just to remove it. WDYT?

Discussed on the weekly planning call:

Logic in the table should replicate logic shown in the tree (see collectDeletable).
Can stop a running experiment which is equivalent to deleting it.

We have a multi-select context menu now.


Autorepeating test sets and other niceties from testing research?

Dear Ian and the team working on updates to Julia's support for testing. I just found out about these new features but must say things look great. Me and some of my research colleagues have been working on a new package for better test automation in Julia and was about to update that for Julia 0.4 before releasing it into the wild. However, when seeing the many changes you are working on it is tempting to rather try to fit in with what is coming in the future. :) So I hope you'd be willing to consider some ideas, proposals and maybe even code from us at some point.
I need to look more closely into the new base/test.jl implementation in 0.5 but it seems to me that a few, fairly small changes might make for a very powerful testing framework. The main thing I have in mind is to add a shouldrepeat method (or some better/shorter name) to the AbstractTestSet interface which would allow it to decide if tests should run another time before continuing (to the next testset or to the parent). Possibly also a start method which is called before starting to run the tests, but maybe a special version of the record method could be used also for this. I guess even the indication to run again could be given to the testset code if it returned something of a certain type if you really do not want to add more methods.
The idea behind this is that it would allow for adaptive decision on whether more testing is needed. In auto-testing with generated test data this would be very handy as one can use a sequential statistical test (!) to decide if enough evidence has been amassed to test a property of some stochastic/non-deterministic code etc. When combining this with our (award-winning! :) ) test data generation framework:
http://www.robertfeldt.net/publications/feldt_2013_godeltest.html
this would allow for very powerful forms of testing (property-based testing, Quickcheck style, for example).
An alternative way to accomplish this might be if the custom test set could be somehow referenced in the loop args in a testset loop. I guess it should be possible using the existing get_testset() but from looking at the code it seems the test set is generated inside the loop body so could not be used in the loop args, right? Also the code might not look very clean even if this could be achieved.
Sorry for this very long and long-winding issue post but wanted to get some indication of the general interest in getting Pull Requests to make the future Base.Test more powerful before we start thinking about how to merge/move over some of our testing code. We also have some code for producing more detailed failure messages to help pinpoint where the root cause might lie when executing a test as well as specific test macros that take decisions based on multiple runs of a testset but this might be taking things too far. But please give some indication of the willingness to extend the basic test interfacing and code; if we can find a few minimal changes that might increase power many times I think it would be worth it. Thanks for any response feedback you might have.

Here is some example code showing some minimal changes to allow looping control from inside the custom test set. This was a quick'n'dirty to give a flavor of usefulness, in practice it should have much more refined logic to decide if to continue testing:
https://github.com/robertfeldt/BaseTestNext.jl/commit/243ea5f78e698ec685ee04a3ee4d39c4f831c917

The example is now a bit better since it shows an example of finding a "rare", seeded bug with property-based testing and a (random) test data generator:
https://github.com/robertfeldt/BaseTestNext.jl/commit/971cb9a1c1ec0616bcfbd5137c5f604a1f9d40c9

Hi @robertfeldt,
This would be better at Julia's main repository. After this was merged into Base, this repo just serves as a "mirror" so people can use it on Julia 0.4.

I'd also so,

So I hope you'd be willing to consider some ideas, proposals and maybe even code from us at some point.
I think people would be willing to consider code first, and ideas last. So if you start with some code showing some of your ideas (e.g. as a proof-of-concept PR), that'd be best.

I did link to some concrete code and I selected this package since I thought it would be harder to get things into the main repo but ok, I'll press on and try to adapt some of our test tools to base/test.jl then. I guess my fear is that the code is likely to grow so maybe people would rather prefer it being its own package rather than go into base.

Maybe people would prefer it in a package, hard to say. Changing the Base.Test to be more customizable though would probably go through fine. All I meant was that if you want people to see it, you should post it at JuliaLang/julia, only I'm really looking at this repo and I'm not doing any more work on testing for the forseeable future.

and that this code just mirrors Base, so we aren't adding code here that isn't in Base.

Ok, I did a RFC PR:
https://github.com/JuliaLang/julia/pull/14971/files
Comments appreciated.


[Event Request] Codeunit 80 Sales Post - procedure CheckPostWhseShptLines - OnBeforePostWhseShptLines

Please add the following Event OnBeforePostWhseShptLines to Procedure  CheckPostWhseShptLines in Codeunit 80 Sales Post:
Original code:
    local procedure CheckPostWhseShptLines(var SalesShptLine: Record "Sales Shipment Line"; var SalesLine: Record "Sales Line")
    var
        WhseShptLine: Record "Warehouse Shipment Line";
        IsHandled: Boolean;
    begin
        IsHandled := false;
        OnBeforeCheckPostWhseShptLines(SalesShptLine, SalesLine, IsHandled, WhseShptHeader, WhseRcptHeader, WhseShip, WhseReceive);
        if IsHandled then
            exit;

        if WhseShip then
            if WhseShptLine.GetWhseShptLine(
                 WhseShptHeader."No.", DATABASE::"Sales Line", SalesLine."Document Type".AsInteger(), SalesLine."Document No.", SalesLine."Line No.")
            then
                PostWhseShptLines(WhseShptLine, SalesShptLine, SalesLine);
    end;

New code:
    local procedure CheckPostWhseShptLines(var SalesShptLine: Record "Sales Shipment Line"; var SalesLine: Record "Sales Line")
    var
        WhseShptLine: Record "Warehouse Shipment Line";
        IsHandled: Boolean;
        // START NEW CODE
        WhseShptLinesFound: Boolean;
        // END NEW CODE
    begin
        IsHandled := false;
        OnBeforeCheckPostWhseShptLines(SalesShptLine, SalesLine, IsHandled, WhseShptHeader, WhseRcptHeader, WhseShip, WhseReceive);
        if IsHandled then
            exit;

        // START MODIFIED CODE
        if WhseShip then begin
            WhseShptLinesFound := WhseShptLine.GetWhseShptLine(
                 WhseShptHeader."No.", DATABASE::"Sales Line", SalesLine."Document Type".AsInteger(), SalesLine."Document No.", SalesLine."Line No.")
            OnBeforePostWhseShptLines(SalesShptLine, SalesLine, WhseShptLinesFound, WhseShptHeader, WhseRcptHeader, WhseShip, WhseReceive);
            if WhseShptLinesFound then
                PostWhseShptLines(WhseShptLine, SalesShptLine, SalesLine);
         end;
       // END MODIFIED CODE
    end;

    [IntegrationEvent(false, false)]
    local procedure OnBeforePostWhseShptLines(var SalesShptLine: Record "Sales Shipment Line"; var SalesLine: Record "Sales Line"; var WhseShptLinesFound: Boolean; WhseShptHeader: Record "Warehouse Shipment Header"; WhseRcptHeader: Record "Warehouse Receipt Header"; WhseShip: Boolean; WhseReceive: Boolean)
    begin
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 11007.


Taks Runner Manager / Gulpfile with latest version of node.js and VS 15.8.5 did not work.

I got it working after adding tasks.json and replacing current version of node.js loading older version of node following the advice found at:
https://developercommunity.visualstudio.com/content/problem/312584/update-158-broke-task-runner-gulpfile.html
It wasn't an easy find.
Do you have a plan to fix this? It seems pointless to suggest to use gulp if Task Runner does not work with latest version of VS. At least advise how to get around it and share what is your pathway forward for this or whatever your alternative development path will be.
Anyway I am hardly and expert on all this just sharing as it was quite frustrating.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: dfb34beb-733d-ad1e-37a7-cbe045ee9f15
Version Independent ID: 02319a95-6eb9-59cd-f5fc-747c61e90123
Content: Use Gulp in ASP.NET Core
Content Source: aspnetcore/client-side/using-gulp.md
Product: aspnet-core
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@Moomite 	thanks for bringing this to our attention. cc/ @scottaddie

Thanks for contacting us.
We don’t have the resources to invest in this area, so we are closing the issue. Should your request generate enough  👍 responses, we’ll reconsider.


Irregular failing to connect to Logfire API errors

Description
I have a bunch of python microservices, currently running on azure container apps.
they write logs to two major projects in Logfire.
For some reason, even though I'm using the same configuration code and the exact same write token, some of the services can't connect to logfire, with a weird open telemetry error msg:
/usr/local/lib/python3.11/site-packages/logfire/_internal/config.py:842: UserWarning: Logfire API is unreachable, you may have trouble sending data. Error: HTTPConnectionPool(host='k8se-otel.k8se-apps.svc', port=4317): Max retries exceeded with url: /v1/info (Caused by NameResolutionError("<urllib3.connection.HTTPConnection object at 0x71713aae7e90>: Failed to resolve 'k8se-otel.k8se-apps.svc' ([Errno -2] Name does not resolve)"))
  warnings.warn(f'Logfire API is unreachable, you may have trouble sending data. Error: {e}')

I haven't been able to find consistency as to why some services can connect and some connect (double-checked the logfire configuration in each)
Python, Logfire & OS Versions, related packages (not required)
logfire="0.42.0"
platform="Linux-<IP_ADDRESS>-1.cm2-x86_64-with"
python="3.11.7 (main, Jan 27 2024, 07:04:48) [GCC 13.2.1 20231014]"
[related_packages]
requests="2.32.3"
pydantic="2.7.4"
fastapi="0.111.0"
protobuf="4.25.3"
rich="13.7.1"
executing="2.0.1"
opentelemetry-api="1.25.0"
opentelemetry-exporter-otlp-proto-common="1.25.0"
opentelemetry-exporter-otlp-proto-http="1.25.0"
opentelemetry-instrumentation="0.46b0"
opentelemetry-proto="1.25.0"
opentelemetry-sdk="1.25.0"
opentelemetry-semantic-conventions="0.46b0"

k8se-otel.k8se-apps.svc is not the Logfire API. If you didn't configure that yourself, then I think something in Azure is setting the OTEL_EXPORTER_OTLP_ENDPOINT environment variable. You can override it with base_url='https://logfire-api.pydantic.dev' in logfire.configure().

@alexmojaki thanks, that was indeed the issue, I'm just a bit curios as to why would this happens on some container apps and not others, but thanks :)

I see OTEL_EXPORTER_OTLP_ENDPOINT mentioned in https://learn.microsoft.com/en-us/azure/container-apps/opentelemetry-agents?tabs=arm#environment-variables, but I don't know the details. If you learn more, please share :)
I'm closing since this seems resolved, but if other people run into the same issue then we might want to consider not paying attention to OTEL_EXPORTER_OTLP_ENDPOINT to avoid confusion.


Use docs.brew.sh links.

These are cleaner, shorter and more user-friendly.

fwiw (you may prefer the current style) you could get even cleaner, shorter URLs by removing the .html extension, as GH Pages will resolve it to the .html file (although not if there's a trailing slash, which can be a bit confusing).

I prefer the cleaner version but still need to figure out how to ensure we end up with authoritative URLs i.e. both Google and the Jekyll links use the non-HTML format


Fix build failure caused by missing OpenJDK 6 dependency on Travis CI

Build was successful. Squashing and merging to master


supply chain management platform

Hi,
I hope this message finds you well.
I recently came across your GitHub profile and noticed your work on a web3 project. As a full-stack blockchain and AI developer with extensive experience in supply chain management platforms, I am very interested in the opportunity to contribute to your project.
If you're open to collaboration or would like to discuss how I can add value to your project, I would love to connect.
Looking forward to hearing from you!
Best regards,
Joe
https://soulstar-0x.surge.sh/
<EMAIL_ADDRESS>https://t.me/secondstar9792

Let me know If you are good at hyperledger fabric 2.x
If so connect me on Linkedin via Linkedin


contrib: add gx-rebase script

/cc @vyzo, @magik6k, @Kubuxu, @schomatis, @kevina
Tagging so you're aware of this as it makes rebaseing on go-ipfs master a bit less painful.

Note: this is still kind of useful, just not as useful.


text garbled for mail subject decoding

https://github.com/mikel/mail/blob/8fbb17d4d5364c77cc870769d451bc2739b3a8ce/lib/mail/encodings.rb#L123-L138
here is the original data of subject
Subject: =?iso-2022-jp?Q?=1B=24B0F7o=3EpJs=1B=28B=5B=2D01_=1B=24?=
 =?iso-2022-jp?Q?BBg=3Cj=3Bq=3B=3A1=3FMQ2q=3CR=1B=28B_=2D_=1B=24B=3B?=
 =?iso-2022-jp?Q?q=3B=3A1=3FMQ=24K=24=2B=24=2B=24k=1B=28BDWH=1B=24B=24?=
 =?iso-2022-jp?Q?NFs=3C=213=2BH=2F6HL3=1B=28B=5D?=

when i use mail.subject,it returns
"案件情報[-01 �BBg<j;q;:1?MQ2q<R - �q;:1?MQ$K$+$+$kDWH�NFs<!3+H/6HL3]"
the subject source code is seperate to multiple lines and seems to be processed seperatly according to Encodings.value_decode,
but when I manually merged those into one line like this
Subject: =?iso-2022-jp?Q?=1B=24B0F7o=3EpJs=1B=28B=5B=2D01_=1B=24BBg=3Cj=3Bq=3B=3A1=3FMQ2q=3CR=1B=28B_=2D_=1B=24B=3Bq=3B=3A1=3FMQ=24K=24=2B=24=2B=24k=1B=28BDWH=1B=24B=24NFs=3C=213=2BH=2F6HL3=1B=28B=5D?=

it returns correct result
"案件情報[-01 大手資産運用会社 - 資産運用にかかるDWHの二次開発業務]"
it seems you need to concat those lines first and then decoding it in some case, or just I got a wrong formatted email?

https://github.com/mikel/mail/blob/8fbb17d4d5364c77cc870769d451bc2739b3a8ce/lib/mail/version_specific/ruby_1_9.rb#L124-L135
I think the force_encoding part shouldn't perform here,
it should perform after the whole string were concatenated

The source code of mail is a little too complicated for me to do the modification, so I implement RFC2047 myself to solve this issue in my project, I borrowed lots of tests from mail and made the my gem passed them all.
RFC2047 implementation is here: https://github.com/tonytonyjan/rfc_2047
Usage
$ gem install new_rfc_2047
$ ruby -rrfc_2047 -e 'puts Rfc2047.decode "Subject: =?iso-2022-jp?Q?=1B=24B0F7o=3EpJs=1B=28B=5B=2D01_=1B=24?=\\n =?iso-2022-jp?Q?BBg=3Cj=3Bq=3B=3A1=3FMQ2q=3CR=1B=28B_=2D_=1B=24B=3B?=\\n =?iso-2022-jp?Q?q=3B=3A1=3FMQ=24K=24=2B=24=2B=24k=1B=28BDWH=1B=24B=24?=\\n =?iso-2022-jp?Q?NFs=3C=213=2BH=2F6HL3=1B=28B=5D?="'
Subject: 案件情報[-01 大手資産運用会社 - 資産運用にかかるDWHの二次開発業務]

Below is how I integreate with my project:
inbound_mail.is_a?(Mail::Message) # => true
Rfc2047.decode_field inbound_mail['subject'].value

it seems you need to concat those lines first and then decoding it in some case, or just I got a wrong formatted email?

I don't think we should concat them first. From RFC 2047, section 5:

The 'encoded-text' in an 'encoded-word' must be self-contained

Take 我愛妳 for example:
This is valid:

UTF-8
RFC 2047

我
\xE6\x88\x91
=?utf-8?B?5oiR?=

愛
\xE6\x84\x9B
=?utf-8?B?5oSb?=

妳
\xE5\xA6\xB3
=?utf-8?B?5aaz?=

This is also valud:

UTF-8
RFC 2047

我愛
\xE6\x88\x91\xE6\x84\x9B
=?utf-8?B?5oiR5oSb?=

妳
\xE5\xA6\xB3
=?utf-8?B?5aaz?=

This is NOT valid:

UTF-8
RFC 2047

我\xE6
\xE6\x88\x91\xE6
=?utf-8?B?5oiR5g==?=

\x84\x9B妳
\x84\x9B\xE5\xA6\xB3
=?utf-8?B?hJvlprM=?=

I think the mail gem approaches correctly based on the spec, and this is an upstream issue belongs of mail servers in Japans or Taiwan.


error loading tabix index

May I ask if this is a problem with the vcf file?
peddy --plot -p $cpu --loglevel DEBUG --prefix tof99test /home/ccymak/tof_exome/TOF_Solexa_99.genotypecalls.vcf /home/ccymak/tof_exome/2018_SS-180814-01a/TOF_99.ped
Thanks

python3/3.6.4 is loaded
2019-10-24 15:47:00 paedbc01 peddy.cli[223643] INFO Running Peddy version 0.4.3
/home/ccymak/peddy/peddy/cli.py:198: FutureWarning:
.ix is deprecated. Please use
.loc for label based indexing or
.iloc for positional indexing
See the documentation here:
http://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#ix-indexer-is-deprecated
ped_df = ped_df.ix[samples, :]
/home/ccymak/.local/lib/python3.6/site-packages/pandas/core/indexing.py:822: FutureWarning:
.ix is deprecated. Please use
.loc for label based indexing or
.iloc for positional indexing
See the documentation here:
http://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#ix-indexer-is-deprecated
retval = getattr(retval, self.name)._getitem_axis(key, axis=i)
2019-10-24 15:47:00 paedbc01 peddy.cli[223643] INFO ped_check
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/software/python/3.6.4/lib/python3.6/multiprocessing/pool.py", line 119, in worker
result = (True, func(*args, **kwds))
File "cyvcf2/cyvcf2.pyx", line 93, in cyvcf2.cyvcf2._par_relatedness
File "cyvcf2/cyvcf2.pyx", line 783, in cyvcf2.cyvcf2.VCF._site_relatedness
File "cyvcf2/cyvcf2.pyx", line 658, in gen_variants
File "cyvcf2/cyvcf2.pyx", line 376, in call
AssertionError: error loading tabix index for b'/home/ccymak/tof_exome/TOF_Solexa_99.genotypecalls.vcf'
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/ccymak/.local/bin/peddy", line 11, in
load_entry_point('peddy', 'console_scripts', 'peddy')()
File "/home/mullinyu/.local/lib/python3.6/site-packages/click/core.py", line 764, in call
return self.main(*args, **kwargs)
File "/home/mullinyu/.local/lib/python3.6/site-packages/click/core.py", line 717, in main
rv = self.invoke(ctx)
File "/home/mullinyu/.local/lib/python3.6/site-packages/click/core.py", line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/home/mullinyu/.local/lib/python3.6/site-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
File "/home/ccymak/peddy/peddy/cli.py", line 209, in peddy
in ("ped_check", "het_check", "sex_check")]):
File "/home/ccymak/peddy/peddy/cli.py", line 43, in run
prefix=prefix, **kwargs)
File "/home/ccymak/peddy/peddy/peddy.py", line 970, in ped_check
min_depth=min_depth, each=each)
File "cyvcf2/cyvcf2.pyx", line 39, in cyvcf2.cyvcf2.par_relatedness
File "/software/python/3.6.4/lib/python3.6/multiprocessing/pool.py", line 735, in next
raise value
AssertionError: error loading tabix index for b'/home/ccymak/tof_exome/TOF_Solexa_99.genotypecalls.vcf'

yes, your vcf should be bgzipped and indexed.

Dear Brent,
Despite putting in a vcf.gz file, these errors still occur.
Is the .ix indexer the problem? Could it have anything to do with the
python version?
Many Thanks
Christopher C Mak
Department of Paediatrics and Adolescent Medicine
LKS Faculty of Medicine
The University of Kong Hong

python3/3.6.4 is loaded
2019-10-25 09:54:44 paedbc01 peddy.cli[407545] INFO Running Peddy version
0.4.3
/home/ccymak/peddy/peddy/cli.py:198: FutureWarning:
.ix is deprecated. Please use
.loc for label based indexing or
.iloc for positional indexing
See the documentation here:
http://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#ix-indexer-is-deprecated
ped_df = ped_df.ix[samples, :]
/home/ccymak/.local/lib/python3.6/site-packages/pandas/core/indexing.py:822:
FutureWarning:
.ix is deprecated. Please use
.loc for label based indexing or
.iloc for positional indexing
See the documentation here:
http://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#ix-indexer-is-deprecated
retval = getattr(retval, self.name)._getitem_axis(key, axis=i)
2019-10-25 09:54:44 paedbc01 peddy.cli[407545] INFO [1;31mped_check [0m
2019-10-25 09:54:50 paedbc01 peddy.peddy[407545] INFO plotting
2019-10-25 09:54:51 paedbc01 peddy.cli[407545] INFO ran in 7.7 seconds
2019-10-25 09:54:52 paedbc01 peddy.cli[407545] INFO [1;31mhet_check [0m
2019-10-25 09:54:58 paedbc01 peddy.pca[407545] INFO loaded and subsetted
thousand-genomes genotypes (shape: (2504, 11496)) in 0.6 seconds
/home/ccymak/.local/lib/python3.6/site-packages/sklearn/svm/base.py:193:
FutureWarning: The default value of gamma will change from 'auto' to
'scale' in version 0.22 to account better for unscaled features. Set gamma
explicitly to 'auto' or 'scale' to avoid this warning.
"avoid this warning.", FutureWarning)
2019-10-25 09:54:59 paedbc01 peddy.pca[407545] INFO ran randomized PCA on
thousand-genomes samples at 11496 sites in 0.7 seconds
2019-10-25 09:54:59 paedbc01 peddy.pca[407545] INFO Projected
thousand-genomes genotypes and sample genotypes and predicted ancestry via
SVM in 0.2 seconds
2019-10-25 09:55:00 paedbc01 peddy.cli[407545] INFO ran in 8.2 seconds
/home/ccymak/peddy/peddy/cli.py:224: FutureWarning:
.ix is deprecated. Please use
.loc for label based indexing or
.iloc for positional indexing
See the documentation here:
http://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#ix-indexer-is-deprecated
ped_df[col_name] = list(df[col].ix[samples])
2019-10-25 09:55:00 paedbc01 peddy.cli[407545] INFO [1;31msex_check [0m
no intervals found for
b'/home/ccymak/tof_exome/TOF_Solexa_99.genotypecalls.vcf.gz' at X:2781480
2019-10-25 09:55:01 paedbc01 peddy.peddy[407545] INFO sex-check: 0 skipped
/ 10000 kept
2019-10-25 09:55:01 paedbc01 peddy.cli[407545] INFO ran in 1.3 seconds

On Thu, Oct 24, 2019 at 8:54 PM Brent Pedersen<EMAIL_ADDRESS>wrote:

yes, your vcf should be bgzipped and indexed.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/brentp/peddy/issues/72?email_source=notifications&email_token=AC46UKV63N3EDOOFZP6B5BLQQGLGTA5CNFSM4JEQF3P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECE5JUY#issuecomment-545903827,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC46UKQJA2SSTNN64WTXF3LQQGLGTANCNFSM4JEQF3PQ
.

Hi, does your VCF file also have an index file (.csi or .tbi) ?

Dear Brent,
Thanks so much for your reply. I have reperformed the indexing and it works
fine now, I suppose I can just ignore the rest of the warnings?
For Relatedness check, am I right in saying that related samples will have
a high IBS2 and a low IBS0 putting the sample in the top left above the
other samples?
Thanks again for creating such a great tool!
Regards,
Christopher C Mak
Department of Paediatrics and Adolescent Medicine
LKS Faculty of Medicine
The University of Kong Hong

2019-10-30 01:39:57 hpch01 peddy.cli[168547] INFO Running Peddy version
0.4.3
/home/ccymak/peddy/peddy/cli.py:198: FutureWarning:
.ix is deprecated. Please use
.loc for label based indexing or
.iloc for positional indexing
See the documentation here:
http://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#ix-indexer-is-deprecated
ped_df = ped_df.ix[samples, :]
/home/ccymak/.local/lib/python3.6/site-packages/pandas/core/indexing.py:822:
FutureWarning:
.ix is deprecated. Please use
.loc for label based indexing or
.iloc for positional indexing
See the documentation here:
http://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#ix-indexer-is-deprecated
retval = getattr(retval, self.name)._getitem_axis(key, axis=i)
2019-10-30 01:39:57 hpch01 peddy.cli[168547] INFO [1;31mped_check [0m
2019-10-30 01:40:10 hpch01 peddy.peddy[168547] INFO plotting
2019-10-30 01:40:12 hpch01 peddy.cli[168547] INFO ran in 14.6 seconds
2019-10-30 01:40:12 hpch01 peddy.cli[168547] INFO [1;31mhet_check [0m
2019-10-30 01:40:21 hpch01 peddy.pca[168547] INFO loaded and subsetted
thousand-genomes genotypes (shape: (2504, 11496)) in 0.8 seconds
/home/ccymak/.local/lib/python3.6/site-packages/sklearn/svm/base.py:193:
FutureWarning: The default value of gamma will change from 'auto' to
'scale' in version 0.22 to account better for unscaled features. Set gamma
explicitly to 'auto' or 'scale' to avoid this warning.
"avoid this warning.", FutureWarning)
2019-10-30 01:40:22 hpch01 peddy.pca[168547] INFO ran randomized PCA on
thousand-genomes samples at 11496 sites in 1.1 seconds
2019-10-30 01:40:22 hpch01 peddy.pca[168547] INFO Projected
thousand-genomes genotypes and sample genotypes and predicted ancestry via
SVM in 0.2 seconds
2019-10-30 01:40:23 hpch01 peddy.cli[168547] INFO ran in 11.3 seconds
/home/ccymak/peddy/peddy/cli.py:224: FutureWarning:
.ix is deprecated. Please use
.loc for label based indexing or
.iloc for positional indexing
See the documentation here:
http://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#ix-indexer-is-deprecated
ped_df[col_name] = list(df[col].ix[samples])
2019-10-30 01:40:23 hpch01 peddy.cli[168547] INFO [1;31msex_check [0m
no intervals found for
b'/home/ccymak/tof_exome/TOF_Solexa_99.genotypecalls.vcf.gz' at X:2781480
2019-10-30 01:40:25 hpch01 peddy.peddy[168547] INFO sex-check: 0 skipped /
10000 kept
2019-10-30 01:40:25 hpch01 peddy.cli[168547] INFO ran in 2.1 seconds
On Mon, Oct 28, 2019 at 10:46 AM Brent Pedersen<EMAIL_ADDRESS>wrote:

Hi, does your VCF file also have an index file (.csi or .tbi) ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/brentp/peddy/issues/72?email_source=notifications&email_token=AC46UKTY27WF3457PQTOJYLQQZHAPA5CNFSM4JEQF3P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECLQ3NI#issuecomment-546770357,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC46UKVQI5AA2ACTR4PZPXDQQZHAPANCNFSM4JEQF3PQ
.

yes, that's correct. you can also change 1 axis to show relatedness which might be more easily interpreted.


Problems bridging VerneMQ to AWS IoT

Environment

VerneMQ Version: 1.7.0
OS: Fedora 29 running docker-vernemq 1.7.0
Erlang/OTP version (if building from source):
VerneMQ configuration (vernemq.conf) or the changes from the default
vernemq.conf.txt
Cluster size/standalone: standalone

Expected behavior

Expected bridging to AWS IoT to work.

Actual behaviour

After each message is bridged/published to AWS IoT, the VerneMQ client disconnects.  After a few cycles of connect/disconnect, AWS IoT refused to accept new connections.

Here's the log output: vernemq.log.txt

The no case clause match error is here: https://github.com/vernemq/vernemq/blob/master/apps/vmq_commons/src/gen_mqtt_client.erl#L455. But instead of the #mqtt_publish it tries to match a tuple likely coming from here https://github.com/vernemq/vernemq/blob/master/apps/vmq_commons/src/gen_mqtt_client.erl#L605

@larshesel bug identified, working on a fix

The crash has gone away, but the vmq_bridge no longer attempts to send the message to AWS IoT:
01:26:48.679 [warning] dropped message {deliver,0,undefined,{vmq_msg,<<70,185,60,216,186,180,209,154,199,73,165,184,90,181,145,230>>,[<<"test">>],<<"test2">>,false,false,0,[],false,prefer_local,#{},undefined}} for plugin vmq_bridge

Hi @Fettuccine-Alfredo I think this is due to an otherwise unrelated refactoring I was doing - I'll investigate and get back later today. Sorry for the inconvenience.

Hi @Fettuccine-Alfredo I created a PR (#1087) to address this problem - it's in review now.

Hi @Fettuccine-Alfredo the PR #1087 was merged, it would be great if you could retry the bridge and report if it works! Thanks!

Seems to be working now.

Great! thanks for the feedback!

Need to use this $aws/things/+ topic i.e vmq_bridge.ssl.br0.topic.1 = $aws/things/+ both 0, but couldn't able to publish message with a topic prefix as '$', please guide.

@saqib-cielo VerneMQ does not allow PUBLISHS to topics starting with '$'. Context:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718108

Look whether you find a combination of topic filter, remote prefix, local prefix that allows you to publish out messages on $aws/ in the bridge

I tried one mentioned in the documentation, didn't work either i.e
pattern[wildcard topic] direction[in|out|both] Qos[0|1|2] local_prefix remote_prefix
$aws/things/+ both 0 $aws/things/ $aws/things/

@ioolkos same case working with Mosquitto as bridge with is config
topic => both 0  $aws/things/ $aws/things

Yes, Mosquitto allows publishing to $ topics. Verne does not.
This is about the out direction, for which you need to subscribe to a topic without $, and then prefix it.

@ioolkos like this
vmq_bridge.ssl.br0.topic.1 = $aws/things/+ in 0  vmq_bridge.ssl.br0.topic.2 = aws/things/+ out 0 aws/things/ $aws/things/

@ioolkos But devices/apps will publish messages to bridge this $aws/things/+ topic, will AWS Iot broker receive message with above configs?
Sorry to bothering you that much.


[Merge] ExecutionPayload preparation via PreparableDuty

PR Description
introduces:

new event onExecutionPayloadPreparationDue in ValidatorTimingChannel, called in TimeBasedEventAdapter
new duty type PreparableDuty

The idea is to run execution payload preparation on:

slotTime + 4s at one slot prior to each slot where we have a Block Production duty.
on each reorg event (late block) occurring on a slot prior to a slot where we have a Block Production duty

TODO: unit tests
Fixed Issue(s)
related to #4504
Documentation

[ ] I thought about documentation and added the documentation label to this PR if updates are required.

Changelog

[ ] I thought about adding a changelog entry, and added one if I deemed necessary.

Few things:

I don't think this lines up with the way that the standard REST API is moving. The VC will simply report which validators it's running to the beacon node and then the beacon node is reponsible for calling prepareExecutionPayload at the right time if any of those validators are scheduled to propose. So I don't think we'll need this even in the VC at all - it will wind up in the beacon node. https://github.com/ethereum/beacon-APIs/pull/178 is the PR to make the REST API changes and https://github.com/sigp/lighthouse/issues/2715 has a bigger write up of it.
We want to call prepareExecutionPayload early if we already have the block for the slot (same as we attest early if we receive the block). That gives the execution engine the maximum amount of time possible to prepare the payload. If we don't have the block by 4s into the slot then we'd call it anyway.
We won't get a re-org event if the block is received late - Teku doesn't consider switching from an empty slot to a filled one a reorg.  So we'd need to trigger a new call on any canonical block being received or on a re-org.


Recursive template implies entangled diverging

Hello,
Dumb user mistake I've just produced :hand_over_mouth:
```{.c #something}
<<something>>
```

```{.c file=something.c}
<<something>>
```

Current behavior (1.3.0): Entangle diverges.
Expected behavior: It would be nice to detect recursions and print an error.
Maybe duplicate of #2

yes, this has been on my todo list for a while ;)

Should be fixed on master branch now.


libosmium will no longer build with upcoming PROJ 7.0

PROJ 7.0 planned for March 1st 2020 will remove proj_api.h that libosmium depends on. The removal pf proj_api.h is imminent per https://github.com/OSGeo/PROJ/pull/1872.  PROJ documentation has a number of hints to help for the migration: https://proj.org/development/migration.html

I have now written the code (in branch proj6-support) in libosmium in a way so that it works with the old and new APIs using a macro to switch between them. (I still have to deprecate part of the API that I can't replicate in PROJ > 6, but the most important part is still available.)
But now I don't know how to automatically set that macro with CMake. Because of all the backwards/forwards-compatibility I can't just decide this based on the existence of proj.h or proj_api.h. There must be somebody who has already written the magic to make this happen? Any suggestions?
I looked at https://proj.org/development/cmake.html but that isn't really helpful, because I can't rely on that config being available on the system, it isn't on any I have.

May I suggest not including a major version in the defines?

OSMIUM_USE_PROJ_H (PROJ >= 6)
OSMIUM_USE_PROJ_API_H (PROJ <= 5)

This mimics the naming of ACCEPT_USE_OF_DEPRECATED_PROJ_API_H in PROJ itself.
Regarding the CMake bit, having and option like USE_DEPRECATED_PROJ_API_H that when enabled uses add_definitions(-DOSMIUM_USE_PROJ_H) and add_definitions(-DOSMIUM_USE_PROJ_API_H) otherwise may work.

I have added this to master now. The CMake config will figure out what version you have installed. If proj_api.h is available, it is used, otherwise proj.h. I had to do it this way around, because the new API doesn't work in version 5, so it sticks with the old API as long as it is available.

@rouault looked at the code and found some potential problems (see comments on this commit.
Thanks @rouault for trying to help, but it seems using the new API is even more complex than I had thought. I am cutting my losses here and will pull out the new projection code again. I don't know of anybody using it anyway, and it doesn't make sense to put something in that might not work correctly.

I have now reverted the change that introduced the support for the new PROJ API due to the potential problems with it that @rouault found. I have moved that code to a new repository https://github.com/osmcode/osmium-proj so it is not lost and people can use it from there if needed or copy it into their own code and change as needed.
It is, after all, just a little bit of code to adapt libosmium to PROJ and doesn't need to be in libosmium itself. It is in no way central to what libosmium is doing. I have marked the old PROJ code in libosmium as deprecated and will remove it in a later version.

@joto thanks for your efforts.  Can you also announce this new repository, such as on [osm-talk] or [tile-serving] lists, as a general call for contributors?  I believe there are many users out there who leverage libosmium's PROJ support (but likely don't realize they depend on it, to display their OSM data in other projections).  Again thank you for trying so hard on this.


Increase Eclipse console lines setting

This will not be implemented as it has a potentially heavy impact on performance.


Add eslint and fix lint errors

This PR adds the eslint config from the create-next-app template and a couple other rules to prevent some invasive changes to this repo:

just warn for explicit any
allow unused args and variables that start with '_'

Thanks for the suggestion, but I'm okay with no ESLint here


Give option in settings to disable output window automatically popup

VSCode Version: 1.21.1
OS Version: window 10

Steps to Reproduce:
1.Type "}" in html JS block.
2.Output window with errors will automatically popup.
Video link:
https://www.youtube.com/watch?v=BkW49oxEUFY
Suggestion:
FIx this bug and give option in settings to disable output window  automatically popup.

Does this issue occur when all extensions are disabled?: Yes

This is a duplicate of #45863.
Please see @aeschli's answer here: https://github.com/Microsoft/vscode/issues/45863#issuecomment-373650148


Missing in-game parameters help for entity-spawn flag

As of griefprevention-1.10.2-<IP_ADDRESS>.jar, when trying to use the entity-spawn claim flag, I can't find a proper definition in-game of the possible parameters.
Typically, when I look for it, ones type: /claimflag entity-spawn x, or /claimflag help, or /gp help.
Here, none of those provide an hint at the solution.
I've tried using /claimflag entity-spawn any false, but I'm not sure it does what I need since I can still spawn mobs and they can mate in the area.
Also, I don't know if/how to prevent mobs spawning (allowing only passive ones), without manually adding all of them.

@LemADEC I'll be working on better docs soon. The command would be as follows
/cf entity-spawn minecraft:monster false
The spawn types are animal, monster, aquatic, ambient.
You would do this for each "mod" type you want to block. I'll add a way to prevent all monster mobs soon.
Also make sure you are using the latest dev build of LuckPerms as PEX currently has some issues and hasnt been updated in awhile.
https://github.com/lucko/LuckPerms
For more help , check GP discord here https://discord.gg/jy4FQDz

Fixed in commit https://github.com/MinecraftPortCentral/GriefPrevention/commit/7548a7796ef9f8d543a4b5d7782648f3cb8a83c4


Auto locate the libjvm [ECR-3074]

Overview
Added a wrapper shell script that adds a path to libjvm to the LD_LIBRARY_PATH variable and executes the App.

See: https://jira.bf.local/browse/ECR-3074
Definition of Done

[x] There are no TODOs left in the code
[ ] Changelog is updated if needed (in case of notable or breaking changes)
[ ] The continuous integration build passes

Coverage remained the same at 85.457% when pulling a926ffe77bb1d2af195ffaf763e79ef9e319ee28 on skletsun:auto-locate-libjvm-ecr-3074 into d4306540a677dfdf818ee8e0e13d451714c6f122 on exonum:master.

We discussed that only the script shall be on the PATH, but the binary is still available.

Corrected. The binary is put to EXONUM_HOME/bin.


uncertainty sampling acquisition for bq

Issue #, if available:
Description of changes:

added uncertainty sampling acquisition for quadrature
added model gradients to vanilla bq such that uncertainty sampling can be used with any differentiable model
added gradients to probability densities because weighted uncertainty sampling needs them
added tests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #264 into master will increase coverage by 0.05%.
The diff coverage is 96%.

@@            Coverage Diff             @@
##           master     #264      +/-   ##
==========================================
+ Coverage   90.08%   90.14%   +0.05%
==========================================
  Files         114      115       +1
  Lines        3670     3712      +42
  Branches      413      415       +2
==========================================
+ Hits         3306     3346      +40
- Misses        283      285       +2
  Partials       81       81

Impacted Files
Coverage Δ

emukit/quadrature/methods/vanilla_bq.py
100% <100%> (ø)
:arrow_up:

...kit/quadrature/acquisitions/squared_correlation.py
97.87% <100%> (-0.13%)
:arrow_down:

emukit/quadrature/acquisitions/__init__.py
100% <100%> (ø)
:arrow_up:

emukit/quadrature/kernels/integration_measures.py
87.87% <88.88%> (-0.26%)
:arrow_down:

...it/quadrature/acquisitions/uncertainty_sampling.py
96.29% <96.29%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2da4944...9c4f676. Read the comment docs.


Issues with Pydantic dependencies

After facing no problems running crewai, facing the following error:

ImportError: cannot import name 'InstanceOf' from 'pydantic' (/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/pydantic/init.cpython-311-darwin.so)

Tried uninstall-reinstall both crewai and pydantic. Any suggestions?

What versions are you using both for crewai and pydantic?

For crewai:

Version: 0.1.24
For pydantic:
Version: 2.5.3
Although, for compatibility I have also down-dated to 2.4.2 and have the same issues.

Figured out the issue: two versions of python running, required upgrading pydantic using:
pip3 install --upgrade pydantic==2.4.2

upgrading pydantic solves the issue for me too
Successfully installed pydantic-2.4.2 pydantic-core-2.10.1


deploy kubeflow on juju3

Hey guys,
The latest stable kubeflow is broken on Juju3.
Because Juju3 uses jammy (has python 3.10 installed) for the operator image now.
And the envoy charm current is broken on jammy.
2022-06-29T17:33:38.314748173Z 2022-06-29 17:33:38 WARNING install Traceback (most recent call last):
2022-06-29T17:33:38.314768603Z 2022-06-29 17:33:38 WARNING install   File "/var/lib/juju/agents/unit-envoy-0/charm/./src/charm.py", line 9, in <module>
2022-06-29T17:33:38.314776734Z 2022-06-29 17:33:38 WARNING install     from envoy_data_plane.envoy.api import v2 as api
2022-06-29T17:33:38.314782854Z 2022-06-29 17:33:38 WARNING install   File "/var/lib/juju/agents/unit-envoy-0/charm/venv/envoy_data_plane/envoy/api/v2/__init__.py", line 10, in <module>
2022-06-29T17:33:38.314795604Z 2022-06-29 17:33:38 WARNING install     from betterproto.grpc.grpclib_server import ServiceBase
2022-06-29T17:33:38.314801425Z 2022-06-29 17:33:38 WARNING install   File "/var/lib/juju/agents/unit-envoy-0/charm/venv/betterproto/grpc/grpclib_server.py", line 2, in <module>
2022-06-29T17:33:38.314844926Z 2022-06-29 17:33:38 WARNING install     from collections import AsyncIterable
2022-06-29T17:33:38.314852796Z 2022-06-29 17:33:38 WARNING install ImportError: cannot import name 'AsyncIterable' from 'collections' (/usr/lib/python3.10/collections/__init__.py)

As they suggested here https://github.com/danielgtaylor/python-betterproto/issues/372, we probably should upgrade the betterproto to 2.0.0b4.
Cheers

Jira

I've been able to deploy the latest bundle of Kubeflow 1.6 on Juju 3 succesfully. Envoy has been removed in this version which seemed to be the only charm with issues. I also was able to execute the following workload also. I will close this issue as it seems like Charmed Kubeflow is ready for juju 3. :partying_face:


(PDOC-75) Strings calls 'interpret_any' with the wrong number of arguments

Puppet strings uses an API private method in puppet which has been updated to take two parameters instead of one. This means strings is calling it with the wrong number of variables in the defined type handler which is causing it to crash:
https://github.com/puppetlabs/puppetlabs-strings/blob/master/lib/puppet_x/puppetlabs/strings/yard/handlers/defined_type_handler.rb#L19

Hi @eXprojects.  Thank you very much for your contribution!
There is currently ongoing work to overhaul Puppet strings and move it to the latest version of Yard (see #98 which will hopefully be merged into master this week).  This work removes the use of the type parser in the defined type handler (and elsewhere), so unfortunately your fix is no longer needed.
The upcoming release of Puppet strings will not attempt to parse the type strings like it did before to verify that the docstring and the parameter types match; instead, it now always respects the Puppet version of the type and warns if you attempt to document the type in the docstring.  This is to prevent users from having to keep their documentation in sync with the code, which was problematic (especially for overloaded Puppet functions where parameter types may differ between overloads).
As such, I am closing this PR in favor of the refactoring work that will hopefully go in soon.  Please reopen this PR or message me if you have any concerns.  Thank you!


error compiling iclc2024.pdf using pandoc and latex template

I am using the makrdown template with pandoc such as below.
cd 2025/papers/markdown
make iclc2025.pdf

But I'm facing the error LaTeX Error: Something's wrong--perhaps a missing \item.
Output:
pandoc --template=pandoc/iclc.latex --citeproc --number-sections iclc2025.md -o iclc2025.pdf
Error producing PDF.
! LaTeX Error: Something's wrong--perhaps a missing \item.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

l.420 \end{CSLReferences}

make: *** [Makefile:10 : iclc2025.pdf] Erreur 43

I made a fix in the file pandoc/iclc.latex, see the diff below.
Git diff:
diff --git a/2025/papers/markdown/pandoc/iclc.latex b/2025/papers/markdown/pandoc/iclc.latex
index 647e644..53f1e79 100755
--- a/2025/papers/markdown/pandoc/iclc.latex
+++ b/2025/papers/markdown/pandoc/iclc.latex
@@ -118,6 +118,7 @@ $if(csl-refs)$
    \setlength{\leftmargin}{\cslhangindent}
    \setlength{\itemindent}{-1\cslhangindent}
   \fi
+  \item hotfix
   % set entry spacing
   \setlength{\itemsep}{#2\baselineskip}}}
  {\end{list}}

With the modification above the pdf was compiled properly.
make iclc2025.pdf

Hi,
thanks for letting us know, and sorry for the inconvenience.
Which version of pandoc are you using? It'd be interesting to reproduce the error ...

Hi @the-drunk-coder,
Sorry for the missing information, you can see below the pandoc version, and also the version of Tex and LaTeX.
$ pandoc --version

pandoc 3.1.3
Features: -server +lua
Scripting engine: Lua 5.4
User data directory: /home/joenio/.local/share/pandoc
Copyright (C) 2006-2023 John MacFarlane. Web: https://pandoc.org
This is free software; see the source for copying conditions. There is no
warranty, not even for merchantability or fitness for a particular purpose.

Tex version:
$ tex --version

TeX 3.141592653 (TeX Live 2025/dev/Debian)
kpathsea version 6.4.0/dev
Copyright 2024 D.E. Knuth.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the TeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the TeX source.
Primary author of TeX: D.E. Knuth.

LaTeX version:
$ latex --version

pdfTeX 3.141592653-2.6-1.40.26 (TeX Live 2025/dev/Debian)
kpathsea version 6.4.0/dev
Copyright 2024 Han The Thanh (pdfTeX) et al.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
Compiled with libpng 1.6.43; using libpng 1.6.43
Compiled with zlib 1.3.1; using zlib 1.3.1
Compiled with xpdf version 4.04

The command I'm using to compile the latex template is:
$ pandoc --template=pandoc/iclc.latex --citeproc --number-sections iclc2025.md -o iclc2025.pdf

I'm running all of this in a Debian testing, see below the versions of some LaTeX and TeX packages I've installed in my system.
$ dpkg -l | grep -i latex

ii  biber                                                    2.20-2                                                  all          Much-augmented BibTeX replacement for BibLaTeX users
ii  fonts-mathjax                                            2.7.9+dfsg-1                                            all          JavaScript display engine for LaTeX and MathML (fonts)
ii  latex-make                                               2.4.3-1                                                 all          easy compiling of complex (and simple) LaTeX documents
ii  latex-mk                                                 2.1-5                                                   all          tool for managing LaTeX projects
ii  libjs-mathjax                                            2.7.9+dfsg-1                                            all          JavaScript display engine for LaTeX and MathML
ii  liblatex-tounicode-perl                                  0.54-2                                                  all          Convert LaTeX commands to Unicode
ii  preview-latex-style                                      13.2-1                                                  all          extraction of elements from LaTeX documents as graphics
ii  texlive-latex-base                                       2024.20240706-1                                         all          TeX Live: LaTeX fundamental packages
ii  texlive-latex-extra                                      2024.20240706-2                                         all          TeX Live: LaTeX additional packages
ii  texlive-latex-recommended                                2024.20240706-1                                         all          TeX Live: LaTeX recommended packages
ii  tipa                                                     2:1.3-21                                                all          system for processing phonetic symbols in LaTeX

Hmm strange, I tested with 3.1.3 and didn't get that error ... is there anything in the references list, or is it empty?
Does the same thing happen with the latest version, 3.3 (I find the latest version generally works best ...)
https://github.com/jgm/pandoc/releases/tag/3.3

The reference list is not empty, I'm running it as it is in the folder iclc-templates/2025/papers/markdown, I didn't edit any file.
That's in fact strange because version 3.1.3 fails for me, before I was testing with the version 3.1.3 from the Debian repositories, but I've tested the 3.1.3 version downloading it from upstream here, and it didn't work as well, I've got the same error LaTeX Error: Something's wrong--perhaps a missing \item.
But, I've downloaded the latest version 3.3 and in fact as you mentioned it worked like a charm, no errors.
I don't know why version 3.1.3 works for you but not for me, maybe something else is causing this issue, I guess it can be related to different version of some latex or tex package.


[] build failure

Operating system
windows10
Compiler
MSVC 2019
Steps to reproduce the behavior
vcpkg install zlib:x64-windows boost:x64-windows eigen3:x64-windows ceres:x64-windows opencv:x64-windows cgal:x64-windows glew:x64-windows glfw3:x64-windows

Failure logs
CreateProcess failed. Command attempted:
"D:/Program Files/CMake/bin/cmcldeps.exe RC D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\liblzma_w32res.rc CMakeFiles\liblzma.dir\src\liblzma\liblzma_w32res.rc.res.d CMakeFiles\liblzma.dir\src\liblzma\liblzma_w32res.rc.res "注意: 包含文件:  " "D:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe" "D:\Windows Kits\10\bin\10.0.19041.0\x64\rc.exe" -DDLL_EXPORT -DHAVE_CHECK_CRC32 -DHAVE_CHECK_CRC64 -DHAVE_CHECK_SHA256 -DHAVE_DECODERS -DHAVE_DECODER_ARM -DHAVE_DECODER_ARM64 -DHAVE_DECODER_ARMTHUMB -DHAVE_DECODER_DELTA -DHAVE_DECODER_IA64 -DHAVE_DECODER_LZMA1 -DHAVE_DECODER_LZMA2 -DHAVE_DECODER_POWERPC -DHAVE_DECODER_SPARC -DHAVE_DECODER_X86 -DHAVE_ENCODERS -DHAVE_ENCODER_ARM -DHAVE_ENCODER_ARM64 -DHAVE_ENCODER_ARMTHUMB -DHAVE_ENCODER_DELTA -DHAVE_ENCODER_IA64 -DHAVE_ENCODER_LZMA1 -DHAVE_ENCODER_LZMA2 -DHAVE_ENCODER_POWERPC -DHAVE_ENCODER_SPARC -DHAVE_ENCODER_X86 -DHAVE_IMMINTRIN_H -DHAVE_INTTYPES_H -DHAVE_LZIP_DECODER -DHAVE_MF_BT2 -DHAVE_MF_BT3 -DHAVE_MF_BT4 -DHAVE_MF_HC3 -DHAVE_MF_HC4 -DHAVE_STDBOOL_H -DHAVE_STDINT_H -DHAVE_USABLE_CLMUL -DHAVE_VISIBILITY=1 -DHAVE__BOOL -DHAVE__MM_MOVEMASK_EPI8 -DHAVE___BUILTIN_ASSUME_ALIGNED -DMYTHREAD_VISTA<EMAIL_ADDRESS>-DPACKAGE_NAME=""XZ Utils"" -DPACKAGE_URL="https://tukaani.org/xz/\" -DTUKLIB_FAST_UNALIGNED_ACCESS -DTUKLIB_SYMBOL_PREFIX=lzma_ -Dliblzma_EXPORTS -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\api -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\common -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\check -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\lz -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\rangecoder -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\lzma -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\delta -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\simple -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\common -I D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\windows\vs2019 -c65001 /DWIN32 -D_DEBUG /fo CMakeFiles\liblzma.dir\src\liblzma\liblzma_w32res.rc.res D:\vcpkg\buildtrees\liblzma\src\f890ee5207-326fe62969.clean\src\liblzma\liblzma_w32res.rc"
ninja: fatal: CreateProcess: %1 不是有效的 Win32 应用程序。
Additional context
No response

Thanks for posting this issue. I can't repro this issue locally.
liblzma is compatible with built-in CMake targets:

    find_package(LibLZMA REQUIRED)
    target_link_libraries(main PRIVATE LibLZMA::LibLZMA)
liblzma provides CMake targets:

    find_package(liblzma CONFIG REQUIRED)
    target_link_libraries(main PRIVATE liblzma::liblzma)
PS E:\Lily\0504> .\vcpkg.exe --version
vcpkg package management program version 2023-04-07-bedcba5172f5e4b91caac660ab7afe92c27a9895

Could you please the full log file?

Likely to be caused by antivirus and/or alibabaprotect.

Thanks for posting this issue. I can't repro this issue locally.
liblzma is compatible with built-in CMake targets:

    find_package(LibLZMA REQUIRED)
    target_link_libraries(main PRIVATE LibLZMA::LibLZMA)
liblzma provides CMake targets:

    find_package(liblzma CONFIG REQUIRED)
    target_link_libraries(main PRIVATE liblzma::liblzma)
PS E:\Lily\0504> .\vcpkg.exe --version
vcpkg package management program version 2023-04-07-bedcba5172f5e4b91caac660ab7afe92c27a9895

Could you please the full log file?

install-x64-windows-dbg-out.log
patch-x64-windows-0-err.log

Likely to be caused by antivirus and/or alibabaprotect.

Thanks for your reply. But I can't find any error in your log. Did you install antivirus or alibabaprotect?

Likely to be caused by antivirus and/or alibabaprotect.

Thanks for your reply. But I can't find any error in your log. Did you install antivirus or alibabaprotect?

Thank you for your efforts. My computer did not download the files you mentioned. It is a newly installed system on this computer.

-- Using cached xz-5.4.1.tar.xz.
-- Cleaning sources at D:/vcpkg/buildtrees/liblzma/src/f890ee5207-326fe62969.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source D:/vcpkg/downloads/xz-5.4.1.tar.xz
-- Applying patch fix_config_include.patch
-- Applying patch win_output_name.patch
-- Applying patch add_support_ios.patch
-- Applying patch build-tools.patch
-- Using source at D:/vcpkg/buildtrees/liblzma/src/f890ee5207-326fe62969.clean
-- Found external ninja('1.10.2').
-- Configuring x86-windows
-- Building x86-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
Command failed: "D:/Program Files/CMake/bin/cmake.exe" --build . --config Debug --target install -- -v -j5
Working Directory: D:/vcpkg/buildtrees/liblzma/x86-windows-dbg
See logs for more information:
D:\vcpkg\buildtrees\liblzma\install-x86-windows-dbg-out.log
D:\vcpkg\buildtrees\liblzma\install-x86-windows-dbg-err.log
Call Stack (most recent call first):
installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build)
ports/liblzma/portfile.cmake:35 (vcpkg_cmake_install)
scripts/ports.cmake:147 (include)

D:\vcpkg\buildtrees\liblzma\install-x86-windows-dbg-err.log

Does this file have any contents? If it does, could you please provide it?

D:\vcpkg\buildtrees\liblzma\install-x86-windows-dbg-err.log

Does this file have any contents? If it does, could you please provide it?

install-x86-windows-dbg-err.log

i am having similar problem.
the log shows:
C:\vcpkg\buildtrees\liblzma\src\v5.2.5-d69c6caafe.clean\src\common\common_w32res.rc(9): fatal error C1083: Cannot open include file: 'config.h': No such file or directory
install-x64-windows-dbg-out.log

i am having similar problem. the log shows: C:\vcpkg\buildtrees\liblzma\src\v5.2.5-d69c6caafe.clean\src\common\common_w32res.rc(9): fatal error C1083: Cannot open include file: 'config.h': No such file or directory install-x64-windows-dbg-out.log

Could you try cloning vcpkg to a different disk and then rebuild liblzma?

D:/Program Files/CMake/bin/cmcldeps.exe

@Ocean-ZHY Could you please remove the CMake which installed by yourself and rebuild this port? It is possible that this error is caused by the locally installed CMake on your machine.

C:\vcpkg\buildtrees\liblzma\src\v5.2.5-d69c6caafe.clean\src\common\common_w32res.rc(9): fatal error C1083: Cannot open include file: 'config.h': No such file or directory

@cr3881 Update your vcpkg repo. We are at 5.4.1.

@Ocean-ZHY's build has -c65001 in the cl options, @LilyWangLL's build hasn't.

We haven't been able to repro this; if more information comes up, or this issue appears again, please reopen.


[x86][intrinsic]Is test_llvm_lookup_intrin test LLVM version dependent?

https://github.com/dmlc/tvm/blob/0241fdc5d23a410cff63a0ffeab7c548fadfaa98/tests/python/unittest/test_codegen_llvm.py#L62
I was trying to run tests using LLVM 7.0. It seemed that this test failed because it triggered an LLVM error during codegen.
Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"), function init, file /Users/chzhi/tools/llvm/llvm/lib/IR/Instructions.cpp, line 299.
Abort trap: 6
@cowanmeg Could you please double check if it is a llvm version problem? If so, we might need llvm version check first.
In addition, it looks that the variable m is defined but not used and there is no assertion for the test.

Hmm..I just downloaded the current llvm-7 development branch and the test passed for me.
Can you see if updating fixes the issue?
Also thanks for catching that unused variable!

I see, Thanks. I think mine was probably the trunk version.

Let us move this discussion to https://discuss.tvm.ai/ as there is no actionable items. Please feel free to send a patch to remove unused variable