feat: Enable rustflags = "-C force-frame-pointers=yes" default for opendal release process

For now, if we want to use the perf or any performance analysis tool to analysis the performance of the opendal process. We will be in trouble because of the symbol issue
For example, I try to use perf to analysis the following code
import opendal
import uuid

op = opendal.Operator("fs", root="/tmp")

uuid_str=str(uuid.uuid4)

for _ in range(10000000):
    op.write(f"/{uuid_str}", [0]*64*1024*1024)
    op.read(f"/{uuid_str}")
    op.delete(f"/{uuid_str}")

The perf record is here
+   63.46%     0.00%  python   [unknown]                                 [.] 0x8b48fb894828ec83
+   43.07%    13.11%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] <&pyo3::types::iterator::PyIterator a
+   14.66%     6.43%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::conversions::std::num::<impl py
+   13.72%    13.72%  python   libpython3.12.so.1.0                      [.] listiter_next
+   12.49%     0.00%  python   [unknown]                                 [.]<PHONE_NUMBER>000000
+   11.24%     0.00%  python   [kernel.kallsyms]                         [k] asm_exc_page_fault
+   11.23%     0.00%  python   [kernel.kallsyms]                         [k] exc_page_fault
+   11.22%     4.01%  python   [kernel.kallsyms]                         [k] do_user_addr_fault
+   11.06%    11.06%  python   ld-linux-x86-64.so.2                      [.] _dl_update_slotinfo
+   10.81%     0.00%  python   libc.so.6                                 [.] __libc_start_call_main
+   10.81%     0.00%  python   libpython3.12.so.1.0                      [.] Py_BytesMain
+   10.81%     0.00%  python   libpython3.12.so.1.0                      [.] Py_RunMain
+   10.79%     0.00%  python   libpython3.12.so.1.0                      [.] pymain_run_python.constprop.0
+   10.79%     0.00%  python   libpython3.12.so.1.0                      [.] _PyRun_AnyFileObject
+   10.79%     0.00%  python   libpython3.12.so.1.0                      [.] _PyRun_SimpleFileObject
+   10.79%     0.00%  python   libpython3.12.so.1.0                      [.] run_mod
+   10.79%     0.00%  python   libpython3.12.so.1.0                      [.] run_eval_code_obj
+   10.79%     0.00%  python   libpython3.12.so.1.0                      [.] PyEval_EvalCode
+   10.79%     0.00%  python   [JIT] tid 210049                          [.] py::<module>:/root/opendal-demo/demo.
+   10.79%     0.00%  python   libpython3.12.so.1.0                      [.] _PyEval_EvalFrameDefault
+    8.14%     8.14%  python   ld-linux-x86-64.so.2                      [.] __tls_get_addr
+    6.88%     1.97%  python   libc.so.6                                 [.] __memmove_avx_unaligned_erms
+    6.81%     0.11%  python   [kernel.kallsyms]                         [k] handle_mm_fault
+    6.64%     6.64%  python   ld-linux-x86-64.so.2                      [.] update_get_addr
+    6.53%     0.23%  python   [kernel.kallsyms]                         [k] __handle_mm_fault
+    6.27%     0.03%  python   [kernel.kallsyms]                         [k] handle_pte_fault
+    5.17%     0.00%  python   [unknown]                                 [.] 0x0000000000000098

We can find that we can not trace the rust code.
Since I enable the rustflag, here's new perf result
+   92.23%     0.00%  python   libc.so.6                                 [.] __libc_start_call_main              ◆
+   92.23%     0.00%  python   libpython3.12.so.1.0                      [.] Py_BytesMain                        ▒
+   92.23%     0.00%  python   libpython3.12.so.1.0                      [.] Py_RunMain                          ▒
+   92.22%     0.00%  python   libpython3.12.so.1.0                      [.] pymain_run_python.constprop.0       ▒
+   92.22%     0.00%  python   libpython3.12.so.1.0                      [.] _PyRun_AnyFileObject                ▒
+   92.22%     0.00%  python   libpython3.12.so.1.0                      [.] _PyRun_SimpleFileObject             ▒
+   92.22%     0.00%  python   libpython3.12.so.1.0                      [.] run_mod                             ▒
+   92.22%     0.00%  python   libpython3.12.so.1.0                      [.] run_eval_code_obj                   ▒
+   92.22%     0.00%  python   libpython3.12.so.1.0                      [.] PyEval_EvalCode                     ▒
+   92.22%     0.00%  python   [JIT] tid 211989                          [.] py::<module>:/root/opendal-demo/demo▒
+   92.22%     0.00%  python   libpython3.12.so.1.0                      [.] _PyEval_EvalFrameDefault            ▒
+   88.98%     0.00%  python   libpython3.12.so.1.0                      [.] PyObject_Vectorcall                 ▒
+   88.98%     0.00%  python   libpython3.12.so.1.0                      [.] method_vectorcall_VARARGS_KEYWORDS  ▒
+   88.98%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal_python::operator::_::<impl p▒
+   88.98%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::impl_::trampoline::cfunction_w▒
+   88.98%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::impl_::trampoline::trampoline ▒
+   83.73%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] std::panic::catch_unwind            ▒
+   83.73%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] std::panicking::try                 ▒
+   83.73%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] __rust_try                          ▒
+   83.73%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] std::panicking::try::do_call        ▒
+   83.73%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::impl_::trampoline::trampoline:▒
+   83.73%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::impl_::trampoline::cfunction_w▒
+   83.73%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal_python::operator::_::<impl o▒
+   83.22%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::impl_::extract_argument::extra▒
+   83.22%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] <T as pyo3::impl_::extract_argument:▒
+   83.22%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::types::any::PyAny::extract    ▒
+   83.22%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::types::sequence::<impl pyo3::c▒
+   81.47%     7.67%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::types::sequence::extract_seque▒
+   50.67%     2.93%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] <&pyo3::types::iterator::PyIterator ▒
+   41.45%     0.43%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::marker::Python::from_owned_ptr▒
+   40.37%     2.06%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] <T as pyo3::conversion::FromPyPointe▒
+   36.33%     1.75%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::gil::register_owned           ▒
+   24.69%     3.91%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] std::thread::local::LocalKey<T>::try▒
+   16.31%     0.34%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::types::any::PyAny::extract    ▒
+   13.54%     3.58%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::conversions::std::num::<impl p▒
+   10.77%     1.33%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::gil::register_owned::{{closure▒
+    8.00%     4.11%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] pyo3::gil::OWNED_OBJECTS::__getit   ▒
+    7.77%     3.46%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] std::thread::local::LocalKey<T>::try▒
+    5.24%     0.00%  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] core::ptr::drop_in_place<pyo3::gil::▒
+    4.94%     4.94%  python   ld-linux-x86-64.so.2                      [.] _dl_update_slotinfo
....
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal_python::operator::_::<impl opendal_python::operator::Operator>::__pymethod_delete__
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal_python::operator::Operator::delete
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal::types::operator::blocking_operator::BlockingOperator::delete
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal::types::operator::operator_functions::FunctionDelete::call
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal::types::operator::operator_functions::OperatorFunction<T,R>::call
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] core::ops::function::FnOnce::call_once
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal::types::operator::blocking_operator::BlockingOperator::delete_with::{{closure}}
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] <alloc::sync::Arc<T> as opendal::raw::accessor::Accessor>::blocking_delete
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal::raw::layer::<impl opendal::raw::accessor::Accessor for L>::blocking_delete
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal::raw::layer::LayeredAccessor::blocking_delete
     0.05%     0.00%             6  python   [kernel.kallsyms]                         [k] ext4_block_write_begin
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal::raw::layer::<impl opendal::raw::accessor::Accessor for L>::blocking_delete
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] <opendal::layers::complete::CompleteAccessor<A> as opendal::raw::layer::LayeredAccessor>::blocking_delete
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] opendal::raw::layer::<impl opendal::raw::accessor::Accessor for L>::blocking_delete
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] <opendal::layers::error_context::ErrorContextAccessor<A> as opendal::raw::layer::LayeredAccessor>::blocking_delete
     0.05%     0.00%             0  python   _opendal.cpython-312-x86_64-linux-gnu.so  [.] <opendal::services::fs::backend::FsBackend as opendal::raw::accessor::Accessor>::blocking_delete

And

Users interested in benchmarking can compile the OpenDAL Python bindings themselves. Is there any benefit to enabling this by default?

Users interested in benchmarking can compile the OpenDAL Python bindings themselves. Is there any benefit to enabling this by default?

I can use the perf directly when it is enabled by default. This would be great when we find the process issue. We perf it and don't need to recompile the whole package

I can use the perf directly when it is enabled by default. This would be great when we find the process issue. We perf it and don't need to recompile the whole package

perf is not a normal use cases. I believe the workflow should be:

perf during developement.
release the package with the best result.

I agree with @Zheaoli that enabling frame pointers is very useful, I'm open to enable it by default.
FYI, Ubuntu is also going to enable frame pointers by default soon: https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-by-default

Will this change affect the performance or binary size? And why rustc disabled it by default?

the performance will lose from 1% to 2%

Seems fine. Is there any other reason for rustc not enabling it by default?

https://doc.rust-lang.org/rustc/codegen-options/index.html#force-frame-pointers
Seems that it is not disabled by default. It depends on the target.

I'm not very familiar with the differences between DWARF and frame-pointers. Does this mean I can omit adding debug=1 when building OpenDAL to generate symbols?

I'm not very familiar with the differences between DWARF and frame-pointers.

FYI

https://www.manjusaka.blog/posts/2023/08/22/a-little-bit-idea-about-unwind
https://maskray.me/blog/2020-11-08-stack-unwinding#中文版

If we add force-frame-pointers=yes, can we remove https://github.com/apache/incubator-opendal/issues/3759?

If we add force-frame-pointers=yes, can we remove #3759?

No! Without symbol, we can't do anything!

I'm also doubtful about adding too many random rustflags. However, searching GitHub, I found tikv also enables this by default, so it seems a reasonable choice. https://github.com/tikv/tikv/blob/f9727af132109754e63fbb4910b73563d0b1da45/Makefile#L37-L51
ref: https://github.com/tikv/tikv/pull/12480

I'm not very familiar with the differences between DWARF and frame-pointers.

FYI

