Cannot find module 'eslint-plugin-material-ui' when running webpack example

Problem Description
When running npm start after running npm install in the webpack example, the following error occurs:
Module build failed: Error: Failed to load plugin material-ui: Cannot find module 'eslint-plugin-material-ui'
Steps to Reproduce:

git clone --depth 1 https://github.com/callemall/material-ui
cd material-ui/examples/webpack-example/
npm install
npm start

Here's the full output:
/home # git clone --depth 1 https://github.com/callemall/material-ui
Cloning into 'material-ui'...
remote: Counting objects: 1706, done.
remote: Compressing objects: 100% (1483/1483), done.
remote: Total 1706 (delta 208), reused 1022 (delta 171), pack-reused 0
Receiving objects: 100% (1706/1706), 1.56 MiB | 0 bytes/s, done.
Resolving deltas: 100% (208/208), done.
Checking connectivity... done.
/home # cd material-ui/examples/webpack-example/
/home/material-ui/examples/webpack-example # npm install
<EMAIL_ADDRESS>/home/material-ui/examples/webpack-example
+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| |     `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   | +--<EMAIL_ADDRESS>|   | `--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | | `--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| |     `--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   | `--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   | +--<EMAIL_ADDRESS>| |   | | `--<EMAIL_ADDRESS>| |   | |   `--<EMAIL_ADDRESS>| |   | +--<EMAIL_ADDRESS>| |   | +--<EMAIL_ADDRESS>| |   | | `--<EMAIL_ADDRESS>| |   | +--<EMAIL_ADDRESS>| |   | +--<EMAIL_ADDRESS>| |   | | `--<EMAIL_ADDRESS>| |   | `--<EMAIL_ADDRESS>| |   |   `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | |   +--<EMAIL_ADDRESS>| | |   `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | | `--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | | +--<EMAIL_ADDRESS>| | | | +--<EMAIL_ADDRESS>| | | | +--<EMAIL_ADDRESS>| | | | | `--<EMAIL_ADDRESS>| | | | |   +--<EMAIL_ADDRESS>| | | | |   `--<EMAIL_ADDRESS>| | | | `--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | | `--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | | +--<EMAIL_ADDRESS>| | | | +--<EMAIL_ADDRESS>| | | | +--<EMAIL_ADDRESS>| | | | `--<EMAIL_ADDRESS>| | | |   `--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   | `--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | |   `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   | +--<EMAIL_ADDRESS>| |   | | +--<EMAIL_ADDRESS>| |   | | | +--<EMAIL_ADDRESS>| |   | | | `--<EMAIL_ADDRESS>| |   | | `--<EMAIL_ADDRESS>| |   | +--<EMAIL_ADDRESS>| |   | `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   | +--<EMAIL_ADDRESS>| |   | `--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   | `--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   | +--<EMAIL_ADDRESS>| |   |   | | `--<EMAIL_ADDRESS>| |   |   | |   +--<EMAIL_ADDRESS>| |   |   | |   +--<EMAIL_ADDRESS>| |   |   | |   | `--<EMAIL_ADDRESS>| |   |   | |   `--<EMAIL_ADDRESS>| |   |   | +--<EMAIL_ADDRESS>| |   |   | `--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   | `--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   | +--<EMAIL_ADDRESS>| |   |   | | `--<EMAIL_ADDRESS>| |   |   | `--<EMAIL_ADDRESS>| |   |   +--<EMAIL_ADDRESS>| |   |   | +--<EMAIL_ADDRESS>| |   |   | `--<EMAIL_ADDRESS>| |   |   `--<EMAIL_ADDRESS>| |   |     +--<EMAIL_ADDRESS>| |   |     `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   | `--<EMAIL_ADDRESS>| |   +--<EMAIL_ADDRESS>| |   | `--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>`--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | `--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | `--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | `--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | `--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | |   `--<EMAIL_ADDRESS>  | `--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | `--<EMAIL_ADDRESS>  |   `--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  `--<EMAIL_ADDRESS>    `--<EMAIL_ADDRESS>
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture<EMAIL_ADDRESS>/home/material-ui/examples/webpack-example # npm start

><EMAIL_ADDRESS>start /home/material-ui/examples/webpack-example
> webpack-dev-server --config webpack-dev-server.config.js --progress --inline --colors

 70% 1/1 build moduleshttp://localhost:3000/
webpack result is served from /
content is served from src/www
Hash: 5d771ea5b5a5046fbf3c
Version: webpack 1.12.14
Time: 1109ms
chunk    {0} app.js (main) 216 kB [rendered]
    [0] multi main 76 bytes {0} [built] [1 error]
    [1] (webpack)-dev-server/client?http://localhost:3000 2.67 kB {0} [built]
    [2] ./~/url/url.js 22.3 kB {0} [built]
    [3] ./~/url/~/punycode/punycode.js 14.6 kB {0} [built]
    [4] (webpack)/buildin/module.js 251 bytes {0} [built]
    [5] ./~/querystring/index.js 127 bytes {0} [built]
    [6] ./~/querystring/decode.js 2.4 kB {0} [built]
    [7] ./~/querystring/encode.js 2.09 kB {0} [built]
    [8] ./~/sockjs-client/lib/entry.js 244 bytes {0} [built]
    [9] ./~/sockjs-client/lib/transport-list.js 613 bytes {0} [built]
   [10] ./~/sockjs-client/lib/transport/websocket.js 2.68 kB {0} [built]
   [11] ./~/process/browser.js 2.06 kB {0} [built]
   [12] ./~/sockjs-client/lib/utils/event.js 2 kB {0} [built]
   [13] ./~/sockjs-client/lib/utils/random.js 746 bytes {0} [built]
   [14] ./~/sockjs-client/lib/utils/browser-crypto.js 438 bytes {0} [built]
   [15] ./~/sockjs-client/lib/utils/url.js 975 bytes {0} [built]
   [16] ./~/url-parse/index.js 6.55 kB {0} [built]
   [17] ./~/requires-port/index.js 753 bytes {0} [built]
   [18] ./~/url-parse/lolcation.js 1.4 kB {0} [built]
   [19] ./~/querystringify/index.js 1.3 kB {0} [built]
   [20] ./~/debug/browser.js 3.76 kB {0} [built]
   [21] ./~/debug/debug.js 4.1 kB {0} [built]
   [22] ./~/ms/index.js 2.33 kB {0} [built]
   [23] ./~/inherits/inherits_browser.js 672 bytes {0} [built]
   [24] ./~/sockjs-client/lib/event/emitter.js 1.11 kB {0} [built]
   [25] ./~/sockjs-client/lib/event/eventtarget.js 1.75 kB {0} [built]
   [26] ./~/sockjs-client/lib/transport/browser/websocket.js 58 bytes {0} [built]
   [27] ./~/sockjs-client/lib/transport/xhr-streaming.js 1.25 kB {0} [built]
   [28] ./~/sockjs-client/lib/transport/lib/ajax-based.js 1.31 kB {0} [built]
   [29] ./~/sockjs-client/lib/transport/lib/sender-receiver.js 1.15 kB {0} [built]
   [30] ./~/sockjs-client/lib/transport/lib/buffered-sender.js 2.3 kB {0} [built]
   [31] ./~/sockjs-client/lib/transport/lib/polling.js 1.32 kB {0} [built]
   [32] ./~/sockjs-client/lib/transport/receiver/xhr.js 1.58 kB {0} [built]
   [33] ./~/sockjs-client/lib/transport/sender/xhr-cors.js 343 bytes {0} [built]
   [34] ./~/sockjs-client/lib/transport/browser/abstract-xhr.js 4.67 kB {0} [built]
   [35] ./~/sockjs-client/lib/transport/sender/xhr-local.js 352 bytes {0} [built]
   [36] ./~/sockjs-client/lib/utils/browser.js 560 bytes {0} [built]
   [37] ./~/sockjs-client/lib/transport/xdr-streaming.js 984 bytes {0} [built]
   [38] ./~/sockjs-client/lib/transport/sender/xdr.js 2.42 kB {0} [built]
   [39] ./~/sockjs-client/lib/transport/eventsource.js 766 bytes {0} [built]
   [40] ./~/sockjs-client/lib/transport/receiver/eventsource.js 1.58 kB {0} [built]
   [41] ./~/sockjs-client/lib/transport/browser/eventsource.js 37 bytes {0} [built]
   [42] ./~/sockjs-client/lib/transport/lib/iframe-wrap.js 981 bytes {0} [built]
   [43] ./~/sockjs-client/lib/transport/iframe.js 3.8 kB {0} [built]
   [44] ./~/json3/lib/json3.js 43.3 kB {0} [built]
   [45] (webpack)/buildin/amd-options.js 43 bytes {0} [built]
   [46] ./~/sockjs-client/lib/version.js 25 bytes {0} [built]
   [47] ./~/sockjs-client/lib/utils/iframe.js 4.95 kB {0} [built]
   [48] ./~/sockjs-client/lib/utils/object.js 532 bytes {0} [built]
   [49] ./~/sockjs-client/lib/transport/htmlfile.js 710 bytes {0} [built]
   [50] ./~/sockjs-client/lib/transport/receiver/htmlfile.js 2.17 kB {0} [built]
   [51] ./~/sockjs-client/lib/transport/xhr-polling.js 894 bytes {0} [built]
   [52] ./~/sockjs-client/lib/transport/xdr-polling.js 712 bytes {0} [built]
   [53] ./~/sockjs-client/lib/transport/jsonp-polling.js 1.02 kB {0} [built]
   [54] ./~/sockjs-client/lib/transport/receiver/jsonp.js 5.49 kB {0} [built]
   [55] ./~/sockjs-client/lib/transport/sender/jsonp.js 2.46 kB {0} [built]
   [56] ./~/sockjs-client/lib/main.js 11.9 kB {0} [built]
   [57] ./~/sockjs-client/lib/shims.js 18.2 kB {0} [built]
   [58] ./~/sockjs-client/lib/utils/escape.js 2.31 kB {0} [built]
   [59] ./~/sockjs-client/lib/utils/transport.js 1.35 kB {0} [built]
   [60] ./~/sockjs-client/lib/utils/log.js 386 bytes {0} [built]
   [61] ./~/sockjs-client/lib/event/event.js 485 bytes {0} [built]
   [62] ./~/sockjs-client/lib/location.js 177 bytes {0} [built]
   [63] ./~/sockjs-client/lib/event/close.js 295 bytes {0} [built]
   [64] ./~/sockjs-client/lib/event/trans-message.js 292 bytes {0} [built]
   [65] ./~/sockjs-client/lib/info-receiver.js 2.22 kB {0} [built]
   [66] ./~/sockjs-client/lib/transport/sender/xhr-fake.js 456 bytes {0} [built]
   [67] ./~/sockjs-client/lib/info-iframe.js 1.52 kB {0} [built]
   [68] ./~/sockjs-client/lib/info-iframe-receiver.js 791 bytes {0} [built]
   [69] ./~/sockjs-client/lib/info-ajax.js 1.03 kB {0} [built]
   [70] ./~/sockjs-client/lib/iframe-bootstrap.js 2.9 kB {0} [built]
   [71] ./~/sockjs-client/lib/facade.js 723 bytes {0} [built]
   [72] ./~/strip-ansi/index.js 161 bytes {0} [built]
   [73] ./~/ansi-regex/index.js 135 bytes {0} [built]
   [74] (webpack)/hot/dev-server.js 1.85 kB {0} [built]
   [75] (webpack)/hot/log-apply-result.js 813 bytes {0} [built]
   [76] (webpack)/hot/only-dev-server.js 2.25 kB {0} [built]

ERROR in ./src/app/app.jsx
Module build failed: Error: Failed to load plugin material-ui: Cannot find module 'eslint-plugin-material-ui'
    at Function.Module._resolveFilename (module.js:339:15)
    at Function.Module._load (module.js:290:25)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.module.exports.load (/home/material-ui/examples/webpack-example/node_modules/eslint/lib/config/plugins.js:116:26)
    at Array.forEach (native)
    at Object.module.exports.loadAll (/home/material-ui/examples/webpack-example/node_modules/eslint/lib/config/plugins.js:134:21)
    at Object.load (/home/material-ui/examples/webpack-example/node_modules/eslint/lib/config/config-file.js:443:21)
    at loadConfig (/home/material-ui/examples/webpack-example/node_modules/eslint/lib/config.js:67:33)
    at getLocalConfig (/home/material-ui/examples/webpack-example/node_modules/eslint/lib/config.js:129:23)
 @ multi main
webpack: bundle is now VALID.```

