3137 illegal hardware instruction (core dumped)  python

Describe the bug
Calling open_soma() returns an error 3137 illegal hardware instruction
To Reproduce
Setup
python3.11 -m venv venv
source venv/bin/activate
pip install -U cellxgene-census

Attempt to run
❯ python
Python 3.11.9 (main, Apr  6 2024, 17:59:24) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cellxgene_census
>>> soma = cellxgene_census.open_soma()
The "stable" release is currently 2023-12-15. Specify 'census_version="2023-12-15"' in future calls to open_soma() to ensure data consistency.
[1]    3766 illegal hardware instruction (core dumped)  python

Expected behavior
open_soma() not returning an error
Environment

Python 3.11.9
Machine: 147GB RAM, 16 CPU cores, M2 SSD disk with enough space
OS: Linux 5.15.0-105-generic #115-Ubuntu SMP Mon Apr 15 09:52:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Software versions:

Python user: pip list

Package            Version
------------------ -----------
aiobotocore        2.12.3
aiohttp            3.9.5
aioitertools       0.11.0
aiosignal          1.3.1
anndata            0.10.7
array_api_compat   1.6
attrs              23.2.0
botocore           1.34.69
cellxgene-census   1.13.0
certifi            2024.2.2
charset-normalizer 3.3.2
contourpy          1.2.1
cycler             0.12.1
fonttools          4.51.0
frozenlist         1.4.1
fsspec             2024.3.1
h5py               3.11.0
idna               3.7
jmespath           1.0.1
joblib             1.4.0
kiwisolver         1.4.5
legacy-api-wrap    1.4
llvmlite           0.42.0
matplotlib         3.8.4
multidict          6.0.5
natsort            8.4.0
networkx           3.3
numba              0.59.1
numpy              1.26.4
packaging          24.0
pandas             2.2.2
patsy              0.5.6
pillow             10.3.0
pip                24.0
pyarrow            16.0.0
pyarrow-hotfix     0.6
pynndescent        0.5.12
pyparsing          3.1.2
python-dateutil    2.9.0.post0
pytz               2024.1
requests           2.31.0
s3fs               2024.3.1
scanpy             1.10.1
scikit-learn       1.4.2
scipy              1.13.0
seaborn            0.13.2
session_info       1.0.0
setuptools         65.5.0
six                1.16.0
somacore           1.0.10
statsmodels        0.14.2
stdlib-list        0.10.0
threadpoolctl      3.5.0
tiledb             0.27.1
tiledbsoma         1.9.5
tqdm               4.66.2
typing_extensions  4.11.0
tzdata             2024.1
umap-learn         0.5.6
urllib3            2.2.1
wrapt              1.16.0
yarl               1.9.4

Hey @Mnikley,
to debug this, it would be helpful to have more information on what hardware/configuration you're using. In particular, are you running this in Docker? If so, what is the CPU type of the host machine?
It would also be useful if you could run import tiledbsoma; tiledbsoma.show_package_versions() and paste the output. If you prefer, you can reach out to me via email at<EMAIL_ADDRESS>

Hey @ebezzi,
thank you for your answer - it seems like the problem is indeed related to the CPU we are using, as we run a VM on a proxmox server. The code works fine on another machine with direct access to the CPU (no virtualization). However, it would be great to run the code on our VM anyway.
On the VM:
❯ python -c "import tiledbsoma; tiledbsoma.show_package_versions()"
tiledbsoma.__version__        1.9.5
TileDB-Py tiledb.version()    (0, 27, 1)
TileDB core version           2.21.1
[1]    6305 illegal hardware instruction (core dumped)  python -c "import tiledbsoma; tiledbsoma.show_package_versions()"

More details about the CPU in the VM:
❯ lscpu
Architecture:           x86_64
  CPU op-mode(s):       32-bit, 64-bit
  Address sizes:        40 bits physical, 48 bits virtual
  Byte Order:           Little Endian
CPU(s):                 8
  On-line CPU(s) list:  0-7
Vendor ID:              GenuineIntel
  Model name:           QEMU Virtual CPU version 2.5+
    CPU family:         15
    Model:              107
    Thread(s) per core: 1
    Core(s) per socket: 8
    Socket(s):          1
    Stepping:           1
    BogoMIPS:           6192.42
    Flags:              fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid pni ssse3 c
                        x16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm cpuid_fault pti
Caches (sum of all):
  L1d:                  256 KiB (8 instances)
  L1i:                  256 KiB (8 instances)
  L2:                   32 MiB (8 instances)
  L3:                   16 MiB (1 instance)
NUMA:
  NUMA node(s):         1
  NUMA node0 CPU(s):    0-7
Vulnerabilities:
  Gather data sampling: Not affected
  Itlb multihit:        KVM: Mitigation: VMX unsupported
  L1tf:                 Mitigation; PTE Inversion
  Mds:                  Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
  Meltdown:             Mitigation; PTI
  Mmio stale data:      Unknown: No mitigations
  Retbleed:             Not affected
  Spec rstack overflow: Not affected
  Spec store bypass:    Vulnerable
  Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:           Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                Not affected
  Tsx async abort:      Not affected

and the CPU information on the host machine running proxmox:
root@pve:~# lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          52 bits physical, 57 bits virtual
  Byte Order:             Little Endian
CPU(s):                   32
  On-line CPU(s) list:    0-31
Vendor ID:                GenuineIntel
  BIOS Vendor ID:         Intel(R) Corporation
  Model name:             Intel(R) Xeon(R) w5-2465X
    BIOS Model name:      Intel(R) Xeon(R) w5-2465X  CPU @ 3.1GHz
    BIOS CPU family:      179
    CPU family:           6
    Model:                143
    Thread(s) per core:   2
    Core(s) per socket:   16
    Socket(s):            1
    Stepping:             8
    CPU(s) scaling MHz:   27%
    CPU max MHz:          4700.0000
    CPU min MHz:          800.0000
    BogoMIPS:             6192.00
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm const
                          ant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2
                          ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_faul
                          t epb cat_l3 cat_l2 cdp_l3 intel_ppin cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2
                          smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xg
                          etbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect user_shstk avx_vnni avx512_bf16 wbnoinvd dtherm ida arat pln pts hwp hwp_
                          act_window hwp_epp hwp_pkg_req vnmi avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq la5
                          7 rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxldtrk pconfig arch_lbr ibt amx_bf16 avx512_fp16 amx_tile amx_int8 flu
                          sh_l1d arch_capabilities
Virtualization features:
  Virtualization:         VT-x
Caches (sum of all):
  L1d:                    768 KiB (16 instances)
  L1i:                    512 KiB (16 instances)
  L2:                     32 MiB (16 instances)
  L3:                     33.8 MiB (1 instance)
NUMA:
  NUMA node(s):           1
  NUMA node0 CPU(s):      0-31
Vulnerabilities:
  Gather data sampling:   Not affected
  Itlb multihit:          Not affected
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Not affected
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Enhanced / Automatic IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
  Srbds:                  Not affected
  Tsx async abort:        Not affected

Running the code directly on the host is unfortunately no option to us.

Hey @Mnikley ,
since we can't easily reproduce your issue (we don't have the same virtualization setup available), it would be useful if you could run the debugger and provide a stack trace that could help us identify the problem.
gdb -- python
(gdb) r
>>> import cellxgene_census
>>> soma = cellxgene_census.open_soma()
# illegal instruction should be caught and printed here...
(gdb) bt

This should generate a stack trace that should hopefully contain more information about the library that is causing the segmentation fault.

Dear @ebezzi ,
this is the stack trace:
>>> soma = cellxgene_census.open_soma()
The "stable" release is currently 2023-12-15. Specify 'census_version="2023-12-15"' in future calls to open_soma() to ensure data consistency.
[New Thread 0x7fffb4029640 (LWP 16613)]
[New Thread 0x7fffb3828640 (LWP 16614)]
[New Thread 0x7fffb3027640 (LWP 16615)]
[New Thread 0x7fffb2826640 (LWP 16616)]
[New Thread 0x7fffb2025640 (LWP 16617)]
[New Thread 0x7fffb1824640 (LWP 16618)]
[New Thread 0x7fffb1023640 (LWP 16619)]
[New Thread 0x7fffb0822640 (LWP 16620)]
[New Thread 0x7fffb0021640 (LWP 16621)]
[New Thread 0x7fffaf820640 (LWP 16622)]
[New Thread 0x7fffaf01f640 (LWP 16623)]
[New Thread 0x7fffae81e640 (LWP 16624)]
[New Thread 0x7fffae01d640 (LWP 16625)]
[New Thread 0x7fffad81c640 (LWP 16626)]
[New Thread 0x7fffad01b640 (LWP 16627)]
[New Thread 0x7fffac81a640 (LWP 16628)]
[New Thread 0x7fffac001640 (LWP 16629)]
[New Thread 0x7fffa3fff640 (LWP 16630)]
[New Thread 0x7fffab800640 (LWP 16631)]
[New Thread 0x7fffaafff640 (LWP 16632)]
[New Thread 0x7fffaa7fe640 (LWP 16633)]

