Customizable window menu for built-in terminal

Continuation of #294 in the custom window menu for the built-in terminal.

Could you implement something like a titlebar-window to put apps in? currently i am using configurations like this:
<item id=htop       label="Htop"       type=DirectVT title="Htop"                  param="$0 -r term htop"             notes=" Interactive process viewer "/>
to make an app have a titlebar.
I am thinking about a titlebar like the demo-apps, but with a custom terminal-command.

Custom Menu Configuration
Terminal window menu can be composed from scratch by specifying a list of menu items in the /config/term/menu/ configuration file section.
Attributes for the /config/term/menu/item object

Attribute
Description

type
Menu item type. type=Command is used by default.

label
Menu item label list. One or more textual representations selected by data= value.

notes
Tooltip. Inherited by the label attribute.

action
The function name which called on item activation.

data
Textual parameter for function call. Inherited by the label attribute.

hotkey
Keyboard shortcut for this menu item. Inherited by the label attribute (not implemented).

Attributes for the /config/term/menu/item/label sub-object

Attribute
Description

internal_value
Label display variation label="_internal_value_".

notes
Tooltip. Inherited from item if not specified.

data
Textual parameter for function call. Inherited from item if not specified.

hotkey
Keyboard shortcut for this menu item. Inherited from item if not specified (not implemented).

Attribute type=

Value
Description

Option
Cyclically selects the next label in the list and exec the function specified by the action= with data= as its parameter.

Command
Exec the function specified by the action= with data= as its parameter.

Attribute action=

Value
Description

TerminalSelectionMode
Set terminal text selection mode. The data= attribute can has the following values none, text, ansi, rich, html, protected.

TerminalWrapMode
Set terminal scrollback lines wrapping mode. Applied to the active selection if it is. The data= attribute can has the following values on, off.

TerminalFindNext
Highlight next match of selected text fragment. Clipboard content is used if no active selection.

TerminalFindPrev
Highlight previous match of selected text fragment. Clipboard content is used if no active selection.

TerminalOutput
Direct output the data= value to the terminal scrollback.

TerminalSendKey
Simulating keypresses using the data= string.

Current built-in terminal window menu configuration
<config>
    ...
    <term>
        ...
        <menu>
            <autohide=true />  <!-- If true, show menu only on hover. -->
            <enabled=1 />
            <slim=1 />
            <item*/>  <!-- Zeroize previous item list. -->
            <item label="Wrap" type=Option action=TerminalWrapMode data="off">
                <label="\e[38:2:0:255:0mWrap\e[m" data="on"/>
                <notes>
                    " Wrapping text lines on/off      \n"
                    " - applied to selection if it is "
                </notes>
            </item>
            <item label="Selection" notes=" Text selection mode " type=Option action=TerminalSelectionMode data="none">  <!-- type=Option means that the тext label will be selected when clicked.  -->
                <label="\e[38:2:0:255:0mPlaintext\e[m" data="text"/>
                <label="\e[38:2:255:255:0mANSI-text\e[m" data="ansi"/>
                <label data="rich">
                    "\e[38:2:109:231:237m""R"
                    "\e[38:2:109:237:186m""T"
                    "\e[38:2:60:255:60m"  "F"
                    "\e[38:2:189:255:53m" "-"
                    "\e[38:2:255:255:49m" "s"
                    "\e[38:2:255:189:79m" "t"
                    "\e[38:2:255:114:94m" "y"
                    "\e[38:2:255:60:157m" "l"
                    "\e[38:2:255:49:214m" "e" "\e[m"
                </label>
                <label="\e[38:2:0:255:255mHTML-code\e[m" data="html"/>
                <label="\e[38:2:0:255:255mProtected\e[m" data="protected"/>
            </item>
            <item label="<" action=TerminalFindPrev>  <!-- type=Command is a default item's attribute. -->
                <label="\e[38:2:0:255:0m<\e[m"/>
                <notes>
                    " Previous match                    \n"
                    " - using clipboard if no selection \n"
                    " - page up if no clipboard data    "
                </notes>
            </item>
            <item label=">" action=TerminalFindNext>
                <label="\e[38:2:0:255:0m>\e[m"/>
                <notes>
                    " Next match                        \n"
                    " - using clipboard if no selection \n"
                    " - page up if no clipboard data    "
                </notes>
            </item>
            <item label="  "    notes=" ...empty menu block/splitter for safety "/>
            <item label="Clear" notes=" Clear TTY viewport "                  action=TerminalOutput data="\e[2J"/>
            <item label="Reset" notes=" Clear scrollback and SGR-attributes " action=TerminalOutput data="\e[!p"/>
            <item label="Hello, World!" notes=" Simulating keypresses "       action=TerminalSendKey data="Hello World!"/>
        </menu>
    </term>
</config>

Repeating button example
<config>
    <term>
        <menu>
            <item label="Push Me" notes=" test " type=Repeat action=TerminalOutput data="pressed ">
                <label="\e[37mPush Me\e[m"/>
            </item>
        </menu>
    </term>
</config>

https://user-images.githubusercontent.com/11535558/209806831-849812e3-c422-433d-837e-cca2fbd5dd7e.mp4


Is the project dead?

There has been no commits in nine months already.
Is the project dead?

I am focusing on https://github.com/coalescejs which is an es6 port of epf (that is not ember-specific but has ember bindings). It is not production ready yet, however.


Invalid integer to pointer cast with segafult on Windows

I am the author of the kmeans crate and I got reports about segfaults on Windows.
To get to the bottom of the problem, I ran one of the project's examples through Miri, which promptly complained about an invalid integer-to-pointer cast in crossbeam-epoch.
Miri complains in both: Linux and Windows, but the segfaults only happen with Windows. Under Linux, there is no segfault and the results of the calculations seem to be correct.
I am not a pro in reading Miri reports, but it at least looks to me like the problem lies with crossbeam. I only have one small piece of unsafe in kmeans but I couldn't find any error with it.
Here is a minimal reproduction project: segfaultrepro.zip
Running cargo miri run in it shows the following report:
warning: integer-to-pointer cast
   --> /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/atomic.rs:204:11
    |