Versions
--------
This is happening as of e6952c8.

@mbrookes I guess the alpha should come out ASAP. this component isn't published yet!

I got the same error running the webpack example

It's because we have a custom rule for eslint, but we haven't published the code to npm yet. :sweat_smile:

@alitaheri - it doesn't need to be published - it's installed locally.
What I'm not entirely sure is why @dstaley is seeing an error when running npm install in the webpack example.
@dstaley, did you npm-install in material-ui first?

git clone --depth 1 https://github.com/callemall/material-ui
cd material-ui
npm install
cd examples/webpack-example
npm install
npm start

@dstaley I got the same issue and it is because I did not run npm install in material-ui.
@mbrookes Thanks for the suggestions. eslint-plugin-material-ui is included only in material-ui/package.json.

Thanks @zzzliyang - good to know we have that workaround, but still note sure why it's being looked for in the first place, since the example uses the published Material-UI package from npm, and has its own .eslintrc.
@oliviertassinari any ideas?

Okay, it's this:
http://eslint.org/docs/user-guide/configuring#configuration-cascading-and-hierarchy
I'll add root: true, and we should be good.


ignore json files which do not contain test/fixtures

skip JSON files if they do not contain 'steps' statement

@AlexKamaev @AndreyBelym , recently our testcafe test cases are broken since we will put all of the json data and test specs under a 'tests' folder. We will specify the whole 'tests' folder as target for testcafe. I am just wondering if it is related with this issue? If so in our project we always use a fixed version for testcafe(1.14.2), not sure if there is any code change recently that caused the problem.

@IssacH The behavior you described looks exactly like the issue addressed in this PR. However, this issue cannot affect the TestCafe 1.14.2 version. At present, I cannot give you a precise estimate on when the next version will be released. However, please take a loot at the 1.20.1-rc.1 version that contains a fix for the issue.


typo: teh -> the

OPS Build status updates of commit 26ce529:
:clock10: Preparing: average preparing time is not available, there is no data for this repository.

OPS Build status updates of commit 26ce529:
:clock10: Incremental building: average incremental building time is not available, there is no data for this repository.

OPS Build status updates of commit 26ce529:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

office-ui-fabric-react/api/office-ui-fabric-react/iresizegroupprops.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@nschonni I will close this PR as this repo contains only files that are autogenerated and will be overwritten daily. If you want to submit a fix you should do it in the original repo where these docs are generated from. Here is the line you were fixing.
https://github.com/OfficeDev/office-ui-fabric-react/blob/6ed9ccb61d4ae031a678370b4aa8179521e6d9a3/packages/office-ui-fabric-react/src/components/ResizeGroup/ResizeGroup.types.ts#L81

Sounds good. Maybe adding a CONTRIBUTING.md, PULL_REQUEST_TEMPLATE.md or a blurb in the README.md would be a good idea


Emit History engine metric on empty decisions

Emit a server-side metric on RespondDecisionTaskCompleted with empty decisions.

Apparently this was already taken care of by #2807. Closing this issue.


fix navbar

fix navbar overflow

@Bhanu-code what's this for?

@Bhanu-code what's this for?

the fix for navbar was overlaping the casbin body section.


Docker 1.13.1 pull on ubuntu_xenial fails

Description
Docker pull does not pull any containers from docker hub
Steps to reproduce the issue:

Use virtualbox, add ubuntu xenial v20170221.0.1
docker pull ubuntu:xenial

Describe the results you received:
Error response from daemon: manifest for ubuntu:xenial not found
Feb 28 19:42:11 ubuntu-xenial dockerd[28773]: time="2017-02-28T19:42:11.268758099Z" level=error msg="Attempting next endpoint for pull after error: manifest unknown: manifest unknown"
Feb 28 19:42:11 ubuntu-xenial dockerd[28773]: time="2017-02-28T19:42:11.269854361Z" level=info msg="Translating \"manifest unknown: manifest unknown\" to \"manifest for ubuntu:xenial not found\""
Feb 28 19:42:11 ubuntu-xenial dockerd[28773]: time="2017-02-28T19:42:11.269952560Z" level=error msg="Handler for POST /v1.26/images/create returned error: manifest for ubuntu:xenial not found"

Describe the results you expected:
Pulling the container image ubuntu:xenial
Output of docker version:
Docker version 1.13.1, build 092cba3

Output of docker info:
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.13.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 0
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1
runc version: 9df8b306d01f59d3a8029be411de015b7304dd8f
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-64-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.953 GiB
Name: ubuntu-xenial
ID: OIOR:IVQV:FOAR:3BKP:X3KB:SQZ7:NVYG:4U26:3PTM:WWGA:QQA7:ETKU
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
VirtualBox Image ubuntu Xenial v20170221.0.1

Thanks, this is related to the S3 outage. See https://status.docker.com for up to date details.


Issue a warning on gnu void pointer arithmetic

Closes https://github.com/Vexu/arocc/issues/759
In this request I implemented the Type.isPtrTo function but only for the .pointer type specifier. I'm not sure if it is right approach to do that. Maybe other specifiers should be considered as well. I'm open for the conversation.

It's not a bad idea but we already have a specialized function for it; you can just use ty.isVoidStar()

It's not a bad idea but we already have a specialized function for it; you can just use ty.isVoidStar()

I agree. Implementation of such a function is out of this pull requests scope

We'll also need a check in the .add branch of the switch where the current check is, to handle things like ptr + 1 or 1 + ptr. In the .sub branch, I just realized we only need to check for a.ty.isVoidStar() because you can only subtract a pointer from a same-type pointer. So there's no valid subtraction where b is void * and a is not. But for addition either one could be void *.
One final area to add the checks would be for .plus_plus and .minus_minus in the suffixExpr and unExpr functions to handle the case of ptr++/ptr--/++ptr/--ptr when ptr is void *.

We'll also need a check in the .add branch of the switch where the current check is, to handle things like ptr + 1 or 1 + ptr. In the .sub branch, I just realized we only need to check for a.ty.isVoidStar() because you can only subtract a pointer from a same-type pointer. So there's no valid subtraction where b is void * and a is not. But for addition either one could be void *.
One final area to add the checks would be for .plus_plus and .minus_minus in the suffixExpr and unExpr functions to handle the case of ptr++/ptr--/++ptr/--ptr when ptr is void *.