Thread 1 "python" received signal SIGILL, Illegal instruction.
0x00007fffc0ac7e32 in void std::vector<std::string, std::allocator<std::string> >::_M_realloc_insert<std::string const&>(__gnu_cxx::__normal_iterator<std::string*, std::vector<std::string, std::allocator<std::string> > >, std::string const&) () from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledbsoma-4d9c0eb1.so
(gdb) bt
#0  0x00007fffc0ac7e32 in void std::vector<std::string, std::allocator<std::string> >::_M_realloc_insert<std::string const&>(__gnu_cxx::__normal_iterator<std::string*, std::vector<std::string, std::allocator<std::string> > >, std::string const&) ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledbsoma-4d9c0eb1.so
#1  0x00007fffbf760f62 in void Aws::Http::URI::AddPathSegments<std::string>(std::string) ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#2  0x00007fffbf78bcf3 in Aws::Http::URI::SetPath(std::string const&) ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#3  0x00007fffbf78beb7 in Aws::Http::URI::ExtractAndSetPath(std::string const&) ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#4  0x00007fffbf78c083 in Aws::Http::URI::ParseURIParts(std::string const&) ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#5  0x00007fffbf784c7d in Aws::Http::CreateHttpRequest(std::string const&, Aws::Http::HttpMethod, std::function<std::iostream* ()> const&) ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#6  0x00007fffbf79ede8 in Aws::Internal::EC2MetadataClient::GetCurrentRegion() const ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#7  0x00007fffbf8089aa in Aws::Client::ClientConfiguration::ClientConfiguration() ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#8  0x00007fffbed9bb2b in tiledb::sm::S3::init_client() const ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#9  0x00007fffbeda1c39 in tiledb::sm::S3::is_dir(tiledb::sm::URI const&, bool*) const ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#10 0x00007fffbedd7c92 in tiledb::sm::VFS::is_dir(tiledb::sm::URI const&, bool*) const ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#11 0x00007fffbf4fa99e in tiledb::sm::StorageManagerCanonical::is_array(tiledb::sm::URI const&) const ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#12 0x00007fffbf4fc183 in tiledb::sm::StorageManagerCanonical::object_type(tiledb::sm::URI const&, tiledb::sm::ObjectType*) const ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#13 0x00007fffbece08f1 in tiledb_object_type () from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledb-22504c42.so.2.21
#14 0x00007fffc0ae98e4 in tiledbsoma::SOMAObject::open(std::basic_string_view<char, std::char_traits<char> >, OpenMode, std::shared_ptr<tiledbsoma::SOMAContext>, std::optional<std::pair<unsigned long, unsigned long> >, std::optional<std::string>) ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledbsoma-4d9c0eb1.so
#15 0x00007fffc0cbbd4a in libtiledbsomacpp::load_soma_object(pybind11::module_&)::{lambda(std::basic_string_view<char, std::char_traits<char> >, OpenMode, std::shared_ptr<tiledbsoma::SOMAContext>, std::optional<std::pair<unsigned long, unsigned long> >, std::optional<std::string>)#1}::operator()(std::basic_string_view<char, std::char_traits<char> >, OpenMode, std::shared_ptr<tiledbsoma::SOMAContext>, std::optional<std::pair<unsigned long, unsigned long> >, std::optional<std::string>) const [clone .constprop.0] ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/pytiledbsoma.cpython-311-x86_64-linux-gnu.so
#16 0x00007fffc0cbda0f in pybind11::cpp_function::initialize<libtiledbsomacpp::load_soma_object(pybind11::module_&)::{lambda(std::basic_string_view<char, std::char_traits<char> >, OpenMode, std::shared_ptr<tiledbsoma::SOMAContext>, std::optional<std::pair<unsigned long, unsigned long> >, std::optional<std::string>)#1}, pybind11::object, std::basic_string_view<char, std::char_traits<char> >, OpenMode, std::shared_ptr<tiledbsoma::SOMAContext>, std::optional<std::pair<unsigned long, unsigned long> >, std::optional<std::string>, pybind11::name, pybind11::scope, pybind11::sibling, pybind11::arg, pybind11::arg, pybind11::arg, pybind11::kw_only, pybind11::arg_v, pybind11::arg_v>(libtiledbsomacpp::load_soma_object(pybind11::module_&)::{lambda(std::basic_string_view<char, std::char_traits<char> >, OpenMode, std::shared_ptr<tiledbsoma::SOMAContext>, std::optional<std::pair<unsigned long, unsigned long> >, std::optional<std::string>)#1}&&, pybind11::object (*)(std::basic_string_view<char, std::char_traits<char> >, OpenMode, std::shared_ptr<tiledbsoma::SOMAContext>, std::opti--Type <RET> for more, q to quit, c to continue without paging--
onal<std::pair<unsigned long, unsigned long> >, std::optional<std::string>), pybind11::name const&, pybind11::scope const&, pybind11::sibling const&, pybind11::arg const&, pybind11::arg const&, pybind11::arg const&, pybind11::kw_only const&, pybind11::arg_v const&, pybind11::arg_v const&)::{lambda(pybind11::detail::function_call&)#3}::_FUN(pybind11::detail::function_call&) () from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/pytiledbsoma.cpython-311-x86_64-linux-gnu.so
#17 0x00007fffc0c3e4fe in pybind11::cpp_function::dispatcher(_object*, _object*, _object*) ()
   from /home/myuser/cellxgenetest/venv/lib/python3.11/site-packages/tiledbsoma/pytiledbsoma.cpython-311-x86_64-linux-gnu.so
#18 0x000000000055539b in ?? ()
#19 0x000000000052f46c in _PyObject_MakeTpCall ()
#20 0x000000000053d620 in _PyEval_EvalFrameDefault ()
#21 0x0000000000613974 in ?? ()
#22 0x0000000000612fd7 in PyEval_EvalCode ()
#23 0x0000000000633deb in ?? ()
#24 0x0000000000630044 in ?? ()
#25 0x00000000004f24b2 in ?? ()
#26 0x00000000004f25b4 in _PyRun_InteractiveLoopObject ()
#27 0x000000000046b0f0 in ?? ()
#28 0x00000000004f2209 in PyRun_AnyFileExFlags ()
#29 0x0000000000465074 in ?? ()
#30 0x00000000006042bd in Py_BytesMain ()
#31 0x00007ffff7c7cd90 in __libc_start_call_main (main=main@entry=0x604210, argc=argc@entry=1, argv=argv@entry=0x7fffffffcb58) at ../sysdeps/nptl/libc_start_call_main.h:58
#32 0x00007ffff7c7ce40 in __libc_start_main_impl (main=0x604210, argc=1, argv=0x7fffffffcb58, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fffffffcb48) at ../csu/libc-start.c:392
#33 0x0000000000604145 in _start ()
(gdb)

best,
Matthias

I'm experiencing "Illegal instruction (core dumped)" as well. Interestingly I'm getting it on 2 of 3 machines all running from the same venv. Different locations for the faults. I've tried earlier and later versions of tiledbsoma with the same outcomes.
Works:
$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         46 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  2
  On-line CPU(s) list:   0,1
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
    CPU family:          6
    Model:               63

Core Dump:
$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  32
  On-line CPU(s) list:   0-31
Vendor ID:               AuthenticAMD
  Model name:            AMD Opteron(tm) Processor 6380
    CPU family:          21
    Model:               2

 (gdb...)
 [Thread 0x7ffed6ffd640 (LWP 896641) exited]

Thread 1 "python" received signal SIGILL, Illegal instruction.
0x00007fff48c26def in std::__detail::_Compiler<std::regex_traits<char> >::_Compiler(char const*, char const*, std::locale const&, std::regex_constants::syntax_option_type) () from

Core Dump:
$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         44 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  64
  On-line CPU(s) list:   0-63
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Xeon(R) CPU E7- 4830  @ 2.13GHz
    CPU family:          6
    Model:               47

 (gdb...)
 [New Thread 0x7ffdf5ffb640 (LWP 2977224)]

Thread 1 "python" received signal SIGILL, Illegal instruction.
0x00007ffea8b7be32 in void std::vector<std::string, std::allocator<std::string> >::_M_realloc_insert<std::string const&>(__gnu_cxx::__normal_iterator<std::string*, std::vector<std::string, std::allocator<std::string> > >, std::string const&) () from /public/home/rcurrie/cellxgene/venv/lib/python3.10/site-packages/tiledbsoma/../tiledbsoma.libs/libtiledbsoma-4d9c0eb1.so

Package Details:
$ python -c "import tiledbsoma; tiledbsoma.show_package_versions()"
tiledbsoma.__version__        1.9.5
TileDB-Py tiledb.version()    (0, 27, 1)
TileDB core version           2.21.1
libtiledbsoma version()       libtiledb=2.21.1
python version                3.10.12.final.0
OS version                    Linux 5.15.0-78-generic

@rcurrie Thanks for posting cpu details!  With these pages at Wikipedia (Intel, AMD) I see that these are in fact old:
Intel(R) Xeon(R) CPU E5-2697 v3 -- Sep 2014
Intel(R) Xeon(R) CPU E7- 4830  -- Apr 2011
AMD Opteron(tm) Processor 6380 -- Nov 2012
We have seen similar issues with old Xeons at CRAN for the R builds also experiencing the 'illegal instruction'. So we then split pre-made artifacts into 'normal' and 'non-AVX2' builds.  One can check for what the cpus have: Eg on my (only ~five or six years old) computer I see cat /proc/cpuinfo | grep avx2 } head -1 return a match whereas on an older Xeon 6226 I do not.   That Xeon machine for example also has issues with Arrow builds when pre-made blobs are integrated to speed the build up.
All this may suggest that the Python wheels might be too new for the hardware used.  A quick workaround may be to build from source.

Makes sense - will try building from source and report back - thank for the quick reply!

@eddelbuettel Building TileDB-SOMA from source worked! I'll add the order to the issue @johnkerl opened.


metals: init at 0.5.1

Things done
Initialize metals package. Note that this package includes wrappers for vim, sublime and emacs written according to the package documentation. As I only use emacs, it's the only one properly tested.

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@chrilves if you want to give it a try, there it is

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/69

@GrahamcOfBorg build metals


chore(organization): fix errors caused by change in API error handling

the first is an intermittent failure,

