Doesn't build on Apple Silicon Macbook

The new M1 Mac's (soon to be all of them) have aarch64 rather than X64 and libtorch is an X64 build under Rosetta 2. This means that it's impossible to link tch with libtorch on this architecture :-
error: linking with cc failed: exit code: 1
|
= note: "cc" "-arch" "arm64" "-L" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.15ldlvw3apdozeag.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.19h2avv3g2rhd8ti.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.19k1jx3fru64ijw.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.1drvgqderknvinw.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.1i8nis694q60f24z.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.1mc8upajqa89ioiy.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.1og2kkfufh9h9llu.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.1p12xb8dd5z0j2oa.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.1pj1c0klt22lo9eb.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.1yhxufjpoe6v7fy2.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.2748x699eb70qaub.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.29lcy82s6g0z7iaj.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.29m8kryg2qd2rmg2.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.2f988bwxfpist170.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.2oxmp72ki5h5bgom.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.2vi9u5dukbl2uikd.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.2wyusal9ofuiba04.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.3385vjp8b4qrvsel.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.341hltlph9ekebsv.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.38vuktn611oyjily.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.3ijtt36ou0xfx2q.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.3k9qu0jiv1tguaoo.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.3kol898l2xc7r2fk.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.3mwyqdu6b4b56evi.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.3xodh5jgs1shsurn.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.3ztkdehoqv5gwbvg.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4879d25nas295rwc.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4agna4wk1t7i24c0.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4ganrnseteo6um71.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4gs1duw6s4knjya3.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4h99wc936opjzbr4.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4mr4zqasfbbiqt95.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4odoazhzgp7jdfxj.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4pjbom7fy2c3x6k3.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4q75hu8bdv6maa09.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4rkxklzlpjccm2rp.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4t73n5mf8dh1e8v.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4u3ykpbbnmskcdeo.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4x7ycr1vw6a17erk.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.4xr6i5aecpyyyz2l.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.5eujk3ii2qx3naew.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.5ezkswgf5ujjvart.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.bqrrpmqse4jjosf.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.iamjjyae3ahp5a1.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.k85jn9gxqjkul62.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.ndflkalgmis3gfx.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.phwdoxrqnic8noa.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.qv44wvrs0ouwk8n.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.sfwv3547m4tyqoa.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.tumzygq7j6woxar.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.ucs77qj3p5djkf1.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.w02wi7sbm4ebo2u.rcgu.o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.yeopzie9w2k5x98.rcgu.o" "-o" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/narrative_classifier.2jlex06tk876gyub.rcgu.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps" "-L" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/build/bzip2-sys-da104762e0916b6d/out/lib" "-L" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/build/torch-sys-60923cbf24534296/out/libtorch/libtorch/lib" "-L" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/build/torch-sys-60923cbf24534296/out" "-L" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librust_bert-22b5d871339b3af2.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libuuid-59dbe3e868a23e7a.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcached_path-a669e071cdeb8ada.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libindicatif-1eb99454eca6b66a.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libconsole-69bf9721c340317b.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libterminal_size-c85d832c80ded689.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libunicode_width-7552a7347a12ef71.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libnumber_prefix-4b8da504c5b04c93.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtar-67768068e97046a1.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libxattr-a14e39c10a2acc0d.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libfiletime-9189dcb11ef4aef3.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libsha2-10faa6d397cd50a6.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libopaque_debug-c9886c8a42d67feb.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libdigest-9b0c84ffaf335058.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libblock_buffer-88681a4bfb306604.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libgeneric_array-f3db85fc3ca98ae3.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtypenum-d9021e3095ef20df.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libreqwest-cf252d3f0f8f8a4e.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libhyper_tls-6f91120669ddd5f8.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libipnet-1dd64096f9ad9e2b.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtokio_native_tls-3b89642b23a8411c.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libserde_urlencoded-0eb1ea4b5052d917.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libmime-3208b3fe7b236677.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libencoding_rs-a423a5c326f4cd93.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libbase64-bc658a2968b862df.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libnative_tls-104265da39a49a00.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libsecurity_framework-e4472c713bc8bbce.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libbitflags-030f118ea26aedff.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libsecurity_framework_sys-f35a4ac0d9af2c8c.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcore_foundation-b798140f37eff239.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcore_foundation_sys-c76011a369868cd1.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libhyper-bf06f7dece7babd5.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libwant-0fdb0d120e00e2bd.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtry_lock-cebe2710626a5a5f.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libsocket2-dcdf550458ae34b3.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libh2-f82066f5b5d4858d.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libindexmap-de0e9fe73c83f54c.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtokio_util-c2ef2aa1d25f9a13.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libfutures_sink-b663b9a0f34dd3f0.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libhttparse-dd238fbfc3464d8c.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtower_service-0bcc09f6f2f22ddf.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libfutures_channel-561aad3ef42c612e.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libpin_project-0c351c981600f056.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtracing-8e9eedfcaffc51d5.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtracing_core-a5586b1cf02fbea1.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtokio-98aafedb3612e2f5.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libmio-4faa90949040754b.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libhttp_body-433cf431bdea4b47.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libfutures_util-3333d10e4623a121.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libfutures_io-562bd1db47ac4c81.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libslab-32852292e25369fe.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libpin_project_lite-51acda515f28381f.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libfutures_task-20a6995672651029.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libpin_utils-e8405942408c137b.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libfutures_core-7d11d6f68192380a.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/liburl-471a025d86db93ff.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libidna-8ed5c58755c97a68.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libunicode_bidi-1df927e8c7b47415.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libform_urlencoded-0427c9dae3f09e3e.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libpercent_encoding-d6d0e159d15dce06.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libmatches-35c5af35eea35aeb.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libhttp-553426dc06b9a18d.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libbytes-b77e6f1391cab4e4.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libfnv-f99eac24deb045f1.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/liblog-4b76127376bc5b1a.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libglob-6c8f7279ee00d982.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libfs2-691c358e52680afe.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libzip_extensions-3921b8ea20f9fd79.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtempfile-4f86e5156c031477.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librand-b2eda018ada2095a.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librand_chacha-7f5f703ae490b9b8.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librand_core-0a0b5f472ae7d3cb.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libgetrandom-284492ff4877b1f1.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libremove_dir_all-63851b140a9045a2.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librust_tokenizers-b98c537487a8e07f.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcsv-c07091acee32b5e2.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcsv_core-9d5176115b5dc5c8.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libbstr-ac8770f63502da28.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libregex_automata-5291171fd6baa0eb.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libserde_json-25ae71fbc7a43861.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libryu-1949ebb3519781f9.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libitoa-caf97236d8888691.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libhashbrown-8b769448b8309382.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libahash-3a0653294e22af62.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libprotobuf-b8c24797dd2327fd.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libunicode_normalization_alignments-053ebe83ca18b7cc.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libsmallvec-9885992c67518033.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libunicode_normalization-fe8f39032a5c21ae.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtinyvec-ecf8eb0eef2475af.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtinyvec_macros-0172dbcfdf06e0ea.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libregex-216d3a71113d1bf2.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libregex_syntax-73dcf24cf9ac5df8.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libaho_corasick-ab2e649414d7d939.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libmemchr-545956354737ddc5.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librayon-52f6bfcf8ae438b1.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librayon_core-98b46b792c441fac.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libnum_cpus-bbb7934e3929db46.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcrossbeam_deque-2ef262a584d0c06e.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcrossbeam_epoch-055ecc85c181a03d.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libmemoffset-d9b5cb5ebd2d3c78.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libscopeguard-f25606b1925e796a.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcrossbeam_channel-a934b7eeeb8d91cf.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcrossbeam_utils-9d22a394ff209c4b.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libitertools-cfbd17c8e11620e5.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libeither-1dda02df6fcc2a1c.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libserde-95884dcf90521c85.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libordered_float-8c24136dcb701918.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtch-f07f0412cf21f5a4.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libndarray-e9509ed28684ba60.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libmatrixmultiply-d42816c01cc503f4.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libnum_complex-69c9368b0cb9b262.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libnum_integer-dccdd1145051f437.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libnum_traits-252500b0c5d20cb1.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librawpointer-61af2a797cefda08.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librand-f982c39add7e3af3.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librand_chacha-3df058882a83d743.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libppv_lite86-b5c231b3ae995b69.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/librand_core-8dd9c695d1d013b2.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libgetrandom-7ec072f85656f020.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libhalf-d81be47b888a5a5f.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtorch_sys-73aea0ccfd975e23.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libzip-41260ffcbcd5f7cb.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libtime-dc217430295069a8.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libbzip2-0eba3cf253a17e65.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libbzip2_sys-242b4359734cc246.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libflate2-7d3e59e4ac63a930.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libminiz_oxide-4df2be6f2114562e.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libadler-5d80528d67dfb908.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libbyteorder-a2f923529288ff0c.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcrc32fast-da49b74d46580a02.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libcfg_if-5d0655e343ff9cae.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libthiserror-86271e4e2281b277.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/liblazy_static-5f023eb1b908c20e.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libdirs-1e15038404d54f6d.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libdirs_sys-e3b1606003fcabb8.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/liblibc-84a68858766e2a51.rlib" "/Users/andrew/CLionProjects/narrative-classifier/target/debug/deps/libanyhow-0e186a4f01ae1c08.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd-e40bd6a3af835df4.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-68aa428439efc3d3.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libobject-e8883902f5c364b6.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libaddr2line-a950b2eed913eb15.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libgimli-9ce7597f6151ffc2.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_demangle-6a556d2584ddcc81.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libhashbrown-e62ba676fce5c547.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_alloc-509c1845891b6a82.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libunwind-082f7f4ff792426f.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcfg_if-28ab4d9e8295eb15.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liblibc-e9e7769a4bdcb2d3.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liballoc-94664336047de1ce.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_core-8df6af481e225202.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcore-214021ad04ab7aee.rlib" "/Users/andrew/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcompiler_builtins-9eb7dc999785b765.rlib" "-framework" "Security" "-framework" "CoreFoundation" "-lc++" "-ltorch" "-ltorch_cpu" "-lc10" "-liconv" "-lSystem" "-lresolv" "-lc" "-lm"
= note: ld: warning: ignoring file /Users/andrew/CLionProjects/narrative-classifier/target/debug/build/torch-sys-60923cbf24534296/out/libtorch/libtorch/lib/libtorch.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /Users/andrew/CLionProjects/narrative-classifier/target/debug/build/torch-sys-60923cbf24534296/out/libtorch/libtorch/lib/libc10.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /Users/andrew/CLionProjects/narrative-classifier/target/debug/build/torch-sys-60923cbf24534296/out/libtorch/libtorch/lib/libtorch_cpu.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture arm64:
"typeinfo for c10::AutogradMetaInterface", referenced from:
typeinfo for torch::autograd::AutogradMeta in libtorch_sys-73aea0ccfd975e23.rlib(torch_api.o)