manjusaka.blog/posts/2023/08/22/a-little-bit-idea-about-unwind
maskray.me/blog/2020-11-08-stack-unwinding#%E4%B8%AD%E6%96%87%E7%89%88

These went to deep. 🤪
I think basically:

frame pointer is part of debuginfo.
DWARF is the format of debuginfo.
debuginfo contains mainly mapping between source code and machine code.

debug=full: can use debugger to inspect variables and stuff
debug=1: can get line number, function name. so often needed for backtrace (e.g. panic) and profiling

perf is not a normal use cases

Agree. But I think profiling performance issues in production is also needed sometimes? Although in my experience, debug=1 is enough for generating flamegraphs (I havn't used perf though). Don't know why frame pointer is needed for opendal (or perf?).

I don't have any major objections to this. @Zheaoli, would you be willing to submit a PR for this change?

Just curious, Does perf need to know the frame point to expand and obtain debugging information? Isn't dwarf not enough?

Just curious, Does perf need to know the frame point to expand and obtain debugging information? Isn't dwarf not enough?

Also was curious. But seems the ubuntu blog explained it. https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-by-default

frame pointer is not a symbol information, it is more like a call convention. It's not just only for performance issue. The DWARF is too complicated to use for the unwind(aka stack backtracing). People may need to take care of the CFI,CFA and so many other details about DWARF.
Perf has DWARF call-graph support already, but not enough for other tools.
For example, I want to trace the delete action on /tmp/abcabdasdas and find out which program deleted it and get the program call stack.
I can simply use bpftrace to reach my target to get the result like following below
        7f992b234ecb unlink+11 (/usr/lib/libc.so.6)
        7f9929635b58 _$LT$opendal..services..fs..backend..FsBackend$u20$as$u20$opendal..raw..accessor..Accessor$GT$::blocking_delete::h29be0d409c0ac8fc+488 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99291ff3d0 _$LT$opendal..layers..error_context..ErrorContextAccessor$LT$A$GT$$u20$as$u20$opendal..raw..layer..LayeredAccessor$GT$::blocking_delete::heeb7b043f40b40d2+80 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929210be5 opendal::raw::layer::_$LT$impl$u20$opendal..raw..accessor..Accessor$u20$for$u20$L$GT$::blocking_delete::hfe8ff62d64908e8c+21 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992977c1b7 _$LT$opendal..layers..complete..CompleteAccessor$LT$A$GT$$u20$as$u20$opendal..raw..layer..LayeredAccessor$GT$::blocking_delete::hf8df1f73a18ab5ee+279 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992978c8c5 opendal::raw::layer::_$LT$impl$u20$opendal..raw..accessor..Accessor$u20$for$u20$L$GT$::blocking_delete::hbfd7055d767e037f+21 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929944768 opendal::raw::layer::LayeredAccessor::blocking_delete::h9a0cabb31d9c83d5+136 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992994cef5 opendal::raw::layer::_$LT$impl$u20$opendal..raw..accessor..Accessor$u20$for$u20$L$GT$::blocking_delete::hd0452586f494ff0d+21 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992919fa91 _$LT$alloc..sync..Arc$LT$T$GT$$u20$as$u20$opendal..raw..accessor..Accessor$GT$::blocking_delete::he4406d9b46c5d061+145 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992980ce55 opendal::types::operator::blocking_operator::BlockingOperator::delete_with::_$u7b$$u7b$closure$u7d$$u7d$::h131b101950b83511+197 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99294ce721 core::ops::function::FnOnce::call_once::h8aac70541118a702+81 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992981f5e7 opendal::types::operator::operator_functions::OperatorFunction$LT$T$C$R$GT$::call::hdaa1b6b2b17fd7ba+87 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99293ae76b opendal::types::operator::operator_functions::FunctionDelete::call::hb7b9fc6b7c5fd5d8+43 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929693d1a opendal::types::operator::blocking_operator::BlockingOperator::delete::h29d3ad415820c9c2+58 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929113e63 opendal_python::operator::Operator::delete::hd67488a4058bb5bb+35 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929117228 opendal_python::operator::_::_$LT$impl$u20$opendal_python..operator..Operator$GT$::__pymethod_delete__::h67da0638ee468daf+600 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929158456 pyo3::impl_::trampoline::fastcall_with_keywords::_$u7b$$u7b$closure$u7d$$u7d$::he1f3cfdfb5a96d74+54 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915801c pyo3::impl_::trampoline::trampoline::_$u7b$$u7b$closure$u7d$$u7d$::h265ebee4038c7f2d+44 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915a4bb std::panicking::try::do_call::h0d63c3720ecb8a94+43 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915d45d __rust_try+29 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915a3d6 std::panicking::try::h8d397070821fac39+86 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915a075 std::panic::catch_unwind::hba46f6d4392f497e+21 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929157c66 pyo3::impl_::trampoline::trampoline::h8e658ba9b211a1e9+278 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99290a526e pyo3::impl_::trampoline::fastcall_with_keywords::h1a57159770804871+78 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99291148b0 opendal_python::operator::_::_$LT$impl$u20$pyo3..impl_..pyclass..PyMethods$LT$opendal_python..operator..Operator$GT$$u20$for$u20$pyo3..impl_..pyclass..PyClassImplCollector$LT$opendal_python..operator..Operator$GT$$GT$::py_methods::ITEMS::trampoline::h05ff33749dc99c1b+16 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992b581d7e method_vectorcall_FASTCALL_KEYWORDS+142 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b574488 PyObject_Vectorcall+88 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b50fad2 _PyEval_EvalFrameDefault+19106 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b690b9f PyEval_EvalCode+543 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b6ec4d8 run_eval_code_obj+88 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b6ec5fc run_mod+140 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b6ef3e7 _PyRun_SimpleFileObject+375 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b6ef9e5 _PyRun_AnyFileObject+69 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b716e80 Py_RunMain+2336 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b7174e2 Py_BytesMain+82 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b158cd0 0x7f992b158cd0 ([unknown])

I can also write a tracing program based on the frame pointer. Actually there are so many community tools based on the frame poiner, not the DWARF.

Just curious, Does perf need to know the frame point to expand and obtain debugging information? Isn't dwarf not enough?

Also was curious. But seems the ubuntu blog explained it. https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-by-default

Lower Overhead: Unwinding with frame pointers is significantly cheaper than using DWARF or DWARF-derived information.

I think this means cheaper for DWARF, but this does not mean can not, it just says it's harder than frame pointer. I don't know.

Just curious, Does perf need to know the frame point to expand and obtain debugging information? Isn't dwarf not enough?

Also was curious. But seems the ubuntu blog explained it. https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-by-default

Lower Overhead: Unwinding with frame pointers is significantly cheaper than using DWARF or DWARF-derived information.

I think this means cheaper for DWARF, but this does not mean can not, it just says it's harder than frame pointer. I don't know.

Yeap, DWARF can do the same thing we do by using the frame pointer. But it's too complicated to use. So many tools are not supporting it yet.

frame pointer is not a symbol information, it is more like a call convention. It's not just only for performance issue. The DWARF is too complicated to use for the unwind(aka stack backtracing). People may need to take care of the CFI,CFA and so many other details about DWARF.
Perf has DWARF call-graph support already, but not enough for other tools.
For example, I want to trace the delete action on /tmp/abcabdasdas and find out which program deleted it and get the program call stack.
I can simply use bpftrace to reach my target to get the result like following below
        7f992b234ecb unlink+11 (/usr/lib/libc.so.6)
        7f9929635b58 _$LT$opendal..services..fs..backend..FsBackend$u20$as$u20$opendal..raw..accessor..Accessor$GT$::blocking_delete::h29be0d409c0ac8fc+488 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99291ff3d0 _$LT$opendal..layers..error_context..ErrorContextAccessor$LT$A$GT$$u20$as$u20$opendal..raw..layer..LayeredAccessor$GT$::blocking_delete::heeb7b043f40b40d2+80 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929210be5 opendal::raw::layer::_$LT$impl$u20$opendal..raw..accessor..Accessor$u20$for$u20$L$GT$::blocking_delete::hfe8ff62d64908e8c+21 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992977c1b7 _$LT$opendal..layers..complete..CompleteAccessor$LT$A$GT$$u20$as$u20$opendal..raw..layer..LayeredAccessor$GT$::blocking_delete::hf8df1f73a18ab5ee+279 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992978c8c5 opendal::raw::layer::_$LT$impl$u20$opendal..raw..accessor..Accessor$u20$for$u20$L$GT$::blocking_delete::hbfd7055d767e037f+21 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929944768 opendal::raw::layer::LayeredAccessor::blocking_delete::h9a0cabb31d9c83d5+136 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992994cef5 opendal::raw::layer::_$LT$impl$u20$opendal..raw..accessor..Accessor$u20$for$u20$L$GT$::blocking_delete::hd0452586f494ff0d+21 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992919fa91 _$LT$alloc..sync..Arc$LT$T$GT$$u20$as$u20$opendal..raw..accessor..Accessor$GT$::blocking_delete::he4406d9b46c5d061+145 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992980ce55 opendal::types::operator::blocking_operator::BlockingOperator::delete_with::_$u7b$$u7b$closure$u7d$$u7d$::h131b101950b83511+197 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99294ce721 core::ops::function::FnOnce::call_once::h8aac70541118a702+81 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992981f5e7 opendal::types::operator::operator_functions::OperatorFunction$LT$T$C$R$GT$::call::hdaa1b6b2b17fd7ba+87 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99293ae76b opendal::types::operator::operator_functions::FunctionDelete::call::hb7b9fc6b7c5fd5d8+43 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929693d1a opendal::types::operator::blocking_operator::BlockingOperator::delete::h29d3ad415820c9c2+58 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929113e63 opendal_python::operator::Operator::delete::hd67488a4058bb5bb+35 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929117228 opendal_python::operator::_::_$LT$impl$u20$opendal_python..operator..Operator$GT$::__pymethod_delete__::h67da0638ee468daf+600 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929158456 pyo3::impl_::trampoline::fastcall_with_keywords::_$u7b$$u7b$closure$u7d$$u7d$::he1f3cfdfb5a96d74+54 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915801c pyo3::impl_::trampoline::trampoline::_$u7b$$u7b$closure$u7d$$u7d$::h265ebee4038c7f2d+44 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915a4bb std::panicking::try::do_call::h0d63c3720ecb8a94+43 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915d45d __rust_try+29 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915a3d6 std::panicking::try::h8d397070821fac39+86 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992915a075 std::panic::catch_unwind::hba46f6d4392f497e+21 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f9929157c66 pyo3::impl_::trampoline::trampoline::h8e658ba9b211a1e9+278 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99290a526e pyo3::impl_::trampoline::fastcall_with_keywords::h1a57159770804871+78 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f99291148b0 opendal_python::operator::_::_$LT$impl$u20$pyo3..impl_..pyclass..PyMethods$LT$opendal_python..operator..Operator$GT$$u20$for$u20$pyo3..impl_..pyclass..PyClassImplCollector$LT$opendal_python..operator..Operator$GT$$GT$::py_methods::ITEMS::trampoline::h05ff33749dc99c1b+16 (/home/manjusaka/.pyenv/versions/3.12.0/envs/jupyter/lib/python3.12/site-packages/opendal/_opendal.cpython-312-x86_64-linux-gnu.so)
        7f992b581d7e method_vectorcall_FASTCALL_KEYWORDS+142 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b574488 PyObject_Vectorcall+88 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b50fad2 _PyEval_EvalFrameDefault+19106 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b690b9f PyEval_EvalCode+543 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b6ec4d8 run_eval_code_obj+88 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b6ec5fc run_mod+140 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b6ef3e7 _PyRun_SimpleFileObject+375 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b6ef9e5 _PyRun_AnyFileObject+69 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b716e80 Py_RunMain+2336 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b7174e2 Py_BytesMain+82 (/home/manjusaka/.pyenv/versions/3.12.0/lib/libpython3.12.so.1.0)
        7f992b158cd0 0x7f992b158cd0 ([unknown])

I can also write a tracing program based on the frame pointer. Actually there are so many community tools based on the frame pointer, not the DWARF.

Thanks, that‘s answer my question. 🚀

I think this means cheaper for DWARF, but this does not mean can not, it just says it's harder than frame pointer. I don't know.

But it's too complicated to use. So many tools are not supporting it yet.

Not only too complicated. The DWARF information can be seen as instructions of a stack virtual machine, which can have endless-loop or any harmful logic, so it's unsafe to evaluate these instructions inside kernel or any other serious scenario.
perf also doesn't work perfectly with DWARF. As perf cannot safely handle the DWARF information in kernel for sample. perf record has to copy and store the stack for each sample on disk (by default 8KB, and maximum 64KB, which is actually not big enough so some frames are lost) . Therefore, the perf data is really big, and profiling over-head is also significant, which can harm the profiling accuracy.
Also, the dependent libraries may have fault DWARF information, as it's hard to generate a correct DWARF information for every instructions. From my experience, the VDSO on ubuntu 18.04, some system libraries on Mac OS can have fault information, which will break the profilers (as the profilers may want to read some unexpected address while evaluating the DWARF instructions).
The LLVM may also generate wrong dwarf information e.g. https://github.com/rust-lang/rust/issues/83139 . I think these problems come from the complexity of DWARF and it's hard to overcome.
BTW, if you are about to enable frame-pointer, remember to also rebuild standard libraries of rust (with --build-std flag of cargo). The pre-build rust standard libraries don't ship with frame-pointer. You can reference https://github.com/tikv/tikv/pull/12480 .

Edit: But it seems that they used this to solve another niche issue

This PR introduces a new version of pprof-rs, which provides stack backtracking based on frame pointers,

TiKV has a continuous profiling feature, which will grab a profile periodically for the developers to understand the system states in history. It uses the https://github.com/tikv/pprof-rs to implement this feature, which actually supports both DWARF and frame-pointer. However, it turns out that it's much stabler to unwind through frame-pointer than DWARF, so we finally migrated to use frame-pointer.
If you have more interests in profiling / sampling, I had a share about the technical choices in profilers in PingCAP internally, and here is the slides and recorded video (in Chinese). It also describes the choices between DWARF and frame-pointer.

If you have more interests in profiling / sampling, I had a share about the technical choices in profilers in PingCAP internally, and here is the slides and recorded video (in Chinese). It also describes the choices between DWARF and frame-pointer.

Fantastic! Thank you so much for sharing!

Implemented in https://github.com/apache/incubator-opendal/pull/3772.
Thank you all!


Enable tests to run via CI

PR #1 includes unit tests that ought to run via CI.  The boilerplate necessary to run tests via CI is in PR #2.

PR #2 is cribbed from the idc_migration repository

Fixing this issue should allow the developer to check out this repository and run make test, which will invoke all the prerequisite steps (like composer install) before actually running tests using phpunit.  The Github Actions will be updated to run tests via CI.

For an example how this is expected to work, check out the idc_migration repository and run make test.

The branch tests-wip is essentially #2 rebased on #1, with some revisions.
The problem is that the ConstraintTest fails to run because it can't require autoload.php:

require(/app/vendor/drupal/autoload.php): failed to open stream: No such file or directory

bootEnvironment() of KernelTestBase has this statement on line 262: $this->classLoader = require $this->root . '/autoload.php';
I have attempted to coax the generation of vendor/drupal/autoload.php using variations of the autoload and autoload-dev composer.json statements.  The composer.json in the test-wip branch includes autoload statements cribbed from the Drupal 8.x branch, but none of my attempts have worked.
The full output of make clean test is below:
 make clean test                                                                                Wed Jul  7 16:20:33 2021
Removing make state from ./.make
Removing vendored source
Removing composer.lock
Reverting .env
source .env && docker pull ghcr.io/jhu-sheridan-libraries/idc-isle-dc/idc_defaults-testing:${TEST_IMAGE_TAG}
e0cf0c5: Pulling from jhu-sheridan-libraries/idc-isle-dc/idc_defaults-testing
Digest: sha256:5b000fdd227eb41be6c4217fd725bb33e933f2810d0763a780d5ee1620f1ce73
Status: Image is up to date for ghcr.io/jhu-sheridan-libraries/idc-isle-dc/idc_defaults-testing:e0cf0c5
ghcr.io/jhu-sheridan-libraries/idc-isle-dc/idc_defaults-testing:e0cf0c5
source .env && docker run --rm -v $PWD:/app ghcr.io/jhu-sheridan-libraries/idc-isle-dc/idc_defaults-testing:${TEST_IMAGE_TAG} install --dev
You are using the deprecated option "dev". Dev packages are installed by default now.
Loading composer repositories with package information
Warning from https://repo.packagist.org: Support for Composer 1 is deprecated and some packages will not be available. You should upgrade to Composer 2. See https://blog.packagist.com/deprecating-composer-1-support/
Updating dependencies (including require-dev)
Package operations: 153 installs, 0 updates, 0 removals
  - Installing twistor/stream-util (v1.0.1): Downloading (100%)
  - Installing league/mime-type-detection (1.7.0): Downloading (100%)
  - Installing league/flysystem (1.1.4): Downloading (100%)
  - Installing twistor/flysystem-stream-wrapper (v1.0.9): Downloading (100%)
  - Installing league/flysystem-replicate-adapter (1.0.1): Downloading (100%)
  - Installing symfony/polyfill-php80 (v1.23.0): Downloading (100%)
  - Installing symfony/polyfill-mbstring (v1.17.0): Downloading (100%)
  - Installing symfony/polyfill-php72 (v1.17.0): Downloading (100%)
  - Installing symfony/polyfill-intl-normalizer (v1.23.0): Downloading (100%)
  - Installing paragonie/random_compat (v9.99.99): Downloading (100%)
  - Installing symfony/polyfill-php70 (v1.17.0): Downloading (100%)
  - Installing symfony/polyfill-intl-idn (v1.17.0): Downloading (100%)
  - Installing symfony/deprecation-contracts (v2.4.0): Downloading (100%)
  - Installing doctrine/lexer (1.0.2): Downloading (100%)
  - Installing psr/log (1.1.3): Downloading (100%)
  - Installing pear/pear_exception (v1.0.1): Downloading (100%)
  - Installing pear/console_getopt (v1.4.3): Downloading (100%)
  - Installing pear/pear-core-minimal (v1.10.10): Downloading (100%)
  - Installing pear/archive_tar (1.4.13): Downloading (100%)
  - Installing symfony/polyfill-ctype (v1.17.0): Downloading (100%)
  - Installing psr/container (1.0.0): Downloading (100%)
  - Installing symfony/polyfill-intl-grapheme (v1.23.0): Downloading (100%)
  - Installing symfony/string (v5.3.3): Downloading (100%)
  - Installing symfony/inflector (v5.3.0): Downloading (100%)
  - Installing symfony/property-access (v4.4.25): Downloading (100%)
  - Installing phpdocumentor/reflection-common (2.2.0): Downloading (100%)
  - Installing webmozart/assert (1.10.0): Downloading (100%)
  - Installing phpdocumentor/type-resolver (1.4.0): Downloading (100%)
  - Installing phpdocumentor/reflection-docblock (5.2.2): Downloading (100%)
  - Installing symfony/debug (v3.4.41): Downloading (100%)
  - Installing symfony/polyfill-util (v1.17.0): Downloading (100%)
  - Installing symfony/polyfill-php56 (v1.17.0): Downloading (100%)
  - Installing symfony/http-foundation (v3.4.41): Downloading (100%)
  - Installing symfony/event-dispatcher (v3.4.41): Downloading (100%)
  - Installing symfony/http-kernel (v3.4.44): Downloading (100%)
  - Installing asm89/stack-cors (1.3.0): Downloading (100%)
  - Installing psr/http-message (1.0.1): Downloading (100%)
  - Installing laminas/laminas-zendframework-bridge (1.0.4): Downloading (100%)
  - Installing masterminds/html5 (2.3.0): Downloading (100%)
  - Installing egulias/email-validator (2.1.17): Downloading (100%)
  - Installing stack/builder (v1.0.5): Downloading (100%)
  - Installing laminas/laminas-stdlib (3.2.1): Downloading (100%)
  - Installing laminas/laminas-escaper (2.6.1): Downloading (100%)
  - Installing laminas/laminas-feed (2.12.2): Downloading (100%)
  - Installing symfony/routing (v3.4.41): Downloading (100%)
  - Installing ralouphie/getallheaders (3.0.3): Downloading (100%)
  - Installing guzzlehttp/psr7 (1.6.1): Downloading (100%)
  - Installing guzzlehttp/promises (v1.3.1): Downloading (100%)
  - Installing guzzlehttp/guzzle (6.5.4): Downloading (100%)
  - Installing doctrine/annotations (v1.4.0): Downloading (100%)
  - Installing typo3/phar-stream-wrapper (v3.1.4): Downloading (100%)
  - Installing symfony/polyfill-iconv (v1.17.0): Downloading (100%)
  - Installing composer/semver (1.5.1): Downloading (100%)
  - Installing symfony/class-loader (v3.4.41): Downloading (100%)
  - Installing laminas/laminas-diactoros (1.8.7p2): Downloading (100%)
  - Installing symfony/psr-http-message-bridge (v1.1.2): Downloading (100%)
  - Installing easyrdf/easyrdf (0.9.1): Downloading (100%)
  - Installing symfony-cmf/routing (1.4.1): Downloading (100%)
  - Installing doctrine/collections (v1.4.0): Downloading (100%)
  - Installing doctrine/cache (v1.6.2): Downloading (100%)
  - Installing doctrine/inflector (v1.2.0): Downloading (100%)
  - Installing doctrine/common (v2.7.3): Downloading (100%)
  - Installing twig/twig (v1.42.5): Downloading (100%)
  - Installing symfony/yaml (v3.4.41): Downloading (100%)
  - Installing symfony/process (v3.4.41): Downloading (100%)
  - Installing symfony/translation (v3.4.41): Downloading (100%)
  - Installing symfony/validator (v3.4.41): Downloading (100%)
  - Installing symfony/serializer (v3.4.41): Downloading (100%)
  - Installing symfony/dependency-injection (v3.4.41): Downloading (100%)
  - Installing symfony/console (v3.4.41): Downloading (100%)
  - Installing drupal/core (8.9.16): Downloading (100%)
  - Installing drupal/flysystem (2.0.0-alpha1): Downloading (100%)
  - Installing league/csv (9.7.1): Downloading (100%)
  - Installing drupal/migrate_source_csv (3.4.0): Downloading (100%)
  - Installing drupal/context (4.0.0-beta6): Downloading (100%)
  - Installing symfony/dom-crawler (v3.4.47): Downloading (100%)
  - Installing symfony/css-selector (v3.4.47): Downloading (100%)
  - Installing symfony/browser-kit (v3.4.47): Downloading (100%)
  - Installing fabpot/goutte (v3.2.3): Downloading (100%)
  - Installing behat/mink (v1.8.1): Downloading (100%)
  - Installing behat/mink-browserkit-driver (v1.3.4): Downloading (100%)
  - Installing behat/mink-goutte-driver (v1.2.1): Downloading (100%)
  - Installing mikey179/vfsstream (v1.6.8): Downloading (100%)
  - Installing sebastian/recursion-context (3.0.1): Downloading (100%)
  - Installing sebastian/exporter (3.1.3): Downloading (100%)
  - Installing doctrine/instantiator (1.4.0): Downloading (100%)
  - Installing phpunit/php-text-template (1.2.1): Downloading (100%)
  - Installing drupal/file_replace (1.2.0): Downloading (100%)
  - Installing drupal/migrate_plus (5.1.0): Downloading (100%)
  - Installing drupal/migrate_tools (5.0.0): Downloading (100%)
  - Installing firebase/php-jwt (v5.4.0): Downloading (100%)
  - Installing drupal/key (1.14.0): Downloading (100%)
  - Installing drupal/jwt (1.0.0-rc1): Downloading (100%)
  - Installing drupal/eva (2.1.0): Downloading (100%)
  - Installing symfony/security (v3.4.49): Downloading (100%)
  - Installing pimple/pimple (v3.3.1): Downloading (100%)
  - Installing silex/silex (v2.2.4): Downloading (100%)
  - Installing monolog/monolog (1.26.1): Downloading (100%)
  - Installing namshi/jose (7.2.3): Downloading (100%)
  - Installing doctrine/dbal (v2.7.2): Downloading (100%)
  - Installing ml/iri (1.1.4): Downloading (100%)
  - Installing ml/json-ld (1.2.0): Downloading (100%)
  - Installing islandora/chullo (dev-dev d563d5e): Cloning d563d5e48e from cache
  - Installing islandora/crayfish-commons (dev-dev 46a1f1b): Cloning 46a1f1b63b from cache
  - Installing islandora/jsonld (dev-8.x-1.x dfd99c4): Cloning dfd99c4c1b from cache
  - Installing drupal/prepopulate (2.3.0): Downloading (100%)
  - Installing drupal/token (1.9.0): Downloading (100%)
  - Installing drupal/search_api (1.19.0): Downloading (100%)
  - Installing drupal/config_update (1.7.0): Downloading (100%)
  - Installing drupal/features (3.12.0): Downloading (100%)
  - Installing drupal/filehash (1.5.0): Downloading (100%)
  - Installing stomp-php/stomp-php (4.6.1): Downloading (100%)
  - Installing islandora/islandora (dev-8.x-1.x 8a28ea2): Cloning 8a28ea28e2 from cache
  - Installing drupal/core-recommended (8.9.16)
  - Installing sebastian/global-state (2.0.0): Downloading (100%)
  - Installing drupal/workbench_access (1.0.0-beta4): Downloading (100%)
  - Installing symfony/phpunit-bridge (v3.4.47): Downloading (100%)
  - Installing symfony/lock (v3.4.47): Downloading (100%)
  - Installing symfony/finder (v3.4.47): Downloading (100%)
  - Installing symfony/filesystem (v3.4.47): Downloading (100%)
  - Installing sebastian/version (2.0.1): Downloading (100%)
  - Installing sebastian/resource-operations (2.0.2): Downloading (100%)
  - Installing sebastian/object-reflector (1.1.2): Downloading (100%)
  - Installing sebastian/object-enumerator (3.0.4): Downloading (100%)
  - Installing sebastian/environment (4.2.4): Downloading (100%)
  - Installing sebastian/diff (3.0.3): Downloading (100%)
  - Installing sebastian/comparator (3.0.3): Downloading (100%)
  - Installing phpunit/php-timer (2.1.3): Downloading (100%)
  - Installing phpunit/php-file-iterator (2.0.3): Downloading (100%)
  - Installing theseer/tokenizer (1.2.0): Downloading (100%)
  - Installing sebastian/code-unit-reverse-lookup (1.0.2): Downloading (100%)
  - Installing phpunit/php-token-stream (3.1.2): Downloading (100%)
  - Installing phpunit/php-code-coverage (6.1.4): Downloading (100%)
  - Installing phpspec/prophecy (1.13.0): Downloading (100%)
  - Installing phar-io/version (2.0.1): Downloading (100%)
  - Installing phar-io/manifest (1.0.3): Downloading (100%)
  - Installing myclabs/deep-copy (1.10.2): Downloading (100%)
  - Installing phpunit/phpunit (7.5.20): Downloading (100%)
  - Installing justinrainbow/json-schema (5.2.10): Downloading (100%)
  - Installing jcalderonzumba/gastonjs (v1.2.0): Downloading (100%)
  - Installing jcalderonzumba/mink-phantomjs-driver (v0.3.3): Downloading (100%)
  - Installing squizlabs/php_codesniffer (3.6.0): Downloading (100%)
  - Installing sirbrillig/phpcs-variable-analysis (v2.11.2): Downloading (100%)
  - Installing drupal/coder (8.3.13): Cloning d3286d571b from cache
  - Installing seld/phar-utils (1.1.1): Downloading (100%)
  - Installing seld/jsonlint (1.8.3): Downloading (100%)
  - Installing composer/xdebug-handler (1.4.6): Downloading (100%)
  - Installing composer/spdx-licenses (1.5.5): Downloading (100%)
  - Installing composer/ca-bundle (1.2.10): Downloading (100%)
  - Installing composer/composer (1.10.22): Downloading (100%)
  - Installing instaclick/php-webdriver (1.4.9): Downloading (100%)
  - Installing behat/mink-selenium2-driver (v1.4.0): Downloading (100%)
  - Installing drupal/core-dev (8.9.16)
league/flysystem suggests installing league/flysystem-eventable-filesystem (Allows you to use EventableFilesystem)
league/flysystem suggests installing league/flysystem-rackspace (Allows you to use Rackspace Cloud Files)
league/flysystem suggests installing league/flysystem-azure (Allows you to use Windows Azure Blob storage)
league/flysystem suggests installing league/flysystem-webdav (Allows you to use WebDAV storage)
league/flysystem suggests installing league/flysystem-aws-s3-v2 (Allows you to use S3 storage with AWS SDK v2)
league/flysystem suggests installing league/flysystem-aws-s3-v3 (Allows you to use S3 storage with AWS SDK v3)
league/flysystem suggests installing spatie/flysystem-dropbox (Allows you to use Dropbox storage)
league/flysystem suggests installing srmklive/flysystem-dropbox-v2 (Allows you to use Dropbox storage for PHP 5 applications)
league/flysystem suggests installing league/flysystem-cached-adapter (Flysystem adapter decorator for metadata caching)
league/flysystem suggests installing league/flysystem-sftp (Allows you to use SFTP server storage via phpseclib)
league/flysystem suggests installing league/flysystem-ziparchive (Allows you to use ZipArchive adapter)
symfony/polyfill-intl-normalizer suggests installing ext-intl (For best performance)
paragonie/random_compat suggests installing ext-libsodium (Provides a modern crypto API that can be used to generate random bytes.)
symfony/polyfill-intl-idn suggests installing ext-intl (For best performance)
pear/archive_tar suggests installing ext-bz2 (Bz2 compression support.)
pear/archive_tar suggests installing ext-xz (Lzma2 compression support.)
symfony/polyfill-intl-grapheme suggests installing ext-intl (For best performance)
symfony/property-access suggests installing psr/cache-implementation (To cache access methods.)
symfony/http-kernel suggests installing symfony/config
symfony/http-kernel suggests installing symfony/var-dumper
egulias/email-validator suggests installing ext-intl (PHP Internationalization Libraries are required to use the SpoofChecking validation)
laminas/laminas-feed suggests installing laminas/laminas-cache (Laminas\Cache component, for optionally caching feeds between requests)
laminas/laminas-feed suggests installing laminas/laminas-db (Laminas\Db component, for use with PubSubHubbub)
laminas/laminas-feed suggests installing laminas/laminas-http (Laminas\Http for PubSubHubbub, and optionally for use with Laminas\Feed\Reader)
laminas/laminas-feed suggests installing laminas/laminas-servicemanager (Laminas\ServiceManager component, for easily extending ExtensionManager implementations)
laminas/laminas-feed suggests installing laminas/laminas-validator (Laminas\Validator component, for validating email addresses used in Atom feeds and entries when using the Writer subcomponent)
symfony/routing suggests installing symfony/config (For using the all-in-one router or any loader)
symfony/routing suggests installing symfony/expression-language (For using expression matching)
guzzlehttp/psr7 suggests installing zendframework/zend-httphandlerrunner (Emit PSR-7 responses)
symfony/class-loader suggests installing symfony/polyfill-apcu (For using ApcClassLoader on HHVM)
symfony/psr-http-message-bridge suggests installing nyholm/psr7 (For a super lightweight PSR-7/17 implementation)
symfony/translation suggests installing symfony/config
symfony/validator suggests installing psr/cache-implementation (For using the metadata cache.)
symfony/validator suggests installing symfony/intl
symfony/validator suggests installing symfony/config
symfony/validator suggests installing symfony/expression-language (For using the Expression validator)
symfony/serializer suggests installing psr/cache-implementation (For using the metadata cache.)
symfony/serializer suggests installing symfony/property-info (To deserialize relations.)
symfony/serializer suggests installing symfony/config (For using the XML mapping loader.)
symfony/dependency-injection suggests installing symfony/config
symfony/dependency-injection suggests installing symfony/expression-language (For using expressions in service container configuration)
symfony/dependency-injection suggests installing symfony/proxy-manager-bridge (Generate service proxies to lazy load them)
behat/mink suggests installing dmore/chrome-mink-driver (fast and JS-enabled driver for any app (requires chromium or google chrome))
behat/mink suggests installing behat/mink-zombie-driver (fast and JS-enabled headless driver for any app (requires node.js))
drupal/migrate_plus suggests installing sainsburys/guzzle-oauth2-plugin (3.0 required for the OAuth2 authentication plugin)
drupal/migrate_plus suggests installing ext-soap (*)
drupal/migrate_tools suggests installing drush/drush (^9 || ^10)
firebase/php-jwt suggests installing paragonie/sodium_compat (Support EdDSA (Ed25519) signatures when libsodium is not present)
symfony/security suggests installing symfony/form
symfony/security suggests installing symfony/expression-language (For using the expression voter)
symfony/security suggests installing symfony/ldap (For using the LDAP user and authentication providers)
monolog/monolog suggests installing graylog2/gelf-php (Allow sending log messages to a GrayLog2 server)
monolog/monolog suggests installing sentry/sentry (Allow sending log messages to a Sentry server)
monolog/monolog suggests installing doctrine/couchdb (Allow sending log messages to a CouchDB server)
monolog/monolog suggests installing ruflin/elastica (Allow sending log messages to an Elastic Search server)
monolog/monolog suggests installing php-amqplib/php-amqplib (Allow sending log messages to an AMQP server using php-amqplib)
monolog/monolog suggests installing ext-amqp (Allow sending log messages to an AMQP server (1.0+ required))
monolog/monolog suggests installing ext-mongo (Allow sending log messages to a MongoDB server)
monolog/monolog suggests installing mongodb/mongodb (Allow sending log messages to a MongoDB server via PHP Driver)
monolog/monolog suggests installing aws/aws-sdk-php (Allow sending log messages to AWS services like DynamoDB)
monolog/monolog suggests installing rollbar/rollbar (Allow sending log messages to Rollbar)
monolog/monolog suggests installing php-console/php-console (Allow sending log messages to Google Chrome)
namshi/jose suggests installing phpseclib/phpseclib (Allows to use Phpseclib as crypto engine, use version ^2.0.)
drupal/search_api suggests installing drupal/facets (Adds the ability to create faceted searches.)
drupal/search_api suggests installing drupal/search_api_autocomplete (Allows adding autocomplete suggestions to search fields.)
drupal/search_api suggests installing drupal/search_api_solr (Adds support for using Apache Solr as a backend.)
islandora/islandora suggests installing drupal/transliterate_filenames (Sanitizes filenames when they are uploaded so they don't break your repository.)
sebastian/global-state suggests installing ext-uopz (*)
phpunit/php-code-coverage suggests installing ext-xdebug (^2.6.0)
phpunit/phpunit suggests installing phpunit/php-invoker (^2.0)
phpunit/phpunit suggests installing ext-soap (*)
phpunit/phpunit suggests installing ext-xdebug (*)
Package symfony/inflector is abandoned, you should avoid using it. Use use `EnglishInflector` from the String component instead instead.
Package silex/silex is abandoned, you should avoid using it. Use symfony/flex instead.
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Writing lock file
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
64 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
source .env && docker run --rm -v $PWD:/app ghcr.io/jhu-sheridan-libraries/idc-isle-dc/idc_defaults-testing:${TEST_IMAGE_TAG} check-platform-reqs
ext-curl       7.4.13      success
ext-date       7.4.13      success
ext-dom        20031129    success
ext-fileinfo   7.4.13      success
ext-filter     7.4.13      success
ext-gd         7.4.13      success
ext-hash       7.4.13      success
ext-json       7.4.13      success
ext-libxml     7.4.13      success
ext-mbstring   7.4.13      success
ext-openssl    7.4.13      success
ext-pcre       7.4.13      success
ext-PDO        7.4.13      success
ext-Phar       7.4.13      success
ext-session    7.4.13      success
ext-SimpleXML  7.4.13      success
ext-SPL        7.4.13      success
ext-tokenizer  7.4.13      success
ext-xml        7.4.13      success
ext-xmlwriter  7.4.13      success
lib-pcre       10.35       success
php            7.4.13      success
source .env && docker run --rm -v $PWD:/app ghcr.io/jhu-sheridan-libraries/idc-isle-dc/idc_defaults-testing:${TEST_IMAGE_TAG} vendor/bin/phpunit tests
PHPUnit 7.5.20 by Sebastian Bergmann and contributors.

E                                                                   1 / 1 (100%)

Time: 600 ms, Memory: 14.48 MB

There was 1 error:

1) Drupal\Tests\idc_defaults\Kernel\ConstraintTest::testConstraint
require(/app/vendor/drupal/autoload.php): failed to open stream: No such file or directory

/app/vendor/drupal/core/tests/Drupal/KernelTests/KernelTestBase.php:262
/app/vendor/drupal/core/tests/Drupal/KernelTests/KernelTestBase.php:262
/app/vendor/drupal/core/tests/Drupal/KernelTests/KernelTestBase.php:245
/app/vendor/drupal/core/modules/node/tests/src/Kernel/NodeAccessTestBase.php:56
/app/tests/src/Kernel/ConstraintTest.php:61

ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
make: *** [test] Error 2

Maybe easier to model this in testcafe


Add "3- Delete Columns to Make Sorted (Lobna Mazhar).py"

Can you add the solution again and delete .DS file

Good Job, thanks for your contribution @LobnaMazhar.


all: Switch to github.com/moov-io/base Time

Fixes: https://github.com/moov-io/ach/issues/298

Codecov Report

Merging #414 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #414   +/-   ##
=======================================
  Coverage   85.49%   85.49%
=======================================
  Files         109      109
  Lines        6818     6818
=======================================
  Hits         5829     5829
  Misses        694      694
  Partials      295      295

Impacted Files
Coverage Δ

addenda99.go
97.05% <ø> (ø)
:arrow_up:

fileHeader.go
100% <ø> (ø)
:arrow_up:

batchHeader.go
98.29% <ø> (ø)
:arrow_up:

iatBatchHeader.go
100% <ø> (ø)
:arrow_up:

test/ach-pop-write/main.go
84.21% <100%> (ø)
:arrow_up:

cmd/writeACH/main.go
58.33% <100%> (ø)
:arrow_up:

test/ach-ccd-write/main.go
87.23% <100%> (ø)
:arrow_up:

test/ach-adv-write/main.go
89.47% <100%> (ø)
:arrow_up:

test/simple-file-creation/main.go
88.23% <100%> (ø)
:arrow_up:

test/ach-web-write/main.go
89.47% <100%> (ø)
:arrow_up:

... and 19 more

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 5ceeae6...76d7b7d. Read the comment docs.


Investigate other package managers

vcpkg is nice when everything is packaged correctly, however it is very difficult to share the result of a single pre-compiled package with someone else to install into their existing set of packages. This design is nice to ensure maximum compatibility for a single machine by hashing almost every component that goes into building the package (compiler, source code, patches, cmake scripts, dependencies, etc.), but it is very difficult to share pre-compiled packages by themselves.
On the other hand, package managers like Homebrew get away with compiling a package once (and any dependencies) and distributing the result to all macOS users on the same OS version. Mac is relatively easy to do this because there is really only a single target operating system. Linux is more difficult if you aren't careful about libc and lib(std)c++ compatibilities, but Homebrew seems to support Linux, and we could only officially target Ubuntu 20.04.
The nice thing about vcpkg is that you only need to specify the CMAKE_TOOLCHAIN_FILE to choose which dependency set you'd like to compile against. With Homebrew, it's more of a global installation (kind of), which would require manually specifying package directories like -DLLVM_DIR=/usr/local/opt/llvm...

You can consider switching to a CMake "superbuild" using ExternalProject_Add. I did a (successful) experiment for remill like this: https://github.com/mrexodia/cxx-common-cmake
The advantage over vcpkg is that you get the folder cxx-common-cmake/build/install that contains all the dependencies. You can copy this folder to other machine and all you have to do is use cmake -B build "-DCMAKE_PREFIX_PATH=<path-to-cxx-common-cmake>/build/install to allow find_package to find your dependencies.
The "disadvantage" is that your dependencies need to produce correct CMake packages and this can be a bit of a challenge. For example xed.cmake requires a bit of hackery: finding python, fetching mbuild, fetching/building xed and finally a custom XEDConfig.cmake that allows find_package(XED).


Can I be allowed to custom the buttons' text in ColorPickerDialog?

I wish I can change the buttons' text in ColorPickerDialog.

Thanks for the PR
932371a2e5ae9970fae15b2b6e7ee3340e59c09a


combinedClickable does not expose MouseClickScope

The APIs for mouse clicks do not give any context about the key presses. Modifier.combinedClickable should expose information about which key is currently being pressed using MouseClickScope. For the double click even, you might pass only the latest MouseClickScope or 2 scopes, each for event.

Lamberto, have you seen section "Mouse right/middle clicks and keyboard modifiers" of the Mouse events tutorial? I guess it answers your question.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Closes #153 by using the current global scope instead of window

Thanks for the fix. Published in 6.2.1


shallow components throwing unknown custom element error

Version
1.0.0-beta.1
Reproduction link
https://jsfiddle.net/Sabazou/uu91qb4w/
Steps to reproduce
Create a component that utilizes another component.
Create a test that shallow mounts the parent component
Run the test
What is expected?
For all unregistered components to be stubbed and the test to pass
What is actually happening?
Vue runtime throws an error.
console.error node_modules/vue/dist/vue.runtime.common.js:474
[Vue warn]: Unknown custom element:  - did you register the component correctly? For recursive components, make sure to provide the "name" option.

Adding { stubs: ['bButton'] } suppresses the error but seems to defeat the purpose of calling shallow in the first place which seems to be convenience

Thanks for reporting and for jfiddle.  Could you expand on what you are expecting?  I think you are saying that you would like vue-test-utils to be able to stub out any custom html element that isn't registered in vue as a component.

I was under the impression that using shallow over mount essentially ignores all of the unregistered child components. From what I'm seeing though it causes a runtime error because they aren't registered with Vue.
So not necessarily wanting it to intelligently traverse my component and look for tags that aren't registered. I just thought this was the intended behavior. Otherwise I wasn't sure what the purpose was calling shallow over just calling mount with the stubs property.
Maybe some confusion on my side or on the documentation side.

In fact even the documentation for shallow describes the behavior this way

Returns Wrapper of first DOM node or Vue component matching selector.
Stubs all child components.

Ok, I think I understand now.
The problem is my child components were globally registered and not locally. That's most likely why it has a problem stubbing them.

You are correct in that it will only stub registered vue components, but it does on both your component instance and globally on the root vue.
Could you check that your component is registered in global vue and that you are not passing a localVue property to the shallow?  To check you could do something like this in your spec before the assert.  If it logs an empty object then you know that b-button is not registered globally and that is why it is not being stubbed globally.
console.log (Vue.options.components)

That's what I was missing. Totally forgot to include the file that registers my global components.
Thank you for your help!

I meet same issue, all my function is work without any warning, but occur "[Vue warn]: Unknown custom element:" when I run unit test, but all my unit test is passed, just have a lot of this warn.
All my components is register like this:
const sharedComponents = {
install(Vue) {
Vue.component('v-input', Input);
Vue.component('popup', Popup);
},
};
Vue.use(sharedComponents);
new Vue({
el: '#app',
...
});
I'm confused why it's not work in unit test?

@Teresast those are all installed globally, it seems to have them stubbed in shallowMount you need to install them like so.
import Popup from './popup.vue';

new Vue({
    el: '#app',
    components: {
        Popup
    },
    ...
});

I solved by adding the global components as stubs -> read here
https://github.com/vuejs/vue-test-utils/issues/894


added a loader in project submit

Fixes Issue
#192

Changes proposed

Added a loader animation to the submit project page
Note to reviewers

Screenshots

@leewan-09 did you able to see the loader?

@leewan-09 did you able to see the loader?

nop

Can you fix the build? Build it locally and test whether it is okay.

okay

@kumaryogesh17 there are prettier build issue. could you fix it

which color should i use ?

is orange color is fine ?

please review I have updated the color of loader.


Unable to run IDFIX in Server 2012

Thank you for reporting an issue, suggesting an enhancement, or asking a question. We appreciate your feedback - to help the team understand your
needs please complete the below template to ensure we have the details to help. Thanks!
Please check out the Docs to see if your question is already addressed there. This will help us ensure our documentation covers the most frequent questions.

If you are reporting a security related issue, instead of submitting it here, please email<EMAIL_ADDRESS>to ensure it is properly handled to resolution.

Category

[ ] Enhancement
[ ] Bug
[ x] Question
[ ] Documentation gap/issue

Version
Please specify what version of IdFix you are using: [  <IP_ADDRESS>   ]
I am unable to run IDFIX on Server 2012. When i click on query option in the IDFIX program, the screen is blan and the message i get is cleared grid. Can someone help me with this issue

Any update on this? I am experiencing the same issue, I also tried running it from a Windows 10 workstations and the same result.

I'm seeing the same issue on Server 2016 Standard.  IdFix version <IP_ADDRESS>


Adapt texture loading code to Ogre 2.2

The current code that loads texture data is both messy and inefficient. There's 2 things that need fixing :

we are loading textures before knowing what material the glTF will use. Thus, we don't know what purpose the textures we load. Some of theses textures differ between how glTF store them and how HLMS PBS need them (eg : metalic-roughness map has to be separated in 2 "one color" texture from the 1 "two color" texture).

current texture loading code is inefficient and messy. It needs cleaning.

Original issue about that problem was #17. But instead of concentrating on fixing the code for Ogre 2.1, we should rewrite it for 2.2, while incorporating the necessary changes.
The Ogre 2.1 code path will still benefit from the change due to the updated texture loading logic, but it is by no mean necessary.
I'm closing issue #17 now, as it is irrelevant from now on.

Ogre 2.2 now is "mostly stable"... And has morph target support. I guess I need to start working on bringing this library to it!


Airflow/Wind sensor

🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸
🎉 New feature
This adds an airflow sensor. These sensors are generally used to measure wind and are ultrasonic devices, measuring the airflow speed and direction using the Doppler effect.
Depends on:

https://github.com/gazebosim/sdformat/pull/1349
https://github.com/gazebosim/gz-msgs/pull/411
https://github.com/gazebosim/gz-sensors/pull/404

Here is some use cases of such sensors from a manufacturer sensor which we have used.
https://fttechnologies.com/case-studies.
This is part of a larger plan to support an airflow sensor in PX4. @dagar
The code is heavily based on the Airspeed Sensor
Checklist

[ ] Signed all commits for DCO
[ ] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

@henrykotze sorry that this set of PRs has taken so long to review. Would you be able to provide the motivation for creating a new sensor instead of using AirSpeed sensor?

@henrykotze we are now in Feature freeze for Gazebo Ionic. Since PR is already open, I've applied the beta label which means it's slotted for the Ionic release if we can get it merged before 08/28/2024. Do you think that's feasible? If not, please let me know and I'll remove the beta label.

@henrykotze are you still interested in pushing this forward?


"Segmentation Fault(core dumped)" when converting waymo dataset to kitti format

I am trying to convert the waymo dataset to kitti format by following this documentation.
When I run the "python tools/create_data.py waymo --root-path ./data/waymo/ --out-dir ./data/waymo/ --workers 128 --extra-tag waymo" command, I received a segmentation fault. Any clue why this is occurring?
Error
Segmentation Fault (core dumped)
Environment
sys.platform: linux
Python: 3.7.12 | packaged by conda-forge | (default, Oct 26 2021, 06:08:21) [GCC 9.4.0]
CUDA available: True
GPU 0,1,2,3: NVIDIA GeForce RTX 2080 Ti
CUDA_HOME: /usr
NVCC: Cuda compilation tools, release 10.0, V10.0.13
GCC: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
PyTorch: 1.10.2
PyTorch compiling details: PyTorch built with:

GCC 7.3
C++ Version: 201402
Intel(R) oneAPI Math Kernel Library Version 2022.1-Product Build 20220311 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v2.2.3 (Git Hash 7336ca9f055cf1bfa13efb658fe15dc9b41f0740)
OpenMP 201511 (a.k.a. OpenMP 4.5)
LAPACK is enabled (usually provided by MKL)
NNPACK is enabled
CPU capability usage: AVX512
CUDA Runtime 11.3
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86;-gencode;arch=compute_37,code=compute_37
CuDNN 8.2
Magma 2.5.2
Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CUDA_VERSION=11.3, CUDNN_VERSION=8.2.0, CXX_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/c++, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -DEDGE_PROFILER_USE_KINETO -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_VERSION=1.10.2, USE_CUDA=ON, USE_CUDNN=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON,

TorchVision: 0.11.3
OpenCV: 4.6.0
MMCV: 1.5.3
MMCV Compiler: GCC 7.3
MMCV CUDA Compiler: 11.3
MMDetection: 2.25.0
MMSegmentation: 0.25.0
MMDetection3D: 1.0.0rc3+bb20469
spconv2.0: False
Tensorflow: 2.0.0

It's hard to tell what happened given the only error message "segmentation fault". Maybe you need to show more information about it, for example, could you successfully create data infos for other datasets? Besides, the installation of tensorflow may bring some trouble when doing experiments on Waymo.


net: lwm2m: add support for coap2coap proxy

Currently, LwM2M firmware download only supports coap2http proxy.
Let's add support for coap2coap proxy as well.
This was tested using Californium demo app cf-proxy with the following
setting changed in Californum.properties:
MAX_RESOURCE_BODY_SIZE=524288
This allows the proxy to get the firmware resource from a remote
server and then deliver it to the requesting device.
Signed-off-by: Michael Scott<EMAIL_ADDRESS>

Updated with better schema checks per @lpereira
Diff: https://hastebin.com/xodadozalo.go

NOTE: I also rebased on today's master


disable the validation of *.d.ts files from npm dependencies

OS?
Windows 10
Versions.
angular-cli: 1.0.0-beta.21
node: 6.9.1
os: win32 x64
Repro steps.
For example with @types/jquery.
In your angular-cli project :
npm i --save-dev @types/jquery

then add the following code anywhere :
import * as jquery from 'jquery';

Then run ng serve or build, and you'll get the following log in the console.
The log given by the failure.
[default] C:\Documents and Settings\nmace\dev\github\angular-buzz\node_modules\@types\jquery\index.d.ts:3246:5
    Duplicate identifier 'export='.
[default] C:\Users\nmace\dev\github\angular-buzz\node_modules\@types\jquery\index.d.ts:623:5
    Duplicate string index signature.
[default] C:\Users\nmace\dev\github\angular-buzz\node_modules\@types\jquery\index.d.ts:2872:5
    Duplicate string index signature.
[default] C:\Users\nmace\dev\github\angular-buzz\node_modules\@types\jquery\index.d.ts:2873:5
    Duplicate number index signature.
[default] C:\Users\nmace\dev\github\angular-buzz\node_modules\@types\jquery\index.d.ts:3246:5
    Duplicate identifier 'export='.
[default] Checking finished with 6 errors

Mention any other details that might be useful.
Any project using this kind of dependencies with<EMAIL_ADDRESS>will have this kind of errors showing, which will break any ng build -prod. I think we should ignore this files by default.

I don't think these are CLI-specific. I would expect any typescript project to behave similarly.


fix typo in filename mentioning "password.yaml" to "passwords.yaml"

Small typo fix
wrong: password.yaml
right: passwords.yaml
Pre-launch Checklist

[x] I read the Contribute page and followed the process outlined there for submitting PRs.
[x] This update contains only one single feature or bug fix and nothing else. (If you are submitting multiple fixes, please make multiple PRs.)
[x] I read and followed the Dart Style Guide and formatted the code with dart format.
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///), and made sure that the documentation follows the same style as other Serverpod documentation. I checked spelling and grammar.
[ ] I added new tests to check the change I am making.
[x] All existing and new tests are passing.
[ ] Any breaking changes are documented below.

If you need help, consider asking for advice on the discussion board.
Breaking changes
No breaking changes

Thanks 🙏


a more fully featured maven buildpack example

I don't think we need this anymore. We have a Ruby example that demonstrates the the usage of libcnb for a concrete language buildpack. The example would not demonstrate additional parts of the libcnb API beyond what the Ruby example does. Not sure where the value-add is here.
On the other hand, this is more code we need to maintain and not all maintainers have the context required to do so efficiently.
Thoughts @heroku/languages?


Poor "getting started" documentation here and on the npm page

I'm by no means a node/javascript expert, but I don't think I'm a dumb-dumb either. But I literally could not figure out how to use this module in my application after about 2 (err, now 3) hours of trying. This is essentially the extent of your getting started documentation:
import ENS, { getEnsAddress } from '@ensdomains/ensjs'

const ens = new ENS({ provider, ensAddress: getEnsAddress('1') })

ens.name('resolver.eth').getAddress() // 0x123

Which may seem obvious to experts but was difficult to decipher for me and probably for other folks.

The "import something, {somethingElse}" syntax was not familiar to me. IMO, you should either explain it with a comment or break it into multiple declarations. Minimizing code may be helpful in some circumstances, but when teaching with an example, readability is paramount.
Many dapps are still on the "require" system as that's how web3js documentation still says to do it. It took me a few attempts to figure out the right "var ENS = require" declaration to move forward.
At the point of giving up, I'm getting errors about "provider" being undefined.
Why use "resolver.eth" as your example lookup? That's just confusing.
"ens.name('resolver.eth').getAddress()" is a promise (unless I'm mistaken) that needs to handled with a .then or in some other way. Why not include that syntax? Why show an incomplete example?
Size - including ensdomains in my AWS deployable nodejs bundle jumped the package size from 12.5 MB to 44 MB. By comparison, ethereum-ens adds less than 1 MB.
I can't find where you explain why you forked this off of "ethereum-ens". What was the problem?
Is there a browser-deployable min.js package?

Anyway I've given up and will try ethers.js or something.
If you're trying to maximize integrations and this repo is not ready for prime time (and this appears the case by the issues load and my own troubles), I would suggest marking it as such to prevent others from falling down this hole.

Thank you for the feedback, it’s helpful to know the trouble you went through and we’ll do better to make this package easier to use and improve documentation.
Thank you again for taking the time to write this up. I’m happy to take this to DMs on Twitter (_jefflau) if you still want to help us the improve this package, we’ve definitely not prioritised it and I will endeavor to improve this as soon as possible.

I have had a quick go at setting it up myself from scratch and I've updated the docs (as a start). Can you have a look to see if this works for you out the box? I think as you said it's important to have the setup work by copying and pasting.
I will work on some of your other requests as soon as I can.
https://github.com/ensdomains/ensjs/blob/0d6f4e99a57539c79cf3f9dcdebc1b3793cb7a49/README.md

Thank you but I'm still stuck on reverse resolution and I'm following the ENS docs as closely as I can with as many brain cells as I can muster. Apparently it's not enough.
const ENSModule = require('@ensdomains/ensjs');
const ENS = ENSModule.default;
const getEnsAddress = ENSModule.getEnsAddress;

const ens = new ENS({ provider, ensAddress:getEnsAddress('1') })
ens.name('ens.eth').getAddress().then(addr => console.log("addr=" + addr))
> 0xb6E040C9ECAaE172a89bD561c5F73e1C48d28cd9

var address = '0xb6E040C9ECAaE172a89bD561c5F73e1C48d28cd9';
ens.getName(address).then( result => console.log("name=" + JSON.stringify(result)));
>  name={"name":null}

Why am I getting back "null"? I literally just resolved that name to the given address.
And the docs (https://docs.ens.domains/dapp-developer-guide/resolving-names)  try to describe using a special domain x.addr.reverse but don't provide any examples and I can't figure out the right formula for using this method either. What methods? Is the address wrapped in a string? Is the whole thing a string? What should the response look like?
Is there a complete technical reference like there is for web3js (or any other mature project, for that matter)?

Reverse records need to be set manually. So you need to do:
address => setName(‘ens.eth’)
addresses are set using a special namespace, which is [address].addr.reverse
To set this you need to use the reverse registrar to claim this “reverse node”. Then you setup a resolver as normal and then setName on that reverse node.
After that you can then do ens.getName and get the name associated with that address.

Ok I don't understand this at all. I just need to reverse various addresses and see if there are ENS addresses. That's all. It should be a pretty basic ask of the ENS ecosystem and tooling to be able to do this. How is it this difficult?
Can you show me a full code snippet for my requirement?

Yes exactly, you can have many names that resolve to one address. e.g. cyrus1.eth, cyrus2.eth could all resolver to 0x123, but you can only have 1 reverse records, e.g if you own 0x123, you can set that to resolver to cyrus1.eth.

Is there a master reverse resolver that most people use? Do services like Etherscan somehow keep track of all the reverse lookups on their own by watching a stream of events that set these values?

Hey and what about all the write options? How am I supposed to update or create a subdomain if I cannot set a custom signer?
Sorry I'm kinda newbie in web3, but clearly this documentation needs an update (and I'm thankful I did found this issue, otherwise I'd be still stuck trying to just read a record).

hey @jefflau, just want to add my 2 cents here and say that I agree with the original post here. I'm new to Ethereum development stuff but just starting to poke around.
I'm a huge fan of ENS and I think it's one of the most exciting projects in the crypto space. we even support sending HNT to ENS names in the Helium app if they have a Helium wallet address specified
but right now I'm doing a little learning project to try and get a handle on ENS / basic Ethereum development, so I want to just do a simple lookup to see if an address has a reverse record/primary name set on ENS, and like Cyrus, I am really struggling to use the current documentation to help me figure it out with either ensjs or any of the other options...
I am also seeing the same error cyrus described:

errors about "provider" being undefined

I guess that provider is just a placeholder example, and I would need to define it before that snippet? (but doing so has just resulted in different errors so far). and ensAddress: getEnsAddress("1") is also confusing to me. is ("1") a placeholder example, or is "1" a valid option there? what would normally go there if it's a placeholder—an address?
I assume that object as the argument for the new ENS() instantiation is like the config for the ENS object, but it's really not quite clear to me what that bit of code is doing or how it works and I can't find any good info about it on the docs site
I kind of expect it to just be like:
const ens = new ENS()

and then be able to call a bunch of useful functions from ens, but changing it to that ^ just gives me: TypeError: Cannot read properties of undefined (reading 'networkId')
I made the (I guess faulty) assumption that the Getting Started code snippet would "just work"
I know you're all probably busy with lots of different things but I really think it's important that the Getting Started code snippet(s) should:

just work
show in one or two lines how to check if a primary name has been set for 0x123
show in one or two lines how to get the address of banana.eth

anyway just some thoughts as I jump between dozens of browser tabs to try to make sense of this...
thanks for all the work you do on this important protocol! I hope to understand it well enough to contribute on the docs site and the frontend(s) soon (I think Brantly said in a Twitter Spaces room that the Figma file for the new manager might be shared to the community soon? 👀  I'd love to help build it)

Im banging my head too :/
could someone ELI5 what is provider?

Im banging my head too :/
could someone ELI5 what is provider?

A provider is like an "abstract connection to the blockchain". Think of it like a node you have running, or alchemy. Usually you set up a provider with an RPC URL or WebSocket.


Add Documentation

What's New?
I finally got some spare time to add documentation. Fixes #2

Closing as Bugsnag has first class support for Vue now. People should use that.


Simplify Installation

These changes push the burden of determining and installing package dependencies into the Python packaging system where those concerns belong.  Since these concerns are now handled automatically, you should be able to run the following commands on any system to get a GDB server up-and-running that is attached to hardware...
$ sudo pip install --pre -U https://github.com/posborne/pyOCD/archive/simplify-installation.zip
$ pyocd
...

I have been able to test on Linux (Ubuntu 14.04) and Windows and this approach works well.  I believe most users will already have pip installed.  If they do not, they should.
When the next release is pushed to pypi, the first step will become even easier...
$ pip install pyocd

I tested on mac as well now.  I had to install Cython (easy enough via pip).  Removing this should be possible but only if the build for hidapi was changed to include the Cython-generated C files in the distribution packages.

Thanks for the patch.  I tried it out on my windows machine and didn't have any problems installing.

Rebased and reworked with the following changes:

There now are entry points defined for all 3 of the tools that were present before.  All are prefixed with pyocd.  I am not too familiar with how the pyocd tool was used, so please provide suggest better names if they might exist.  I prefixed them all with pyocd in order to prevent namespace confllicts/pollution as most users will install pyocd globally.
Updated documentation and tested pyinstaller.  See https://github.com/posborne/pyOCD/commit/e38cf5ad07dcc505768db5793a0cfa713bdce8ed for more details.
Other documentation updates including some additional guidance encourage developers to use virtualenv in keeping with modern python best practices.

Thanks @posborne, well documented. This should simplify usage. We can start using pyocd-gdbserver :+1:


Different DetectNet output in DIGITS and JetsonTX2

I have trained custom object detection dataset fallowing this tutorial.

Originally 640x512 images -> re-scaled to 2560x2048
During training 640x512 image crops but full size in testing. Adjusted coverage threshold and min bounding box length for better detection.
Validation and Testing in DIGITS works GOOD.
For JetsonTX2 deleted clustering layer and adjusted threshold parameter with '--threshold=0.1' same as DIGITS. Using same image getting different bbox outputs. It seems those are the same detections but some just have bigger bounding box.
1. Are these the same outputs as DIGITS just clustered together similar to eps parameter setting? If so how to adjust it?
2. #107 #48 #86 suggests issue with mean values, but no mean subtraction is performed from DIGITS interface. And detectnet layers have mean shift -127 for both train and deploy.  It seems this has been already been taken care of.
3. DIGITS (red), TX2 (blue)

@dusty-nv Could you kindly suggest possible cause of problem?
Different question: do I have to code pre-process scaling for images from 640x512 to 2560x2024 before using detectnet-camera or detectnet-console or this is taken care of automatically. Detectnet-console seemed to not scale them, but detectnet-camera had only 2FPS using default camera which is lower FPS than for default models.

The clustering of bounding boxes is handled separately in the detectNet class #L406. If you look at the merging logic closely, you can see that there is a very loose criterion for clustering the boxes unlike the one used on DIGITS. You can try to modify/reimplement this and this should solve your 'bigger box' issue. I have done the same because I was also dealing with similar issue.
As per the FPS, if you are displaying the 2560x2024 then a significant amount of computation will be used in rendering these images and thus leads to lower FPS. What is the network time reported on single image? This should be considered for the FPS of detection using the network, not considering the display or read/write time.

Hi. Thanks for clearing that up. I tried solution provided #195 which worked partially for me and hence re-implementing this is needed. What I understand from that thread is that confidence of each bbox is not taken into account during original clustering algo which can lead to worse accuracy depending on data.
What did you use for your solution at the end? I'm thinking that maybe a non-max suppression algorithm might be appropriate but have to verify.
Inference speed was ~520ms for full image size so I should probably get ~1.9FPS if not rendering images. However I'll need to resize and save them on the fly so this should decrease FPS slightly.

I am using something that is very close to NMS. But it does slow down a bit the total inference time. I think that the GPU implementation for NMS can be done. But haven't worked on it yet.


README renderer workflow with RMarkdown README

Adds a README.Rmd file which renders to a clean, formatted README.md upon push to main, devel and pre-release. This will allow for dynamic content to be added to the README.

@dinakar29 @bms63 i just changed Friday -> Monday for the admiral release schedule piece as discussed and agreed in the chatroom. if all OK happy for you to merge this one anytime.
I couldn't find anywhere else we talk about the Friday schedule but please update if you spot anywhere (FYI @thomas-neitmann too)

@dinakar29 from what you say above, i guess if we merge this to main then README.md will then render and all the broken links get fixed right?

Can we get back the original wordlist?  I think this is handy for admiral extension packages.

@bms63 would be hard to maintain that here as every package ext wordlist will evolve with new words over time? i think we'd be better just using the automation and running the script each time that adds the accepted words to the wordlist for you in your package repo rather than trying to maintain a master list here for new packages

@dinakar29 from what you say above, i guess if we merge this to main then README.md will then render and all the broken links get fixed right?

Yes, that is correct.

@dinakar29 it didn't work after the merge, i forward'ed you the failed workflow.

The version of pkgdown in the current renv.lock is old. My subsequent PR should fix it: https://github.com/pharmaverse/admiraltemplate/pull/26/files#diff-0a4513e8dc7e92cfc41839907ae36b739c44d06cd3323735b29423ce4b8c9887R489-R490


colons in figure titles and/or descriptions break legend

This appears to be a problem of Jekyll parsing the YAML block (returns: Error reading file […].md: (<unknown>): mapping values are not allowed in this context at line […]). Escaping with \: doesn't work. Replacing with : or wrapping in Markdown (*Scale bar: 1µm* or **A:** … **B:** …) both do. In the latter case however, the * then can't be the 1st character after YAML's description:, because it expects an alphanumeric one. What a rabbit hole :-D
Since colons in, as well as panel references at the start of, figure legends are desirable, I'd like to discuss ideas to solve this problem.

applying the abstract notation with |, newline and two spaces to the figure title and description templates
adding a note to the readme
automated escaping of unsupported characters
other way of paring figure metadata

The first two I could implement & send a pull request.

Wrapping the text in double-quotes is the simplest way to avoid this, unless there are newlines, in which case | works better.

Thanks! This was driving me nuts!

The example YAML now uses double quotes where appropriate.

Thanks for the hints :-)


Task installation failure

The /install option fails under some circumstances. See https://github.com/just-install/registry/issues/207#issuecomment-653797393.

I think it's not the /install failing, but installation of the msi. You said that it only adds a task for the executable and I had this task.

I tested the installer from various commits and it also didn't work. I tested the installer from the commit adding the msi installer and it also doesn't work.

@geek1011 Shouldn't Execute="commit" Impersonate="no" be changed to Execute="deferred" Impersonate="yes"? This works for me.

Also, why aren't you using user's startup folder?

Also, why aren't you using the startup folder?

It needs to run as admin and show a GUI, but there's nothing like setuid on Windows.

Shouldn't Execute="commit" Impersonate="no" be changed to Execute="deferred" Impersonate="yes"? This works for me.

I'll have to take a closer look at the docs. deferred makes sense, but I'm not convinced about Impersonate.
https://wixtoolset.org/documentation/manual/v3/xsd/wix/customaction.html, Impersonate:

This attribute specifies  whether the Windows Installer, which executes as LocalSystem,                                  should impersonate the user context of the  installing user when executing this custom action.                                  Typically the value should be 'yes', except when the custom  action needs elevated privileges                                 to  apply changes to the machine.


Double allocation in __clove_path_basepath

__clove_path_basepath uses strdup and calloc. This results in two separate memory allocations, which is inefficient and may cause memory fragmentation. A better approach would be to use only one allocation as mentioned in the function itself.
See: clove-unit.h#L818

In this case perf and Memory frag are not really an issue, but would be nice if we find a way to improve it without loose code clarity.


Prepend functionality not working for me

This is a (multiple allowed):

[x] bug

Initially there is 2 slide empty space even when prepend value is zero; how can I fix this gap?
http://prntscr.com/e46f0a

Issue is closed because of outdated/irrelevant/not actual/needed more information/inactivity.
If this issue is still actual and reproducible for latest version of Swiper, please create new issue and fill the issue template correctly:

Clearly describe the issue including steps to reproduce when it is a bug.
Make sure you fill in the earliest version that you know has the issue.
Provide live link or JSFiddle/Codepen or website with issue


fix(NO_TICKET): wrong parameter for IR timeout

This commit fixes the FBC parameter (requestTimeoutSeconds) to wait for the InternalRequest to complete.
Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Issue ticket number and link
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/retest

/retest

/retest


How is global mapping (G bit in a PTE) supposed to work?

Current privileged spec says:
The G bit designates a global mapping. Global mappings are those that exist in all address spaces.
For non-leaf PTEs, the global setting implies that all mappings in the subsequent levels of the page
table are global. Note that failing to mark a global mapping as global merely reduces performance,
whereas marking a non-global mapping as global is a software bug that, after switching to an
address space with a diﬀerent non-global mapping for that address range, can unpredictably result
in either mapping being used.

Global mappings need not be stored redundantly in address-translation caches for multiple
ASIDs. Additionally, they need not be ﬂushed from local address-translation caches when an
SFENCE.VMA instruction is executed with rs2̸=x0.

Based on the spec, assume we have the following setup:

A PTE table is configured with several pages marked as global mapping under ASID x, and its PPN is written to satp.
A new PTE table is configured with additional PTEs that map additional non-global memory under ASID y, and its PPN is written to satp followed by sfence.vma x0, rs2 where rs2 =x0 and contains ASID y

For the global mappings that have already been cached in the TLB, in the new ASID y context, access to these memory mapped by the cached global mappings should work as expected. But for those global mappings that have not been cached anywhere in the TLB in previous ASID x context, how does the processor know these mappings when trying to access to these memory?

I don't quite understand what's the setup you're mentioning: sfence.vma x0, x0 means flush all translation caches. Do you mean rs2 != x0?
You'll need to make sure all global pages are mapped with consistent meanings in all page tables.

As @nbdd0121 said, global mappings must be stored redundantly in each page table.

I don't quite understand what's the setup you're mentioning: sfence.vma x0, x0 means flush all translation caches. Do you mean rs2 != x0?

Sorry, this is a typo. Yes, I mean rs2 != x0

You'll need to make sure all global pages are mapped with consistent meanings in all page tables.

OK, with such setup I can understand how it works. Originally I thought it was a mechanism of software optimization that global mappings can exist in just one page table hence software is not required to provide global mappings in all page tables, but that is wrong based on this information you provide.
So the value of G bit in a PTE is only a hardware optimization, if such a PTE is cached by hardware, sfence.vma x0, rs2 (!=x0) can leave it in the translation caches.
Is my understanding correct?

As @nbdd0121 said, global mappings must be stored redundantly in each page table.

Thanks for the confirmation. I believe it's worth mentioning such statement explicitely in the spec.


Add script's integrity and crossorigin attributes

When using <script> to pull a library from a CDN, it's usually a good idea to attach an integrity check so that if they get hacked and someone changes all the script, malicious scripts don't get executed on your website.
To achieve this, you need to attach integrity and crossorigin to your <script/> tag
Script(
	Scr("https://cdn.jsdelivr.net/npm/bootstrap@5.0.0-beta1/dist/js/bootstrap.bundle.min.js"),
	Integrity("sha384-ygbV9kiqUc6oa4msXn9868pTtWMgiQaeYH7/t7LECLbyPA2x65Kgf80OJFdroafW"),
	CrossOrigin("anonymous"),
)

Turns into
<script<EMAIL_ADDRESS>    integrity="sha384-ygbV9kiqUc6oa4msXn9868pTtWMgiQaeYH7/t7LECLbyPA2x65Kgf80OJFdroafW"
    crossorigin="anonymous"></script>

Hint for whoever likes unpkg.com, adding ?meta at the end of any script you import form them will give you the current integrity for the file. Example: https://unpkg.com/three@0.165.0/build/three.cjs?meta

Thank you for that! 😊