the second is expected, has been reported to the team (a probable consequence of #1184)
should be good to go 👍


Build cuquantum-python in this repo?

Right now, when making a new release, we need to build cuquantum first, and then wait some time (a couple of hours in the past) to sync CDN so that we can build cuquantum-python. By unifying the conda recipes we can release them at once. We should look into it.

Hi @conda-forge/core I am seeing a situation. I am trying to generate cuquantum-python in this feedstock so that I can abandon cuquantum-python-feedstock. I already bumped the build number, but it seems the CI is unable to upload the packages to cf-stage, am I missing any step?
copy results:
{
  "errors": [
    "output linux-64/cuquantum-python-22.07.1-py38hca921df_1.tar.bz2 not allowed for conda-forge/cuquantum-feedstock",
    "output linux-64/cuquantum-python-22.07.1-py310hbe3ad0c_1.tar.bz2 not allowed for conda-forge/cuquantum-feedstock",
    "output linux-64/cuquantum-python-22.07.1-py39hcf40d7a_1.tar.bz2 not allowed for conda-forge/cuquantum-feedstock"
  ],
  "valid": {
    "linux-64/cuquantum-python-22.07.1-py38hca921df_1.tar.bz2": false,
    "linux-64/cuquantum-python-22.07.1-py310hbe3ad0c_1.tar.bz2": false,
    "linux-64/cutensornet-1.1.1-h0800d71_0.tar.bz2": true,
    "linux-64/cuquantum-python-22.07.1-py39hcf40d7a_1.tar.bz2": false,
    "linux-64/custatevec-1.1.0-h0800d71_0.tar.bz2": true,
    "linux-64/cuquantum-<IP_ADDRESS>-h0bbbad9_1.tar.bz2": true
  },
  "copied": {
    "linux-64/cutensornet-1.1.1-h0800d71_0.tar.bz2": true,
    "linux-64/custatevec-1.1.0-h0800d71_0.tar.bz2": true,
    "linux-64/cuquantum-<IP_ADDRESS>-h0bbbad9_1.tar.bz2": true,
    "linux-64/cuquantum-python-22.07.1-py38hca921df_1.tar.bz2": false,
    "linux-64/cuquantum-python-22.07.1-py310hbe3ad0c_1.tar.bz2": false,
    "linux-64/cuquantum-python-22.07.1-py39hcf40d7a_1.tar.bz2": false
  }
}
Failed to upload due to copy from staging to production channel failed. Trying again in 10 seconds

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=613908

Would do something like this:

https://github.com/conda-forge/feedstock-outputs/pull/3
https://github.com/conda-forge/feedstock-outputs/pull/5

Thanks @jakirkham 🙏 Done: https://github.com/conda-forge/feedstock-outputs/pull/38

I see the uploads succeeded now, closing.


Close button isn't shown for Edit connection pop-up

System information:

Ubuntu 18.04
DBeaver version 6.0.2

Describe the problem you're observing:
Close button (at the top right corner of the window) isn't shown for Edit connection pop-up
Steps to reproduce, if exist:

Create connection
Choose Edit connection (F4)

As shown in issue #7272, there is now (6.2.5) a Close button at the bottom.


udpate quick start for tfjobs

The quick start for tfjobs is out of date, The current versions of the TF operator is v1beta1, but the quick start is still for v1alpha2, that cannot be executed in kubeflow 0.4, and some link is not reasonable.
The PR is to update the quick start for v1beta1, and correct a link and sample outputs. Thanks.

This change is

/assign @scorpiocph

Coverage remained the same at 76.744% when pulling 0485bcc3a33809ad3e0bdc640ac86db10122320c on jinchihe:udpate_quick_start_for_tf into 4e86081b5bc44763be0d596868cde80afa8944c8 on kubeflow:master.

/assign @gaocegege
Could you please take a look or assign someone? Thanks.

Current version is v1beta2 and v1beta1 configs are also supported.  I see that v1beta2 examples are not added though.
Related: https://github.com/kubeflow/tf-operator/pull/943

Current version is v1beta2 and v1beta1 configs are also supported. I see that v1beta2 examples are not added though.
Related: #943

Thanks @johnugeorge, I updated the quick start to mention v1beta2. But I think we can just show v1beta1 as previous behavior, since just have example for v1beta1 under examples. Comments?

Sounds good

/retest

/lgtm

/approve


Rename spring-doc to springdoc

Following https://github.com/jhipster/jhipster-lite/pull/538

cc @Bolo89 : hope you're ok with this change


Remote Control Results in Protocol Error Win7

When I remote control a user from Task Manager, it disconnects admin RDP session and shows
"Because of protocol error, the session will be disconnected"
Using Win 7 Pro
Session Shadowing Mode: Full access without user permission

Try to update your RDP client, maybe this helps.

Closed as solved. If not - reopen it.


[Bug]: dynamic ess starts to discharge my battery to grid

Contact Details
through github
VRM portal ID
e45f019ec891
Country / region
Germany (de)
B max
10
TB max
4
FB max
4
TG max
4
FG max
4
Battery costs
0.01
Buy price
(p+0.1574)
Sell price
0.07
feed-in possible
yes
feed-in possible
yes
Version
0.1.3
What happened?
When i enable Dynamic ESS - it starts to immeaditly discharge the battery to grid - even the battery is not full and i would need the power for night...
Or is it due to the fact that i see no forecast in vrm? I added grid and pvinverter just 3 days ago.
Relevant log output
no idea how to get the log. I did not find any information how to get a log. Never used Node Red before... i'm more in python or C ;-)

Screenshots
![DESCRIPTION](LINK.png)

Please wait until there is one week of forecast data and try again. At the moment the models require a week of data before to function properly.
If the problem persists, please re-open the issue (or file a new one).

Ok thanks may be update the documentation which says 48hours.


Tv turn on but changes sound output twice

My LG Oled B7 is connected to my Yamaha AVR via HDMI ARC. When I turn on the tv via homebrige it does change the sound output twice. How can I stop this behaviour? Sound output should always be the external speaker.
4/22/2020, 3:52:07 PM] [Televisore] webOS - connected to TV
[4/22/2020, 3:52:07 PM] [Televisore] webOS - app launched, current appId: com.webos.app.livetv
[4/22/2020, 3:52:07 PM] [Televisore] webOS - audio status changed
[4/22/2020, 3:52:07 PM] [Televisore] webOS - current volume: 0
[4/22/2020, 3:52:07 PM] [Televisore] webOS - muted: No
[4/22/2020, 3:52:07 PM] [Televisore] webOS - sound output changed
[4/22/2020, 3:52:07 PM] [Televisore] webOS - current sound output: external_speaker
[4/22/2020, 3:52:07 PM] [Televisore] webOS - current channel status changed
[4/22/2020, 3:52:07 PM] [Televisore] webOS - current channel: 507, LA7 HD
[4/22/2020, 3:52:12 PM] [Televisore] webOS - sound output changed
[4/22/2020, 3:52:12 PM] [Televisore] webOS - current sound output: tv_speaker
[4/22/2020, 3:52:14 PM] [Televisore] webOS - sound output changed
[4/22/2020, 3:52:14 PM] [Televisore] webOS - current sound output: external_speaker

Honestly i have no idea, but what i can tell is that this comes from the TV and not my plugin. Maybe the TV behaves like that always, you just now see it because i listen to those status changes in my plugin.

Hi,
No it does not behave that way normally, I can tell you that because when I switch output the AVR makes a “click” so I can hear it.
When I turn on the TV vie remote control I hear only one AVR click and the sound is istant.
Via homebridge I hear the first click with istant sound, soon after I hear audio through tv speakers, and again one more avr click.

Il giorno 22 apr 2020, alle ore 17:34, Marcin<EMAIL_ADDRESS>ha scritto:
Honestly i have no idea, but what i can tell is that this comes from the TV and not my plugin. Maybe the TV behaves like that always, you just now see it because i listen to those status changes in my plugin.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/merdok/homebridge-webos-tv/issues/219#issuecomment-617853548, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF53ICDLRBHW5V4YXNB3E63RN4FBLANCNFSM4MOISXIA.
[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/merdok/homebridge-webos-tv/issues/219#issuecomment-617853548", "url": "https://github.com/merdok/homebridge-webos-tv/issues/219#issuecomment-617853548", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Sorry, no idea about the issue then, but i still think that this is not related to this plugin. I do not have any external sound device on my tv to even test that out.

During the period when my soundbar was wired up to my tv via HDMI ARC, I was unable to change volume via homebridge/homekit. If I'm not busy, I'll try to troubleshoot my soundbar via HDMI ARC and see if I can recreate the issue

@RealDyllon i am not sure if you are aware, but the slider volume control does not work when using an external audio device. In that case you need to use buttons

@merdok thanks, I’ll try changing the volume control mode, and attempt to recreate the issue.

@RealDyllon do you still have the issue?


Can I use conditional comments to import entry script?

I have multiple entry like:
entry: {
  foo: 'foo.js'
  bar: 'bar.js'
  ie: 'ie.js'
},
output: {
  path: path.join(__dirname, '/dist/'),
  filename: '[name]-[hash].min.js'
}

when I use HtmlWebpackPlugin, It's for certain to import or not import an entry, using chunks.
I hope to generate conditional comments in HTML file, like:
<!--[if lte IE 9]>
  <script type="text/javascript" src="ie-2e1dwn....js"></script>
<![endif]-->

Any idea on how to achieve that?

You have to create a custom index file:
https://github.com/ampedandwired/html-webpack-plugin/blob/master/default_index.html#L15

Ops, I missed that part.
work great for me, thanks a lot.
my scripts:
<!--[if lte IE 9]>
{% for (var chunk in o.htmlWebpackPlugin.files.chunks) { %}
{% if (/^ieCompatible-\w+\.min\.js$/.test(o.htmlWebpackPlugin.files.chunks[chunk].entry)) { %}
<script type="text/javascript" src="{%=o.htmlWebpackPlugin.files.chunks[chunk].entry %}></script>
{% } %}
{% } %}
<![endif]-->

Cool :+1:

syntax has changes now, change regular expression according to your chunks
<!--[if lte IE 9]>     <% for (var chunk in htmlWebpackPlugin.files.chunks) { %>       <% if ((htmlWebpackPlugin.files.chunks[chunk].entry).match('ie')) {%>         <script src="<%= htmlWebpackPlugin.files.chunks[chunk].entry %>"></script>       <% } %>     <% } %>     <![endif]-->

Thanks for notification.

@saalmaan How to filter those ie chunks from regular injection?

@bammoo take a look at the html-webpack-exclude-assets-plugin by @jamesjieye - it allows filtering by regular expressions


Fix deleted branch isn't removed when push the branch again

Will fix #9201

make lg-tm work...

Please send backport


DEA advertise causes flood of blobstore requests

When a DEA registers for the first time via the NATS 'staging.advertise', CC responds with a NATS 'buildpack' response.
In the small, this doesn't seem bad, but when you have 30 CCs, 400 DEAs and 15 buildpacks, this creates a nightmare. Each DEA will broadcast to each CC which will intern generate the 15 buildpack URIs. If we just focus on 1 DEA, this is 30 x 15 = 450 requests.
When a CC is restarted, it will respond to all 400 DEAs since it has no record of them, the requests to the objectstore become 400 x 15 = 6000 requests per CC. If each request takes .5s, that will be a minimum of 6000 / 20 * .5 = 150s.
During this 150s, the CC will be unresponsive and monit at times will become unhappy and restart CC.
This is also happening across all the CCs as they are restarted.
There are a few problems identified, some easier to fix than others.

Numerous calls to the blobstore to obtain the buildpack uris.
Having all N CC's respond to a staging.advertise with a buildpack is nice but overkill

Solutions

We should remember the list of files from the blobstore once rather than doing it multiple times when the list does not change.
CCs and DEAs should be able to compute a simple SHA of the known buildpacks without going to the blobstore.
A DEA can determine if it needs to request the buildpack URIs.
DEAs should request the buildpack uris rather than blindly have them sent by all CCs.

        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:134:in `select'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:134:in `rescue in block in connect'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:114:in `block in connect'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:110:in `each'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:110:in `connect'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/ssl_socket.rb:150:in `connect'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:28:in `initialize'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/ssl_socket.rb:8:in `initialize'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/connection.rb:387:in `new'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/connection.rb:387:in `socket'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/connection.rb:106:in `request_call'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/middlewares/mock.rb:47:in `request_call'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/middlewares/instrumentor.rb:22:in `request_call'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/middlewares/base.rb:15:in `request_call'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/middlewares/base.rb:15:in `request_call'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/middlewares/base.rb:15:in `request_call'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/connection.rb:233:in `request'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/fog-core-1.28.0/lib/fog/core/connection.rb:63:in `request'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/fog-1.27.0/lib/fog/openstack/storage.rb:149:in `request'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/fog-1.27.0/lib/fog/openstack/requests/storage/head_object.rb:12:in `head_object'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/fog-1.27.0/lib/fog/openstack/models/storage/files.rb:84:in `head'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/blobstore/client.rb:138:in `file'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/blobstore/client.rb:122:in `blob'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/blobstore/client.rb:117:in `download_uri'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/blobstore/url_generator.rb:72:in `generate_download_url'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/blobstore/url_generator.rb:30:in `admin_buildpack_download_url'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/admin_buildpacks_presenter.rb:17:in `admin_buildpack_entry'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/admin_buildpacks_presenter.rb:10:in `block in to_staging_message_array'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/admin_buildpacks_presenter.rb:10:in `collect'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/admin_buildpacks_presenter.rb:10:in `to_staging_message_array'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/dea/stager_pool.rb:53:in `admin_buildpacks'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/dea/stager_pool.rb:49:in `publish_buildpacks'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/dea/stager_pool.rb:18:in `process_advertise_message'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/dea/stager_pool.rb:44:in `block in register_subscriptions'",
        "/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/cf-message-bus-0.3.3/lib/cf_message_bus/message_bus.rb:88:in `yield'",

@fraenkel Okay to close this issue?  I believe all the PRs were merged.

Yup. Closed.


Fix #LIBCLOUD-925

Fixex an error in _get_error function in GCE driver.
Description
Fixes an error in _get_error function in common/google.py file that assumes that the body['error'] value is a dict, but in some cases it contains an string (unicode).
So it tries to do a err.get and it failts.
Status
done, ready for review
Checklist (tick everything that applies)

[X] Code linting (required, can be done after the PR checks)
[ ] Documentation
[ ] Tests
[ ] ICLA (required for bigger changes)

Coverage increased (+0.003%) to 88.231% when pulling 814bc3e366bdce7f2b935eeb3c7ed21d562cf3e8 on micafer:trunk into 98c4fe0a085717e1a5353edf8cb9c3d3f699ed5d on apache:trunk.

👍  thanks for the contribution


Issues running sample examples on zcu102 with Vitis AI

Hi,
I have a zcu102 evaluation board and I am trying to run the samples from Running Vitis AI Examples Based on VART.
I have setup the host and evaluation board following the instructions from below locations.
https://www.xilinx.com/html_docs/vitis_ai/1_1/lbv1583226048322.html
https://www.xilinx.com/html_docs/vitis_ai/1_1/aqc1570690254969.html
Now I see below errors when I run the sample application. Could you please help me resolve the error?
./resnet50 model_dir_for_zcu102/
WARNING: Logging before InitGoogleLogging() is written to STDERR
F0416 17:53:44.919674  3203 xrt_cu.cpp:156] Check failed: is_done cu timeout! core_idx 1  handle=0x557695b1c0 ENV_PARAM(XLNX_DPU_TIMEOUT) 10000 state 1 ERT_CMD_STATE_COMPLETED 4 ms 10010  bo=1is_done 0
*** Check failure stack trace: ***
Aborted
Same issue happens when the run the sample applications from the overview folder.
~/overview/samples/classification# ./test_jpeg_classification resnet50 sample_classification.jpg
WARNING: Logging before InitGoogleLogging() is written to STDERR
F0416 17:19:27.592169  3193 xrt_cu.cpp:156] Check failed: is_done cu timeout! core_idx 1  handle=0x559b2d1800 ENV_PARAM(XLNX_DPU_TIMEOUT) 10000 state 1 ERT_CMD_STATE_COMPLETED 4 ms 10010  bo=1is_done 0
*** Check failure stack trace: ***
Aborted
Thanks
Susmitha