Did you figure this out?

Looking at the compilation failures above, it seems that the tch-rs code is compiled for arm64 but tries to link with x86 binaries for libtorch. The libtorch binaries are automatically downloaded from the pytorch website and afaik only x86 binaries are available there.
Not sure if it's possible to build pytorch for arm64, if that's the case you can try doing so and use the LIBTORCH environment variable to point tch-rs at it (details on the main readme).
Alternatively, maybe it's possible to compile tch-rs for x86 on your platform but I wouldn't know how to do this nor do I have access to an arm macos box.

@azw413 I just had this same problem while attempting to build (sleef)[https://sleef.org/] on an M1 Mac mini.
Let me know if you figure this out - I haven't yet.

I have it working on my M1 mac, I used pip3 install torch and copied the libraries from it. There are precompiled aarch64 macos dylibs in the wheels distributed with the torch package. The precompiled aarch64 macos dylibs don't seem to be available anywhere else as far as I can tell.
While I'm here, I'd like to share the solution to a problem I was having on my M1 mac with this because it took me so long to solve:
I'm using a custom install of libtorch (from pip) at a custom path and kept getting rpath errors from dyld about how the library could not be found.
dyld: Library not loaded: @rpath/libtorch.dylib
  Referenced from: /Users/mark/app/target/debug/app
  Reason: image not found
sh: line 1: 34785 Abort trap: 6

Putting the dyld next to executable solved the problem but that's not a real solution. I kept trying to use DYLD_LIBRARY_PATH, DYLD_FALLBACK_LIBRARY_PATH, etc., I tried using println!("cargo:rustc-link-search=native=path") in a build.rs, I tried a lot of things and nothing worked.
Eventually I checked env and sure enough, DYLD_LIBRARY_PATH was not there despite echo $DYLD_LIBRARY_PATH showing a value... This is due to "System Integrity Protection": env vars starting with DYLD are not passed to protected executables. The solution to this is to disable SIP or symlink your dylibs into /usr/local/lib.
That was a massive headache to find out and I wasn't able to find any information about this until I started looking for why DYLD_LIBRARY_PATH was not showing up in the output of env. I hope sharing this information here is able to save someone that hassle.

For Xcode 13.1 users... I also had a problem with curl that is addressed here https://github.com/rust-lang/rust/issues/90342
An additional export is needed if you see ld: reference to symbol (which has not been assigned an address) __ZN4curl4init9INIT_CTOR17he9a2e3e218d0021fE in '__ZN4curl4init17he40dac590a19b3f7E'

Waz relationship between rust and python? Pytorch seems a python project, why could be resolve a issue about  rust compile?

Here is the precise procedure to follow:

Clone version 1.8.1 of Pytorch

git clone --branch v1.8.1 --recurse-submodule https://github.com/pytorch/pytorch.git

Create a new folder and build with cmake (to be installed via brew if not already done)

mkdir pytorch-build
cd pytorch-build
cmake -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_BUILD_TYPE:STRING=Release -DPYTHON_EXECUTABLE:PATH=`which python3` -DCMAKE_INSTALL_PREFIX:PATH=../pytorch-install ../pytorch
cmake --build . --target install

Define the following variables before launching your cargo build.

export LIBTORCH=/path/to/pytorch-install
export LD_LIBRARY_PATH=${LIBTORCH}/lib:$LD_LIBRARY_PATH

If I'm not too clear on the procedures, don't hesitate to come back to me :)

I tried to use the command listed up there, but then I am hitting this error at the very end. Any clue how can I solve that?
[100%] Linking CXX shared library ../../lib/libcaffe2_detectron_ops.dylib
Undefined symbols for architecture arm64:
  "___kmpc_for_static_fini", referenced from:
      _.omp_outlined. in upsample_nearest_op.cc.o
  "___kmpc_for_static_init_4", referenced from:
      _.omp_outlined. in upsample_nearest_op.cc.o
  "___kmpc_fork_call", referenced from:
      caffe2::UpsampleNearestOp<float, caffe2::CPUContext>::RunOnDevice() in upsample_nearest_op.cc.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libcaffe2_detectron_ops.dylib] Error 1
make[1]: *** [modules/detectron/CMakeFiles/caffe2_detectron_ops.dir/all] Error 2
make: *** [all] Error 2

Thanks for the detailed instructions, unfortunately I got a segfault in clang when compiling :-
[ 67%] Building C object sleef/src/libm/CMakeFiles/sleefsve.dir/sleefsimdsp.c.o clang: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument] clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple clang version 12.0.5 (clang-1<IP_ADDRESS>) Target: aarch64-apple-darwin20.4.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I did a bit of searching but nothing looked useful.

idk if this is related, since your error looks slightly different, but initially attempting to build libtorch i also got an error at around 67 %, which went away and i got a successful build after deleting the protobuf package (brew uninstall protobuf)

@taminki
$ brew ls --verbose libtorch | grep dylib
/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib
/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch_global_deps.dylib
/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch_cpu.dylib
/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libc10.dylib
 $ export LIBTORCH=/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib
Brandons-MacBook-Air:quant brandonros 2022-06-23 10:28:18 $ cargo build
   Compiling torch-sys v0.7.2
The following warnings were emitted during compilation:

warning: clang: warning: -Wl,-rpath=/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib/lib: 'linker' input unused [-Wunused-command-line-argument]
warning: libtch/torch_api.cpp:1:9: fatal error: 'torch/csrc/autograd/engine.h' file not found
warning: #include<torch/csrc/autograd/engine.h>
warning:         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
warning: 1 error generated.

error: failed to run custom build command for `torch-sys v0.7.2`

Caused by:
  process didn't exit successfully: `/Users/brandonros/Desktop/quant/target/debug/build/torch-sys-9541fb47d72ab990/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=TORCH_CUDA_VERSION
  cargo:rerun-if-env-changed=LIBTORCH
  cargo:rustc-link-search=native=/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib/lib
  cargo:rerun-if-changed=libtch/torch_api.cpp
  cargo:rerun-if-changed=libtch/torch_api.h
  cargo:rerun-if-changed=libtch/torch_api_generated.cpp.h
  cargo:rerun-if-changed=libtch/torch_api_generated.h
  cargo:rerun-if-changed=libtch/stb_image_write.h
  cargo:rerun-if-changed=libtch/stb_image_resize.h
  cargo:rerun-if-changed=libtch/stb_image.h
  cargo:rerun-if-env-changed=LIBTORCH_CXX11_ABI
  TARGET = Some("aarch64-apple-darwin")
  OPT_LEVEL = Some("0")
  HOST = Some("aarch64-apple-darwin")
  CXX_aarch64-apple-darwin = None
  CXX_aarch64_apple_darwin = None
  HOST_CXX = None
  CXX = None
  CXXFLAGS_aarch64-apple-darwin = None
  CXXFLAGS_aarch64_apple_darwin = None
  HOST_CXXFLAGS = None
  CXXFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  CARGO_CFG_TARGET_FEATURE = Some("aes,crc,dit,dotprod,dpb,dpb2,fcma,fhm,flagm,fp16,frintts,jsconv,lor,lse,neon,paca,pacg,pan,pmuv3,ras,rcpc,rcpc2,rdm,sb,sha2,sha3,ssbs,vh")
  running: "c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-arch" "arm64" "-I" "/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib/include" "-I" "/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib/include/torch/csrc/api/include" "-Wl,-rpath=/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib/lib" "-std=c++14" "-D_GLIBCXX_USE_CXX11_ABI=1" "-o" "/Users/brandonros/Desktop/quant/target/debug/build/torch-sys-7c94b7b2979661c3/out/libtch/torch_api.o" "-c" "libtch/torch_api.cpp"
  cargo:warning=clang: warning: -Wl,-rpath=/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib/lib: 'linker' input unused [-Wunused-command-line-argument]
  cargo:warning=libtch/torch_api.cpp:1:9: fatal error: 'torch/csrc/autograd/engine.h' file not found
  cargo:warning=#include<torch/csrc/autograd/engine.h>
  cargo:warning=        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  cargo:warning=1 error generated.
  exit status: 1

  --- stderr

  error occurred: Command "c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-arch" "arm64" "-I" "/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib/include" "-I" "/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib/include/torch/csrc/api/include" "-Wl,-rpath=/opt/homebrew/Cellar/libtorch/1.11.0_1/lib/libtorch.dylib/lib" "-std=c++14" "-D_GLIBCXX_USE_CXX11_ABI=1" "-o" "/Users/brandonros/Desktop/quant/target/debug/build/torch-sys-7c94b7b2979661c3/out/libtch/torch_api.o" "-c" "libtch/torch_api.cpp" with args "c++" did not execute successfully (status code exit status: 1).

 $ uname -a
Darwin Brandons-MacBook-Air.local 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:29 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T8101 arm64

Nevermind, had these wrong:
export LIBTORCH=/opt/homebrew/Cellar/libtorch/1.11.0_1
export LD_LIBRARY_PATH=${LIBTORCH}/lib:$LD_LIBRARY_PATH

from

$ brew ls --verbose libtorch | grep dylib

Hello all,
same question here, PyTorch does support but not sure for the lib torch.
Jianshu

export LIBTORCH=/opt/homebrew/Cellar/libtorch/1.11.0_1
export LD_LIBRARY_PATH=${LIBTORCH}/lib:$LD_LIBRARY_PATH

from
brew ls --verbose libtorch | grep dylib

works great.
Do we know if the version of libtorch from brew on arm64 has support for the "MPS" Apple M1 GPU built in?

Can you please show how to make it work on MacOS arm, I still have the same error after following your suggestions.
Thanks,
Jianshu

Closing in favor of #488