done


Prevent mule missing STASHmaster warnings

Closes #126
This PR adds a warning filter around the mule.load_umfile() call in process, in order to hide warnings about missing STASHmaster files. The information in these files is not used in um2nc and hence these warnings aren't too relevant.
I aded the filter directly in process to try and keep it localised, however this does add slightly more code to process. Any suggested changes or ideas are welcome!

I aded the filter directly in process to try and keep it localised, however this does add slightly more code to process. Any suggested changes or ideas are welcome!

Localising the context manager to 1 function call is ideal & keeps the scope small. Nice one! Command line test output is the cleanest it has ever been for this project.
This one is good to go!


English Placeholder for Voucher Code Input After Switching to Arabic Language

Overview:
Upon switching the language to Arabic on the Enatega Food Delivery website, an issue is identified where the placeholder text for entering a voucher code remains in English. This inconsistency can create confusion for users interacting with the site in Arabic, as it disrupts the localized experience.
Steps to Reproduce:
Access the Enatega Food Delivery website.
Change the language to Arabic.
Navigate to the voucher code input field during the checkout process.
Observe that the placeholder text for entering the voucher code remains in English.
Expected Behavior:
The placeholder text for entering the voucher code should be translated and displayed in Arabic when the language is set to Arabic, maintaining consistency with the selected language.
Actual Behavior:
The placeholder text for the voucher code input field remains in English after switching to Arabic.
https://github.com/Ninjas-Code-official/Enatega-Multi-Vendor-Food-Delivery-System/assets/152266796/2676e692-bf56-4326-842f-04cdff0a3866

Resolved!

waiting for publish


🌱 remove vendor from Makefile (not used anywhere)

Summary
Related issue(s)
Fixes #

/ok-to-test

/hold

/unhold

We are not using vendor, maybe the CI does @MikeSpreitzer  ?


Persist state

Persist the state of the bot in a file that can be reloaded if the bot needs to be restarted.

Fixes #34


detect patchmatch

feat(api): app/config route returns available infill methods
feat(ui): use query to populate infill methods dropdown

available infill methods is server state - remove it from client state, use the query to populate the dropdown
add listener to ensure the selected infill method is an available one

Looks good! Thx


Fix issue with one-cycle logic

Turns out the logic for one-cycle on the scheduler was backwards so step was never called.
Fixes https://github.com/huggingface/accelerate/issues/690 and adds some tests

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Glossary: "Connector for Microsoft 365 Groups" should be in 'C' section (not 'O')

https://learn.microsoft.com/en-us/microsoftteams/platform/get-started/glossary#o

@surbhigupta12 - Can you please here in adding 'Connector for Microsoft 365 Groups' to the 'C' section of the Glossary and removing it from the 'O' section?


Better OAuth 2.0 docs

Especially a better explanation of why provision_key is required and why it should be kept secret.

Is this issue open to work

This particular case has been covered, but we are always open to improvements on our documentation

The documentation has been improved: https://docs.konghq.com/hub/kong-inc/oauth2/


i believe this was patched in chrome os update 108, so dont update if you wanna keep this 💀

just sayin

I added a note to the readme. Thanks!

some chromebooks havent updated yet. but if youre prompted to finish it, do not restart or let your chromebook run out of battery. it will apply the update automatically next time you turn on.


Rename time trigger 'after' to 'at'

Description:
This PR renames the time trigger 'after' option to 'at'.
In #7556, implemented with #7651, we decided it's too confusing to try and force the trigger configuration names to match the condition names. Similarly, 'after' as a trigger name isn't exactly intuitive. This PR proposes to change it to 'at'. I'm also open to other ideas for the name if someone has a better idea, but it should at least be better than 'after'.
CC @amelchio
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#2731
Example entry for configuration.yaml (if applicable):
automation:
  trigger:
    platform: time
    at: '15:32:00'

I agree, it's confusing. Typing after makes me wonder "how long after?"
If we want to clean up all of these, maybe #7170 should be considered at the same time?

Ah, good catch. I agree with that as well. I'll try and get out a PR today, since it would be nice if we could get all of our trigger refactoring into 0.46. Should just be a matter of fixing here: https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/helpers/condition.py#L169-L173

Can we think of a use case that would require the old logic? I'm wondering if we should also include the keywords min and max that replicate the existing logic, making both options available. I can't think of anything off the top of my head, but when it comes to floating points sometimes it's the desired behavior and not cleanly replicated otherwise.

I have that same feeling but cannot think of an example off the top of my head.

Opened #7857 for discussion.

Did you leave backward compatibility? Supporting at and after would be nice, at least for a few revision, this will break too much configuration and to handle both keyword it mustn't be too hard, or?

Read either the PR description or the code…

@RiRomain Yes, there is currently backward compatibility. A warning will be issued in the logs if the old name is detected.

@balloob I did, didn't see any mention about a backward compatibility but rather a "breaking change".
@armills Ok, thanks for the reply and for the change, it does make the trigger simpler to apprehend :-)

@RiRomain It is mentioned right the description

For time triggers, after is deprecated and replaced with at.


Disable telemetry

Add CLI daemon flag -disable-telemetry. If set, the telemetry RPC returns an error indicating the disabling.
Note that this PR is against the release/0.0.13-beta branch.
Closes #4628.

Looks grat! Sorry for the long delay.


pull request for e2e test at 11/16/2016 04:15:12

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

Details

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


HANDLE pointers are incorrect in at least one union

The file handle returned by LOAD_DLL_DEBUG_INFO, obtain from DEBUG_EVENT, will never be valid in a 64-bit application.
This due to the fact that Microsoft for compability reasons has defined that HANDLEs defined in 64-bit applications, uses 32-bit handles. Because of the way unions are implement in winapi-rs, this will return an incorrect handle.
See https://msdn.microsoft.com/en-us/library/aa384203.aspx for more information about this.

I'm not exactly sure what you're trying to say. It doesn't really matter what values handles actually have, winapi simple binds the headers as they are. If there is a mistake with the bindings themselves, then point out the exact binding that is in error. Otherwise I'm not really sure what you want me to do here.

Sorry I should have explained better. Here is an example:
let dll_info = unsafe { debug_event.LoadDll() };
println!("Handle: 0x{:x}", dll_info.hFile as usize);
println!("Correct handle: 0x{:x}", (dll_info.hFile as usize).rotate_right(32));

The output could be something like this:
Handle: 0x19c00000000
Correct handle: 0x19c

The reason this happens is because when compiling for a x64 platform the pointer itself is 64 bit, but it should be intrepreted as a 32 bit pointer when working with handles.

Due to how little endian works, interpreting a 32bit handle incorrectly as a 64bit handle would not shift it up by 32bits. That could only happen if you were reading from the wrong offset. The bindings in winapi seem to be correct according to the headers, so I'm failing to see what could be causing you to get invalid handles Is this an issue you're actually experiencing, and if so do you have an example program I could check out to see the problem for myself?

Yes this is an issue I'm experiencing, and if verified the workaround in C (as good as possible as handles changes). I'll create a small sample in Rust and C tomorrow evening and post

@retep998 Here is some Rust code not working as I would expect without my workaround. Let me now if I should create the same in C.
https://gist.github.com/kichristensen/ddfa5b9e2982afbfe9e20e6a8f5b78f6

Ah I see, you're using winapi 0.2. I rewrote that code using winapi 0.3 and it appears to be working correctly.
https://gist.github.com/retep998/da9586ce0c4ded14b33d3fe535c683ec

It sure does, thanks


Keyword Model Required

SubTask of User Story 03

current allowed categories will be: interest, hobby

category constraint: max length 10 chars
name constraint: max length 30 chars
date_added: default now


Licensing issue: AGPL derivative

Just noticed that Lychee uses code from https://github.com/reacherhq/check-if-email-exists, which is licensed under the copyleft GNU AGPLv3 for open source projects and a commercial license for proprietary software. Lychee therefore would need to use a GNU AGPLv3 license to remain compliant, or drop the dependency.
Thought you should know.

let's drop email capability.

Honestly, email features were one of the best parts of Lychee IMO. Would it be possible to switch to AGPL, or to do something similar to projects like ffmpeg and support optional copyleft features?

it's possible but requires some changes.
lychee-lib can be licensed under MIT/Apache 2.0 without email feature.
The email feature can be moved to a new crate lychee-email under AGPL 3.0 license.
Then lychee-bin can be licensed under one of these licenses depending on whether the email feature is enabled.

also need to mention that, we cannot easily change the license.
when people contributed their work to the codebase, their intent was to license their code under MIT/Apache 2.0.
you'll need everyone to agree to change the license.

to prevent any license issues in the future, we should use https://lib.rs/crates/cargo-deny to check license compatibility in CI workflow.

You do not need permission to relicense from MIT/Apache to AGPL. You would need permission to do the reverse. MIT and Apache are AGPLv3-compatible, but AGPLv3 is not MIT/Apache-compatible.

@Seirdy
Nope. that's a misunderstanding.
As for license compatibility: MIT/Apache 2.0 code can be used in AGPL 3.0 project and the reverse is not true.
But what I'm saying is that you can change the license of this project without the agreement from the authors. This is not about license compatibility.

changing license is nearly impossible unless you get agreement from ALL contributors.