Hi @SusmithaGadagottu
Could you follow the instructions on the links below and try it again?
https://github.com/Xilinx/Vitis-AI/tree/master/VART#setting-up-the-host-for-edge
https://github.com/Xilinx/Vitis-AI/tree/master/VART#setting-up-the-target
https://github.com/Xilinx/Vitis-AI/tree/master/VART#running-vitis-ai-examples-for-edge
#Flashing the OS Image to the SD Card
https://www.xilinx.com/html_docs/vitis_ai/1_1/gum1570690244788.html

Hi @SusmithaGadagottu
May I know if your issue has been solved? Let me know if you have any problems. Thank you.

I am going to try this tomorrow and let you know the status by end of day
tomorrow.
On Thu, May 28, 2020 at 3:24 AM qianglin-xlnx<EMAIL_ADDRESS>wrote:

Hi @SusmithaGadagottu https://github.com/SusmithaGadagottu
May I know if your issue has been solved? Let me know if you have any
problems. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Xilinx/Vitis-AI/issues/85#issuecomment-635255072, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AMXY4IHKYLJCIL2GGR5WLULRTY3VRANCNFSM4MKLGIPA
.

Hi @SusmithaGadagottu and @qianglin-xlnx
I also encountered the same error when following the instructions on the links
https://github.com/Xilinx/Vitis-AI/tree/master/VART#setting-up-the-host-for-edge
https://github.com/Xilinx/Vitis-AI/tree/master/VART#setting-up-the-target
https://github.com/Xilinx/Vitis-AI/tree/master/VART#running-vitis-ai-examples-for-edge
#Flashing the OS Image to the SD Card
https://www.xilinx.com/html_docs/vitis_ai/1_1/gum1570690244788.html
Error message is
root@xilinx-zcu102-2019_2:~/VART/samples/resnet50# ./resnet50 model_dir_for_zcu102
WARNING: Logging before InitGoogleLogging() is written to STDERR
F1126 06:35:55.888309  3111 xrt_cu.cpp:156] Check failed: is_done cu timeout! core_idx 1  handle=0x556ca39f80 ENV_PARAM(XLNX_DPU_TIMEOUT) 10000 state 1 ERT_CMD_STATE_COMPLETED 4 ms 10010  bo=1is_done 0
*** Check failure stack trace: ***
Aborted
Do you have idea how to resolve this ?
regards,
HuiPeng

Hi @lhuipeng
It seems that the DPU works abnormal. It may caused by the OS image flashing abnormal or the unstable SD . I think you can try the following:

Use another SD, >=16G is better
Using Etcher tool to flash the OS image again .
https://www.xilinx.com/html_docs/vitis_ai/1_1/gum1570690244788.html

Hi @qianglin-xlnx,
With the new OS image, it is working now. Thanks.
regards,
Hui Peng