204 |         &*(ptr as *const T)
    |           ^^^^^^^^^^^^^^^^^ integer-to-pointer cast
    |
    = help: this program is using integer-to-pointer casts or (equivalently) `ptr::with_exposed_provenance`, which means that Miri might miss pointer bugs in this program
    = help: see https://doc.rust-lang.org/nightly/std/ptr/fn.with_exposed_provenance.html for more details on that operation
    = help: to ensure that Miri does not miss bugs in your program, use Strict Provenance APIs (https://doc.rust-lang.org/nightly/std/ptr/index.html#strict-provenance, https://crates.io/crates/sptr) instead
    = help: you can then set `MIRIFLAGS=-Zmiri-strict-provenance` to ensure you are not relying on `with_exposed_provenance` semantics
    = help: alternatively, `MIRIFLAGS=-Zmiri-permissive-provenance` disables this warning
    = note: BACKTRACE on thread `unnamed-1`:
    = note: inside `<crossbeam_epoch::internal::Local as crossbeam_epoch::atomic::Pointable>::deref::<'_>` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/atomic.rs:204:11: 204:28
    = note: inside `crossbeam_epoch::atomic::Shared::<'_, crossbeam_epoch::internal::Local>::deref` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/atomic.rs:1421:9: 1421:22
    = note: inside `crossbeam_epoch::sync::list::List::<crossbeam_epoch::internal::Local>::insert` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/sync/list.rs:176:41: 176:58
    = note: inside `crossbeam_epoch::internal::Local::register` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/internal.rs:330:13: 330:65
    = note: inside `crossbeam_epoch::collector::Collector::register` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/collector.rs:45:9: 45:30
    = note: inside `crossbeam_epoch::default::HANDLE::__init` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:34:34: 34:56
    = note: inside `<fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init} as std::ops::FnOnce<()>>::call_once - shim(fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init})` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
    = note: inside `std::option::Option::<crossbeam_epoch::collector::LocalHandle>::unwrap_or_else::<fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init}>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:1017:21: 1017:24
    = note: inside `std::thread::local_impl::LazyStorage::<crossbeam_epoch::collector::LocalHandle, ()>::initialize::<fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init}>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/native/lazy.rs:64:17: 64:59
    = note: inside `std::thread::local_impl::LazyStorage::<crossbeam_epoch::collector::LocalHandle, ()>::get_or_init::<fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init}>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/native/lazy.rs:56:40: 56:61
    = note: inside closure at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/native/mod.rs:94:25: 94:54
    = note: inside `<{closure@crossbeam_epoch::default::HANDLE::{constant#0}::{closure#0}} as std::ops::FnOnce<(std::option::Option<&mut std::option::Option<crossbeam_epoch::collector::LocalHandle>>,)>>::call_once - shim` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
    = note: inside `std::thread::LocalKey::<crossbeam_epoch::collector::LocalHandle>::try_with::<{closure@crossbeam_epoch::default::with_handle<{closure@crossbeam_epoch::default::is_pinned::{closure#0}}, bool>::{closure#0}}, bool>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:282:37: 282:55
    = note: inside `crossbeam_epoch::default::with_handle::<{closure@crossbeam_epoch::default::is_pinned::{closure#0}}, bool>` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:59:5: 60:28
    = note: inside `crossbeam_epoch::default::is_pinned` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:46:5: 46:45
    = note: inside `crossbeam_deque::deque::Stealer::<rayon_core::job::JobRef>::steal` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-deque-0.8.5/src/deque.rs:641:12: 641:30
    = note: inside `rayon_core::registry::WorkerThread::take_local_job` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:751:19: 751:39
    = note: inside `rayon_core::registry::WorkerThread::wait_until_cold` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:785:32: 785:53
    = note: inside `rayon_core::registry::WorkerThread::wait_until::<rayon_core::latch::OnceLatch>` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:769:13: 769:40
    = note: inside `rayon_core::registry::WorkerThread::wait_until_out_of_work` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:818:9: 818:65
    = note: inside `rayon_core::registry::main_loop` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:923:5: 923:43
    = note: inside `rayon_core::registry::ThreadBuilder::run` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:53:18: 53:33
    = note: inside closure at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:98:20: 98:32
    = note: inside `std::sys::backtrace::__rust_begin_short_backtrace::<{closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:154:18: 154:21
    = note: inside closure at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:541:17: 541:71
    = note: inside `<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}> as std::ops::FnOnce<()>>::call_once` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:272:9: 272:19
    = note: inside `std::panicking::r#try::do_call::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}>, ()>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:557:40: 557:43
    = note: inside `std::panicking::r#try::<(), std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}>>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:520:19: 520:88
    = note: inside `std::panic::catch_unwind::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}>, ()>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:358:14: 358:33
    = note: inside closure at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:540:30: 542:16
    = note: inside `<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}} as std::ops::FnOnce<()>>::call_once - shim(vtable)` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
    = note: inside `<std::boxed::Box<dyn std::ops::FnOnce()> as std::ops::FnOnce<()>>::call_once` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1968:9: 1968:52
    = note: inside `<std::boxed::Box<std::boxed::Box<dyn std::ops::FnOnce()>> as std::ops::FnOnce<()>>::call_once` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1968:9: 1968:52
    = note: inside `std::sys::pal::unix::thread::Thread::new::thread_start` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/thread.rs:105:17: 105:64

warning: integer-to-pointer cast
    --> /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/atomic.rs:1345:9
     |
1345 |         raw as *const _
     |         ^^^^^^^^^^^^^^^ integer-to-pointer cast
     |
     = note: BACKTRACE on thread `unnamed-1`:
     = note: inside `crossbeam_epoch::atomic::Shared::<'_, crossbeam_epoch::internal::Local>::as_raw` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/atomic.rs:1345:9: 1345:24
     = note: inside `crossbeam_epoch::internal::Local::register` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/internal.rs:332:24: 332:38
     = note: inside `crossbeam_epoch::collector::Collector::register` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/collector.rs:45:9: 45:30
     = note: inside `crossbeam_epoch::default::HANDLE::__init` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:34:34: 34:56
     = note: inside `<fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init} as std::ops::FnOnce<()>>::call_once - shim(fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init})` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
     = note: inside `std::option::Option::<crossbeam_epoch::collector::LocalHandle>::unwrap_or_else::<fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init}>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:1017:21: 1017:24
     = note: inside `std::thread::local_impl::LazyStorage::<crossbeam_epoch::collector::LocalHandle, ()>::initialize::<fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init}>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/native/lazy.rs:64:17: 64:59
     = note: inside `std::thread::local_impl::LazyStorage::<crossbeam_epoch::collector::LocalHandle, ()>::get_or_init::<fn() -> crossbeam_epoch::collector::LocalHandle {crossbeam_epoch::default::HANDLE::__init}>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/native/lazy.rs:56:40: 56:61
     = note: inside closure at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/native/mod.rs:94:25: 94:54
     = note: inside `<{closure@crossbeam_epoch::default::HANDLE::{constant#0}::{closure#0}} as std::ops::FnOnce<(std::option::Option<&mut std::option::Option<crossbeam_epoch::collector::LocalHandle>>,)>>::call_once - shim` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
     = note: inside `std::thread::LocalKey::<crossbeam_epoch::collector::LocalHandle>::try_with::<{closure@crossbeam_epoch::default::with_handle<{closure@crossbeam_epoch::default::is_pinned::{closure#0}}, bool>::{closure#0}}, bool>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:282:37: 282:55
     = note: inside `crossbeam_epoch::default::with_handle::<{closure@crossbeam_epoch::default::is_pinned::{closure#0}}, bool>` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:59:5: 60:28
     = note: inside `crossbeam_epoch::default::is_pinned` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:46:5: 46:45
     = note: inside `crossbeam_deque::deque::Stealer::<rayon_core::job::JobRef>::steal` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-deque-0.8.5/src/deque.rs:641:12: 641:30
     = note: inside `rayon_core::registry::WorkerThread::take_local_job` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:751:19: 751:39
     = note: inside `rayon_core::registry::WorkerThread::wait_until_cold` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:785:32: 785:53
     = note: inside `rayon_core::registry::WorkerThread::wait_until::<rayon_core::latch::OnceLatch>` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:769:13: 769:40
     = note: inside `rayon_core::registry::WorkerThread::wait_until_out_of_work` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:818:9: 818:65
     = note: inside `rayon_core::registry::main_loop` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:923:5: 923:43
     = note: inside `rayon_core::registry::ThreadBuilder::run` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:53:18: 53:33
     = note: inside closure at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:98:20: 98:32
     = note: inside `std::sys::backtrace::__rust_begin_short_backtrace::<{closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:154:18: 154:21
     = note: inside closure at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:541:17: 541:71
     = note: inside `<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}> as std::ops::FnOnce<()>>::call_once` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:272:9: 272:19
     = note: inside `std::panicking::r#try::do_call::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}>, ()>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:557:40: 557:43
     = note: inside `std::panicking::r#try::<(), std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}>>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:520:19: 520:88
     = note: inside `std::panic::catch_unwind::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}>, ()>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:358:14: 358:33
     = note: inside closure at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:540:30: 542:16
     = note: inside `<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}} as std::ops::FnOnce<()>>::call_once - shim(vtable)` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
     = note: inside `<std::boxed::Box<dyn std::ops::FnOnce()> as std::ops::FnOnce<()>>::call_once` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1968:9: 1968:52
     = note: inside `<std::boxed::Box<std::boxed::Box<dyn std::ops::FnOnce()>> as std::ops::FnOnce<()>>::call_once` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1968:9: 1968:52
     = note: inside `std::sys::pal::unix::thread::Thread::new::thread_start` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/thread.rs:105:17: 105:64

error: Undefined Behavior: trying to retag from <115679> for SharedReadWrite permission at alloc54434[0x8], but that tag does not exist in the borrow stack for this location
   --> /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/internal.rs:549:9
    |
549 |         &*local_ptr
    |         ^^^^^^^^^^^
    |         |
    |         trying to retag from <115679> for SharedReadWrite permission at alloc54434[0x8], but that tag does not exist in the borrow stack for this location
    |         this error occurs as part of retag at alloc54434[0x0..0x180]
    |
    = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
    = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <115679> was created by a SharedReadWrite retag at offsets [0x0..0x8]
   --> /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/internal.rs:548:26
    |
548 |         let local_ptr = (entry as *const Entry).cast::<Self>();
    |                          ^^^^^
    = note: BACKTRACE (of the first span) on thread `unnamed-1`:
    = note: inside `<crossbeam_epoch::internal::Local as crossbeam_epoch::sync::list::IsElement<crossbeam_epoch::internal::Local>>::element_of` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/internal.rs:549:9: 549:20
    = note: inside `<crossbeam_epoch::sync::list::Iter<'_, crossbeam_epoch::internal::Local, crossbeam_epoch::internal::Local> as std::iter::Iterator>::next` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/sync/list.rs:290:37: 290:53
    = note: inside `crossbeam_epoch::internal::Global::try_advance` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/internal.rs:235:22: 235:45
    = note: inside `crossbeam_epoch::internal::Global::collect` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/internal.rs:200:28: 200:51
    = note: inside `crossbeam_epoch::internal::Local::pin` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/internal.rs:435:17: 435:46
    = note: inside `crossbeam_epoch::collector::LocalHandle::pin` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/collector.rs:81:18: 81:37
    = note: inside closure at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:40:26: 40:38
    = note: inside closure at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:60:23: 60:27
    = note: inside `std::thread::LocalKey::<crossbeam_epoch::collector::LocalHandle>::try_with::<{closure@crossbeam_epoch::default::with_handle<{closure@crossbeam_epoch::default::pin::{closure#0}}, crossbeam_epoch::guard::Guard>::{closure#0}}, crossbeam_epoch::guard::Guard>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:283:12: 283:27
    = note: inside `crossbeam_epoch::default::with_handle::<{closure@crossbeam_epoch::default::pin::{closure#0}}, crossbeam_epoch::guard::Guard>` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:59:5: 60:28
    = note: inside `crossbeam_epoch::default::pin` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-epoch-0.9.18/src/default.rs:40:5: 40:39
    = note: inside `crossbeam_deque::deque::Stealer::<rayon_core::job::JobRef>::steal` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-deque-0.8.5/src/deque.rs:645:22: 645:34
    = note: inside `rayon_core::registry::WorkerThread::take_local_job` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:751:19: 751:39
    = note: inside `rayon_core::registry::WorkerThread::wait_until_cold` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:785:32: 785:53
    = note: inside `rayon_core::registry::WorkerThread::wait_until::<rayon_core::latch::OnceLatch>` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:769:13: 769:40
    = note: inside `rayon_core::registry::WorkerThread::wait_until_out_of_work` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:818:9: 818:65
    = note: inside `rayon_core::registry::main_loop` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:923:5: 923:43
    = note: inside `rayon_core::registry::ThreadBuilder::run` at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:53:18: 53:33
    = note: inside closure at /home/seiji/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-core-1.12.1/src/registry.rs:98:20: 98:32
    = note: inside `std::sys::backtrace::__rust_begin_short_backtrace::<{closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:154:18: 154:21
    = note: inside closure at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:541:17: 541:71
    = note: inside `<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}> as std::ops::FnOnce<()>>::call_once` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:272:9: 272:19
    = note: inside `std::panicking::r#try::do_call::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}>, ()>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:557:40: 557:43
    = note: inside `std::panicking::r#try::<(), std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}>>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:520:19: 520:88
    = note: inside `std::panic::catch_unwind::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}::{closure#0}}>, ()>` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:358:14: 358:33
    = note: inside closure at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:540:30: 542:16
    = note: inside `<{closure@std::thread::Builder::spawn_unchecked_<'_, {closure@<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}}, ()>::{closure#1}} as std::ops::FnOnce<()>>::call_once - shim(vtable)` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
    = note: inside `<std::boxed::Box<dyn std::ops::FnOnce()> as std::ops::FnOnce<()>>::call_once` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1968:9: 1968:52
    = note: inside `<std::boxed::Box<std::boxed::Box<dyn std::ops::FnOnce()>> as std::ops::FnOnce<()>>::call_once` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1968:9: 1968:52
    = note: inside `std::sys::pal::unix::thread::Thread::new::thread_start` at /home/seiji/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/thread.rs:105:17: 105:64

error: aborting due to 1 previous error; 2 warnings emitted

The ptr2int issue has been resolved in master, and crossbeam-epoch is not compatible with SB, but only with TB (https://github.com/crossbeam-rs/crossbeam/issues/545). Could you tell us what error you get when you use -Zmiri-tree-borrows with the master branch of crossbeam?

I only have one small piece of unsafe in kmeans but I couldn't find any error with it.

The following two line:
https://github.com/seijikun/kmean-rs/blob/f8eab6f4cd12ac3cb54ae5b1ff76fa54472be87b/src/memory.rs#L83-L84

let aligned_ptr = alloc_zeroed(layout) as *mut T;
let resvec = Vec::from_raw_parts(aligned_ptr, size, size);

alloc_zeroed returns null pointer when allocation failed. Your code is unsound because it does not handle that case.

Awesome, thank you so much for the quick reply and help!
When I patch the dependency to master:
[patch.crates-io]
crossbeam = { git = "https://github.com/crossbeam-rs/crossbeam.git" }
crossbeam-epoch = { git = "https://github.com/crossbeam-rs/crossbeam.git" }

and run with MIRIFLAGS="-Zmiri-tree-borrows" cargo miri run
The miri complaints inside crossbeam go away.

alloc_zeroed returns null pointer when allocation failed. Your code is unsound because it does not handle that case.

Oh, thanks for the heads up! Will fix that.
With the crossbeam errors gone, I also saw that deallocation of the Vec doesn't work properly either, since it tries to dealloc with the wrong alignment :sweat_smile:


Change directory organisation to reflect upstream LLVM default sysroot path

Upstream LLVM introduced a default sysroot path when targeting bare metal (link). It follows this pattern:
DRIVER_PATH/lib/clang-runtimes/TARGET_TRIPLE
Currently we install newlib and compiler-rt to DRIVER_PATH/targets/TARGET_TRIPLE, and this is used as sysroot.
The proposal here is to align our sysroot with upstream LLVM. Hence, we'd install newlib and compiler-rt to the new default path for bare metal compilations. Consequently, occurrences of --sysroot in configuration files can be removed as the default can be used.

Fixed in #7


Support run as windows service.

sc create etcd binPath= "C:\etcd\etcd.exe -data-dir=C:\etcd\etcd.service.data"
net start etcd
net stop etcd
sc delete etcd

TODO: Need to add "code.google.com/p/winsvc/svc" to Godeps.

The new PR is here: https://github.com/coreos/etcd/pull/3410


DO NOT MERGE: Add context caching

Feature: Context Caching
Design doc (API) (internal): https://docs.google.com/document/d/1kJTdoz-RO7mkzsjE1QDfJfD1YvSxJXuzmqTAtsS1hJ0/edit?resourcekey=0-cv2C2J8SLDn__yoetTPvBw&tab=t.0
Design doc (Python SDK) (internal): https://docs.google.com/document/d/11en7rPCuXIu-hfF71jUDWkfQctWeFEoq_5KgkinnxWg/edit?resourcekey=0-ntvB0-Y_GBQXOfkO-KDaXg&tab=t.0
APIs added

GoogleAICacheManager class (exported from new /server path) with create, update, get, list, delete methods.
GoogleGenerativeAI.getGenerativeModelFromContextCache() added

Infrastructure changed

/files subpath changed to /server. GoogleAIFileManager and GoogleAICacheManager will be exported from here as they are only meant to be used in a server environment.
All types moved to a single folder.
Generate common/api-review md files for easier review of API mistakes/gaps
Refactor makeRequest-related functions to reduce code duplication

Fixes merged.
Documentation merged.


ddev 1.21.3/mutagen: file and directory permissions on host should match perms in container

Is there an existing issue for this?

[X] I have searched the existing issues

Run a Diagnostic and Paste Link Here
No response
Expected Behavior
Files and directories synced over mutagen should carry over their permission bits
Actual Behavior
Permissions are reset to only granting access to the owner, not for group/other
Steps To Reproduce
Running latest macOS 12.6, a globally enabled mutagen project on startup syncs all files and directories with 0600 / 0700.
If I create a directory inside ddev, it's running usuall permissions according to umask (0644 / 0755). On the host this is synced back as "0600/0700". Creating files on Host with 0644 is synced to ddev with 0600.
Anything else?
I am pretty sure, this worked in 1.12.1 before.
I run deployment scripts from within my ddev (using TYPO3 Surf). This uses rsync to sync a workspace directory. If I start the project where this workspace directory exists, all permissions are reset to 0600/0700, and deployed like this - on the server this leads to 403 errors because Apache does not deliver 0600/0700 files and dirs.
If I completely remove the workspace directory so that within ddev it is recreated from scratch, the permissions are alright. But of course the next time ddev is restarted, all permissions will be reset again. Also, they sync back to the host with wrong permissions.
Is this just a misconfiguration on my site? I definitely made deployments already with a ddev 1.21.1 and mutagen enabled, also with multiple restarts there. Was there some change I couldn't find?
Thanks!

I'm sorry. I need to be productive for work, so I had to switch back to NFS ASAP; sadly I don't have a second machine to test this with.
I'll try to do that on the weekends.
I'm using TYPO3.Surf, not Deployer. Surf ist aimed for having zero dependencies on the host. So composer, frontend building, npm/grunt and other tasks are all performed locally, packaged, and uploaded to the host (through rsync). We have a lot of hosts, where we cannot perform building locally, so deployer is not really an option and would make building/packaging also not reliable, as it currently is (or not, due to the issue, lol).
Before I go down to the reproduction steps, a quick question: It should be possible, to have the same umask between mutagen client and mutagen server, yes? Are you aware of a change in 1.21.1 to 1.12.3 that could affect this permission issue?
Best regards,
Garvin

A new version of mutagen is in v1.21.3.
Mutagen does not attempt to make permissions exact, the reasoning is in https://github.com/mutagen-io/mutagen/issues/282
But if you demonstrate your exact problem in a reproducible way that does not involve rsync or deployment scripts, I'll be happy to work with you on it. I'm sure you know that with rsync (outgoing) you can set flags to change the destination permissions.

Thank you. I know it's definitely up to me now to make this reproducible, I'll do my best to get this out soon.
I do know I could change rsync params (but thank you for pointing it out specifically), but we have many repositories using different configurations, and adding/patching different rsync into each repository would be a huge task. I'd rather find a solution with a mutagen option if possible.

Addendum. Thanks for referencing the issue, I should've read this before posting. It describes my setup already quite well.
So I'll have to read up on --default-file-mode and --default-directory-mode and how to specifically run this. For our development, filemode 0644 and directorymode 0755 would be all we need. Any permissions that DIFFER from this on our deployment scenario is addressed through scripts running on the host. But we can't easily "fix" thousands of files and dirs transfered as 0600/0700.
I suppose I could add those default-file-mode/directory parameters to my global user mutagen configuration? No time left today, but I'll check this out tomorrow, if I find a solution, I'd happily see to create a PR for addings this in the mutagen ddev documentation to help others who may face the same situation.

Really, you'll want to either set rsync up with explicit perms or have a chmod and chown on your deployment anyway, because your deployment should never be dependent on the source-side ownership and permissions.
Regardless of that, I'm interested in seeing how this affects a ddev project in your case.

Can you tell me, is there a global mutagen configuration that ddev uses (so: not per-project in .ddev/mutagen/mutagen.yml) but rather ~/.mutagen.yml? The mutagen docs mention said file, but I wonder because ddev ships its own mutagen, is that still the right location? Or does it need to be a file like in ~/.ddev/mutagen.yml?
If I set:
sync:
  defaults:
    permissions:
      defaultFileMode: 0644
      defaultDirectoryMode: 0700

I would be good.
(For now I'm just looking for a quick "get it running again", an adaptation of our deployment scripts to either use rsync params, or locally "fix" permissions is a bigger issue I'd rather not like to hot-tackle like my personal mutagen setup but needs more thorough team planning)

There is no global mutagen configuration. It would be nice if there were two levels of config for mutagen, but there aren't.
DDEV sets the mutagen config to be .ddev/mutagen/mutagen.yml.
You can certainly make the change you suggest in .ddev/mutagen/mutagen.yml (and remove the #ddev-generated from the file so it doesn't get overwritten).
But you'll want defaultDirectoryMode: 0755 I imagine.
Again... you don't really want source-side permissions to be how you control deployment-side-permissions.
Also again, I'm interested in the actual problem, if described from a ddev-project point of view.

Here's a longer writeup for my reasoning and reproducible situation. I'm being verbose to properly document this - not to waste anybody's time. I totally appreciate your time and effort, and this is my effort to give back to it, not to force a bookstack onto you. ;)
By writing this, I think I found a workable way for me, so this journey was great at least for me.
TL;DR
I'll need to create a per-project add_mutagen.sh for me, to specify the needed mutagen options for defaultFileMode/defaultDirectoryMode.
It would help me, if ddev would allow to specify a global mutagen file that would be concatenated with the ddev-generated one, if that ever is an option. I have zero knowledge in Go, but if you point me to a place in the ddev source, and how to build a customized ddev, I would try to provide a PR (more on this at the bottom of this comment).
My ddev environment
As requested, a gist of my environment. I created a test repository here:
https://github.com/garvinhicking/ddev_deploy_mutagen
The ddev debug test output is there: https://github.com/garvinhicking/ddev_deploy_mutagen/blob/main/ddev-debug.txt
The setup
Our goal is to change our project deployment from "per developer" to a central one. But we have some challenges to solve before we get there. So we have to deal with a non-ideal intermediate way.
For now, our setup is that each of our developers can check out a ddev project from git (we also have virtualbox+vagrant ones as legacy projects, which we usually convert to ddev whenever there's a deployment to perform). With very few steps, a repository can be setup so that each developer can perform the deployment:
ddev start
ddev exec "cd deployment && composer install && ./vendor/bin/surf deploy Production.Production"

The deployment
What TYPO3 Surf (https://github.com/TYPO3/Surf) actually does is:

It creates a "working space" (directory in ./deployment/workspace), per target (i.e. one for Production, Staging, Development)
It checks out a specified GIT branch into this directory tree (using a git working directory)
It executes specified tasks: composer installation, frontend build (via npm/gulp), ...
The resulting directory is then pushed via rsync to a target machine inside a temporary working directory, and can also exclude certain things (i.e. node_modules)
On the server, Surf can execute defined tasks via SSH (i.e. typo3cms console for DB migrations, adding custom htaccess rules, downloading translation files, etc.). In the end, the working directory is then copied over to the final release directory structure.

The upside of this (compared to deployer) is:

Near zero-dependencies on target host (only ssh/rsync)
"Secure code is no code" - the target host will not contain possible build-related details, so if it gets hacked, "key build ingredients" can still be secure
No git/credentials to the infrastructure are needed on the target host (i.e. private packagist keys, fontawesome serials, other code that only needs to exist in a compiled state on the target)
Each developer can locally develop and "push" his project

The downside of course is, that the target and development environments need to match up (same PHP versions).
In the future, a central build server would do the same a developer currently does locally, but on a controlled single server instance (which might even be running ddev for easier migration of our current projects).
The problem
As you already mentioned, a problem is that since the build is created within the ddev environment (which is matched up with our target environment) and transferred via rsync, it pushes the current permissions of the ddev working space.
TYPO3 Surf uses rsync -avz for this for years:
https://github.com/TYPO3/Surf/blob/master/src/Task/RsyncFoldersTask.php#L73
So there's no way to "inject" custom rsync options like --chmod or --perms at this point. We'd have to create our own transport agent, which would mean to adapt possibly 100 repositories we currently use, all with different TYPO3 Surf and PHP versions and dependencies, so that would be a huge pain.
We could add a "post-rsync" hook and execute chown on files and directories after the fact, but again: We would need to adapt a hundred deployment configurations to add that hook.
So the bottom line is, it's not practical for us to fix this issue of permissions as it stands, but we need to satisfy the current condition, where the final local build needs to have the same 0644/0755 permissions as we need on the server side, plus maybe even 0600/0700 permissions for specific directories/files.
Reproducing the problem
Now to describe what happens with mutagen, even though it's clear already with the issue you referenced.

Spin up the mutagen project: ddev start
Create test file: ddev exec "cd deployment && touch file-created-in-ddev && ls -la file-created-in-ddev"
Result: -rw-r--r-- 1 garvin dialout 0 Oct 25 09:10 file-created-in-ddev
Locally create a test file: touch deployment/file-created-on-host && ls -la deployment/file-created-on-host
Result: -rw-r--r--  1 garvin  staff  0 Oct 25 11:11 deployment/file-created-on-host
See the ddev-file on host: ls -la deployment/file-created-in-ddev
Result: -rw-------  1 garvin  staff  0 Oct 25 11:10 deployment/file-created-in-ddev
See the local test file on ddev: ddev exec "ls -la deployment/file-created-on-host"
Result: -rw------- 1 garvin dialout 0 Oct 25 09:11 deployment/file-created-on-host

So as you can see, files created within ddev get the 0644/0755 perms. That would be great, and expected.
The files on the host though are transferred back as 0600/0700. I could live with that at this point, the host is of no concern to me.
However, inside the workspace directory, where Surf builds the files (this is not committed to GIT), it happens for me that after a ddev poweroff and maybe a reboot, that when I re-enter ddev, all the dirs/files in there have been changed to 0600/0700 permissions.
I couldn't reproduce this with the touched files above, maybe the files need to have content for mutagen to pick up synching and thus adjusting permissions.
The solution
So, this problem with ddev and mutagen is a problem of "my own". Other developers use older ddev builds, or run Windows/WSL, and seem not be be affected by those permission problems.
That means, I need to find a solution to allow myself working with a ddev based project, without affecting others.
Changing the deployment pipeline would both be a lot of work for all projects I'm involved in, and also may affect the others.
First I wanted to fall back to NFS, but then I remembered that sadly on MaCOS a running nfsd means, powersaving of a macbook cannot be used.
My solution would cover:

I want to use mutagen
The project itself must NOT have mutagen enabled in its GIT configuration (not affect other developers)
I want to add a non-default DDEV setting for the defaultFileMode / defaultDirectoryMode options (to not affect ddev users that are happy with current setup, which may be the more sensible default)
Ideally I would want that for EVERY of our ddev projects, without needing to touch every project

Since there is no central ~/.mutagen.yaml configuration that ddev uses (because the daemon runs per-ddev-project, as I understand), all of the above can currently not be reached (for now).
Solution: Step 1
First, I need to make sure that mutagen is globally disabled, to not interfer (by creating a mutagen-config that is not of my own making).
Then I created a simple bash script ~/add_mutagen.sh which enables mutagen per-project:
https://github.com/garvinhicking/ddev_deploy_mutagen/blob/main/add_mutagen.sh
I can call that script within each project once. The created files (.ddev/config.mutagen.yml, .ddev/mutagen/mutagen.yml) are in the .gitignore file, so they won't affect my co-developers. (Thinking about this, maybe only the config.mutagen.yml should be excluded?).
Solution: Improving ddev?
To make this whole process easier, it would be awesome if ddev could allow to manage a central file that is merged with per-project mutagen creation. That would allow me to NOT maintain a customized mutagen configuration (per project), and benefit from future upstream patches to mutagen.yml which I would otherwise probably not even notice (because the file will no longer be ddev-maintained).
When ddev initializes its default .ddev/mutagen/mutagen.yml file, maybe it could look within ~/.ddev/global_mutagen.yml and just prepend these settings to the autogenerated file?
Then you could always overwrite global settings still with per-project settings again. Maybe even also add a possible .ddev/global_mutagen_post.yml file, which gets appended to the file, to ensure a way a global settings can always be global and never overwritten per-project.
Both options would make sense to me, but I would understand if you do not want the maintenance overhead of this in the official ddev distro. If you're open to this, I'd be happy to try making a PR for ddev and try to understand the coding of ddev. Happy for any pointers of course, but I figure it shouldn't be too hard to make a lookup for two files and prepend/append them into an autogenerated file?
The End.

Are you running surf inside the web container or on the host?
I do find this problem with mutagen annoying, and think we should reopen the discussion with the maintainer of mutagen.
However, can you not set permissions before you run your surf deployment?

Also, you're not willing to set permissions in .ddev/mutagen/mutagen.yml? Or that doesn't solve the problem?

I recommend that you enable mutagen globally (ddev config global --mutagen-enabled) rather than have a config.mutagen.yaml. BTW, you have config.mutagen.yml, if that works I'm surprised, as I think ddev just looks for config.*.yaml.
Using global config for mutagen means that there will be nothing about it in your local config.

I run surf inside the web container, not on the host. The host does not have the dependencies and PHP version as the web container, but that is required.
I can not set permissions before I run deployment, but that would mean changing the deployment recipe for 100 deployments, which would also affect my colleagues, which is a goalpoast I don't want to move.
In my lengthy eassy I did address that I cannot globally enable mutagen, because I need that directoryMode specifically set to 0644/0755, and I cannot do that globally from what I understand (you wrote "There is no global mutagen configuration."). So I'd need a per-project mutagen configuration.
If ddev would allow to have a global mutagen configuration that is applied, that would solve things for me of course.
(I tried it with config.mutagen.yml and not config.mutagen.yaml and it worked, yeah - I just verified that a second time)

Regarding this comment, I'm happy to re-open the discussion on additional permission propagation/preservation modes in Mutagen, but I'm not sure what the ask would be here.  It seems like the desire in this case is more about setting the default permission settings that exist, but if there's a specific behavior or configuration option that would help here, please let me know.
I'll open a new permissions propagation/preservation issue in any case, but is the specific proposal here just fully raw POSIX ownership/permission propagation?  UID/GIDs and perm/sticky/setuid/setgid bits?  Some subset of those?

Just raw POSIX permissions would be all I'd ask for. Ownership is too hard. sticky/setuid should never be used IMO. So just ugo/rwx

Gotcha.  I'll go ahead and open up an initial proposal in the next day or two for what this should look like, trying to summarize the use cases and reference the prior discussion issues.

Awesome, thank you. And just to add, yes - propagating ugo permissions is all I'd need, and would make my whole trip of adjusting the default permissions via mutagen configuration obsolete. Given that a possibly new permission option will be the ddev default ;-)

@rfay Thanks. Yes, I actually use that for adjusting SSH key permissions.
I had to run a few tests before I got back here. Turns out my solution had a larger caveat that I recognized thanks to your message.
On a mutagen reset, of course all individual permissions within the container are reset. That includes things like id_rsa keys (which we copy from a NAS to our boxes for the deployment) or directories that TYPO3 sets to 0700 for internal usage. Also I was told a couple of tools and scripts we use actually set restricted permissions on files/dirs, and check those, and fail if permissions are not met.
Of course I could start to inventorize all possible special permission on special files and directories, and create a "fixup" script that I run time and again. But some of our projects contain a few tenthousand files, and doing that on every refresh feels pretty redundant.
I see that syncing the 'execute' permission bit carries over properly and "survive" a mutagen reset, so I assume some kind of check is in place. I see this touches the mutagen side of things and ddev can't do too much about it, but it would be oh-so-helpful if the raw ugo-Permissions could just be propagated from A<>B

Just a sidenote on your SSH keys. DDEV has ddev auth ssh, which is intended to be usable without ever copying keys into the container. You probably know that, but I wanted to make sure.

(Thanks; actually we tried this when starting with ddev some time ago but faced some issues I can't remember; I think it was because we used company-global SSH keys that users should not operate with in their usual accounts, so our developers didnt have that key in our keychain, but only for the containers. Also we use a script that actually creates per-container unique deployment SSH keys through ssh-keygen, which we don't sync back to our host because it's not needed there)

I'm going to close this for now, but hopefully future improvements in mutagen will allow more options here. Thanks! I imagine you have everything sorted out now, if not, happy to continue the conversation.

@rfay Thank you. Yeah I got that cumbersome script working.
I also opened an issue with the mutagen project.
However, I still remain curious if ddev couldn't provide the ability to globally specify mutagen options. Would you be open for a more isolated/brief issue request to track that feature?
If I could just have a central yaml file that gets merged with each mutagen configuration of each ddev docker instance, it would make my hackish way of applying it per-project obselte.
Best regards,
Garvin

@garvinhicking I have talked with @xenoscopic about an option for a ddev-global mutagen config, and it turns out that

It would already be possible for DDEV to use the ~/.mutagen.yml global file... except that DDEV explicitly creates sync sessions with --no-global-configuration. I don't think I'll change that, because we don't want global mutagen config intended for other things to accidentally interfere with ddev usage.
@xenoscopic and I did talk about another option for config, and he implied he might be able to slip in multiple config files (allowing a DDEV global mutagen.yml) in a coming release. It might help for you to open an issue in the mutagen queue for that, even though it's on his (informal) radar.

Yay, that looks exactly like what could help me, something like a ~/.mutagen-ddev.yml. Fingers crossed, I'll create the issue and hope to not come across spammy. Thanks once again for your great help.


fps drops

I usually get around 200 fps but when i inject osiris my fps drop to around 100 and game lags randomly. Any fix?

diable post processing and compile ur code as avx2 code gen. lemme know how it goes

diable post processing and compile ur code as avx2 code gen. lemme know how it goes

What is avx2?

diable post processing and compile ur code as avx2 code gen. lemme know how it goes

What is avx2?
AVX2 is yet another extension to the venerable x86 line of processors, doubling the width of its SIMD vector registers to 256 bits, and adding dozens of new instructions.

Project Property Pages | Configuration Properties | C/C++ | Code Generation | Enable Enhanced Instruction Set

diable post processing and compile ur code as avx2 code gen. lemme know how it goes

compiled my code using avx2 and fps drops reduced to 120 from 200 . improvement of 20 fps and fps drops still come randomly meaning that fps drops to 30 or 20 for a second or 2 seeming as if the game has freezed .

I also noticed that my cpu utilization of cs go after injecting osiris increases to 40 percent from 20 percent

nice pc usell?

nice pc usell?

huh?

please research online whether your processor supports avx2 @MasterChief220

please research online whether your processor supports avx2 @MasterChief220

no it doesnt but how can i fix that.

if ur pc doesnt support avx2 then dont compile it  using avx2. The default is SSE2. Just use that and you'll be gucci

Id you need add me on discord uzdiiilekk_#3312 i send you my upgraded osiris with fps drop fix


Non-superuser setup problems

I have a PostgreSQL setup that serves multiple webs and other hobby projects. I’d like to use it for promscale as well, without running an extra PostgreSQL instance. Unfortunately, it seems that promscale assumes superuser privileges way too often. It also appears to assume unrestricted access to the whole cluster (instead of being constrainted to a specific database).
It requires the CREATEROLE privilege (at least for initialization)
promscale[2505103]: level=error ts=2021-04-04T05:55:52.831Z caller=runner.go:43 msg="aborting startup due to error" err="migration error: Error while trying to migrate DB: Error encountered during migration: error executing migration script: name preinstall/001-users.sql, err ERROR: permission denied to create role (SQLSTATE 42501)"

So I gave it the CREATEROLE privilege. It apparently insisted on creating prom_reader and prom_writer. No problem with that, in general, but such initialization might be better suited for a separate tool or script rather than for the main “production” binary startup.
Also, it didn’t give the new roles (prom_{reader,writer}) any permissions on the database it was logging into (db_promscale) or any membership in the login role (pguser_promscale). Not sure how that’s supposed to work then. :question:
It could not execute CREATE EXTENSION for some reason
The documentation says one should not create the extension manually. The extension was installed, configured in postgresql.conf and loaded. Nonetheless, I had to manually call CREATE EXTENSION IF NOT EXSISTS promscale;, because otherwise I was getting this:
promscale[2505119]: level=warn ts=2021-04-04T05:55:58.142Z caller=extension.go:58 msg="could not install promscale: ERROR: permission denied to create extension \"promscale\" (SQLSTATE 42501). continuing without extension"

The role pguser_promscale (the login role) has CREATE permissions on db_promscale (the database for promscale to use), so it should be able to create extensions.
(Or does one need to mark extensions trusted somehow somewhere? This is mentioned in the docs, but it’s unclear to me what exactly needs to be done.)
Also, should one give the new roles, prom_reader and prom_writer, membership in the default role (pguser_promscale in my case)? Or vice versa?

cc @cevian

We'll put these issue on the plan for 0.4.0

Fix started in #587

Last PR resolving this should be #616 it will be included in the next release

Thanks a lot for working on this. Is there any documentation on how to migrate from the old setup (the one with two roles that required a bit of manual tweaking) to the new setup? I assume I’ll need to give Promscale (temporarily) some extra CREATEROLE permissions so that it can update its configuration.
Also, #616 and related changes (still) seem to be using hardcoded database role names (e.g. prom_admin). This is rather inflexible on a PostgreSQL instance that serves tens of non-Promscale databases and uses a set of role naming conventions to make management easier. Something like a role_name_prefix parameter would be very helpful in this regard.
A fully fledged non-superuser setup should (also) make it possible to run multiple Promscale instances on one and the same PostgreSQL instance. This would be rather cumbersome with hardcoded role names. It may be feasible by manually grant the prom_.* roles permissions on multiple Promscale databases, but one could definitely achieve better isolation among PostgreSQL users (Promscale or other) by using distinct roles.

@andrejpodzimek All the role migration stuff should happen automatically when you upgrade Promscale and migrate the schema.
Hmm the role name prefix idea is an interesting one and I do see why it may be useful. It also doesn't quite seem straightforward to implement since we'd have to have protections against people accidentally trying to use different prefixes on different promscale instances, across migrations etc. Let me think about this.

Let's do the role prefix in a separate issue. Feel free to open a new issue for discussion of that feature request.


make bors a bit better

bors try

it should be able to live in .github

borst try

bors try

bors try

bors try-


Database Object search with wildcards broken

Using ctrl-shift-d to search objects returns no results while using the * wildcard character. Currently only way it works is if I write the prefix, wait for the list to load, then further characters inserted will perform a fuzzy search on the loaded results.
Using 5.2.2, this worked fine in 5.2.1.

A gif to better explain myself:

Thanks for the bug report (and reminder)


2.5.1 release

Fixed the design.js file !!!   Add enyo.scrim
ENYO-4133   :)
Enyo-DCO-1.1 Signed-off-by: Signed-off-by<EMAIL_ADDRESS>

Ok fixed

Thank you for the pull request


Added missing flag for enabling bitcode

Just in case, I can confirm that "BITCODE_GENERATION_MODE=bitcode" is a necessary change in our project. Without it "archive" action failed trying to link some app code (apparently bitcode enabled, verified it through the logs) with the framework generated by this plugin.

can we merge this and release? I'm available to help if needed because I use this in my project ☺ @X140Yu

'OTHER_CFLAGS="-fembed-bitcode"' is removed in commit 30cbf7f1


pod lib lint error when  flutter product into existing iOS project

Export flutter compilation product, integrated into existing iOS project in the form of private pod, error when doing pod lib lint SYDFlutterSDK.podspec --allow-warnings --verbose

Undefined symbols for architecture x86_64:
"OBJC_CLASS$_FlutterIosPlugin", referenced from:
objc-class-ref in GeneratedPluginRegistrant.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
** BUILD FAILED **

Hi, sorry for the delay, I just want to check if you could solve this problem.

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


A11y improvements

announcer
modal

Codecov Report

Merging #233 (341a014) into main (d3a2aab) will decrease coverage by 0.43%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##             main     #233      +/-   ##
==========================================
- Coverage   62.29%   61.86%   -0.44%
==========================================
  Files         109      108       -1
  Lines        1074     1075       +1
  Branches      189      193       +4
==========================================
- Hits          669      665       -4
- Misses        394      399       +5
  Partials       11       11

Impacted Files
Coverage Δ

src/components/app/Layout/Layout.tsx
0.00% <0.00%> (ø)

src/components/app/Navigation/Navigation.tsx
100.00% <ø> (ø)

src/components/app/Skyscraper/Skyscraper.tsx
100.00% <ø> (ø)

...c/components/app/TutorialButton/TutorialButton.tsx
0.00% <0.00%> (ø)

src/pages/index.tsx
0.00% <ø> (ø)

src/pages/livers.tsx
0.00% <ø> (ø)

src/pages/livers/[id].tsx
0.00% <ø> (ø)

src/pages/tags.tsx
0.00% <ø> (ø)

src/pages/user.tsx
0.00% <ø> (ø)

src/components/ui/Slide/Slide.tsx
90.90% <83.33%> (-3.54%)
:arrow_down:

... and 4 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 d3a2aab...341a014. Read the comment docs.

Codecov Report

Merging #233 (341a014) into main (d3a2aab) will decrease coverage by 0.43%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##             main     #233      +/-   ##
==========================================
- Coverage   62.29%   61.86%   -0.44%
==========================================
  Files         109      108       -1
  Lines        1074     1075       +1
  Branches      189      193       +4
==========================================
- Hits          669      665       -4
- Misses        394      399       +5
  Partials       11       11

Impacted Files
Coverage Δ

src/components/app/Layout/Layout.tsx
0.00% <0.00%> (ø)

src/components/app/Navigation/Navigation.tsx
100.00% <ø> (ø)

src/components/app/Skyscraper/Skyscraper.tsx
100.00% <ø> (ø)

...c/components/app/TutorialButton/TutorialButton.tsx
0.00% <0.00%> (ø)

src/pages/index.tsx
0.00% <ø> (ø)

src/pages/livers.tsx
0.00% <ø> (ø)

src/pages/livers/[id].tsx
0.00% <ø> (ø)

src/pages/tags.tsx
0.00% <ø> (ø)

src/pages/user.tsx
0.00% <ø> (ø)

src/components/ui/Slide/Slide.tsx
90.90% <83.33%> (-3.54%)
:arrow_down:

... and 4 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 d3a2aab...341a014. Read the comment docs.


card login design

Codecov Report

Merging #5 (64bdd4d) into master (d5375ee) will decrease coverage by 64.75%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master      #5       +/-   ##
============================================
- Coverage     68.75%   4.00%   -64.75%
  Complexity       95      95
============================================
  Files            35      12       -23
  Lines           624     300      -324
  Branches         30       0       -30
============================================
- Hits            429      12      -417
- Misses          175     288      +113
+ Partials         20       0       -20

Flag
Coverage Δ
Complexity Δ

back-functional
?
?

back-unit
4.00% <ø> (ø)
95.00 <ø> (ø)

backend
4.00% <ø> (-83.33%)
95.00 <ø> (ø)

front-e2e
?
?

front-unit
?
?

frontend
?
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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