If I were to fork an MIT project and make my fork AGPLv3, that would be allowed. I'd be re-using contributors' code that was licensed under the MIT license, because using MIT code in an AGPLv3 project is allowed.
If a project were to switch from MIT to AGPLv3, that would be allowed because using contributors' MIT code in an AGPLv3 project is allowed.
If a project were to switch from AGPLv3 to MIT, that would require permission from all contributors because you can't use AGPLv3 code in an MIT project and keep the license.
Contributors do not sign a legal agreement stating that their contribution is contingent upon a project never changing a license; they simply agree to the terms set forth by the existing license. If the existing license is AGPLv3, that means that it cannot be re-licensed to MIT without permission from all authors. The reverse is not true.

that's not correct.
license cannot be changed retroactively, so all current code are always MIT/Apache 2.0.
Suppose lychee became licensed under AGPL, for any significant contribution (> 10 loc), the copyright holder must gives the permission. Otherwise lychee must carries the original license and declare which portion of code was licensed under that.

Thanks for raising this @Seirdy.
The email feature is currently not very reliable at the moment. We talked about disabling it by default in https://github.com/lycheeverse/lychee/issues/575. I would not mind dropping it entirely, but it seems like you think it's useful. Didn't you encounter a lot of false positives?
We could create a separate lychee-email crate and it could be moved to a separate plugin, which could be helpful anyway at some point. I'm struggling to find a great plugin system, though. Considered Webassembly, but I don't know of any existing solution for Rust or any other tool we could look at for inspiration. @lebensterben any thoughts?

@mre
We can drop it from lychee-lib and lychee-bin.
And use a standalone check-if-email-exists binary in lychee-action. We don't even need to disclose the source code because we are not distributing the binary.

Sounds like @Seirdy meant the binary, not the action, though? In any case it would be nice to have the ability to check emails from the cli as well.

you are talking past each other @Seirdy @lebensterben
It's without a doubt possible to generally redistribute lychee under the AGPL without requesting permission from the contributors. The MIT license requires you to retain copyright notices and the permission notice from the MIT, but that does not mean you can change the main license of the entire project right now and license future changes to lychee under AGPL only.
Keep in mind that any license change always only ever applies to future versions of a piece of software. While it's possible to change the license for lychee 1.0, it's not possible to retroactively change the license for lychee 0.9.
This quote from @lebensterben is key:

Otherwise lychee must carries the original license and declare which portion of code was licensed under that.

That's exactly how to do the relicensing. You keep the original license around on top of the AGPL.

I also don't think it's a good idea to do any of that. It will impact use of lychee-lib in third-party software. reacherhq appears to have licensed check-if-email-exists under AGPL to prevent commercialization by a competitor who would not be willing to open-source their codebase. If lychee wants to pursue a similar business model eventually, it could do so, but it means it's not possible to build a proprietary service around the library anymore.

A third, probably not very useful, option not mentioned: it'd be possible to put lychee's usage of check-if-email-exists behind a compile-time feature. If that feature is disabled, the resulting binaries do not contain AGPL code.

I was hoping to look into the wasm plugin system that zellij provides to see if we could use that somehow. Then e-mail support could be moved there. Alternatively, can't we simply move it to a sub-crate and isolate it this way? When it gets published, it will have the correct license.

if it's in a subcrate but you still have that subcrate as dependency, the AGPL violation just becomes less direct. I would recommend to drop this functionality.

Honestly, email features were one of the best parts of Lychee IMO. Would it be possible to switch to AGPL, or to do something similar to projects like ffmpeg and support optional copyleft features?

#1099 added an email-check feature flag for the AGPL-licensed check-if-email-exists crate. This was necessary because the crate doesn't support Rustls yet. However, you can disable email checks at compile time now by passing --no-default-features --features native-tls or --no-default-features --features rustls-tls to Cargo.

I am thinking about disabling email-check by default. Email addresses lead to a lot of false positives at the moment (see https://github.com/lycheeverse/lychee/issues/1111). If people need the feature, they would have to compile lychee themselves from the sources. Maybe there's also a way to distribute the "full" lychee CLI with email support as a binary under a different license?
Related: https://github.com/lycheeverse/lychee/issues/1089

There are a lot of differing opinions regarding the rules for re-licensing. I am not so confident that the answer would even be the same in every jurisdiction after seeing the lack of consensus. Given this, it seems at least courteous to solicit contributor approval for re-licensing.
As someone who encountered a lot of false positives from email-check, I am also a fan of removing this feature in light of the licensing concerns.


Animate exploding messages on mobile

[x] Slide
[x] Fire

@keybase/react-hackers this is ready!


Update codes.go

fix typo

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.602%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5148

Relevant Lines:
5221

💛  - Coveralls

Another great PR, thank you @helderjnpinto :)


Update the PHP indentation script from 1.60 to 1.62