From: qianglin-xlnx<EMAIL_ADDRESS>Sent: Thursday, June 11, 2020 12:25 PM
To: Xilinx/Vitis-AI
Cc: Lim Hui Peng; Mention
Subject: Re: [Xilinx/Vitis-AI] Issues running sample examples on zcu102 with Vitis AI (#85)
Hi @lhuipenghttps://github.com/lhuipeng
It seems that the DPU works abnormal. It may caused by the OS image flashing abnormal or the unstable SD . I think you can try the following:

Use another SD, >=16G is better
Using Etcher tool to flash the OS image again .
https://www.xilinx.com/html_docs/vitis_ai/1_1/gum1570690244788.html

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Xilinx/Vitis-AI/issues/85#issuecomment-642398104, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APG7RSFQ5UKULUV3N3YPLUDRWBMENANCNFSM4MKLGIPA.

I am ok now and able to run the samples from VART and also AI libraries.
This issue can be closed if it is not closed already.
On Mon, Jun 15, 2020 at 6:58 PM lhuipeng<EMAIL_ADDRESS>wrote:

Hi @qianglin-xlnx,
With the new OS image, it is working now. Thanks.
regards,
Hui Peng

From: qianglin-xlnx<EMAIL_ADDRESS>Sent: Thursday, June 11, 2020 12:25 PM
To: Xilinx/Vitis-AI
Cc: Lim Hui Peng; Mention
Subject: Re: [Xilinx/Vitis-AI] Issues running sample examples on zcu102
with Vitis AI (#85)
Hi @lhuipenghttps://github.com/lhuipeng
It seems that the DPU works abnormal. It may caused by the OS image
flashing abnormal or the unstable SD . I think you can try the following:

Use another SD, >=16G is better
Using Etcher tool to flash the OS image again .
https://www.xilinx.com/html_docs/vitis_ai/1_1/gum1570690244788.html

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Xilinx/Vitis-AI/issues/85#issuecomment-642398104>, or
unsubscribe<
https://github.com/notifications/unsubscribe-auth/APG7RSFQ5UKULUV3N3YPLUDRWBMENANCNFSM4MKLGIPA

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Xilinx/Vitis-AI/issues/85#issuecomment-644484153, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AMXY4IHB6W3DFAOB4KZXL6TRW3GT5ANCNFSM4MKLGIPA
.


Upgrade to Scala 2.10.5 and 2.11.6.

Nightly: https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/1878/
Weekly: https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/1879/

Review by @gzm0 one of these days.
Btw, I published the compiler for 2.10.5 and 2.11.6 in versions 0.5.6, 0.6.0 and 0.6.1.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/1460/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/1879/
Test PASSed.

The 2.10.5 and 2.11.6 of nightly and weekly passed.

That's all

Updated.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/1463/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/1885/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/1464/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/1886/
Test FAILed.

@gzm0 I have an issue with the CI infrastructure. See this failing worker task:
https://scala-webapps.epfl.ch/jenkins/job/scalajs-task-worker/31081/console
It reports a binary compatibility issue wrt 0.6.1, saying that OptimizerCore.withState changed return type from Object to TailRec. But that's not true, it hasn't. A local run reports no issue.
But withState is precisely the method I had to change between the failed attempt at releasing 0.6.1, and the actual 0.6.1. I guess this worker was the one testing sbt-plugin-test, and so it published locally the wrong 0.6.1. Now, when trying to check bin compat, it resolves to the locally published, wrong, 0.6.1, and reports a binary compat issue which, in fact, does not exist.
Do you know how can I make this worker (and possibly others) forget about this wrong local 0.6.1?

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/1465/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/1887/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/1466/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/1888/
Test FAILed.

retest this please

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/1467/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/1890/
Test PASSed.

Do you know how can I make this worker (and possibly others) forget about this wrong local 0.6.1?

You'll have to nuke the local directory in the ivy/sbt home at /localhome/jenkins/scala-js-sbt-homes/sbt-home. It would be best to have a home per Jenkins workspace and remove the local directory before each run. (So we could get caching, but not leak stuff between builds).

I don't think I have access to these machines ^^

OK, done. At least on that machine.

I don't think I have access to these machines ^^

Uname & Password are in the LAMP wiki (in case you haven't figured out). Or ask Fabien.


Modifier key stays pressed

Is there a way to solve this problem?
Expected key operation meta+c
⭕ + meta + shift - shift + c -> meta+c
❌ + shift + meta - shift + c -> shift+meta+c
Expected key operation alt+left
⭕ + alt + shift - shift + left -> alt+left
❌ + shift + alt - shift + left -> shift+alt+left
Expected key operation shift+left
⭕ + shift + alt + left - alt + left -> shift+left
❌ + alt + shift + left - alt + left -> shift+alt+left
+ press / - release
default.conf
[ids]
*

[main]
leftmeta = overload(control, muhenkan)
rightmeta = overload(control, henkan)

[shift]
meta = layer(ctrl_shift)
alt = layer(alt_shift)

[control]
left = home
shift = layer(ctrl_shift)

[ctrl_shift:C-S]
left = S-home

[alt]
left = C-left
shift = layer(alt_shift)

[alt_shift:A-S]
left = S-C-left

keyd 2.2.6-beta

Unfortunately this is just a consequence of the way that layers work. In some circumstances this is desirable, but in the case of modifiers it presents the subtle issue you have described above. I have considered changing the default behaviour or adding a feature to address this, but I haven't encountered any issues in my day to day use or heard enough complaints to warrant the effort. Is this a major issue for you?

Great! This issue has been fixed in v2.3.0-rc 😁
2.3.0-rc default.conf
[ids]
*

[main]
leftmeta = overload(control, muhenkan)
rightmeta = overload(control, henkan)

[shift]

[control]
left = home

[alt]
left = C-left

[ctrl+shift]
left = S-home

[alt+shift]
left = S-C-left

Indeed :). I was going to update this thread. The config you posted has a typo (ctrl+shift should be control+shift (unless you've defined ctrl somewhere else) but I assume you've already figured that out :P.


feat(kit): Allow specifying types for addComponent

Describe the feature
Currently component.d.ts file is generated based on the filePath and export properties passed to addComponent function as defined here.
There are cases where component source and types are defined separately. This is possible to workaround if you have control over the components but this not always the case for module authors.
I suggest something like:
addComponent({
  name: 'MyComponent',
  filePath: 'lib/components/my-component',
  export: 'default',
  // If `typings` is not defined, it falls back to current implementation.
  typings: {
    filePath: 'lib/types',
    export: 'MyComponent'
  }
})

Additional information

[X] Would you be willing to help implement this feature?
[ ] Could this feature be implemented as a module?

Final checks

[X] Read the contribution guide.
[X] Check existing discussions and issues.

Learned existence of prepare:types hook and reference. This enhancement would probably be unnecessary.


Accessor Function in columnHelper.group() fails to infer properly

Describe the bug
If you use createColumnHelper<RowType>() to make a column helper, then make a group, then make accessor columns inside of that group; then the types of the TValue generic for each column ends up as any unless you explicitly type it. See the sandbox.
Your minimal, reproducible example
https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true&allowUnreachableCode=true&allowUnusedLabels=true&noUnusedLocals=true&noUnusedParameters=true&exactOptionalPropertyTypes=true&noFallthroughCasesInSwitch=true&noImplicitOverride=true&noPropertyAccessFromIndexSignature=true&useUnknownInCatchVariables=true&suppressImplicitAnyIndexErrors=true&allowSyntheticDefaultImports=true#code/JYWwDg9gTgLgBAbzgYygUwIYzQYQgGwFcQA7ACTXzDSjgF84AzKCEOAcgAEYMSBnHsgDWAenQZkMALQ8ARvjTsA3AChQkWIgCSfAIIkAng2as4AIhgHqUxmgFnVKy9TgA1DPmAATLMAgkAFQx5NAAlCAB3OABeRBU4OAEoYBIAcwBpNAMALkSYZLSVOkdkfwEUAmJySmpaWNRMbDwiUgoqGgAed08fGD9A4IVwiIA+AAoAShLK1pqaADpUlkIwMYRvXLMliBWAETRkfAx0Ly0STxI0MwAaCpb+XIBtUvu22vmJZDs+aDGWKOiIzg-3mSRSGSytwQ8QScA25gwfC8jBuMISX3w+DWqTQMG6hDQdAmcVhpIq-HgADcPASYnAcXiaWhJmiySIRHAYAALYB8OF8kgQekQCBeVmk0oUuAAD1yOn0Bg6zjQEEYcGpRDQQNijA8fDQ4thkp+Cnm+AgqTW0qJhoS6BghCgJHVTNUpLoRQmAF0bSpjfAXlU+PtDsc0F4APKEGB8bxoADiyzAdOeM2q7SgH2QXz4Pygf0iMSBILBaUyBihrPhZkRyNREsoWIQDPxhOJ0LJRrKVKZdJbTJZnYS7M5PL5vKYKTQcDQlLjJBg+AMtvJ5VlcHlhiVVhVao1BO1TD1BqHq4IaDNFqtNtP9sdzv3aDdsI9RK9frK58vlsDpGDByOE4oxjONEx2MAJiAA
Steps to reproduce
As described
Expected behavior
Inference still works as it does when you don't declare columns in a group
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform
irrelevant, but macOS
react-table version
8.9.8
TypeScript version
5.2.2
Additional context
You can work around it by making the columns in an array, then assigning the array to the group instead. see the playground link.
Terms & Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

This happens on v8.10 as well when destructuring from getHeaderGroups and goes away when you loosen the strictness of your tsconfig by disabling the noUncheckedIndexedAccess flag.


Banning applies immediately across servers with a shared DB, unbanning does not

Presumably, the plugin checks the actual database for logins, so a DB update on banning propagates (although I'm not sure if it is instant or not, actually). But when I unban somebody, it does not propagate and they are still blocked from logging onto a different shard. I have to go teleport aruond and unban them from every shard.
It is possible that if I only did it in one place, it would figure it out over the course of a day or something, but I can't rely on that, because I don't know if they'll log in somewhere while I'm waiting for updates to spread.
I would suggest that manually typed out bans and forgives by admins should both probably immediately update the database. It seems unnecessary to cache updates for something that only admins can type and that they only type once every few hours or days.
Unless I just got lucky, and logins are only using the cache, in which case dunno what to suggest

The present issue is that the results of the commands are shard/server local; the other shards all have bans in memory for fast application, and they don't realize their cache is out of date.
So, somehow need to alert all co-users of the DB that they need to refresh their state. Thanks for this issue, will consider best approach!


Support out of order message processing and committing

Most of how arroyo is designed quietly requires messages to be processed and committed in the same order they are received. The only exception is the parallel transform that transforms messages potentially out of order, but then re-orders them before sending them to the next step, thus the problem does not apply.
There was a potential use case in replays recently, I suspect we will encounter more as we expand to more use cases that need throughput but do not have strong consistency guarantees.
In that scenario most messages would be quick to process, while some took orders of magnitude longer. In a scenario like this, we would write a consumer such that it would have two independent queues inside to process the messages at different pace. One way to build this is to have a router and two separate consumer for the separate classes of traffic but at times the giht queue is not known upfront.
In scenarios like the one above, messages would reach the last step in the pipeline out of order. Which means that we cannot just trust the committable property as the high watermark of what to commit. We would need to keep track of all the offsets we saw and only commit an offset when all the previous offsets have been processed.
The first question to support this is: should we? Out of order processing can be very useful for throughput though the question is whether the consumer owner should take care of understanding that and reordering the offsets before committing. It seems to me this would go slightly against the idea of making commit easy and as transparent as possible.
The second question, if we say yes to the first, is how to reorder the offsets behind the scenes before committing. One way would be to record all the offsets we see and mark them as "committable" when the application code asks to commit. Though we would only commit the highest watermark.

I think this idea of separate pipelines for different types of messages is a valid use case, but my feeling is that it is quite an exotic one.
Firstly I think we should rule out the idea of a processing step needing to see every offset. Especially one that might appear at the end of a pipeline. I think this would go against arroyo's design where strategies only process individual messages and know nothing about what happened beforehand and other context around it. This would be fragile and present problems in many scenarios such as:

What happens if a filter step or some batching happened beforehand. All strategies are supposed to work with all others. If a specific sequence of strategies breaks it's a problem
What happens on startup. A strategy doesn't know the offset where the consumer picked up from. As far as a strategy later in the pipeline is concerned there is no difference between an offset that is stuck in some earlier processing step and an offset that will never ever arrive because the consumer had already consumed committed it long time ago

Now, I do think there is another way to maintain a watermark across multiple pipelines that you may have been hinting at in your description. If we have two alternative processing pipelines I can imagine something along the lines of:
synchronize_step = SynchronizeOffsets(inputs=["a", "b"], CommitOffsets(commit_func))

# A message goes through either ProcessA or ProcessB and always end up at synchronize
strategy = Router(router_function, [ProcessA(synchronize_step), ProcessB(synchronize_step)])

# ProcessA and ProcessB would internally call the synchronize step with their identifier, e.g.
next_step.submit(("a", payload))

The key to this is that although messages received by SynchronizeOffsets are not ordered, the messages which came from each input source are still ordered and SynchronizeOffsets would know the minimum offset that had been reached from each of the inputs and was thus safe to commit.
But there are still some gotchas:

This only works if there is a reasonable amount of data on all partitions flowing through both of the parallel pipelines. The moment that one path isn't used as much everything gets stuck there and our watermark can't advance
Batch payloads are not guaranteed to have a valid total order. It is conceivable that a batch in one pipeline contains offsets that are ahead on one partition and behind on another compared to a batch in the other pipeline. Which one comes first? There is no right answer in that case. Same with empty messages or those with no offsets to commit. For some use cases this might be able to be resolved by having the synchronizer rewrite the committable offsets in line with the watermarks it saw, but the right decision here depends a lot on the use case

My personal opinion is that while this might be a valid use case something like this is for experts only and is not advisable for most people since there are many things to be wary of and it makes your consumer significantly more complex. We didn't really have any real use cases for it yet - though it was floated for replays there are probably a lot more low hanging fruits than can be done first there before resorting to something like this.
This kind of strategy is already possible today with Arroyo, though it will have to be hand rolled. I think we don't need to do more to make this "easy" as I think it can be quite dangerous.

Closing since I don't think we should do this. @fpacifici Welcome to reopen if you want to kick off the discussion again.


How can I wait for a future in multiple threads

I can't seem to make this work, perhaps I'm being dumb! In any case, I think this should be in the documentation as an example.
In my case, I have background processes loading data for a given ID. Obviously if a piece of data is already being loaded then I want to join the existing waiters rather than starting a new background process.
I've implemented this using a Map <Id, Vec <Complete>>>, then the first loader triggers the completion of subsequent loaders when it has completed. This is a lot of boilerplate.
I've tried all sorts of things to get this to work but somehow I can't get anything else to compile. Waiting for a future consumes it, so I can only do that once. I have tried to replace the future with a new one and wait on that, like I might do in JavaScript, but this also doesn't work.
If anyone can show me an example then that would be great, if not then I'll probably create an abstraction around my current method and submit this as a pull request for the library.

Strictly speaking the issue as titled is not possible. To poll a future it requires &mut self which means synchronized. In other words, only one thread can call Future::poll at a time.
What you may want to do is to create your own custom implementation of Future for this. You'd have to keep track of all tasks waiting for a value to get produced, and then wake them all up once the value is ready. You'd then also have the logic for the future being immediately ready if the value is already there.
Does that make sense?

Yes, as I explained I've done something like this in my code already and it is working.
The question, I guess, is if you would be interested in this being submitted as a pull request for inclusion in the futures library itself, or if I should just go ahead and implement it separately.

Perhaps! Mind if I take a peek at what you've got going on?

Well it's kind of mixed up in the other code, but it's in this file:
https://github.com/wellbehavedsoftware/wbs-backup/blob/6428167c0bfe42144b8d0d42f6e94b597daa33d7/rzbackup/src/zbackup/repo.rs
Here's where I keep a map of "additional" clients waiting for a future to complete, presumably the map key would stay the same but the value would be a struct mapping the desired behaviour:
https://github.com/wellbehavedsoftware/wbs-backup/blob/6428167c0bfe42144b8d0d42f6e94b597daa33d7/rzbackup/src/zbackup/repo.rs#L74
Then in this function, I either create a direct future to produce a result, or I add a new oneshot to the list above. The first one will fire off all the others on completion:
https://github.com/wellbehavedsoftware/wbs-backup/blob/6428167c0bfe42144b8d0d42f6e94b597daa33d7/rzbackup/src/zbackup/repo.rs#L953
The idea is to refactor out this logic into some kind of reusable future. Presumably it could be constructed by consuming an existing future into some kind of other object, which could then hand out regular futures to be used and consumed by waiting as normal.
Here's a simple example of how you might use it for lazy loading:
let lazy_loader_future =
    create_lazy_loader ();

let lazy_loader_multiplexer =
    futures::multiplexer (lazy_loader_future);

// ...

for key in items {

    init_some_module (
        lazy_loader_multiplexer.spawn_future ());

}

That actually sounds pretty reasonable to me, this looks to be like some form of memoization going on I think? Perhaps something along the lines of:
pub fn cell<T, E>() -> (Cell<T, E>, Complete<T, E>) {
    // ...
}

impl Future for Cell<T, E> {
    type Item = CellComplete<T, E>;
    type Error = Canceled;

    // ...
}

impl<T, E> Clone for Cell<T, E> {
    // ...
}

impl<T, E> Deref for CellComplete<T, E> {
    type Target = Result<T, E>;
    // ...
}

That is, you'd have a oneshot-like interface. One Complete could be used to complete the computation, and otherwise Cell handles (modulo naming) can be used to resolve to a completed value which then implements Deref to the target (abstracting away the backing storage)

Ok, so in your example the Future itself implements Clone, and does the same kind of logic internally. That would work for me as well, although I would still like to be able to produce one of these by consuming a Future. I don't see any reason why both couldn't be supported.
To be honest, I feel like there should be more API support for directly plumbing together Futures and Completes, which would perhaps make this moot, although perhaps it's there and I've missed it. Probably a separate discussion...

I think a more general solution should be written, that will make it easier to wait for a task completion on multiple threads.
What do you think? @alexcrichton

@jamespharaoh I'm not sure I quite understand what you mean by plumbing together futures and completes? In theory that's exactly what oneshot is, but do you perhaps have something else in mind?
@liran-ringel perhaps yeah! Just trying to figure out what that more general solution is :)

(oops didn't mean to close)

@alexcrichton A solution might look like that:
let shared_future = SharedFuture::new(my_future);
let mut f1 = shared_future.future();
let mut f2 = shared_future.future();

@liran-ringel yeah that's actually basically what I was proposing above as well!

I'll put something together for everyone to check out. I have a feeling I can actually go one better than we've discussed but let's see what the borrow checker has to say about that before I promise anything ;-)
@alexcrichton I mean that I feel like Future and Complete are a bit like a producer and a consumer and that they should be able to be plugged together in a simple way and "forgotten" about by the developer. I probably need to come up with some examples, but I'll look at that later. I also may be missing something obvious, and from the work I've done with this library already I know that there are certain things that need to be done to keep the borrow checker happy and ensure that things actually get run.

@jamespharaoh ok! Looking forward to seeing what you come up with

@alexcrichton  I've done something, but I don't have permission to push a new branch.
Do I need to fork this repo?

There's more work to be done, but I'd like you @alexcrichton to check if it's the right direction:
https://github.com/alexcrichton/futures-rs/compare/master...liran-ringel:feature/multishot

@liran-ringel
Sorry for the delay, but I've now taken a look! I think that's along the right lines semantically but we'll likely want enable us to add a more efficient implementation eventually as well. I wonder if we could perhaps have an interface like:
trait Future {
    // ...

    fn shared(self) -> Shared<Self> {
        // ...
    }
}

struct Shared<F> {
    // ...
}

impl<F> Clone for Shared<F> {
    // ...
}

impl<F> Future for F {
    type Item = SharedItem<F::Item>;
    type Error = SharedError<F::Error>;
    // ...
}

struct SharedItem<T> { /* ... */ }
struct SharedError<T> { /* ... */ }

impl<T> Deref for SharedItem<T> {
    type Target = T;
    // ...
}

impl<T> Deref for SharedError<T> {
    type Target = T;
    // ...
}

That is, we could hide the abstraction of an Arc and also leverage Clone for "create a new reference"

@alexcrichton Before I came with the previous solution I tried to do something similar to the Shared future, but I had issues with synchronization, which would complicate it a lot.
To simplify that, I created a future Multishot that can create oneshots, and will trigger them when the original future is ready. The job of the Multishot future is actually to trigger the other oneshots, so no extra locks are needed.
The downside is that it's less flexible since all of the oneshots can only be created from the same Multishot.
I can try again to implement the Shared-like interface, but first, what did you mean by "a more efficient implementation"?
If you talk about performance, what should I avoid for the next time?

Yes depending on the interface you might have problems with synchronization or not. Right now though the memory requirement is O(number of clones) which seems unfortunate when it should in theory be O(1)?

I've also had a play with this but got a little confused trying to implement my own future. I'm still quite new to Rust and so am still getting used to some of the more complex things.
The "clever" thing I am still hoping to do, however, is to provide some way to simply clone a future, and have it work as expected. I now believe it should be possible to implement Clone for &mut BoxFuture, but would like some feedback before I play around with this.
Firstly, does anyone with more knowledge than me think this is possible? Secondly, do people think this is desirable?
Underneath, the implementation would replace the boxed future with a CloneableFuture, which either uses multishot underneath, or some manual bookkeeping. I think we'd need to add a method to the Future trait, which would consume the Future and returns CloneableFuture. The default implementation would instantiate the CloneableFuture, and the overriden implementation for CloneableFuture would simply return itself.
Of course, the CloneableFuture has other uses of its own, but it's nice of course to try and implement things which hide the details if possible, and having &mut BoxFuture be cloneable sounds very useful and intuitive to me.

I don't think we'll be able to clone arbitrary futures, but cloning a particular future seems reasonable to me. That is, creating a custom future wrapper that's cloneable sounds like it can work.
Other than that sounds reasonable!

Yeah well that was what the &mut was about, but I'm not sure at all it's even possible, for various reasons. To be honest, anyone who needs this feature can simply call a trait method such as cloneable(), probably followed by a call to boxed(), based on my experience with this library so far. I think the box will automatically be Clone based on built in generic trait implementations for a boxed, cloneable future, although again I'm still working out how these things work in rust.
Possibly we could provide transparent cloneability for boxed futures inside some kinds of wrappers, but again, it's just plumbing and not really necessary.
I will have another crack at this when I get a chance. Got a bit confused with the library when I tried it before. I am guessing the complexity is related to the "zero-cost" design goal you discuss in your blog post about the library.

Ok, let's see how far implementing the cloneable function takes us! If you need any help just let me know, and looking at some other combinators may provide insights of implementation methodologies.

@alexcrichton What do you say about that?
https://github.com/alexcrichton/futures-rs/compare/master...liran-ringel:feature/shared

I didn't dig too much into the implementation details but at a conceptual level at least looks reasonable to me!

I'm happy this has reached public release, and it has simplified my code a lot. I'm a bit embarrassed I didn't contribute anything concrete, but having used it, I have a suggestion for a further refinement.
You can see my code here:
https://github.com/wellbehavedsoftware/rzbackup/blob/master/src/misc/cloning_shared_future.rs
Basically this transforms a Shared into a CloneableSharedFuture by called .cloneable (). I realise this would need some modification to confirm to the naming and formatting styles of this project, but I think this is going to be a /very/ common use case, and that the general idea is sound.
Probably you could add a .shared_cloneable () function to the Future trait to return something like this, then, so long as your items and errors are cloneable (and you're going to have a rough time if they're not in a multi-threaded environment), then you can use them like normal futures, without any need for references.
Let me know what you think and I can do a pull request into futures-rs...

In fact, I wonder if Clone couldn't be implemented for Future in general if both the Item and Error types are Clone....

@jamespharaoh I think A .cloning() method on Shared<F> where F::Item: Clone, F::Error:Clone would make a lot of sense.

Makes sense to me too!
Coming back to this issue I'm actually going to close this now that we have Shared as this issue itself is solved.


Remove runtime dependency on kotlin-reflect to reduce jar size

Description
As far as I understand, this library mainly uses compile time reflection to generate bindings, but there is currently a runtime dependency on kotlin-reflect as can seen from the dependency report:
...
|    +--- app.cash.sqldelight:postgresql-dialect:2.0.2
|    |    +--- org.postgresql:postgresql:42.7.3
|    |    |    \--- org.checkerframework:checker-qual:3.42.0
|    |    +--- app.cash.sqldelight:dialect-api:2.0.2
|    |    |    +--- com.alecstrong.sql.psi:core:0.4.9
|    |    |    |    \--- org.jetbrains.kotlin:kotlin-stdlib:1.9.23 -> 2.0.21 (*)
|    |    |    +--- com.squareup:kotlinpoet:1.16.0
|    |    |    |    \--- com.squareup:kotlinpoet-jvm:1.16.0
|    |    |    |         +--- org.jetbrains.kotlin:kotlin-stdlib:1.9.22 -> 2.0.21 (*)
|    |    |    |         \--- org.jetbrains.kotlin:kotlin-reflect:1.9.22
|    |    |    |              \--- org.jetbrains.kotlin:kotlin-stdlib:1.9.22 -> 2.0.21 (*)
...

As we are using this library in serverless lambdas, we are sensitive to binary size bloat, so I was wondering if there would be a way to separate the compile-time and run-time dependency on reflection (which increases our binary size by 20%). I don't have a good grasp on the internals of your library, so please correct me if I am wrong.
Thank you for this library, it's been a pleasure to work with it so far!

I just remembered I could manually exclude the dependency in gradle:
    implementation(libs.sqldelight.postgres.dialect) {
        exclude(group = "org.jetbrains.kotlin", module = "kotlin-reflect")
    }

and it seems to continue to work with my limited testing so far, binary size is back down. Still, it would perhaps benefit other users to have this excluded upstream.

The dialects are what is used by the compiler to generate code for that specific database. It should not be on your classpath at runtime.
The driver is what is used at runtime, and it does not have this dependency.

I see, I misread the documentation and added the dialect as an implementation dependency. It's fixed now, thanks for clarifying.


⚠ Bofrost.be has degraded performance

In e5071eb, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1764 ms

Resolved: Bofrost.be performance has improved in fd95648.


Refactor root execution

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 63.18%. Comparing base (eea68ce) to head (803299e).

Files
Patch %
Lines

cmd/main.go
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #40   +/-   ##
=======================================
  Coverage   63.18%   63.18%
=======================================
  Files          16       16
  Lines        1323     1323
=======================================
  Hits          836      836
  Misses        422      422
  Partials       65       65

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


review and test command line arguments

CLI args don't seem to always work

no specific info here, closing.


[Suggestion] Make End woods and plants fiammable by lava and fire

I use Fabric v.1.11.1 on MC 1.16.5 and API v.0.30.3, and mod version is v.0.9.1-pre-1.16.4/5
Realized this after trying to burn away the leaves from the Helix Trees in order to get rid of them quickly, which didn't work. Tested on almost all plants, and none of them burns away, while some of them catching fire for a short time (Helix leaves catch fire, while Lacugrove leaves do not at all, for example). This might be intended but i don't know if these plants in the End should be immune to fire and lava, even if there is no lava in The End (i don't know about the "lore").
When it comes to trees: in order to avoid weird things, the "leafy" trees could burn away after catching fire, like ordinary overworld wood/leaf types. This means that elements from "shroomy" trees like Mossy Glowshroom, Umbrella Tree and Small Jellyshroom shouldn't burn away, but they could catch fire anyway like the vanilla mushroom blocks, unless one doesn't want to make wood builds near lava with these mushroom wood types in order to avoid annoyances.

Between making these elements vulnerable to fire and lava, and making them immune, i would go with the first option, but the choice isn't mine here, it's just an enhancment suggesion.

Added in 0.9.2


how to use face API ?

I tried code below
from face_process.face_api import FaceAPI
face_api = FaceAPI()
import cv2
img = cv2.imread('C:\Users\sathi\Downloads\benchmark_images\frame279.jpg',0)
face_api.track_faces(img)
ValueError: not enough values to unpack (expected 3, got 2)

Please use cv2.imread('C:\Users\sathi\Downloads\benchmark_images\frame279.jpg') without the second parameter. The second parameter "0" indicate loading image in gray scale

i tried same error throw please sample code sent me
On Tue, Jun 12, 2018 at 7:21 AM, martinambition<EMAIL_ADDRESS>wrote:

Please use cv2.imread('C:\Users\sathi\Downloads\benchmark_images\frame279.jpg')
without the second parameter. The second parameter "0" indicate loading
image in gray scale
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/martinambition/FaceRecognitionAPI/issues/3#issuecomment-396440044,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AR3U-MOkAy0qDfgS0S0IWiGNhdI_mTjnks5t7x6QgaJpZM4Uikx6
.


Pulling challenge data from Google Sheets

Uses https://cdnjs.com/libraries/marked to parse latest challenges from Google Sheets so we don't have to edit the challenges manually every week on the Testnet page
Data is being pulled from https://docs.google.com/spreadsheets/d/1CLX9DF7oFDWb1UiimQXgh_J6jO4fVLJEcEnPVAOfq24/edit#gid=639239905, where challenges can be added each week with name and description

Screenshot attached to show styling

You might notice that the ci/circleci: build-wallet test is failing.
This is because we didn't reformat the code.  You can run yarn reformat in the website folder to do this. I sometimes like to set up my editor to reformat on save to avoid this problem.


Usage with Dataloaders?

Is there any way I can make this work with dataloaders i.e. the one that comes default with graphql java or node dataloader js libs?

Hi @Togrias,
You can put in resolver function anything that returns instance of declared object, so based on this example from java-dataloader it would look like:
        query("user") {
            resolver{ id: Long ->
                userLoader.load(id).dispatchAndJoin()
            }
        }

of course you have to initialize loader first, as shown in example.


Not able to install Defcetdojo on Ubuntu 20.04

We are trying to install latest version of Defect Dojo with Godojo installer on on ubuntu 20.04  but we are getting this error - ERROR: 2023/02/08 20:04:53 - Failed to run OS command /opt/dojo/bin/pip3 install -r /opt/dojo/django-DefectDojo/requirements.txt, error was: exit status 1
Checking connectivity to PostgreSQL
Validating DB connection settings
Note: pg_hba.conf has not been altered by godojo.
It may need to be updated to allow DefectDojo to connect to the DB.
Please consult the PostgreSQL documentation for further information.
==============================================================================
Preparing the OS for DefectDojo installation
Preparing the OS for DefectDojo...(--*-------)
##############################################################################
ERROR: 2023/01/31 14:59:35 - Failed to run OS command /opt/dojo/bin/pip3 install -r /opt/dojo/django-DefectDojo/requirements.txt, error was: exit status 1
##############################################################################
Can someone please let us know how we can resolve this issue?

Moving issue to godojo repo


python310Packages.azure-mgmt-containerservice: 21.1.0 -> 21.2.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.azure-mgmt-containerservice is: This is the Microsoft Azure Container Service Management Client Library
meta.homepage for python310Packages.azure-mgmt-containerservice is: https://github.com/Azure/azure-sdk-for-python
meta.changelog for python310Packages.azure-mgmt-containerservice is: https://github.com/Azure/azure-sdk-for-python/blob/azure-mgmt-containerservice_21.2.0/sdk/containerservice/azure-mgmt-containerservice/CHANGELOG.md
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 21.2.0 with grep in /nix/store/pfz4v3n4m2qf691vgxjj1w7jnszcq6sl-python3.10-azure-mgmt-containerservice-21.2.0
found 21.2.0 in filename of file in /nix/store/pfz4v3n4m2qf691vgxjj1w7jnszcq6sl-python3.10-azure-mgmt-containerservice-21.2.0

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
azure-cli
python310Packages.azure-mgmt-containerservice
python311Packages.azure-mgmt-containerservice

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/pfz4v3n4m2qf691vgxjj1w7jnszcq6sl-python3.10-azure-mgmt-containerservice-21.2.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.azure-mgmt-containerservice https://github.com/r-ryantm/nixpkgs/archive/8c693ec9acedb2983168be2e5e3e9b8e2a621ca7.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/pfz4v3n4m2qf691vgxjj1w7jnszcq6sl-python3.10-azure-mgmt-containerservice-21.2.0
ls -la /nix/store/pfz4v3n4m2qf691vgxjj1w7jnszcq6sl-python3.10-azure-mgmt-containerservice-21.2.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

3 packages built:

azure-cli
python310Packages.azure-mgmt-containerservice
python311Packages.azure-mgmt-containerservice

Maintainer pings
cc @mwilsoncoding for testing.

@ofborg build azure-cli


Tnir changes

Codecov Report

Merging #209 into dev will increase coverage by 0.03%.
The diff coverage is 65.71%.

@@             Coverage Diff              @@
##                dev     #209      +/-   ##
============================================
+ Coverage     32.82%   32.85%   +0.03%
- Complexity     1436     1439       +3
============================================
  Files            97       97
  Lines         23383    23406      +23
  Branches       3889     3893       +4
============================================
+ Hits           7675     7690      +15
- Misses        14163    14166       +3
- Partials       1545     1550       +5

Flag
Coverage Δ
Complexity Δ

#JDBC41
32.72% <65.71%> (+0.07%)
1431 <2> (+5)
:arrow_up:

#JDBC42
32.79% <65.71%> (+0.05%)
1438 <2> (+4)
:arrow_up:

Impacted Files
Coverage Δ
Complexity Δ

...in/java/com/microsoft/sqlserver/jdbc/IOBuffer.java
36.02% <33.33%> (-0.33%)
0 <0> (ø)

.../microsoft/sqlserver/jdbc/SQLServerConnection.java
40.7% <68.75%> (+0.6%)
207 <2> (+3)
:arrow_up:

src/main/java/microsoft/sql/DateTimeOffset.java
37.14% <0%> (-2.86%)
8% <0%> (-2%)

...m/microsoft/sqlserver/jdbc/SQLServerResultSet.java
23.92% <0%> (+0.04%)
171% <0%> (+1%)
:arrow_up:

...om/microsoft/sqlserver/jdbc/SQLServerBulkCopy.java
44.94% <0%> (+0.14%)
182% <0%> (+1%)
:arrow_up:

Continue to review full report at Codecov.

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

@saurabh500 Hello Saurabh, I have separated TNIR timeslice from MSF timeslice and formatted the code.
For the DNS resolution, do you think I need to roll back to previous implementation to do DNS resolution with each connection re-try? Thank you.

@v-xiangs

For the DNS resolution, do you think I need to roll back to previous implementation to do DNS resolution with each connection re-try?

I have been talking to the folks from the server side. It turns out that time-slicing is needed in case of Single DNS IP address as well.
This is because a DB availability group can have a cluster in a single subnet. When a failover occurs, the Windows Fail over clustering moves the IP address of the old primary to the new primary replica. However only a single IP address is available. I need to research more in this area.
I think we should take out the DNS logic from the changes completely and as you suggested, continue with the DNS resolution with each connection re-try.
What do you think?
I am reviewing the rest of the code.

@saurabh500 Thank you for your quick response.
Please let me confirm the solution with you. I just want to make sure I will do the right thing.

Turn Tnir off for Fed Auth
Change the TNIR multiplier to 0.125 instead of 0.08
Change the time slices to a multiple of 2,4,8 instead of 2,3,4
In case the timeout for the first slice is less than 500 ms then bump it up to 500 ms
Keep TNIR on if the user has explicitly specified it in the connection string.

A small correction
Change the time slices to a multiple of 2,4,8 instead of 2,3,4 In case the timeout for the first slice is less than 500 ms then bump it up to 500 ms
Change the time slices to a multiple of 1,2,4,8 instead of 1,2,3,4
Explanation: For the first attempt we should connect to the first IP addressed as is the behavior right now, however the timeout should be = 1st timeslice and if the 1st timeslice is < 500 ms, bump it to 500 ms. As a result we increase the timeout for the first slice. From the 2nd timeslice, we do parallel open, the way it is right now.

Hi @saurabh500 , I guess you might miss this from my previous comment. That's the reason why I make it start at 2. I definitely can change the behaviour to a multiple of 1,2,4,8 as you mentioned.

Yes, I did miss out the comment.
I hadn't realized that the MSF steps were 2,3,4 for time slice calculation in JDBC.
Let's stick to your proposal of 2,4,8.
Without the TNIR redesign, the number of timeslices allocated would be really 4 for a timeout of 30 sec

With the change the number of slices will reduce by 1.

You are right, we dont want to reduce the minimum time slice multiplier to 1, if a stable JDBC version has shipped with a Timeslice of 2 for the first try.

@saurabh500 thank you for confirming this with me. I really appreciate all your thoughtful suggestions and code reviews. I feel this PR is too messy for me to roll back some logics, so I created a new PR #240 . Therefore, I am going to close this PR. I hope you won't mind if I add you as Reviewer on the new PR #240 .

Sounds Good.


Tesseract 4.x using Tess4j java wrapper leaking handles while disposing TessBaseAPIDelete

Hi Team,
I am using Tess4j 4.3.1 which internally uses Tesseract 4.0 to do the OCR. But I started seeing the handles are leaking while disposing the API. This is not happening with Tess4j 3.5.3 which uses Tesseract 3.X.
Is there a known issue?
Tesseract.class
/**
* Releases all of the native resources used by this instance.
*/
protected void dispose() {
if (api != null && handle != null) {
api.TessBaseAPIDelete(handle);  --> Leaking the handles
}
}

Please respect guidelines for posting issue: we do not provide support for 3rd party projects (e.g. tesseract wrappers).
Reproduce your problem with resent version of and with C/C++ code.  Tesseract 4.0 is too old.

Please respect guidelines for posting issue: we do not provide support for 3rd party projects (e.g. tesseract wrappers).
Reproduce your problem with resent version of and with C/C++ code.  Tesseract 4.0 is too old.


Define a rustfmt file

Since adding a rustfmt file would likely cause many merge-conflicts for all open-branches, I've decided to just open an issue for it and also see what fields you feel are important to set and to what values.

Added


Improve desktop mode for dApp browser

[x] Add support save change desktop mode
[x] Update DApp config to set default desktop mode on some DApp

Version test: https://file.cdmteck.com/s/DB9JLAnjJczopcC/download?path=%2F&files=SubWalletMobile-build-302-1397-merge-2024-01-24T05-11-55.apk
Device test: S20 FE 5G

[ ] Update icon for dApp support Desktop mode

Version test: v1.1.29(308)
Device test: IP 11
Validation passed.


The shuffle of the vertices

Hi, thank you for your work.
I noticed that you remove the shuffle of the vertices of the identity and pose meshes which added in NPT. Have you tried to add the shuffle in your work?

Since there is a shuffle procedure, all the vertices will be randomly allocated with an extra function. Besides, to calculate the edge loss, the faces of the vertices will also be re-arranged. This will make the mesh loading slower.
Sure! Sorry I was busy with CVPR submission nowadays. I will prepare a pretrained model that can run on the demo soon.


[DOCUMENTATION]

This form is ONLY for reporting issues with https://datasheets.raspberrypi.com/camera/picamera2-manual-draft.pdf
Please only report one documentation bug per issue!
Describe the problem
Page 16 Section <IP_ADDRESS>
Code snippet describing lores preview has typo in the import line.
Suggested Improvement
Replace:-
from picamera import Picamera2
with:-
from picamera2 import Picamera2

Thanks, I've fixed this now and it will be in the next documentation release!


Incompatible with IDEA 2020.01

The plugin incompatible with IDEA 2020.01.

Working on a PR for this.

https://github.com/chathurabuddi/intellij-jasper-report-support/pull/16

Hi @ronhks , @slestak ,
Please note that the pull request #16 was merged and released with v1.0.2.
Refer #17 for more details.

@chathurabuddi thanks!


Inner constructors should fill in type parameters

You should be able to remove the @concrete macro and still have valid code. Right now this isn’t the case if you have an inner constructor. Here the user needs to fill in types of fields they never specified like the following with typeof(c):
@concrete struct MyType{T,N,A<:AbstractArray{T,N}} <: AbstractArray{T,N}
    a::A
    b::T
    c
    function MyType(a::AbstractArray{T,N}, b::B, c) where {T,N,B}
        Tnew = promote_type(T, B)
        a, b = Tnew.(a), Tnew(b)
        return new{Tnew,N,typeof(a),typeof(c)}(a, b, c)
    end
end

The @concrete macro should make a valid inner constructor without this parameter specified.

I'm not sure this will be easy to do with inner constructors. I'm not even sure its a good idea anymore. But d060a20 makes an inner constructor that works as if the struct were not decorated with @concrete. I think I'm going to close this.


Setup kubeconfig without running kubectl under local exec

I have issues
I'm submitting a...

[ ] bug report
[x] feature request
[ ] support request
[ ] kudos, thank you, warm fuzzy

What is the current behavior?
Adding an additional role to the EKS cluster requires kubectl in local exec. We would like this to work natively in Terraform.
If this is a bug, how to reproduce? Please include a code sample if relevant.
What's the expected behavior?
Terraform supports making kubeconfig change natively and it would be great to support that in this module. Detailed here:
<EMAIL_ADDRESS>Are you able to fix this problem and submit a PR? Link here if you have already.
https://github.com/sumitag/terraform-aws-eks/pull/new/v4.0.2_native_Terraform
I don't think this keeps all the functionality working
Environment details

Affected module version: v4.0.2
OS:
Terraform version: 0.11

Any other relevant info

Duplicate of https://github.com/terraform-aws-modules/terraform-aws-eks/issues/353


Add toggle to show all players in medal overview table

Would this be ok? Would love to be able to see everyone in this table :-)

Hmm, having a tie breaker makes perfect sense.
Not sure about showing all the people by default. There's one pro (seeing everyone!) but several cons:

On some boards not everyone participates each year (e.g. my company's private leaderboard), and those people will clutter the table
On boards with 50+ish people, it will take up a lot of real estate
A podium is in essence about getting medals at all

Also, #39 might give something that you are after with all people in a table?
I'll be happy to merge your PR later either way, but I might tweak the specifics if that makes sense?

Ah just updated again showing the default behavior by default and adding a toggle all button. #39 does look really good, so maybe this is unnecessary. I trust your judgement!

Taking some time to do some updates this year, found your PR again @leyanlo so thanks once more! Looks really nice indeed, can see the value in this.
I'll append a few commits locally before merging to:

move the button to toggle this from the "plugin generic buttons" towards the actual graph itself
remove the local-score-sorting in the podium table (for local score sorting the other graphs are meant, I want the medal overview to always be sorted on medals (first))

Your feature should be coming to the browser somewhere this week!

Yay thanks!


Small accessibility fixes

:wave:
Here a few suggestions to improve usage with screen readers and keyboard-only navigation. Everything is split in small commits with detailed explanations.
Since I stumbled upon a file needing a prettier fix I also included a tiny file to help with prettier-only commits (we track those in a .git-blame-ignore-revs file to hide them from git blames).
pouet @lebaudantoine

One thing I realize I forgot is I wanted to harmonize how we pass aria-labels in our components. Sometimes it's via title, sometimes via ariaLabel… I'd argue we should just have props named aria-label everywhere as it's the default one used by html in React and it's more explicit like that.

Hey @lebaudantoine, made a few changes after your input, let me know if you any other, I'll rework commits and merge then.


Add definite assignment analysis for local variables

It would be useful for analyzer to be able to perform a definite assignment analysis on local variables.

I imagine this can be closed? We support definite assignment as specified by the Non Null spec.


Pit run invalid memory address or nil pointer derefence

Details
Bot crashed and stopped during a pit run, cause seems to be the IsFinished function in file action.go
Version
dev
Logs
time=10:53:53 level=ERROR msg="fatal error detected, forcing shutdown" supervisor=sorc error="runtime error: invalid memory address or nil pointer dereference" stacktrace="goroutine 296 [running]:\nruntime/debug.Stack()\n\truntime/debug/stack.go:24 +0x5e\ngithub.com/hectorgimenez/koolo/internal.(*SupervisorManager).Start.func2.1()\n\tgithub.com/hectorgimenez/koolo/internal/manager.go:76 +0x108\npanic({0x11377c0?, 0x1888a80?})\n\truntime/panic.go:770 +0x132\ngithub.com/hectorgimenez/koolo/internal/action.(*StepChainAction).IsFinished(0xc0010ee400?)\n\t:1 +0x9\ngithub.com/hectorgimenez/koolo/internal.(*Bot).Run(0xc0010ee400, {0x1415480, 0xc0012220f0}, 0x1, {0xc001158200, 0x5, 0x0?})\n\tgithub.com/hectorgimenez/koolo/internal/bot.go:161 +0x1065\ngithub.com/hectorgimenez/koolo/internal.(*SinglePlayerSupervisor).Start(0xc00009a350)\n\tgithub.com/hectorgimenez/koolo/internal/single_supervisor.go:70 +0x485\ngithub.com/hectorgimenez/koolo/internal.(*SupervisorManager).Start.func2()\n\tgithub.com/hectorgimenez/koolo/internal/manager.go:82 +0xa2\ncreated by github.com/hectorgimenez/koolo/internal.(*SupervisorManager).Start in goroutine 12\n\tgithub.com/hectorgimenez/koolo/internal/manager.go:69 +0x21d\n"

The fix seems to be changing the IsFinished function in action.go to :
func (b *basicAction) IsFinished() bool {
if b == nil {
return true
}
return b.isFinished
}

It seems this error was happening because I was too lazy to also copy the "tools" folder. The problem seems to be fixed. Ignore this issue.