How would you recommend this is used

Hi, the wonderful solution here. Meets my requirements 100%. However I have some issues, I have been able to install and work with this on my server, using socketio as a layer to the client and all works well. But as expected, it uses my server's IP and also my servers internet speed. I have also tried making this a clientside module using browserify, I first encountered an issue with util.promisify which I solved by polyfilling and now another issue with fs.statSync not being a function.
Who has been able to successfully deploy this package to work well with the client and how have you done so?
Server: Heroku
Environment: Nodejs, with Plain html, css and Js

This module cannot work in the browser since it uses the official Speedtest command line client which cannot run in the browser.


sensu_api_validator fails when Backend has SSL enabled

Description of problem
Puppet run fails on sensu_api_validator Exec when Backend has SSL enabled (cert-file and key-file specified in backend.yml, as it always assumes HTTP.  The underlying code actually has a use_ssl parameter, but the incantation in sensu::backend doesn't currently set it.
Command used and debugging output
$ puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for mgmt01.example.org
Info: Applying configuration version '1545709040'
Notice: /Stage[main]/Sensu::Backend/Service[sensu-backend]/ensure: ensure changed 'stopped' to 'running'
Info: /Stage[main]/Sensu::Backend/Service[sensu-backend]: Unscheduling refresh on Service[sensu-backend]
Notice: Unable to connect to sensu_api server (http://<IP_ADDRESS>:7001): Failed to open TCP connection to <IP_ADDRESS>:7001 (Connection refused - connect(2) for "<IP_ADDRESS>" port 7001)
Notice: Failed to connect to sensu_api; sleeping 2 seconds before retry
Notice: Unable to connect to sensu_api server (http://<IP_ADDRESS>:7001): wrong status line: "\x15\x03\x01\x00\x02\x02"
Notice: Failed to connect to sensu_api; sleeping 2 seconds before retry
Notice: Unable to connect to sensu_api server (http://<IP_ADDRESS>:7001): wrong status line: "\x15\x03\x01\x00\x02\x02"
Notice: Failed to connect to sensu_api; sleeping 2 seconds before retry
Notice: Unable to connect to sensu_api server (http://<IP_ADDRESS>:7001): wrong status line: "\x15\x03\x01\x00\x02\x02"
Notice: Failed to connect to sensu_api; sleeping 2 seconds before retry
...

Platform and version information

Your OS: CentOS 7.5
Your version of Puppet: OS Puppet 6.1.0
Your version of Sensu: Sensu-Go 5.1.0
Your version of this module: sensu2 (https://github.com/sensu/sensu-puppet/commit/fa0dfd176075925c4f9fc1f7d9c5e2c86d3b38de)

@rickatnight11 Would it be possible to share your Puppet definition for sensu::backend?  I would like to add some SSL acceptance tests to verify SSL works with the types and our execution of sensuctl but am having some issues properly configuring the backend I think, or maybe because I'm using self-signed certificates.

@treydock, certainly:
sensu::backend::config_hash:
  agent-host: '<IP_ADDRESS>'
  agent-port: 7002
  api-listen-address: '<IP_ADDRESS>:7000'
  use_ssl: true
  cert-file: '/etc/sensu/ssl/sensu-backend.pem'
  key-file: '/etc/sensu/ssl/sensu-backend.key'
  trusted-ca-file: '/etc/ipa/ca.crt'
  dashboard-host: '<IP_ADDRESS>'
  dashboard-port: 7001
  log-level: info

I'm using the new use_ssl parameter my linked PR adds (happy to handle this a different way, though).  The cert-file / key-file params are pointing at files provided by my IPA service:
$ ipa-getcert list -i<PHONE_NUMBER>2626
Number of certificates and requests being tracked: 10.
Request ID '20181203002626':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/sensu/ssl/sensu-backend.key'
        certificate: type=FILE,location='/etc/sensu/ssl/sensu-backend.pem'
        CA: IPA
        issuer: CN=Certificate Authority,O=EXAMPLE.ORG
        subject: CN=mgmt01.example.org,O=EXAMPLE.ORG
        expires: 2020-12-03 00:26:28 UTC
        dns: mgmt01.example.org
        principal name<EMAIL_ADDRESS>        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command:
        post-save command:
        track: yes
        auto-renew: yes

...and trusted-ca-file is pointed at that same IPA service's CA cert.  I've also added that CA cert to the system trust store across all my CentOS 7.5 systems (copied cert to /etc/pki/ca-trust/source/anchors/ and ran update-ca-trust), which I believe is what allowed my sensuctl and Sensu Agents trust the Backend.
I'm not sure how to get trust established if using a self-signed cert.  You could totally create your own temporary CA cert, import it into your system trust-stores, like I did above, then sign a cert with it for your backend to use.

@rickatnight11 Thanks.  I'm assuming you ran sensuctl configure to ensure it was using SSL?

Yep! My api-url in ~/.config/sensu/sensuctl/cluster is set to https://mgmt01.example.org:7000.

Good to know.  I opened #1025 that documents the issue with current handling of sensuctl configure.  Ideally one wouldn't have to manually re-run sensuctl configure and given the way its state is stored it should be possible to make a type/provider around sensuctl configure.

Is this still an issue using the latest version with the merged SSL code you two worked on?

This is now working for me using the latest code on the sensu2 branch.  @treydock extended my original PR with https://github.com/sensu/sensu-puppet/pull/1027.


added ListResponse to RefList and ExampleList

I wonder why the white-space on some items changed, though? (not very important)
LGTM overall, merge away.
P.S. Ping me when you send a change to implement this too, I'd like to see it (I can review it too, if you like).

The whitespace changes are because Atom automatically trims whitespace at the end of each line.

@neelance That's actually really nice. LGTM

LGTM.
Sublime Text does that too if you set "trim_trailing_white_space_on_save": true in preferences. It's like a mini-gofmt-on-save for non .go files.


Remote task cur_dir broken?

I'm running remote tasks and got this error
TRACE: Step becomes task_pending
TRACE: Start submitting M10_986ce4efb43ae3434c72d0d17ab3b9b9 (status: pending)
INFO: M10_986ce4efb43ae3434c72d0d17ab3b9b9 sending [R_library("rhdf5"), ...] (30 items)
ERROR: 'cur_dir'

The v4 info is long but not informative to me. I'll be happy to post more details if the bug cannot be reproduced. My task configuration is:
task: workdir = cwd, walltime = '10m', cores = 1, mem = "8G",
        trunk_size = 200, trunk_workers = 1

and I use ${cur_dir} the same way as documented here

BTW the error persists even if I remove all ${cur_dir} from my host.yml .

Seems like cur_dir is not in the dictionary. Let me see if I can identify the problem without an example.

Not sure what is going on because cur_dir seems to be defined in all relevant environments. Could you send me your site.cfg and scripts or create an example?

I was not aware there is a site.cfg file! I have a host.yml ... is that the reason (that we renamed the config file default name)?

My typo. There is a sos_site.cfg for system admin though.

Great -- I get this MWE:
[1]
genes = ["A", "B", "C", "D"]
tissues = [1,2,3,4]
input: for_each = ['genes', 'tissues']
output: "${_tissues}_${_genes!b}.txt"
task: walltime = '10m', cores = 1, mem = "2G",
        trunk_size = 200, trunk_workers = 1
bash:
 echo hello > ${_output}

The key is the loops. I do not think configuration matters but it is here:
  midway2:
    description: xxx xxx xxx
    address<EMAIL_ADDRESS>    paths:
      home: /home/gaow
    queue_type: pbs
    status_check_interval: 120
    max_running_jobs: 30
    max_cores: 40
    max_walltime: "36:00:00"
    max_mem: 64G
    job_template: |
      #!/bin/bash
      #SBATCH --time=${walltime}
      #SBATCH --nodes=1
      #SBATCH --ntasks-per-node=${cores}
      #SBATCH --mem-per-cpu=${mem//10**9}G
      #SBATCH --job-name=${job_name}
      #SBATCH --output=${cur_dir}/.sos/${job_name}.out
      #SBATCH --error=${cur_dir}/.sos/${job_name}.err
      cd ${cur_dir}
      mkdir -p .sos
      sos execute ${task} -v ${verbosity} -s ${sig_mode} ${'--dryrun' if run_mode == 'dryrun' else ''}
    walltime: "06:00:00"
    cores: 20
    mem: 1G
    submit_cmd: sbatch ${job_file}
    submit_cmd_output: "Submitted batch job {job_id}"
    status_cmd: squeue --job ${job_id}
    kill_cmd: scancel ${job_id}

Cannot replicate.

You say config does not matter, do you see the same problem with local tasks?

Hmm this is interesting. I said config does not matter because I removed cur_dir from ~/.sos/hosts.yml yet it still did not work.
Local tasks works well. Here is the complete v4 output. The same setup (with loop) used to work for me -- like a month ago. Not sure what is going on here. It complains site_config.yml  does not exist. Is that the issue?
[GW] sos run /tmp/1.sos -q midway2 -v 4
DEBUG: Workflow default created with 1 sections: default_1
TRACE: /opt/miniconda3/lib/python3.6/site-packages/sos-<IP_ADDRESS>-py3.6.egg/sos/site_config.yml does not exist
DEBUG: Args "${_tissues}_${_genes!b}.txt"
 cannot be determined: name '_tissues' is not defined
DEBUG: Args "${_tissues}_${_genes!b}.txt"
 cannot be determined: name '_tissues' is not defined
DEBUG: Master execute f5fc5b94889fe1551d4b4e475ea8cc6e from DAG
DEBUG: Worker SoS_Worker-1 receives request ('step', <sos.sos_script.SoS_Step object at 0x7fdbba893cf8>, {'__signature_vars__': {'_output'}, '__environ_vars__': {'trunk_size', 'walltime', 'mem', 'trunk_workers', 'for_each', '_tissues', '_genes', 'cores', 'b'}, '__changed_vars__': set(), '__step_output__': [], '__completed__': [], '__workflow_sig__': '/home/gaow/.sos/6b25451e54bb9efe.sig'}, {}, [], 'run', 'default', 4)
DEBUG: Worker SoS_Worker-1 working on default_1 with args []
TRACE: /opt/miniconda3/lib/python3.6/site-packages/sos-<IP_ADDRESS>-py3.6.egg/sos/site_config.yml does not exist
INFO: Executing default_1:
TRACE: Handling input statement for_each = ['genes', 'tissues']

INFO: input:    []
DEBUG: Set _genes = 'A'
DEBUG: Set _tissues = 1
DEBUG: _input: []
TRACE: Lock acquired for output files [1_A.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/fea6571f5379be89c1cea875ad01cb56.exe_info
TRACE: Lock released for output files [1_A.txt]
DEBUG: Set _genes = 'B'
DEBUG: Set _tissues = 1
DEBUG: _input: []
TRACE: Lock acquired for output files [1_B.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/d2c76f2b4836d129b55b965069629981.exe_info
TRACE: Lock released for output files [1_B.txt]
DEBUG: Set _genes = 'C'
DEBUG: Set _tissues = 1
DEBUG: _input: []
TRACE: Lock acquired for output files [1_C.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/29d2f88e849e864468c66465ffd0428f.exe_info
TRACE: Lock released for output files [1_C.txt]
DEBUG: Set _genes = 'D'
DEBUG: Set _tissues = 1
DEBUG: _input: []
TRACE: Lock acquired for output files [1_D.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/07f2fbfc20219ea7bbe10ccc67a76513.exe_info
TRACE: Lock released for output files [1_D.txt]
DEBUG: Set _genes = 'A'
DEBUG: Set _tissues = 2
DEBUG: _input: []
TRACE: Lock acquired for output files [2_A.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/1c792fe6fe7c6fc6d9aa4767d3457c18.exe_info
TRACE: Lock released for output files [2_A.txt]
DEBUG: Set _genes = 'B'
DEBUG: Set _tissues = 2
DEBUG: _input: []
TRACE: Lock acquired for output files [2_B.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/07709cff531380018881efccdf31b154.exe_info
TRACE: Lock released for output files [2_B.txt]
DEBUG: Set _genes = 'C'
DEBUG: Set _tissues = 2
DEBUG: _input: []
TRACE: Lock acquired for output files [2_C.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/47da45fc8348fe9a1e56db35b42d7e18.exe_info
TRACE: Lock released for output files [2_C.txt]
DEBUG: Set _genes = 'D'
DEBUG: Set _tissues = 2
DEBUG: _input: []
TRACE: Lock acquired for output files [2_D.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/a639ba132d522c6424cf4c69c45b04c6.exe_info
TRACE: Lock released for output files [2_D.txt]
DEBUG: Set _genes = 'A'
DEBUG: Set _tissues = 3
DEBUG: _input: []
TRACE: Lock acquired for output files [3_A.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/63bf9f3949df24846e6da1e3c4903c8c.exe_info
TRACE: Lock released for output files [3_A.txt]
DEBUG: Set _genes = 'B'
DEBUG: Set _tissues = 3
DEBUG: _input: []
TRACE: Lock acquired for output files [3_B.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/5cf9a2f2eaae85e8110cd1c998092c13.exe_info
TRACE: Lock released for output files [3_B.txt]
DEBUG: Set _genes = 'C'
DEBUG: Set _tissues = 3
DEBUG: _input: []
TRACE: Lock acquired for output files [3_C.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/0b3c6b6a2855c0262a97abd263f3457b.exe_info
TRACE: Lock released for output files [3_C.txt]
DEBUG: Set _genes = 'D'
DEBUG: Set _tissues = 3
DEBUG: _input: []
TRACE: Lock acquired for output files [3_D.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/59ccb27ddc07378bad5789a4d78bae72.exe_info
TRACE: Lock released for output files [3_D.txt]
DEBUG: Set _genes = 'A'
DEBUG: Set _tissues = 4
DEBUG: _input: []
TRACE: Lock acquired for output files [4_A.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/559dfb05755a215fd7b10cfcd922ef39.exe_info
TRACE: Lock released for output files [4_A.txt]
DEBUG: Set _genes = 'B'
DEBUG: Set _tissues = 4
DEBUG: _input: []
TRACE: Lock acquired for output files [4_B.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/3038211898d1a345baa018b16086c041.exe_info
TRACE: Lock released for output files [4_B.txt]
DEBUG: Set _genes = 'C'
DEBUG: Set _tissues = 4
DEBUG: _input: []
TRACE: Lock acquired for output files [4_C.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/c8c01794cb044b68cee44a8b6099c4c7.exe_info
TRACE: Lock released for output files [4_C.txt]
DEBUG: Set _genes = 'D'
DEBUG: Set _tissues = 4
DEBUG: _input: []
TRACE: Lock acquired for output files [4_D.txt]
DEBUG: Signature mismatch: Missing signature file /home/gaow/.sos/.runtime/0edaea3718cb46bd832768a67425bca3.exe_info
TRACE: Lock released for output files [4_D.txt]
DEBUG: Send ['M16_36934469c90d2d7f4fa78b1620fa3e15']
DEBUG: Master receives task request tasks __default__ M16_36934469c90d2d7f4fa78b1620fa3e15
DEBUG: Executing command ssh -q<EMAIL_ADDRESS>-p 22 "bash --login -c '[ -d /home/gaow/ ] || mkdir -p /home/gaow/; cd /home/gaow/ && sos status  -v 2  --start-time '"
DEBUG: Executing command ssh -q<EMAIL_ADDRESS>-p 22 "bash --login -c '[ -d /home/gaow/ ] || mkdir -p /home/gaow/; cd /home/gaow/ && squeue --job 37015344'"
slurm_load_jobs error: Invalid job id specified
DEBUG: Check output of ssh -q<EMAIL_ADDRESS>-p 22 "bash --login -c '[ -d /home/gaow/ ] || mkdir -p /home/gaow/; cd /home/gaow/ && squeue --job 37015344'"  failed: Command 'ssh -q<EMAIL_ADDRESS>-p 22 "bash --login -c '[ -d /home/gaow/ ] || mkdir -p /home/gaow/; cd /home/gaow/ && squeue --job 37015344'" ' returned non-zero exit status 1.
TRACE: Failed to query status for task cb18c46221c3c7607c12907c5b767a01: Command 'ssh -q<EMAIL_ADDRESS>-p 22 "bash --login -c '[ -d /home/gaow/ ] || mkdir -p /home/gaow/; cd /home/gaow/ && squeue --job 37015344'" ' returned non-zero exit status 1.
DEBUG: Executing command ssh -q<EMAIL_ADDRESS>-p 22 "bash --login -c '[ -d /home/gaow/ ] || mkdir -p /home/gaow/; cd /home/gaow/ && squeue --job 37015486'"
slurm_load_jobs error: Invalid job id specified
DEBUG: Check output of ssh -q<EMAIL_ADDRESS>-p 22 "bash --login -c '[ -d /home/gaow/ ] || mkdir -p /home/gaow/; cd /home/gaow/ && squeue --job 37015486'"  failed: Command 'ssh -q<EMAIL_ADDRESS>-p 22 "bash --login -c '[ -d /home/gaow/ ] || mkdir -p /home/gaow/; cd /home/gaow/ && squeue --job 37015486'" ' returned non-zero exit status 1.
TRACE: Failed to query status for task b54336fcb61b7484bce8ccfd2f51501b: Command 'ssh -q<EMAIL_ADDRESS>-p 22 "bash --login -c '[ -d /home/gaow/ ] || mkdir -p /home/gaow/; cd /home/gaow/ && squeue --job 37015486'" ' returned non-zero exit status 1.
TRACE: Step becomes task_pending
TRACE: Start submitting M16_36934469c90d2d7f4fa78b1620fa3e15 (status: pending)
ERROR: 'cur_dir'
DEBUG: scp -P 22 -p -q gaow@midway.rcc.uchicago.edu:.sos/tasks/M16_36934469c90d2d7f4fa78b1620fa3e15.* /home/gaow/.sos/tasks
scp: .sos/tasks/M16_36934469c90d2d7f4fa78b1620fa3e15.*: No such file or directory
  File "/opt/miniconda3/lib/python3.6/site-packages/sos-<IP_ADDRESS>-py3.6.egg/sos/__main__.py", line 350, in cmd_run
    executor.run(args.__targets__, mode='dryrun' if args.dryrun else 'run')
Traceback (most recent call last):
  File "/opt/miniconda3/lib/python3.6/site-packages/sos-<IP_ADDRESS>-py3.6.egg/sos/__main__.py", line 350, in cmd_run
    executor.run(args.__targets__, mode='dryrun' if args.dryrun else 'run')
  File "/opt/miniconda3/lib/python3.6/site-packages/sos-<IP_ADDRESS>-py3.6.egg/sos/sos_executor.py", line 1068, in run
    raise e
  File "/opt/miniconda3/lib/python3.6/site-packages/sos-<IP_ADDRESS>-py3.6.egg/sos/sos_executor.py", line 912, in run
    task_status = proc[2]._host.retrieve_results(proc[2]._pending_tasks)
  File "/opt/miniconda3/lib/python3.6/site-packages/sos-<IP_ADDRESS>-py3.6.egg/sos/hosts.py", line 877, in retrieve_results
    return {task: self._host_agent.receive_result(task) for task in tasks}
  File "/opt/miniconda3/lib/python3.6/site-packages/sos-<IP_ADDRESS>-py3.6.egg/sos/hosts.py", line 877, in <dictcomp>
    return {task: self._host_agent.receive_result(task) for task in tasks}
RuntimeError: Failed to retrieve result of job M16_36934469c90d2d7f4fa78b1620fa3e15 from midway2 with cmd
scp -P 22 -p -q gaow@midway.rcc.uchicago.edu:.sos/tasks/M16_36934469c90d2d7f4fa78b1620fa3e15.* /home/gaow/.sos/tasks
ERROR: Failed to retrieve result of job M16_36934469c90d2d7f4fa78b1620fa3e15 from midway2 with cmd
scp -P 22 -p -q gaow@midway.rcc.uchicago.edu:.sos/tasks/M16_36934469c90d2d7f4fa78b1620fa3e15.* /home/gaow/.sos/tasks

You will have to help me debug this. Could you use print or something similar to determine if PBS/sos_task.py:_prepare_script has been executed, and if not, where does it stop? As far as I can tell, cur_dir is in params.sos_dict.
Note that another possibility is that your task file was created before the cur_dir was saved to task files and used in these places....

I've added a print statement prior to self._prepare_script call; it did not get executed. But TaskEngine.run() apparently has completed execution. I"m still trying to identify where it is stopped ...

Find Start submitting in sos_task and see the thread that points to execute_task, which should point to prepare_task....

In fact it did not get pass this point:
https://github.com/vatlab/SoS/blob/master/src/sos/PBS/sos_task.py#L62
It returned False.

Then it is still at https://github.com/vatlab/SoS/blob/master/src/sos/sos_task.py#L1392

You can set some print in https://github.com/vatlab/SoS/blob/master/src/sos/hosts.py#L488

Check the keys of task_vars there

This is the problematic line:
https://github.com/vatlab/SoS/blob/master/src/sos/hosts.py#L529
The keys for dictionary task_vars['_runtime'] are just ['walltime', 'cores', 'mem']:
[GW] sos run /tmp/1.sos -q midway2
INFO: Executing default_1:
INFO: input:    []
slurm_load_jobs error: Invalid job id specified
slurm_load_jobs error: Invalid job id specified
['walltime', 'cores', 'mem']
ERROR: 'cur_dir'
scp: .sos/tasks/M16_36934469c90d2d7f4fa78b1620fa3e15.*: No such file or directory

Maybe it is related to the slurm+load_jobs error? Still looking

Ohmm, cur_dir is set https://github.com/vatlab/SoS/blob/master/src/sos/sos_step.py#L670 , and the passing of walltime etc reset it?

tasks are pushed to an array https://github.com/vatlab/SoS/blob/master/src/sos/sos_step.py#L719 and saved at https://github.com/vatlab/SoS/blob/master/src/sos/sos_step.py#L742 or another line if bundled. So you will need to check line 719 if taskdef is correct.

Here is the def file this line loads:
https://github.com/vatlab/SoS/blob/master/src/sos/hosts.py#L153
M16_36934469c90d2d7f4fa78b1620fa3e15.def.zip
Here the runtime is already messed up:
>>> from sos.sos_task import loadTask
>>> params = loadTask('/home/gaow/Dropbox/M16_36934469c90d2d7f4fa78b1620fa3e15.def')
>>> params.sos_dict
{'_runtime': {'walltime': '02:30:00', 'cores': 2, 'mem':<PHONE_NUMBER>}, '_input': [], '_output': ['1_A.txt', '1_B.txt', '1_C.txt', '1_D.txt', '2_A.txt', '2_B.txt', '2_C.txt', '2_D.txt', '3_A.txt', '3_B.txt', '3_C.txt', '3_D.txt', '4_A.txt', '4_B.txt', '4_C.txt', '4_D.txt'], '_depends': []}
>>>

So you are right, taskdef did not get saved properly.

It is possible that the master def file does not define cur_dir https://github.com/vatlab/SoS/blob/master/src/sos/sos_step.py#L758

Am looking at the same line. I think that's the problem. But I do not understand why it was not possible to reproduce on your end ...

Me either. Check https://github.com/vatlab/SoS/blob/master/src/sos/sos_task.py#L99 , add cur_dir so that it can be copied from slave to master (here we assume that all slaves have the same cur_dir.

Great, now it complains about home_dir not found. I added that too. Now it says:
[GW] sos run /tmp/1.sos -q midway2
INFO: Executing default_1:
INFO: input:    []
slurm_load_jobs error: Invalid job id specified
slurm_load_jobs error: Invalid job id specified
WARNING: input is not in task namespace and cannot be mapped.
WARNING: depends is not in task namespace and cannot be mapped.
INFO: On midway2: _output = ['/home/gaow/1_A.txt', ...] (16 items)
WARNING: output is not in task namespace and cannot be mapped.
ERROR: 'MasterTaskParams' object has no attribute 'name'
scp: .sos/tasks/M16_36934469c90d2d7f4fa78b1620fa3e15.*: No such file or directory
ERROR: Failed to retrieve result of job M16_36934469c90d2d7f4fa78b1620fa3e15 from midway2 with cmd
scp -P 22 -p -q gaow@midway.rcc.uchicago.edu:.sos/tasks/M16_36934469c90d2d7f4fa78b1620fa3e15.* /home/gaow/.sos/tasks

OK, at least we know that the problem is that master task does not have enough information to be copied... let us fix this one by one.

You see that MasterTaskParams does not call the constructor of TaskParams because it does not have the information needed and have to decide them when the tasks are pushed in. For now, you can simply set self.name to '' in the constructor and copy the first task's name to the master under if not self.task_stack (for the first task).

I tested the workflow with a docker server with shared directory so the task do not actually need to be copied. I guess this is why I could not reproduce the problem.

Ok, then I get ERROR: name 'step_name' is not defined -- more missing information.

I tested the workflow with a docker server with shared directory so the task do not actually need to be copied. I guess this is why I could not reproduce the problem.

Ha that's actually what bothers me most: I was worried that I had some global setting issue!

Ok. Push whatever you have fixed and I will do the rest.

I just pushed but said attempt to fix which automatically closed the issue. ... reopen it. I did not add the self.name fix for now.

Try again.

Well, warning messages are gone now, but step_name error persists ...
$ sos run ~/Dropbox/1.sos -q midway2
INFO: Executing default_1:
INFO: input:    []
INFO: M16_36934469c90d2d7f4fa78b1620fa3e15 restart from status pending
INFO: On midway2: _output = ['/home/gaow/GIT/SOS/1_A.txt', ...] (16 items)
ERROR: name 'step_name' is not defined
ERROR: 1 job failed

Again?

Hmm now it is ERROR: name '_index' is not defined

Must be the last one.

Sorry not exactly:
ERROR: Failed to generate job file for task M16_36934469c90d2d7f4fa78b1620fa3e15: name 'verbosity' is not defined

Now?

Great it worked for that MWE! I'm closing the issue now until my field test says otherwise -- will have to do it tomorrow on my office computer because I dont want to monitor it from my home desktop.

Thanks for the bug report. I will have to figure out a test (with real data copy) to our test suite.


EN README file will be in the root folder

Hi @mehmet-mert ,
First of all FrameRecorder looks great.
But i think English README.md file must be in the root folder, It is good for first look for this repo :+1:

Thank you for your contribution. The necessary arrangement has been made.


tmt.check.dmesg is not saving the dmesg log after the dmesg after execution.

After executing the following test, https://gitlab.cee.redhat.com/kernel-qe/kernel/-/tree/master/general/locking/torture, i expected to have information in the dmesg after log but it did not have the dmesg information.
tmt version is 1.35.0.
e.g. of expected log messages:
[Mon Sep  9 21:42:37 2024] ww_mutex_lock-torture: Creating torture_shuffle task
[Mon Sep  9 21:42:37 2024] ww_mutex_lock-torture: torture_shuffle task started
[Mon Sep  9 21:42:37 2024] ww_mutex_lock-torture: Creating torture_stutter task
[Mon Sep  9 21:42:37 2024] ww_mutex_lock-torture: torture_stutter task started
[Mon Sep  9 21:42:37 2024] ww_mutex_lock-torture: Creating lock_torture_writer task
[Mon Sep  9 21:42:37 2024] ww_mutex_lock-torture: lock_torture_writer task started
[Mon Sep  9 21:42:37 2024] ww_mutex_lock-torture: Creating lock_torture_writer task

What I found in the log file looked exactly like the dmesg before log.
I don't think this needs to be on a debug kernel but it is where I ran my case. I will confirm later if dmesg output is expected on the non debug kernel.
To reproduce, export TORTURE_RUNTIME=1m, or through tmt -e TORTURE_RUNTIME=1m .
The current version of the test does not have dmesg check enabled so use this fork to get the current version I tested against:

https://gitlab.cee.redhat.com/sbertram/kernel

branch

ft_general_updates

path

/general/locking/torture

That should do it. The test is setup to work with pruning enabled as well.
Running it on the device directly in shell, not using tmt, with the settings above, it ran for about 20 minutes. Much of that time is building the module used in the test. With tmt expect a little more time for copy and prepare.

Also confirmed can be tested on a non debug kernel and still get dmesg output from the module.

 Calculating average duration per loop (nanoseconds)...
[62276.277316] Runs	Time(ns)
[62276.277359] 1	529.063
              2	528.831
              3	584.104
              4	431.263
              5	490.312
              6	559.661
              7	628.720
              8	615.736
              9	578.126
              10	518.497
              11	611.676
              12	175.990
              13	485.779
              14	399.264
              15	398.977
              16	617.390
              17	534.726
              18	607.868
              19	517.030
              20	528.942
              21	609.016
              22	536.439
              23	557.696
              24	551.241
              25	568.222
              26	580.527
              27	562.615
              28	558.461
              29	550.862
              30	560.744

So I am going to assume it is something to do with the debug kernel. I will run a few more tests to try and narrow.

Chalk it up to learning curve and just bad lookup on my part :( . I looked at the wrong test in the plan. This is working as expected. Closing ticket.

Chalk it up to learning curve and just bad lookup on my part :( . I looked at the wrong test in the plan. This is working as expected. Closing ticket.


Remove as_handle and NonOwnedHandle [ECR-910]

Overview
Remove non-owned handles implementation as it's not needed.

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

[ ] There are no TODOs left in the code
[ ] Change is covered by automated tests
[ ] The coding guidelines are followed
[ ] Public API has Javadoc
[ ] Method preconditions are checked and documented in the Javadoc of the method
[ ] Changelog is updated if needed (in case of notable or breaking changes)
[ ] The continuous integration build passes

Let's postpone these changes until DS will be implemented. The task is marked as todo again.


Tests

Add tests to cover basic coon usages.

one test added in https://github.com/comtihon/coon/pull/19
need to make all testcases start by make tests


Within & Intersects Queries Not Documented

Documentation Issue
It seems the within and intersects query operators for the Point field is not documented on the site.
https://github.com/payloadcms/payload/blob/afd69c4d5432bb484a1c3a244c3db19fc6973aa9/test/collections-rest/int.spec.ts#L1185
https://github.com/payloadcms/payload/blob/afd69c4d5432bb484a1c3a244c3db19fc6973aa9/test/collections-rest/int.spec.ts#L1240
Additional Details

Discord Thread

Hey @ainsleyclark,
I believe the docs for those are coming in the next release thanks to Ritsu. See his PR that got merged.

He's too quick 😂

Right, they are now https://payloadcms.com/docs/fields/point#example


⚠ Samsung has degraded performance

In 9514eb7, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 1891 ms

Resolved: Samsung performance has improved in c8dbab1.


[Feature]: Add aria attributes to all the icons

Feature Summary
Cuttle uses icons semantically, meaning all the icons have an intended meaning. For accessibility purposes, these icons should therefore have certain metadata set. We should update the existing uses of icons to set this data accodingly.
Detailed Description
Specifically, each <v-icon> in the application should set:

aria-label="descriptive text based on what the icon is for"
aria-hidden="false" (this ensures it is read on screen readers)
role="img"

We should set these for every icon in the application, which you can find by doing a search for all instances of <v-icon

@itsalaidbacklife , Can i do it?


Slow serving static files

We've noticed on and off static files serving slowness.
Root cause is still TBD. Might be due to Google shared disk performance degrading over high load?
A cheap mitigation could be to move Brave to CDN serving since that is likely the store that causes high load.

Wrong repo!!!

Wrong repo!!!


Is there a way to analyse an image, not a video?

For a project, I need to analyse images for facial features. I wondered if this library is able to do so, and not just videos.
The best solution I have so far is to create a video with the image moving left-to-right, and rotating left-to-right, up-and-down. but that is dirty.

It is possible to use images as well, take a look at some of the examples, for instance this : https://auduno.github.io/clmtrackr/clm_image.html

Odd.
I was using this image for testing:

Sometimes it converges, but not really and sometimes it fails.

And locally, the results is quite funny:


JAVA-1729 Adding equals to tuple

So this is a bit embarrassing: I just realised that there is no way that the field codecs can be missing, since we're dealing with CQL types (which any decent CodecRegistry implementation must support out of the box -- I've added a javadoc to that effect). Sorry for misleading you, I've removed the unnecessary checks.
I've also moved the tests to DefaultTupleValueTest.


Definitions should define variables not words

Definitions in Pop-11 define variable names. Although at run-time Pop-11 variable-names are represented by words (unfortunately) it is not ideal to call them words as strictly speaking they are variable-names. So we should replace Word by Variable in this definition.
	'define' Word ('(' Varslist? ')' | Varslist)? ('->' Varslist)* ';' Sequence 'enddefine'

It turns out the issue is deeper than I thought. Abandoning this issue.


CET-11 - Add branch protection escalation action

Description

Moves GitHub Branch Protection Policy to new credentials
Adds escalation action

Issues Resolved
None
Contribution Check List

[ ] All tests pass.
[ ] New functionality includes testing.
[x] New functionality has been documented in the README if applicable
[x] New functionality has been documented in CHANGELOG.MD

          4 Errors

:no_entry_sign:
compliance/github/repository_branch_protection/CHANGELOG.md:1: MD002 First header should be a top level header
compliance/github/repository_branch_protection/CHANGELOG.md:1: MD022 Headers should be surrounded by blank lines
compliance/github/repository_branch_protection/CHANGELOG.md:6: MD022 Headers should be surrounded by blank lines
compliance/github/repository_branch_protection/CHANGELOG.md:10: MD022 Headers should be surrounded by blank lines
compliance/github/repository_branch_protection/CHANGELOG.md:14: MD022 Headers should be surrounded by blank lines
compliance/github/repository_branch_protection/CHANGELOG.md:3: MD032 Lists should be surrounded by blank lines
compliance/github/repository_branch_protection/CHANGELOG.md:8: MD032 Lists should be surrounded by blank lines
compliance/github/repository_branch_protection/CHANGELOG.md:12: MD032 Lists should be surrounded by blank lines
compliance/github/repository_branch_protection/CHANGELOG.md:16: MD032 Lists should be surrounded by blank lines
A detailed description of the rules is available at https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md

:no_entry_sign:
compliance/github/repository_branch_protection/README.md:1: MD002 First header should be a top level header
compliance/github/repository_branch_protection/README.md:13: MD012 Multiple consecutive blank lines
compliance/github/repository_branch_protection/README.md:21: MD012 Multiple consecutive blank lines
compliance/github/repository_branch_protection/README.md:35: MD012 Multiple consecutive blank lines
compliance/github/repository_branch_protection/README.md:7: MD022 Headers should be surrounded by blank lines
compliance/github/repository_branch_protection/README.md:9: MD029 Ordered list item prefix
compliance/github/repository_branch_protection/README.md:10: MD029 Ordered list item prefix
compliance/github/repository_branch_protection/README.md:11: MD029 Ordered list item prefix
compliance/github/repository_branch_protection/README.md:8: MD032 Lists should be surrounded by blank lines
compliance/github/repository_branch_protection/README.md:30: MD033 Inline HTML
A detailed description of the rules is available at https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md

:no_entry_sign:
Please add the info field. compliance/github/repository_branch_protection/repository_branch_protection.pt

:no_entry_sign:
Please add labels to this Pull Request

  Generated by :no_entry_sign: Danger

          3 Errors

:no_entry_sign:
Please add a CHANGELOG.md file

:no_entry_sign:
compliance/github/repository_branch_protection/README.md:1: MD002 First header should be a top level header
compliance/github/repository_branch_protection/README.md:15: MD012 Multiple consecutive blank lines
compliance/github/repository_branch_protection/README.md:23: MD012 Multiple consecutive blank lines
compliance/github/repository_branch_protection/README.md:33: MD012 Multiple consecutive blank lines
compliance/github/repository_branch_protection/README.md:7: MD022 Headers should be surrounded by blank lines
compliance/github/repository_branch_protection/README.md:9: MD029 Ordered list item prefix
compliance/github/repository_branch_protection/README.md:10: MD029 Ordered list item prefix
compliance/github/repository_branch_protection/README.md:11: MD029 Ordered list item prefix
compliance/github/repository_branch_protection/README.md:12: MD029 Ordered list item prefix
compliance/github/repository_branch_protection/README.md:13: MD029 Ordered list item prefix
compliance/github/repository_branch_protection/README.md:8: MD032 Lists should be surrounded by blank lines
A detailed description of the rules is available at https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md

:no_entry_sign:
Please add the info field. compliance/github/repository_branch_protection/repository_branch_protection.pt

  Generated by :no_entry_sign: Danger


M3-2051: capitalize linode progress bar text

M3-2051: capitalize linode progress bar text
Description
Updates transitionText method to ensure it returns a capitalized version of the event.
Type of Change

Fix linode progress bar transition text casing

Coverage increased (+0.03%) to 31.888% when pulling 09d9f307b12f82eddb1223c525ec30515eefea26 on rulikrulit:defect/M3-2051-progress-bar into e1231c9fcc14ef51577784b25b4607e167127b96 on linode:develop.


BUG: fix DataFrame constructor w named Series

closes #7893
Closes https://github.com/pydata/pandas/issues/9232
Problem was passing Series w/ a name to DataFrame w/ the columns kwarg.
Before:
In [55]: x = pd.Series(range(5), name=1)

In [56]: y = pd.Series(range(5), name=0)

In [57]: pd.DataFrame(x, columns=[0])
Out[57]:
Empty DataFrame
Columns: [0]
Index: []

In [58]: pd.DataFrame(x, columns=[1])
Out[58]:
   1
0  0
1  1
2  2
3  3
4  4

In [59]: pd.DataFrame(y, columns=[0])
Out[59]:
   0
0  0
1  1
2  2
3  3
4  4

In [60]: pd.DataFrame(y, columns=[1])
Out[60]:
   1
0  0
1  1
2  2
3  3
4  4

after
In [1]: x = pd.Series(range(5), name=1)

In [2]: y = pd.Series(range(5), name=0)

In [4]: pd.DataFrame(x, columns=[0])
Out[4]:
   0
0  0
1  1
2  2
3  3
4  4

In [5]: pd.DataFrame(y, columns=[1])
Out[5]:
   1
0  0
1  1
2  2
3  3
4  4

There were two intertwined problems

we checked if getattr(data, 'name', None):, which returned False when data.name was Falseish (like 0). I now compare it directly against None.
If data has a name and the columns kwarg is specified, the constructor returned an Empty DataFrame w/ the column specified in columns. Now, we do what's documented:

The result will be a DataFrame with the same index as the input Series, and with one column whose name is the original name of the Series (only if no other column name provided).

this is an api change
i will have to look at this

Yep, I wasn't sure where to document it in whatsnew. I can expand it.
I think the docs are pretty clear that this was the intended behavior..

How I always understood it, it is the y case (pd.DataFrame(y, columns=[1]) not giving an empty dataframe) that was buggy and not the x case (pd.DataFrame(x, columns=[0]) giving an empty frame). It was sometimes odd or surpising behaviour, but giving a series/frame to DataFrame is regarded as a reindex.
I wanted to say that this is in line with how a DataFrame itself is treated when given to DataFrame, but it appears this is still somewhat different (not giving an empty frame, but one with NaNs):
In [42]: x = pd.Series(range(5), name=1)

In [43]: pd.DataFrame(x.to_frame(), columns=[0])
Out[43]:
    0
0 NaN
1 NaN
2 NaN
3 NaN
4 NaN

see more discusion on #7893
this AFAIK was a longstanding behavior which I think I broke in 0.12-13 . I agree with @jorisvandenbossche here
This should return a column of NaN if the passed name in the columns does not match, e.g. its a reindex. (the bug is its returning an empty frame). In fact the undelrying code should do exactly to_frame() as this handles the edge cases.

I think we should have a mini section in basics.rst to show conversions of series -> dataframe (and obviously in the 0.16.0 whatsnew)

OK, so I'll repurpose this PR to make to_frame() and the constructor consistent (both return a column of NaNs) and rewrite the docs.

Just for the docs, if you want to give a series as input to DataFrame, but do want to overwrite the series name (which is a valid use case), what is the recommended way to do? As first changing the series name, or afterwards renaming the dataframe is somewhat cumbersome.
I suppose giving it as a dict:
In [59]: s = pd.Series([1,2,3], index=[10,11,12], name='test')

In [60]: pd.DataFrame(s)
Out[60]:
    test
10     1
11     2
12     3

In [61]: pd.DataFrame(s, columns=['col'])
Out[61]:
Empty DataFrame
Columns: [col]
Index: []

In [62]: pd.DataFrame({'col': s})
Out[62]:
    col
10    1
11    2
12    3

OK, but of course for just this, using to_frame:
In [63]: s.to_frame(name='col')
Out[63]:
    col
10    1
11    2
12    3

@TomAugspurger can you update the top section. I don't think this is correct. The columns argument will cause a reindex of the input (after the column name is set by name). So if they different you would get a column of nans. What I think is here is inconsistent with that.

@TomAugspurger can you rebase this. and confirm (just change the top section) of the existing and new behavior (may also need an example in the api breaking section of the same).

@TomAugspurger ?

@jreback so the expected behavior is
In [24]: y = pd.Series(range(5), name=0)

In [25]: pd.DataFrame(y, columns=[1])
Out[25]:
   1
0  NaN
1  NaN
2  NaN
3  NaN
4  NaN

?

IMO, it should be identical to what you get from a dict
In [29]: pd.DataFrame({y.name: y.values}, columns=[1])  # y.name is 0
Out[29]:
Empty DataFrame
Columns: [1]
Index: []

@TomAugspurger
I think [24/25] is the correct return. (0.15.2 does what you have for 24/25). [29] is just wrong (same in master).
The canonical way to do this is: y.to_frame(name=1) which in effect is: DataFrame({ name : y }), where name is y.name or the new_name if provided.
This has to be a reindex, e.g. construct the dict using the current name THEN reindex. (its done like this for a dictionary construction, but it is not entirely correct; the [1] column in your example should still exist, eg. [24/25] and NOT [29])
Imagine this scenario:
In [1]: DataFrame({'y1' : Series(range(5),name='foo'), 'y2' : Series(range(5),name='bar') }, columns=['y2'])
Out[1]:
   y2
0   0
1   1
2   2
3   3
4   4

So the columns are selecting (e.g. reindexing) on the passed dictionary keys, if you JUST pass a single Series, then it must be { s.name : s } so the same thing should happen
TL;DR; but makes sense?

Yep, it definitely is a reindex. We'll go with [24]/[25].

And I'm comfortable saying that
In [16]: pd.DataFrame({"A": [1, 2, 3], "B": [4, 5, 6]}, columns=["C"])

Returning an Empty DataFrame is a bug (not an API change)

@TomAugspurger agree with your [16]. thxs

This is breaking some tests unfortunately. When constructing from a dict of {col: Series} with differing indicies and specifying columns. Here's what I do now
In [2]: s1 = pd.Series([1, 2, 3], name='a')

In [3]: s2 = pd.Series([4, 5, 6], name='b', index=[2, 3, 4])

In [5]: pd.DataFrame({'a': s1, 'b': s2}, columns=['a'])
Out[5]:
    a
0   1
1   2
2   3
3 NaN
4 NaN

Before it was
In [5 master]: pd.DataFrame({'a': s1, 'b': s2}, columns=['a'])
Out[5 master]:
    a
0   1
1   2
2   3

Since we filtered out b before determining what the index was. I think it's good that we clarifying all these constructors and make them consistent, but it's feeling pretty disrupting.

@TomAugspurger hmm, I see what you mean. I don't think this should change though. We are only reindexing on the columns (as opposed to creating the frame first from the ENTIRE dict, then reindexing)
Hmm I guess that is why the [29] is the way it is.
Ok, why don't you investigate and see what makes the most sense.

Is it cool to push this all off to 0.17? I don't have much time today and I need to squash a weird bug in the plot accessors. Is there anything that is obviously broken and should be fixed today? I'd say that this is obviously wrong.
In [1]: y = pd.Series(range(5), name=0)

In [2]: z = pd.Series(range(5), name=1)

In [3]: pd.DataFrame(y, columns=[2])
Out[3]:
   2
0  0
1  1
2  2
3  3
4  4

In [4]: pd.DataFrame(z, columns=[2])
Out[4]:
Empty DataFrame
Columns: [2]
Index: []

I jsut don't want to make anything harder down the road.

sure let's push thx!

@TomAugspurger ought to re-examine this for 0.17.0. pls rebase when you have a chance

@TomAugspurger what's status?

Just reread through. I'll have something by the end of next week.

@TomAugspurger pushing, but if you get to it next week or 2 can put in.

@TomAugspurger status?

Won't really have time to work on this in the short term. Better to close or leave open?

let's close for now.


[path_provider] Deprecated API error. Is that ok ?

Hi, I'm using Path Provider 1.6.0 in my APP and I get the following error:
Note: D:\Other Apps\Flutter\.pub-cache\hosted\pub.dartlang.org\path_provider-1.6.0\android\src\main\java\io\flutter\plugins\pathprovider\PathProviderPlugin.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details.
Do I need to update something or is it normal and ok to use the plugin with this msg ?
Thanks.

Package specific questions should be asked in the packages repository (path_provider repo)
The path_provider package uses a native android implementation as far as i know. So it could be the case, that they use a deprecated api and will probably change it soon.

Hi @hauketoenjes, thanks for your answer. I tried to open an issue on the repository you mention but there's no Issues on the repo, only pull requests. Any idea how to ask for assistance on those repos ? This issue has being hunting me for almost 2 months, they updated the plugin and it's still there, maybe I have something setup wrong, that's why I was trying to get in contact with the provider ppl.
Thanks again, Martin.

Hi! You don't have anything to worry about, I get the error too. As you see, it says "Note", not "Error". It happens with a lot of packages like device_info and others. As @hauketoenjes said, they use native code as it's a plugin. It's up to them to change the deprecated API out, not on you as you didn't do anything wrong.

Yeah, just dont worry about these things, just keep developing your app (btw, i overread the issue line at their docs) So you asked at the right repositoy :)

Oh ok, thanks fir the info ! Everything was working fine but as I'm getting close to publish didn't want to leave it to chance.
Thanks @hauketoenjes

Hi @MartinCCota
It's totally fine as #50870 Comment says
given your last message I feel safe to close this issue,
if you disagree please write in the comments and I will reopen it.
Thank you for your contribution


feat: add HashSet.insertMany

This had been added separately in aesop and in mathlib4, and once we imported both sources in the same place there was a name clash. This suggests it's time to move it to the correct place.

Note: if lean4 doesn't want to take this definition, std can take it in Std.Lean.HashMap (where additions to Lean's HashMap type will be stored).


Move edit translation page to the GOVUK Design System

⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠
What
Move the unwithdraw page to the GOVUK design system layout.

Why
This is part of a Whitehall transition work to move from bootstrap to GOVUK design system.
Screenshots

Before

Code looks good but tests are failing


[WIP] BUG: Prevent crash in LAPACK Hermitian eigendecomposition wrapper.

In the LAPACK wrapper for ?heevr, enlarge the size of the isuppz array
parameter in order to prevent out-of-bound access by the underlying
library. For both ?heevr and ?syevr, more robust checks and default
values are also put in place.

Reference issue

#11709
What does this implement/fix?

Crashes related to linalg.eigh()
Additional information

The current status is mostly a workaround for MKL on macos. Further investigation is needed to access the presence or impact of similar issues on other platforms.

@congma Please use to fix #11709 or fixes #11709 in the PR description in order to auto-close related issue after merging PR.

@congma Please use to fix #11709 or fixes #11709 in the PR description in order to auto-close related issue after merging PR.

Thanks. This is still very much WIP.

I haven't reviewed the changes in this PR, so this is just a report on the effect. I am on MacOS 10.12.6.  With the master branch of scipy (SHA 1150c4c...) and using numpy from anaconda (so with MKL), I get a seg. fault when I run the linalg test suite.  With this PR, the linalg test suite completes with all tests passing. 🎉

Fixes multiple crashes on Linux with MKL as well:
FAILED scipy/linalg/tests/test_decomp.py::TestSVDVals::test_empty
FAILED scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py::test_symmetric_modes
FAILED scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py::test_hermitian_modes
FAILED scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py::test_real_nonsymmetric_modes
FAILED scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py::test_svd_linop

These crashes are starting to get annoying, and I'm not sure if on macOS we're only seeing these ones or another one as well.
This PR is still WIP, but it does improve the situation. @congma, @ilayn is there any reason not to merge this?

No there isn't. I just forgot. We need to cleanup a bit a few details but essentially quite doable quickly. I'll have a look.

Apart from the recent Cython issue, Travis being Travis again hence merging. Feedback from MKL users are welcome.

Thanks @congma and @ilayn!

Thanks @congma and @ilayn, and @rgommers for the nudge!


librsvg: fix cross compilation by using emulator for shell completion…

… generation
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[x] riscv64-linux (cross)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

:( i don't want cross compilation work to be painful for the next month https://github.com/NixOS/nixpkgs/pull/244950

oh p11-kit is broken too so much stuff will be broken anyway


ignore CI error

Why is this PR needed?
What changes were proposed in this PR?
Does this PR introduce any user interface change?

No
Yes. (please explain the change and update document)

Is any new testcase added?

No
Yes

@xubo245  Why did you ignore these tests? Could you explain it?

@xubo245  please check. Did you do some test on you local machine  ?

@xubo245 Why did you ignore these tests? Could you explain it?

The CI has some problem,  we can not see the CI result in details because there are some network limitation. I want to find which tests case has some problems, and then we can know how to fix it.


Prettier fix

Thanks for this @craigmulligan!

Seems like the typescript doesn't compile with these changes.


custom theme button decoration does not work. Font becomes erased upon pressing and in focused mode.

Following https://github.com/okamstudio/godot/wiki/tutorial_gui_skinning, I noticed that custom themed button does not properly display pressed/focused mode. Hover works.

Cleaning up button.cpp, base_button.cpp abit. I think I got it almost working. Not sure why focused is showing ERROR in decoration. Unsure how to debug cause of that.. it goes behind a visual server raster, which I'm not familiar with.

Fixed. Problem was style = get_stylebox("focus"); instead of "focused" :)

Pull request #2047

I had same problem and I noticed focused StyleBoxTexture should be unchecked Draw Center property.
Then it seems to work.

Yes, this is not a bug, focus is drawn as an overlay, it's not a button state as you can press, hover and release when a button is focused.

If you want a more custom behavior, you can make a simple script that inherits BaseButton and override the _draw() function, using get_draw_mode() to know what you have to draw and overriding get_minimum_size() to specify to the UI how big the button is.

not a bug, focus is an overlay
On Mon, Jun 8, 2015 at 4:01 AM, Kevin Choi<EMAIL_ADDRESS>wrote:

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/2046.

The bug is that when focus is drawn as an overlay, but it draws over everything else. As a result, when focus is opaque, it clobbers everything on the button.

pushed a fix, making focus draw before the text
On Mon, Jun 8, 2015 at 10:38 AM, Kevin Choi<EMAIL_ADDRESS>wrote:

The bug is that when focus is drawn as an overlay, but it draws over
everything else. As a result, when focus is opaque, it clobbers everything
on the button.
—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/2046#issuecomment-109997752.


[BUG]Code wont encode

If you have XML keywords in back quotes, RSS will ERROR

Please provide us with a proper example.
Also, do note that jekyll-feed generates Atom feeds.

Such as：
:xiang
echo  //special character
goto xiang

Oh, it's a special character that can't be parsed.
Link:https://mabbs.github.io/atom.xml

OK,I see. It's a special character fault.


HCAP-606 confirm interest criteria

https://freshworks.atlassian.net/browse/HCAP-606
Add criteria so we only update records that match the initial query.

Don't update PEOI where interest = withdrawn
Don't update PEOI where userUpdatedAt > 6 weeks ago

Also fixed bug on the FE component where I implemented fetch like Axios by accident

Missed the hired check, if there's a more efficient way to check hired status please let me know


Fix utf8 offsets in actions

Maybe not fitting well, but much better than writing call like this instead:
final range = document.rangeAt(context.displayOffsetConverter.utf8OffsetToCharacterOffset(document.content, pos.max),
      context.displayOffsetConverter.utf8OffsetToCharacterOffset(document.content, pos.max));

There is some other offset places, they can be checked with this regexes in vscode search:
rangeAt\(.+?(?!true)\)
positionAt\(.+?(?!true)\)
I changed mostly places that i tested.
Closes https://github.com/vshaxe/vshaxe/issues/583

iirc it's not that simple and there are 3 possibilities: utf16, utf8 and bytes, depending on context. This might be slightly less bad than current way but doesn't look like a proper way either to me :/
I will also do some tests to make sure this doesn't break #76

We can use abstract enum as argument then?
But how does document can be bytes?

I meant positions/offset can be calculated/provided as either byte pos, utf8 char or utf16 char, depending on the context (communication with editor, communication with old haxe compiler, communication with recent haxe compiler, etc)


Sound fade in and fade out

Is there a way to have the sound fade in instead of just playing at full volume and fade out when stopped instead of just stopping?

Hey,
That's not something I'm interested in adding, I normally use SoundBoard for short one-shot sounds that wouldn't require fading.
If you want to create a PR to make it an option, I'd gladly review and merge.
Thanks


External references/No terms on Terms & Definitions

This issue mirrors https://github.com/riboseinc/asciidoctor-iso/issues/82.
The boilerplate content is:
<<ISO27000, ISO/IEC 27000>> 中确立的以及下列术语和定义适用于本标准。

<<ISO27000, ISO/IEC 27000>>，<<ISO27001, ISO/IEC 27001>> 和 <<ISO27002, ISO/IEC 27002>> 中确立的以及下列术语和定义适用于本标准。

To do this, I need all of:

No terms and definitions are listed in this document.
For the purposes of this document,
the following terms and definitions apply.
the terms and definitions given in #{src["citeas"]} apply.
the terms and definitions given in and the following apply.

I assume GB has no counterpart of:

ISO and IEC maintain terminological databases for use in
      standardization at the following addresses:

ISO Online browsing platform: available at
           <link target="http://www.iso.org/obp"/>

IEC Electropedia: available at
           <link target="http://www.electropedia.org"/>

No terms and definitions are listed in this document.
** 本文件不提供术语和定义。（GB/T 1.1-2009 was written before the mandatory nature of the T&D section, so does not provide this. I did the translation instead.)

When T&D is only given in this document:
** "For the purposes of this document, the following terms and definitions apply."
** 下列术语和定义适用于本文件。 (As defined by GB/T 1.1-2009 6.3.2)

When using additional sources:
** "For the purposes of this document, the terms and definitions given in #{src["citeas"]} and the following apply."
** #{src["citeas"]} 界定的以及下列术语和定义适用于本文件。(As defined by GB/T 1.1-2009 6.3.2)

When using external sources:
** "For the purposes of this document, the terms and definitions given in #{src["citeas"]} apply."
** #{src["citeas"]} 界定的术语和定义适用于本文件。(As defined by GB/T 1.1-2009 6.3.2)

Sometimes, they add this line:
** For the convenience of use, the following terms and definitions from #{docname} are given below.
** 为了便于使用，以下重复列出了 #{docname} 中某些术语和定义。
Plurality of citeas:
** "#{docname1}, #{docname2} and #{docname3}"
** "#{docname1}、 #{docname2} 和 #{docname3}"

No counterpart of "ISO and IEC maintain terminological databases..." in GB.

I was hoping to avoid multiple doc sources, but OK, I'll put them in.

So "为了便于使用，以下重复列出了 #{docname} 中某些术语和定义。" is really a variant of "#{src["citeas"]} 界定的术语和定义适用于本文件。" I'll use the latter.

Implemented multiple doc sources for isodoc as well.

The latter is the typical line. The former is an occurrence within GB/T 1.1, where some definitions are cited AND repeated for ease of use. I don’t know how common this usage is. So if we can allow the author to manually put in an additional sentence after the boilerplate, we cover both cases.

... Well, currently we don't: I've just started stripping all non-term content in the terms section, so that the correct boilerplate overrules anything the source document has. I'd rather avoid this kind of flexibility, but I can disable stripping boilerplate text out if you want; there's less boilerplate in GB anyway.

Disabled termdef_boilerplate_cleanup() in asciidoctor-gb

Can there be a document attribute that is like ":terms-definitions-disable-boilerplate-enforcement:" ?

Overkill. All it does is strip extraneous content. If you have the presence of mind to populate :terms-definitions-disable-boilerplate-enforcement:, you have the presence of mind to exclude the extraneous content to begin with.


Add failing test for unsetting array index

Should Cursor.unset() work for array elements?
Wiki suggests it used to work with remove().
Added a failing test, not sure if this is expected behaviour.

When developing v1, I decided to remove unset support for arrays in favor of splice for shady reasons (the wiki is probably outdated and should be updated but I can't find time to peruse it thoroughly). I guess we can discuss this problem if you want: do you think unset should apply to arrays?

I think it makes sense to support unset for arrays.
I need to remove an entry from an array, and I was expecting unset to work, like it does on object keys. Bit weird for it not to work on arrays too, imo.

The other question there is should this work like the delete keyword on array (which does delete the entry but keep the array's length intact) or like a splice?

I was imagining it like a splice, expecting the length of the array to be reduced when i unset.

Opening a related issue #246 here.


placeholders not detected in path

path param not handled

check in method path
find {} placeholders
get from struct placeholder data, if field not found - return error.BadRequest
switch on request method, if get - all other struct fields encode via https://github.com/google/go-querystring/blob/v1.0.0/query/encode.go
if not get - check body element and fills url path, in body send only specified field
do request

all logic handled in micro-client-http

done, may be needs additional stuff to support slice/maps

done, may be needs additional stuff to support slice/maps

close for now


Simplify user-facing DMA channel types

The goal of this PR is to simplify the SpiDma type from
 SpiDma<
    'd,
    SpiInstance,
    ChannelTx<'d, ChannelNTxImpl, ChannelN>,
    ChannelRx<'d, ChannelNRxImpl, ChannelN>,
    SuitablePeripheralN,
    FullDuplexMode,
>

to
 SpiDma<
   'd,
    SpiInstance,
    ChannelN,
    FullDuplexMode,
>

This PR also makes the I2s type ascribe-able by the user. Previously, the list of generics included a private type which has been turned into an associated type now.
I have also removed the example introduced in #623 and changed the s3 embassy-spi example to use SPI3.

Seems I somehow didn't notice this PR ... LGTM


[Theme] Use an anonomous ID to generate the event data we need for conversion funnels.

Example query with the anonymous ID
FROM TessenAction SELECT filter(uniqueCount(anonymousId), WHERE eventName = 'TLMK_SignUp_signup'), filter(uniqueCount(anonymousId), WHERE eventName = 'TLMK_SignUp_signupThankYou') TIMESERIES AUTO SINCE 1 month ago

Acceptance Criteria

[ ] Discuss with PLG how they get the anonymous ID , is it from segment? - #help-plg slack channel
[ ] Determine how we can use this ID to generate the event data we need for conversion funnels.
[ ] Once confirmed, add the anonymous ID to all events via the theme

Asking in #help-plg on this, will update with more details

@rudouglas could you add me to the thread, I'm interested in their reply.

The anonymousId comes from Segment—at least on the signup page (which is a repo that PLG built, but is transitioning ownership to #help-signup). On the signup page, here's the source for how we get anonymousId.
For more info, I'd suggest asking in #project-tessen or #wizards-amplitude to see if someone else knows more.


Implement flexible interface in translator

return (new Translator())->addCategorySource($source);

better than
$translator = new Translator();
$translator->addCategorySources($categorySource);
return $translator;

Closed by #109


include/swift/Basic: fix deprecation warnings

These are deprecation warnings
include/swift/Basic/type_traits.h:49:29: warning: builtin __has_trivial_constructor is deprecated; use __is_trivially_constructible instead [-Wdeprecated-builtins]
  static const bool value = __has_trivial_constructor(T);
                            ^
include/swift/Basic/type_traits.h:61:29: warning: builtin __has_trivial_destructor is deprecated; use __is_trivially_destructible instead [-Wdeprecated-builtins]
  static const bool value = __has_trivial_destructor(T);
                            ^
2 warnings generated.

@swift-ci smoke test

@jckarter this apparently reverts your previous commit 1a602e987c5dfc1ea644dc444f9e77e1c00b7369 that started using these deprecated versions in the first place, would you be available for review then?

@swift-ci smoke test

Would conditionally enabling __is_trivially_constructible and __is_trivially_destructible, but falling back on deprecated versions be ok?

@swift-ci smoke test