Multi-line indenting could get wrong whenever started on a commented line. (issue 2072/PHP-Indenting-for-VIm#44)
Prevent multi-line strings declaration from breaking indentation. (issue 2072/PHP-Indenting-for-VIm#47)
Fix some multi-line block declaration interferences (issue 2072/PHP-Indenting-for-VIm#49)
Fix Grouped 'use' declaration (issue 2072/PHP-Indenting-for-VIm#48)
Fix array index issue with function call (issue 2072/PHP-Indenting-for-VIm#54)
Add anonymous class declaration support (issue 2072/PHP-Indenting-for-VIm#55)

I'll include it, thanks.


Short reference switch

Let's use this macros in arm_converter_embedding_bag_offset_sum.cpp, arm_converter_embedding_bag_packed_sum.cpp, arm_converter_embedding_segments_sum.cpp

@l-bat please review version without MACRO

Please look at https://github.com/openvinotoolkit/openvino_contrib/blob/master/modules/arm_plugin/src/arm_converter/arm_converter_one_hot.cpp.
Please, add switch to all reference.


Changing autopilot behaviour from a code

Hello everyone.
I am new Carla simulator user and I have questions regarding your autopilot which I use in manual_control.py and also I'm using C++.In my project I'm supposed to detect vehicle in front of me. Also I am supposed to brake to avoid collision. For driving I use your autopilot where I changed code so it doesn't stop automatically. My problem is that when I use autopilot it doesn't register my brake command. I decided to change autopilot so that my vehicle breaks if distance is enough small, and throttles if distance is larger. So my plan was to put one flag that changes autopilot mode. I did that in WheeledVehicleAIController.cpp but I guess that that file is compiled during make package so I am unable to change it. My question is if it is possible to  somehow interact with autopilot from my C++ code during the simulation.

Pls, anyone!? :(
Turning autopilot from .cpp file would help also if it is possible.


Authentication validation function doesn't respect error classes

I created a security schema based on this example linked from the docs.
def decode_bearer_token(bearer_token):
    try:
        jwks_client = PyJWKClient(
            os.environ["JWKS_URI"],
            headers={
                "User-agent": os.environ["USER_AGENT"],
                "X-CORRELATION-ID": osep_correlation_id,
            },
        )

        signing_key = jwks_client.get_signing_key_from_jwt(bearer_token)

        return decode(
            jwt=bearer_token,
            key=signing_key.key,
            algorithms=[os.environ["JWT_ALGORITHM"]],
            audience=[os.environ["JWT_AUDIENCE"]],
            issuer=os.environ["JWT_ISSUER"],
        )
    except Exception:
        raise Unauthorized("Invalid token")

The Unauthorized raised in the last line results in a 500 internal server error. I'd expect a problem detail returned reflecting the 401.
Am I doing something wrong or is 500 expected here?

I had the same issue and was able to solve it by importing connexion.exceptions.Unauthorized instead of werkzeug.exceptions.Unauthorized provided in the example.


i cannot use it?

As a beginner, please assist me with a video tutorial on how to use your files. I am eager to utilise your files but need the knowledge to achieve it. Can you provide me with a video or direct me to one that can teach me how to use your files?

This is a Command Line (CLI) Application. It is not designed to used by beginners from scratch and unfortunately most tutorials to use CLI application or running Node JS are geared towards developers.
However, you could ask ChatGPT to guide you along, for example if you are on Windows:
https://chat.openai.com/share/95cdb242-52e0-41d5-8350-e9832877b41b

I appreciate your prompt response and would like to express my gratitude.


Fix not finding certain GOG games that use launchers

Encountered an issue where BoilR would miss some of my GOG client games; turns out their goggame-*.info file has their first playTask category field set to "launcher", and BoilR was skipping over them because of this. This fixes it by matching on either "launcher" or "game".

I am pretty sure this also solves this issue!
https://github.com/PhilipK/BoilR/issues/137


Feature/postgres combination

Ive attempted to merge the two postgres branches. There were a lot of merge conflicts so I decided to apply the changes to a new branch. @Keanumrc  I will need your help I think since the onboarded stuff has changed the connection manager

I know tests are failing. This Branch is un-finished


Register user endpoint

please review @Msindy @ODINKS
endpoint for creating a user

If you feel it's good to go, then it's good to go.

If this passes your test runs , We can close this .


visdrone training is pulling and doing coco dataset training

I am trying to train on visdrone and the code is pulling coco_train.py from the train_tools instead of visdrone_train.py Can you please look into this ?

Hi, please try train_visdrone.py for VisDrone experiments.


Can't save the image. Return null when calling saveImage().

 Tests indicate that everything is working fine.


tendermint, monitoring: 0.17.1 and fix build

This change is

Reviewed 10 of 10 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

Reviewed 10 of 10 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable


#545 fixed

fix the issue #545.

hope this PR can't be merged soon

this approach is not good
we still see the previous highlighted search input characters in dropdowns
event the input search item is empty


Compiled and Ready hooks doesn't work

Today I've tried the vue-cli for the first time and I've being using the created, compiled and ready hooks for the Hello.vue component and it only works the Ready one. I put a console.log/alert on each hook and it only executes the created one. Then I've done the same example with vue.js and all the  hooks work.

Which template have you tried? It's probably because all official templates are now Vue 2.0 which don't support all the hooks any more. See http://rc.vuejs.org/guide/migration.html#Lifecycle-Hooks


[main] Upgrade to latest dependencies

Cron -knative-prow-robot
/cc knative-sandbox/api-core-wg-leads
/assign knative-sandbox/api-core-wg-leads
Produced by: knative-sandbox/knobots/actions/update-deps
Details:
bumping knative.dev/pkg f4b57ae...bab3d0d:
  > bab3d0d Update actions (# 2413)
  > 671e46d :dizzy: we must use `flags` instead of `pflags`, since this is not working. It  seems like pflag.* adds the var to its own flag set, not the one package flag uses, and it doesn't expose the internal flag.Var externally - hence this fix. (# 2414)
  > 7880fb4 Update community files (# 2412)
  > 8681fe2 Continual tests logging within test scope (# 2293)

/lgtm
/approve


✨ Add swap header

To see the specific tasks where the Asana app for GitHub is being used, see below:

https://app.asana.com/0/0/1207314316210187

please check the icon colors


Fix edge cases on test_backbone_utils when the sampled node is buffer with integer value

Cherry pick https://github.com/pytorch/vision/pull/6090 from main into release/0.13

The type check failed, but seems like it is not related with this PR. It affect all the model loading. Will investigate...

Seems like the problem in typecheck is not because of this PR: https://github.com/pytorch/vision/pull/6092
I have created this dummy PR to check.
I am not too sure what cause this problem, but I have a fix for the type check, will create separate PR for it

The problem is not on your side. We should merge this and review the issue on a separate PR.


added blog to README.md

added kaveh.page to the list of blogs using your template. Thanks 🙏

Wrong repository, this is my personal blog... maybe I should update the readme 😆

Ahhh lol. Sorry I didn't notice! I'll send the PR to the template repo.


Price on detail - map

Trello

Looks like it is already fixed

Found it again was looking on the wrong map


Fixing the key scan on Redis for the feature set and property set.

Removed the * keys command by using a fixed set of features and properties. This reduces the complexity from O(n) to O(1) lookup.
Removed read hitting redis twice, once for checking exist and one for reading.
Removed string parsing during read.

More optimization possible, probably in one of the next PRs.

Coverage remained the same at 88.871% when pulling 28f1b58d826a423b93b9b16ad715a2e6b9f0127c on shridharns:ff4j-dev into d888e07b1f2b55593966c79f29224351683a9b43 on clun:master.


Bug/prevent flag mutation#33

Solve: https://github.com/lucagez/slow-json-stringify/issues/33

Nudge


feat: Cross Filters in FilterBar

SUMMARY
This PR adds the ability to see applied cross filters in the FilterBar in both horizontal and vertical mode
AFTER
https://user-images.githubusercontent.com/60598000/220887300-b4be95d3-94df-48a8-905a-f7f2c5b7c856.mp4
TESTING INSTRUCTIONS

Enable cross filtering in the Dashboard
Add one or more cross filters from the available charts
Remove a cross filter
Change filter bar orientation and verify that filters are appearing correctly
Reduce size of the screen and make sure the cross filters are appearing in the "More filters" dropdown correctly

KNOWN ISSUES
Highlighting a chart by clicking on the search icon does not work properly right now. It will be fixed in a separate PR as this issue affects master already
ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Required feature flags: DASHBOARD_CROSS_FILTERS
[x] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

A few visual issues:

Tag's X button is not centered.

Tag's outline is different colour than in designs

Horizontal line between cross-filters and native filters is missing in vertical filter bar

Spacing between title and icon is 8px, should be 4

Separator line in horizontal bar is too thick - should be 1px

Top margin in overflow dropdown is too big

Separator line in overflow dropdown is too thick

I think it wasn't included in designs, but "Filters out of scope" should probably be the same font size as "Cross-filters" collapsible title for consistency

1 more comment (we can handle it in a separate PR) - currently we display the filter bar only if the native filters FF is enabled. I think now that we use the filter bar to also show the cross filters, we should display the filter bar when either of the feature flags is enabled

@kgabryje thanks for the feedback! All above issues should be sorted now. I have also included unit tests and separated the code a little bit more.

/testenv up FEATURE_DASHBOARD_CROSS_FILTERS=true

/testenv up FEATURE_DASHBOARD_CROSS_FILTERS=true FEATURE_HORIZONTAL_FILTER_BAR=true

A few more comments:

I think the search icon is not centered. I fixed it by giving the span.anticon line-height: 0.

The spacing between the X and the right edge of the tag is slightly too large - 8px instead of 4

I think the separator line is redundant if there are no native filters added

If there are no native filters, there's a vertical line in the "More filters" dropdown

Not sure what to do about that empty state here...

@kasiazjc about the "No filters" empty state that is referring to the native filters and it is mentioning the button to add new filters. Should we change the copy a bit to make sure it is referring to the native filters and not cross filters?

/testenv up FEATURE_DASHBOARD_CROSS_FILTERS=true FEATURE_HORIZONTAL_FILTER_BAR=true

This is incredible stuff, love it! ❤

@kasiazjc about the "No filters" empty state that @kgabryje mentioned above, that is referring to the native filters and it is mentioning the button to add new filters. Should we change the copy a bit to make sure it is referring to the native filters and not cross filters?

So this is what I'm thinking:

No global filters are currently added
Click on “+Add/Edit Filters” button to create new dashboard filters.

In the next version of the dashboard filters we wanted to actually use term "global filters" which made sense to our users and they could easy understand what does it mean. So let's start there
thanks for all the work @geido and @kgabryje ❤

I found an issue that when i try to locate the chart for emitting cross filter, all charts under a mask and the emitting chart is not highlight, i have to refresh page to show the charts again
https://user-images.githubusercontent.com/81597121/221263954-fec9b1cd-66f4-4d44-867b-e3311f3df689.mov

I found an issue that when i try to locate the chart for emitting cross filter, all charts under a mask and the emitting chart is not highlight, i have to refresh page to show the charts again

@jinghua-qa it is a known issue mentioned in the PR description that @kgabryje has fixed and we are ready to merge.


Cannot access 'NgxMatCalendar' before initialization

I just updated to @3.0.0 after updating a project to Angular 9 and the application cannot bootstrap throwing the following error:
Cannot access 'NgxMatCalendar' before initialization
It may be something else gone wrong with my update  but just wanted to reach out in case this rings a bell to you.
Thank you!

Downgrading to 2.0.3 fixed the issue for me

I'm having the same problem. Can't downgrade to 2.0.3 though (https://github.com/h2qutc/ngx-mat-datetime-picker/issues/46).
It also seems quite a couple peer dependencies are a bit restrictive?
<EMAIL_ADDRESS>has incorrect peer dependency "<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency "<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency "<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency "<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency "<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency "<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency "<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency "<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>

Hi,
This repo is no longer supported, please consider using the repository angular-material-components instead.
This issue was fixed in @angular-material-components/datetime-picker v2.0.1
npm install --save  @angular-material-components/datetime-picker

Free free to open issue here.
Thank you very much.


Update list of env vars used

Describe your changes

Please include a summary of the changes and the related issue/task. Please also include relevant motivation and context. List any dependencies that are required for this change, including links to other pull requests/branches in other repositories if applicable.

Changes: Updated list of environment variables that were modified in https://github.com/mcode/rems-smart-on-fhir/pull/95
Related PRs

https://github.com/mcode/rems-smart-on-fhir/pull/95
https://github.com/mcode/rems-cds-hooks/pull/18

Issue ticket number and Jira link

Please include the Jira Ticket Number and Link for this issue/task.

REMS-660 and REMS-678.
Checklist before requesting a review

[x] I have performed a self-review of my code
[x] Ensure the target / base branch for any feature PR is set to dev not main (the only exception to this is releases from dev and hotfix branches)

Checklist for conducting a review

[ ] Review the code changes and make sure they all make sense and are necessary.
[ ] Pull the PR branch locally and test by running through workflow and making sure everything works as it is supposed to.

Workflow
Owner of the Pull Request will be responsible for merge after all requirements are met, including approval from at least one reviewer. Additional changes made after a review will dismiss any approvals and require re-review of the additional updates. Auto merging can be enabled below if additional changes are likely not to be needed. The bot will auto assign reviewers to your Pull Request for you.

This PR does not touch any testable code


Feature Request: Advanced QoS based on DPI

Dear all,
an advanced detection on what kind of traffic is produced to filter it efficiently to the corresponding QoS pipe would be great. L7 is in my opinion deprecated and never worked very good. nDPI might be an option on realizing this.
Even more with nDPI denying of certain webpages like Facebook or youtube would be possible.
BR
Ben

Hi Ben,
L7 hasn't existed in OPNsense since 2015. :)
I agree that nDPI is the best thing to go forward, however, as far as I know it's not easily possible to integrate it into QoS for easy policy management based on protocol/application properties.
It would certainly require an effort to bring a third packet filter framework into the mix in order to filter according to all those properties and the means to do userspace/kernel decisions in tandem. Suricata does this with the netmap framework already, but Suricata is an IPS so it only drops. QoS or similar techniques require shaping algorithms and queues, which we would have to implement in userspace.
Another way to go forward would be the dummynet framework, which may be able to deliver the required complexity.
So far, this is only theory and not a concrete plan. All comments are welcome to move this forward. Leaving this open as a future feature ticket. :)
Cheers,
Franco

Hello Franco,
I totally agree with you that this cannot be a "just do it" task/feature. I am quiet unused to *BSD, but I know linux well (for an hobby enthusiast) and had been a developer for a linux FW for some time. All I could find about nDPI is, that it is working with iptables and a netfilters kernel module. I could not find anything comparable for PF or IPFW. The Dummynet approve sounds to me definitely the most promising choice.
Any further ideas?
Yes, please keep this open as a "future feature ticket".
Greets,
Ben

Another idea which came to my mind and would like to discuss is using a docker container containing a small Linux like alpine with the xtables netfilter patches.
E.g. for traffic going from inet to LAN:
The container acts as a gateway somewhere between LAN and traffic leaving wan. It needs a static ip which can be addressed.
This way the whole DPI story could be handled as a plugin and the FW itself could be untouched.
Please feel free to discuss this idea.
Cheers
Ben

@BenSchweikert I think this is a bad idea because iptables is afaik EOL. The current Linux firewall is nftables. However, it should be supported as well: https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables
Docker will not work because it is using a shared kernel - which means that the container is still running on a FreeBSD kernel - and will have PF or IPFW as packet filtering framework. Note that docker on FreeBSD is still experimental.

@BenSchweikert
An NDPI or any network routing system should not be running as a docker container since it cannot have it's own kernel and will be binded to the host one.
@fabianfrz
iptables is not really EOL and nftalbes is just an addition of "API" to the same system with a bit of "remixing" in it.
Basically iptables will stay stable for at-least 5 years for production systems.
And if someone is capable to add nDPI to iptables then nftables would be pretty simple task but will require some learning curve.

timeout due to inactivity


neogit leaves behind another empty buffer every time its open

Description
opening neogit adds an empty buffer, closing neogit doesn't remove this buffer. they accumulate during use of neogit. especially problematic with tabs or other UI that works with buffers
Neovim version
NVIM v0.10.0-dev-3107+g8c7a8be27
Build type: RelWithDebInfo
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info
Operating system and version
macos 14.4.1
Steps to reproduce
open neovim with any minimal repro (including the one provided by the issue template)
:Neogit then close with q or any other way
:buffers shows a no name buffer, keep opening neogit to add more buffers
Expected behavior
no accumulation of no name buffers
Actual behavior
accumulation of no name buffers
Minimal config
-- NOTE: See the end of this file if you are reporting an issue, etc. Ignore all the "scary" functions up top, those are
-- used for setup and other operations.
local M = {}

local base_root_path = vim.fn.fnamemodify(debug.getinfo(1, "S").source:sub(2), ":p:h") .. "/.min"
function M.root(path)
  return base_root_path .. "/" .. (path or "")
end

function M.load_plugin(plugin_name, plugin_url)
  local package_root = M.root("plugins/")
  local install_destination = package_root .. plugin_name
  vim.opt.runtimepath:append(install_destination)

  if not vim.loop.fs_stat(package_root) then
    vim.fn.mkdir(package_root, "p")
  end

  if not vim.loop.fs_stat(install_destination) then
    print(string.format("> Downloading plugin '%s' to '%s'", plugin_name, install_destination))
    vim.fn.system({
      "git",
      "clone",
      "--depth=1",
      plugin_url,
      install_destination,
    })
    if vim.v.shell_error > 0 then
      error(string.format("> Failed to clone plugin: '%s' in '%s'!", plugin_name, install_destination),
        vim.log.levels.ERROR)
    end
  end
end

---@alias PluginName string The plugin name, will be used as part of the git clone destination
---@alias PluginUrl string The git url at which a plugin is located, can be a path. See https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols for details
---@alias MinPlugins table<PluginName, PluginUrl>

---Do the initial setup. Downloads plugins, ensures the minimal init does not pollute the filesystem by keeping
---everything self contained to the CWD of the minimal init file. Run prior to running tests, reproducing issues, etc.
---@param plugins? table<PluginName, PluginUrl>
function M.setup(plugins)
  vim.opt.packpath = {}                      -- Empty the package path so we use only the plugins specified
  vim.opt.runtimepath:append(M.root(".min")) -- Ensure the runtime detects the root min dir

  -- Install required plugins
  if plugins ~= nil then
    for plugin_name, plugin_url in pairs(plugins) do
      M.load_plugin(plugin_name, plugin_url)
    end
  end

  vim.env.XDG_CONFIG_HOME = M.root("xdg/config")
  vim.env.XDG_DATA_HOME = M.root("xdg/data")
  vim.env.XDG_STATE_HOME = M.root("xdg/state")
  vim.env.XDG_CACHE_HOME = M.root("xdg/cache")

  -- NOTE: Cleanup the xdg cache on exit so new runs of the minimal init doesn't share any previous state, e.g. shada
  vim.api.nvim_create_autocmd("VimLeave", {
    callback = function()
      vim.fn.system({
        "rm",
        "-r",
        "-f",
        M.root("xdg")
      })
    end
  })
end

-- NOTE: If you have additional plugins you need to install to reproduce your issue, include them in the plugins
-- table within the setup call below.
M.setup({
  plenary = "https://github.com/nvim-lua/plenary.nvim.git",
  telescope = "https://github.com/nvim-telescope/telescope.nvim",
  diffview = "https://github.com/sindrets/diffview.nvim",
  neogit = "https://github.com/NeogitOrg/neogit"
})
-- WARN: Do all plugin setup, test runs, reproductions, etc. AFTER calling setup with a list of plugins!
-- Basically, do all that stuff AFTER this line.
require("neogit").setup({}) -- For instance, setup Neogit

this only happens on the nightly branch. easiest way i found to get there was to not clone with depth=1 and just check it out manually

No worries, I found the issue.

this is also happening after upgrading to neovim 0.10, thanks @CKolkey in advance and looking forward for the fix

Yes, I am having the same problem and it started when I upgraded to Neovim 0.10 (but it can be a coincidence). The temporary solution was to change kind to replace.

I am also having this issue.

Me toooo. Hope be solved soon~ :D

Same, I tried the replace thing but it doesn't matter if you are doing a lot of git stuff as it creates buffers for anything you do inside Neogit.

keymap('n', '<leader>b.', function()
    local buffers = vim.api.nvim_list_bufs()
    for _, buf in ipairs(buffers) do
        if vim.api.nvim_buf_is_valid(buf) then
          local lines = vim.api.nvim_buf_get_lines(buf, 0, -1, false)
          if #lines == 1 and #lines[1] == 0 then
          -- Buffer is empty, delete it
          vim.api.nvim_buf_delete(buf, { force = true })
        end
      end
    end
  end, { desc = "Delete all empty buffer", noremap = true, silent = true })

for emergency. :D

If anyone still experiences this issue with the above fix merged, please let me know here. That said, I can reproduce the no name issue before, but not after, that patch.

Shoot, really? With all kinds (split, tab, etc), or one specifically?

Still experiencing the same issue with no name buffers.

Are you both using a buffer-line plugin? I'm using :buffers to check this.

I use tabline

I am using bufferline and I am experiencing the same. Note that most empty buffers are gone; only the one from the main neogit instance is hanging about.

Note that most empty buffers are gone; only the one from the main neogit instance is hanging about.

@qRoC Are you using any special kind, or the default?

default

Ahh, I can in fact reproduce every time I open a new tab, e.g. log_view etc.

I am using default kind (tab), and I have lualine for my buffers, removing the setting to displaying buffer from lualine config still shows empty buffers being created. when I search buffers via telescope. For me nothing changed I still see buffers being created whenever I do any git related stuff inside neogit.

If someone could give this branch a try and let me know if the issue persists for them, I'd appreciate it :) https://github.com/NeogitOrg/neogit/pull/1326

unfortunately for me it's still behaving the same way on that branch

If someone could give this branch a try and let me know if the issue persists for them, I'd appreciate it :) #1326

Sorry to say but yes I'm still having the same issues :(
Thank you for all your efforts, it's appreciated!

I tried setting up both Tabby and https://github.com/akinsho/bufferline.nvim and can't get it to show any noname buffers :\
Also tried with a very very minimal config and can't reproduce.
Happy to keep trying to fix this, but I think at this point I need a minimal reproduction config to actually work on it. If someone wants to make that, then I'll do what I can to fix it :)

Here is mine, and for what it's worth, I'm on macOS.
require("neogit").setup {
    use_default_keymaps = true,
    integrations = {
        diffview = false,
    },
    commit_editor = {
        kind = "vsplit",
        show_staged_diff = false,
        staged_diff_split_kind = "split"
    },
}

Alright, found a way to reproduce it! Thanks for the help, I'll try to fix this tonight after the kiddo is asleep

Here, the new commit does not create anymore the empty buffer when opening the popup, but it does show if we open the commit message buffer.

@CKolkey the empty buffer seems to be created by tabnew. Replacing the call of tabnew (in Buffer:show()) with tab sb <bufno> solved the problem for me.
diff --git a/lua/neogit/lib/buffer.lua b/lua/neogit/lib/buffer.lua
index 42c14789..c70f522e 100644
--- a/lua/neogit/lib/buffer.lua
+++ b/lua/neogit/lib/buffer.lua
@@ -258,8 +258,7 @@ function Buffer:show()
     api.nvim_set_current_buf(self.handle)
     win = api.nvim_get_current_win()
   elseif kind == "tab" then
-    vim.cmd("tabnew")
-    api.nvim_set_current_buf(self.handle)
+    vim.cmd("tab sb " .. self.handle)
     win = api.nvim_get_current_win()
   elseif kind == "split" then
     win = api.nvim_open_win(self.handle, true, { split = "below" })

the fix from @iH8c0ff33  also solved the problem for me.

Awesome - I'll have it shipped in a few minutes. Thank you @iH8c0ff33 !

@CKolkey new problem :)

Run Neogit - this create new tab
Close this tab - This close my buffer

https://github.com/NeogitOrg/neogit/assets/1789565/a4dcad38-7233-413b-9a2b-7f623b7cff31

depends on CWD

https://github.com/NeogitOrg/neogit/assets/1789565/ba35fb12-ae2d-49a3-82e0-bceecde2e3ec

guys, I've got a 2 year old and my wife is pregnant - feel free to submit a PR 😅
Anyways, I appreciate the patience otherwise :)

The fix works for me. No any empty buffers.

This is happening for me again.
One commit that causes this is https://github.com/NeogitOrg/neogit/commit/d639f5a5bd1f609d6a466b18a1c1e572bb7308bd.
Patching it this way closes them:
diff --git a/lua/neogit/lib/buffer.lua b/lua/neogit/lib/buffer.lua
index add3d56f..c074070c 100644
--- a/lua/neogit/lib/buffer.lua
+++ b/lua/neogit/lib/buffer.lua
@@ -209,7 +209,7 @@ function Buffer:close(force)
   if self.kind == "tab" then
     local ok, _ = pcall(vim.cmd, "tabclose")
     if not ok then
-      vim.cmd("tabnew")
+      vim.cmd("tab sb " .. self.handle)
       vim.cmd("tabclose #")
     end

@@ -279,7 +279,7 @@ function Buffer:show()
     api.nvim_set_current_buf(self.handle)
     win = api.nvim_get_current_win()
   elseif kind == "tab" then
-    vim.cmd("$tabnew")
+    vim.cmd("tab sb " .. self.handle)
     api.nvim_set_current_buf(self.handle)
     win = api.nvim_get_current_win()
   elseif kind == "split" or kind == "split_below" then


Enable content search in .leptonrc

As mentioned in https://github.com/hackjutsu/Lepton/issues/82, only the content of the downloaded snippets can be searched.  This feature doesn't seem to be useful, so I plan to make it disabled by default. Users should be able to enable it in .leptonrc.

Any news on this? I can't seem to find .leptonrc. Not being able to search through snippets/gists that are already downloaded to offline storage is pretty inconvenient.

the downloaded snippets can be searched？ how to use it ?


Incompatibility with Immersive Portals

When Immersive portals is installed with a mod that includes the newer versions of Incubus core there is a rendering issue caused on
transitional loading screens (death in another dimension or passing through a vanilla portal) where everything except hud elements goes completely black. this issue is not fixable by quitting and rejoining world, the only solution is to close and relaunch Minecraft.
this issue appears to only be present on newer versions of incubus core (what is included in spectrum)
and older versions do not have this issue (paradise lost)

This has since been fixed by yeeting bloom from Incubus-Core. Can be closed.


Fixed that lpar ''--defined-capacity' option takes boolean argument

No review needed.

coverage: 37.054%. remained the same
when pulling be6c1f7d95d77e9c9427b5d985c3c3e7f073b3d0 on andy/fix-lpar-defined-capacity
into 3cca72e103d93db99c0ea2b33c9a667fe714f140 on master.


Float values returned as strings

fmt.Sprintf("%T", ticker.XXBTZEUR.Volume[0]) == "string"
// returns true

Please see the discussion at #3

yeap! this is a duplicate. It makes sense that strings hold the exact info, making it float might lose in precision.


add more SI units

add Power as Watt
add Electrical Capacitance as farad
add Luminous Flux as lumen
add Luminous Intensity as candela
add Energy as joule
add easy to verify tests for new units and there prefixes(eg 1GJ == GigaJoule etc...)
add picoAsString to support ElectricalCapacitance
add picoAsString test

You may want to rebase on top of origin/master to help with the PR.

gohci


Add a newsletter subscription form

Done! See https://jamstack.club/theme/hugo-papermod/#newsletter

A dedicated branch was pushed: https://github.com/RoneoOrg/jamstack.club/tree/buttondown


array_run.py exception not working

I run cxsystem2 from command line, but it gives error due to value error which it does not understand as int. This is probably easy to fix (and I will), but probably there is some logic which fails, too. So I will make the correction, but can u Vafa check it.
(simuenv) PS C:\Users\Simo\Laskenta\Models\SchwabeModel\config_files> cxsystem2 -a .\exported_anatomy_example_short.csv -p .\exported_physiology_example_short.csv

Current run filename suffix is: 20191220_1115533
The system is running with euler integration method
simulation folder C:\Users\Simo\Laskenta\Models\SchwabeModel\test
ERROR      Brian 2 encountered an unexpected error. If you think this is bug in Brian 2, please report this issue either to the mailing list at http://groups.google.com/group/brian-development/, or to the issue tracker at https://github.com/brian-team/brian2/issues. Please include this file with debug information in your report: C:\Users\Simo\AppData\Local\Temp\brian_debug_xkx0hqp1.log  Additionally, you can also include a copy of the script that was run, available at: C:\Users\Simo\AppData\Local\Temp\brian_script_2gao56o6.py Thanks! [brian2]
Traceback (most recent call last):
File "c:/users/simo/laskenta/git_repos/cxsystem2/cxsystem2/hpc/array_run.py", line 429, in
ArrayRun(anatomy_df, physiology_df, suffix, cluster_start_idx, cluster_step, anat_file_address, physio_file_address, array_run_in_cluster, array_run_stdout_file)
File "c:/users/simo/laskenta/git_repos/cxsystem2/cxsystem2/hpc/array_run.py", line 66, in init
self.multidimension_array_run = int(parameter_finder(self.anatomy_df, 'multidimension_array_run'))
ValueError: invalid literal for int() with base 10: 'False'
(simuenv) PS C:\Users\Simo\Laskenta\Models\SchwabeModel\config_files> cxsystem2 -a .\exported_anatomy_example_short.csv -p .\exported_physiology_example_short.csv
Current run filename suffix is: 20191220_1117250
The system is running with euler integration method
simulation folder C:\Users\Simo\Laskenta\Models\SchwabeModel\test
ERROR      Brian 2 encountered an unexpected error. If you think this is bug in Brian 2, please report this issue either to the mailing list at http://groups.google.com/group/brian-development/, or to the issue tracker at https://github.com/brian-team/brian2/issues. Please include this file with debug information in your report: C:\Users\Simo\AppData\Local\Temp\brian_debug_6nt26ge0.log  Additionally, you can also include a copy of the script that was run, available at: C:\Users\Simo\AppData\Local\Temp\brian_script_ducgbhuy.py Thanks! [brian2]
Traceback (most recent call last):
File "c:/users/simo/laskenta/git_repos/cxsystem2/cxsystem2/hpc/array_run.py", line 429, in
ArrayRun(anatomy_df, physiology_df, suffix, cluster_start_idx, cluster_step, anat_file_address, physio_file_address, array_run_in_cluster, array_run_stdout_file)
File "c:/users/simo/laskenta/git_repos/cxsystem2/cxsystem2/hpc/array_run.py", line 66, in init
self.multidimension_array_run = int(parameter_finder(self.anatomy_df, 'multidimension_array_run'))
ValueError: invalid literal for int() with base 10: 'False'

can be solved by int(eval('True')), by adding the eval. I will do it in my branch but can u Vafa pls check the logic

The corrected versions are in branch macv1, if u can Vafa check and pull to master if u agree.

merged in 8d56217a5d6e6e8193f779f886f2042027e96f5f


feat: Intl API Performance

Fixes Issue

closes #3483
Changes proposed

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] My change requires changes to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Thanks @krshkun 👍  are there any visual changes from this?


Update documentation for breaking changes and improve usability of examples

In addition to updating docs to reflect breaking changes in MLJFlux 0.5.0 this PR:

fixes problems with docs/Project.toml that was causing doc generation to fail (silently, see #261)
removes docs/Manifest.toml
adds readme.md files for the workflow examples, and also commits a Manifest.toml for each example, so users can get a reliable stable version of packages known to work with the notebooks appearing there (see more in todo below)
adds generate.jl file in each example for maintainers to use to generate all the notebooks from .jl source
(temporarily?) replaced @example fencing with @julia fencing in generated example markdown
updates examples/mnist
fixes missing pkg metadata for new binary classifier
fixes the spam example so that it actually runs (e.g., add missing stop_words)

To do:

[x] Consider generating executed markdown for the examples (or re-instate @example fencing)
[x] Add links from the examples to the github folders that contain the notebook, julia source and Manifest.toml, so these can be accessed from the Documenter documentation
[x] Copy "examples/mnist" into "docs/src/work flows" (version in examples now flagged as "archived", ie not to be updated further)
[x] Fix remaining Documenter warnings about missing links and so forth.
[ ] Add a README.md in examples/ pointing users to the examples sections of /docs
[ ] Add documentation badge and dump most of /README.MD  and now redundant

cc @EssamWisam

cc @EssamWisam

Thanks for this significant effort 🙏.  I may mention that the local version of the spam example works for me without defining an explicit list of stop words or changing anything. They directly come from Languages.jl.
In further commits in MLJFlux or elsewhere, I will try to ensure running the Julia formatter (not a habit yet).

I may mention that the local version of the spam example works for me without defining an explicit list of stop words or changing anything. They directly come from Languages.jl.

Thanks for flagging! On further inspection I found a corrupted character (probably my bad) that explains my original problem but have re-instated the Languages.jl solution.

Closed in favour of #263


BUG?: Channel interpolation: exclude ref_meg in CTF data?

Interpolating channels from CTF data with _interpolate_bads_meg results in the interpolated channels having very high amplitude slow fluctuations, if gradient compensation/ref_meg channels are present. I think, similarly to #4663, the ref_meg channels have to be excluded for the reconstruction by setting ref_meg=False in the function. What makes me hesitating about this, is that they are actually explicitly included in the moment. Maybe that is related to changes discussed in #5292?
Anyway, I already made a tiny PR which attempts to fix that.
Please let me know if more details/examples are needed (i.e. if this bug is not so obvious).

I agree that they should probably be excluded.

Fixed in #6242


feat(pycontw-2023): add pycontw-2023

Types of changes

[x] New feature

Description
Add pycontw-2023 version

Please help me check if there is the word "PyCon APAC" that should be updated to "PyCon TW" https://github.com/pycontw/pycon.tw/search?q=APAC


Issue586

https://github.com/vizhub-core/vzcode/pull/new/issue586

Closing in favor of https://github.com/vizhub-core/vzcode/pull/646


CVSL-231: Fix case rule bug

Null check on rules.case - avoid undefined for conditions.

Codecov Report

Merging #109 (7239094) into main (35d4383) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #109      +/-   ##
==========================================
+ Coverage   67.50%   67.53%   +0.03%
==========================================
  Files         123      123
  Lines        2102     2104       +2
  Branches      320      322       +2
==========================================
+ Hits         1419     1421       +2
  Misses        683      683

Impacted Files
Coverage Δ

server/utils/conditionsProvider.ts
93.97% <100.00%> (+0.14%)
:arrow_up:


Database Update on Initial Migration

The documentation states that after you apply the initial migration you need to run a database update to update the schema.  It appears (maybe with a new tooling release?) that the database update automatically runs against your database when you run your initial migration.
Example:
Add-Migration Initial
This will create the initial migration file, the snapshot and create the database with a matching schema.

@scottkuhl This should not happen. Can you please file an issue on https://github.com/aspnet/EntityFrameworkCore/issues including a runnable project/solution or complete code listing that demonstrates the behavior you are seeing.


Required struct fields of type struct

Just started using Cuelang last week. Really enjoying it so far. I've run into a data modeling issue and am looking for help. Please let me know if there's a better place to ask these types of questions.
I'm modeling a service that has multiple types of operations. Each operation has a method ("READ" or "WRITE"), a request struct and and a response struct. Here's my code.
Operation :: {
	method: "READ" | "WRITE"
	...
}

CreateFoo :: Operation & {
	method: "WRITE"
	request: {
		foo: string
	}
	response: {
		message: string
	}
}

GetBar :: Operation & {
	method: "WRITE"
	request: {
		bar: string
	}
	response: {
		message: string
	}
}

How can I make Operation a closed struct, but still ensure the request and response fields are the correct type on concrete instances? I thought the following might work, but it doesn't work because {...} allows all fields.
Operation :: {
	method: "READ" | "WRITE"
	request: {...}
	response: {...}
}

// Same definitions as above

GetBarExample: GetBar & {
    request: {
        foo: "hey" // I want this to error, but it does not
    }
}

Any advice?

Slack is the best place to ask questions and learn all things Cue!
You can signup through the link here: https://cuelang.org/community/

Thanks @verdverm, wasn't sure where to ask these types of questions.

This issue has been migrated to https://github.com/cue-lang/cue/issues/372.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.


Allow special characters in DB connection parts

Details
Addresses #383, tests based on #384.
This approach uses urllib.prase.quote() to handle special characters in Postgres passwords and other conn string components.  This allows continuing to use URI style connection strings. There are a variety of places throughout the code that expect URI style connections.
The quote() method appears to handle the requirements defined by Postgres.

"The connection URI needs to be encoded with percent-encoding if it includes symbols with special meaning in any of its parts. Here is an example where the equal sign (=) is replaced with %3D and the space character with %20:"
From  Postgres libpq connection docs

Thank you @jmealo for all the sleuthing you did to determine the cause of the issue and suggesting a path forward!  I'll get an updated :latest image pushed soon, will comment here when that's ready.

@rustprooflabs: thanks for addressing this so quickly.


+(-1 - 1.i) return (1 +1.i)

Adding + in front of a complex number return a new complex with a positive value of the real and imaginary part.
require "complex"
pp! +( 1 + 1.i) # => (1.0 + 1.0i)
pp! +(-1 + 1.i) # => (1.0 + 1.0i)
pp! +( 1 - 1.i) # => (1.0 + 1.0i)
pp! +(-1 - 1.i) # => (1.0 + 1.0i)

This is caused by the instance method Complex#+
In Ruby, Python and C++, +(-1 - 1i) return (-1 - 1i).

Complex.+ methods returns the absolute value of self. Believe you are treating or expecting it to behave like normal unary operator on other primitives. Please refer to API documentation

@naqvis That's how it works but I think + should always return self. I'll fix this now.

Thanks @asterite. One question after change though: shouldn't it return a copy instead of returning self?

It's a struct (a copy is naturally returned) and it's immutable so a copy is never necessary (if it were a class).

It looks like Complex#+ was added by @Sija through #5440. Was there any reasoning for the current implementation?

@jhass Can't remember.


NpProfile need for orcid

Hi @vemonet, we are finally getting back into the nanopub realm as part of our work.
I wanted to ask you, why do you think the NpProfile constructor requires an orcid_id and a name?
These two values can be securely derived by a consumer application from the public key and the (one of many?) introductory nanopublications.
Such a consumer application should, also, not trust the orcid_id or name in the pubinfo as they could have been counterfeited.
Similarly, the introduction_nanopub_uri seems useful to simplify the task of authenticating a nanopublication, but it may also be considered optional, isn't it?
On the other hand, if the orcid_id value was verified by nanopub servers before "accepting" a nanopublication, then it becomes useful indeed. But I understand it's not the case currently.

Hi @pepoospina , indeed that is a good remark
Regarding signing ultimately we just need the private key to be provided in the profile
Currently you can provide an empty string as ORCID and name when defining the profile. But it should be Option<String> instead to make it clearer
I'll look into improving this soon (making ORCID and name "officially" optional)

NpProfile can be created without orcid now using the builder pattern (cf. docs)


chore: refresh lockfile

Description of changes

Refresh lockfile.

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

Please update PR title before merging


airbrussh configuration of command_output not working

Steps to reproduce
Using default airbrussh format in cap 3.8
In my deploy.rb I'm setting command_output to false, but everything still shows on the console.
set :log_level, :info
set :format_options, command_output: false, log_file: "deploy_logs/deploying.log"

Expected behavior
no output (or minimal) to console
Actual behavior
Full output to console, no matter what is set as command_output false or :stderr
System configuration
https://gist.github.com/avonderluft/d4ba9be7e7b40482042ba5d7805b3d0d

Closing in favor of https://github.com/mattbrictson/airbrussh/issues/104


Deploying 1.0 ver. of project

There was main development, mostly implementation of new fucntion, such as /ask, /imagine, connecting new APIs, etc.

Merging


[evm] README.md for language/evm #118 _71

This PR added and updated README.md files in the language/evm directory.
Motivation
To add README file for Move-On-EVM
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
CI/CD tests are covered.

/canary

:sunny: Canary successful

/land


chores(deps): bumps block-explorer-rpc-cosmos v1.1.2

This PR update version for 1 dependency:

github.com/bcdevtools/block-explorer-rpc-cosmos v1.1.1 → v1.1.2

Content:

Improve content returns for indexer.
Prevent crashing the entire method when batch query blocks for indexing.

@0xbcdev please handle conflicts

@trinitys7 done 🤝


Make the ping endpoint use a less expensive operation

Codecov Report

Merging #638 into develop will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff            @@
##           develop     #638   +/-   ##
========================================
  Coverage    96.44%   96.44%
========================================
  Files          129      129
  Lines         3878     3878
  Branches       334      334
========================================
  Hits          3740     3740
- Misses          96       97    +1
+ Partials        42       41    -1

Impacted Files
Coverage Δ

datahub/ping/services.py
81.81% <100%> (ø)
:arrow_up:

datahub/company/admin.py
86.2% <0%> (ø)
:arrow_up:

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 a3aa62d...a5f94e0. Read the comment docs.