Exporting Saves to Text

I tried using the tool to export my save file to .txt, but it seems to just save the .sl2 file as a text file so it's unreadable.
Is there a way to export the save file's information to serialized text, like JSON or YAML?
I'm trying to put together an auto-tracker for game progress using git, where each time the game is saved, I check for what's changed and create a commit with those notes, adding tags when something big happens, like a boss kill. I have everything else, I just can't tell what's changed from one save to the next in the .sl2 file.
If you happen to have an easy way of generating that export with this tool... I'd love to know how!
If not, but you have somewhere I can go next to find info on reading the binary save file format, I'll happily go figure it out for myself. I just haven't found any resources like that online recently.

I believe you want to serialize the save state so that it is no longer in the binary representation.
I was able to do this for my website by applying serde to many structs in the code. You can read more about that on #34
After doing that, you can export the save state as json (I do this internally on my website, feel free to copy the code)

I know it's probably alot to explain but what's the process of doing that,
I tried messing with the visual code thing from Microsoft and got lost and
gave up, any clearer way to do it, I'm new to coding
On Tue, Jul 16, 2024, 1:36 PM Ethan Shumate @.***>
wrote:

I believe you want to serialize the save state so that it is no longer in
the binary representation.
I was able to do this for my website by applying serde to many structs in
the code. You can read more about that on #34
https://github.com/ClayAmore/ER-Save-Editor/issues/34
After doing that, you can export the save state as json (I do this
internally on my website, feel free to copy the code)
—
Reply to this email directly, view it on GitHub
https://github.com/ClayAmore/ER-Save-Editor/issues/59#issuecomment-2231464777,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJ2VSELFHCG5LHOXMOKIXPLZMVK23AVCNFSM6AAAAABKRVJXIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZRGQ3DINZXG4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

What language are you using? Or would a cli tool meet your needs?

English
On Tue, Jul 16, 2024, 3:36 PM Ethan Shumate @.***>
wrote:

What language are you using? Or would a cli tool meet your needs?
—
Reply to this email directly, view it on GitHub
https://github.com/ClayAmore/ER-Save-Editor/issues/59#issuecomment-2231694396,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJ2VSEMUMFXWJLTUPERMMGTZMVY35AVCNFSM6AAAAABKRVJXIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZRGY4TIMZZGY
.
You are receiving this because you commented.Message ID:
@.***>

Ensi without the + whatever
On Tue, Jul 16, 2024, 3:43 PM Troid Patch Jr. @.***>
wrote:

English
On Tue, Jul 16, 2024, 3:36 PM Ethan Shumate @.***>
wrote:

What language are you using? Or would a cli tool meet your needs?
—
Reply to this email directly, view it on GitHub
https://github.com/ClayAmore/ER-Save-Editor/issues/59#issuecomment-2231694396,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJ2VSEMUMFXWJLTUPERMMGTZMVY35AVCNFSM6AAAAABKRVJXIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZRGY4TIMZZGY
.
You are receiving this because you commented.Message ID:
@.***>

@twp2000 what programming language 😂. I can compile you a library to convert save state to json. Just want to know how you would use it.
It could be a cli tool you call with bash or PowerShell.
Could be a python lib
Npm library... Etc

Hey, if I could get it as a CLI tool, that would be FANTASTIC. I'm a huge Powershell guy, a CLI tool would be the holy grail for my plans.

elden-ring-save-parser-cli.zip
Here is the code I used to make the executable: https://github.com/EthanShoeDev/elden-ring-compass/tree/cli-tool/packages/elden-ring-save-parser-cli
@Charles-Stuart

How do I do this?
On Wed, Jul 17, 2024, 12:33 PM Ethan Shumate @.***>
wrote:

image.png (view on web)
https://github.com/user-attachments/assets/6375539d-2c8b-4ffb-a42f-ed88373d3bd8
elden-ring-save-parser-cli.zip
https://github.com/user-attachments/files/16270429/elden-ring-save-parser-cli.zip
Here is the code I used to make the executable:
https://github.com/EthanShoeDev/elden-ring-compass/tree/cli-tool/packages/elden-ring-save-parser-cli
@Charles-Stuart https://github.com/Charles-Stuart
—
Reply to this email directly, view it on GitHub
https://github.com/ClayAmore/ER-Save-Editor/issues/59#issuecomment-2233728183,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJ2VSEOCMKLXEBSHD6JONCDZM2MGNAVCNFSM6AAAAABKRVJXIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZTG4ZDQMJYGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

Download the zip, extract the exe.
Open PowerShell in same folder as exe.
Run the command:
'elden-ring-save-parser-cli.exe --save-file {PATH_TO_SAVE_FILE}'
Then there will be a new file called 'output.json'
You can look at the screenshot I attached as an example

I must've did something wrong because it's not working for me I'm new to
coding
On Wed, Jul 17, 2024, 2:34 PM Ethan Shumate @.***>
wrote:

Download the zip, extract the exe.
Open PowerShell in same folder as exe.
Run the command:
'elden-ring-save-parser-cli.exe --save-file {PATH_TO_SAVE_FILE}'
Then there will be a new file called 'output.json'
You can look at the screenshot I attached as an example
—
Reply to this email directly, view it on GitHub
https://github.com/ClayAmore/ER-Save-Editor/issues/59#issuecomment-2233993070,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJ2VSEPULYX23RBDOXLTDY3ZM22LNAVCNFSM6AAAAABKRVJXIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZTHE4TGMBXGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Download the zip, extract the exe. Open PowerShell in same folder as exe.
Run the command: 'elden-ring-save-parser-cli.exe --save-file {PATH_TO_SAVE_FILE}'
Then there will be a new file called 'output.json'
You can look at the screenshot I attached as an example

Thank you!  I'll try this as soon as I'm home tonight

Could be something wrong with the cli, let me know when you give it a real shot. You can also try to upload it to my website here: www.eldenringcompasss.com.
If my website can't parse your save, neither will the cli. You can also send me your save and I will be sure it can work.

@EthanShoeDev , sorry for the delay. My flight got caught up in yesterday's nightmare outage. Thank you so much, the CLI seems to be working. I'll look in more depth soon to see if I can find a table or something to help convert the ID values to item names.

It definitely picked up on my save's current level! Again thank you!

@EthanShoeDev This cli looks great. However, inside the output.json, there are some entries that are not easily interpretable. For example, what are those hexadecimal numbers "_0x290" and "gaitem_handle"?

@SongTonyLi I somewhat lazily converted the raw save to json. Essentially the author of this repo made structs that match up perfectly with save offset.
Save is a file of contiguous memory.
ClayAmore wrote a lot of rust structs such as:
struct SaveHeader {
  someRandomThing: 4 bytes
  playerName: x bytes
}

This is a gross simplification but I think it gets the point across. Some properties in the struct are helpful, others are completely unknown.
The json cli that I made just json serializes the structs without much thought. This includes some useful properties (like playerLevel) and some unknown regions of the save.
Obviously, this could be cleaned up a lot but the og poster wanted to track the save with git. I figured that even if the json is a mess, they could still get some value by viewing the diffs.
There is a section in the save file that stores all inventory gaHandles (whatever that is) and another region of the save that has all the persistent event flags. If you actually want to read that data usefully, you need a map from Item names to item gaHandle and a map from event name to event flag offset.
The code that does this exists within this repo in the vm folder. I did not include that in the cli.
I have also rewritten all the vm (view models) in typescript for my website. I couldn't think of a way to easily embed my typescript view models in the cli unless the og installed bun or nodejs.
If I were better at rust, I could just rewrite the vms in this repo to work in a cli mode but I have not done that :)

I mean if it were something we could hook into (like a REST API), then that would be fantastic! Like, for example, if we could PUT with the .sl2 file's contents and have it respond with the JSON text, then we'd have a pretty solid way of building on this in the future. That being said, something like that would put more strain on you if you got too much traffic to your site...

hey @EthanShoeDev, I am looking for help parsing a save file using savewizard.net, when opening this file it simply crashes. The logs say the following error
thread 'main' panicked at src/save/common/user_data_11.rs:31:9:
assertion failed: user_data_11.rest[0] == 0 || user_data_11.rest[0] == 151 ||
    user_data_11.rest[0] == 27

system: macos
rust version: 1.78.0
full log running RUST_BACKTRACE=full cargo r 👇
thread 'main' panicked at src/save/common/user_data_11.rs:31:9:
assertion failed: user_data_11.rest[0] == 0 || user_data_11.rest[0] == 151 ||
    user_data_11.rest[0] == 27
stack backtrace:
   0:        0x1053cca10 - std::backtrace_rs::backtrace::libunwind::trace::h6de1cbf3f672a4f8
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/../../backtrace/src/backtrace/libunwind.rs:105:5
   1:        0x1053cca10 - std::backtrace_rs::backtrace::trace_unsynchronized::hd0de2d5ef13b6f4d
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x1053cca10 - std::sys_common::backtrace::_print_fmt::h2a33510d9b3bb866
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:68:5
   3:        0x1053cca10 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h01b2beffade888b2
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:44:22
   4:        0x1053e8f9c - core::fmt::rt::Argument::fmt::h5ddc0f22b2928899
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/fmt/rt.rs:142:9
   5:        0x1053e8f9c - core::fmt::write::hbadb443a71b75f23
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/fmt/mod.rs:1153:17
   6:        0x1053ca724 - std::io::Write::write_fmt::hc09d7755e3ead5f0
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/io/mod.rs:1843:15
   7:        0x1053cc868 - std::sys_common::backtrace::_print::h3cd1786cbb1caf0f
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:47:5
   8:        0x1053cc868 - std::sys_common::backtrace::print::h28349e5c25acbac7
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:34:9
   9:        0x1053cdd7c - std::panicking::default_hook::{{closure}}::hd24b6196784d991e
  10:        0x1053cda60 - std::panicking::default_hook::hfcec80a2720c8c73
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:292:9
  11:        0x1053ce670 - std::panicking::rust_panic_with_hook::h84760468187ddc85
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:779:13
  12:        0x1053ce030 - std::panicking::begin_panic_handler::{{closure}}::he666a5eb600a7203
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:649:13
  13:        0x1053cce94 - std::sys_common::backtrace::__rust_end_short_backtrace::h592f44d2bf9f843f
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:171:18
  14:        0x1053cddd4 - rust_begin_unwind
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:645:5
  15:        0x105420af8 - core::panicking::panic_fmt::h98bbf7bdf4994454
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panicking.rs:72:14
  16:        0x105420b80 - core::panicking::panic::hc59c8a709a9b37ae
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panicking.rs:145:5
  17:        0x104921674 - <er_save_editor::save::common::user_data_11::UserData11 as er_save_editor::read::read::Read>::read::hbe71434c77e87c79
                               at er-dlc-save-editor/src/save/common/user_data_11.rs:31:9
  18:        0x104b11c80 - <er_save_editor::save::playstation::ps_save::PSSave as er_save_editor::read::read::Read>::read::h620cd67910822666
                               at er-dlc-save-editor/src/save/playstation/ps_save.rs:34:29
  19:        0x104b1b38c - <er_save_editor::save::save::save::Save as er_save_editor::read::read::Read>::read::hc4a6390bcc9297e8
                               at er-dlc-save-editor/src/save/save.rs:779:56
  20:        0x104b1b81c - er_save_editor::save::save::save::Save::from_contents::h22ea09d1b0a9d3af
                               at er-dlc-save-editor/src/save/save.rs:809:13
  21:        0x104b1b8a8 - er_save_editor::save::save::save::Save::from_path::h3fd9e13bb5bc0530
                               at er-dlc-save-editor/src/save/save.rs:814:13
  22:        0x104b36eb8 - er_save_editor::App::open::hd07d3a8c44ff1453
                               at er-dlc-save-editor/src/main.rs:80:21
  23:        0x10494eaa8 - <er_save_editor::App as eframe::epi::App>::update::{{closure}}::{{closure}}::{{closure}}::h5a2062e22634af7e
                               at er-dlc-save-editor/src/main.rs:127:43
  24:        0x104b627a0 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hb094262ac93a007b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
  25:        0x10520b0b4 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h598133341d38b247
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/boxed.rs:2020:9
  26:        0x105240e8c - egui::ui::Ui::with_layout_dyn::heb5f5b1c51007126
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/ui.rs:2020:21
  27:        0x1049af9a0 - egui::ui::Ui::with_layout::hb74910119eb355df
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/ui.rs:2011:9
  28:        0x10494e6d8 - <er_save_editor::App as eframe::epi::App>::update::{{closure}}::{{closure}}::ha0a790d770ad3cae
                               at er-dlc-save-editor/src/main.rs:123:17
  29:        0x104b61204 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h393d80366d45a598
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
  30:        0x104ae39ac - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hd5ca5166b5a14537
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/boxed.rs:2020:9
  31:        0x1049ae824 - egui::ui::Ui::columns_dyn::h96c39de6fc3c9b6e
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/ui.rs:2109:22
  32:        0x1049b400c - egui::ui::Ui::columns::h04563544a582fa54
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/ui.rs:2081:9
  33:        0x10494e5fc - <er_save_editor::App as eframe::epi::App>::update::{{closure}}::h4780e3f2d1afb899
                               at er-dlc-save-editor/src/main.rs:122:13
  34:        0x104b61d60 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h763b424c3eac57b3
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
  35:        0x10520b0b4 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h598133341d38b247
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/boxed.rs:2020:9
  36:        0x104973e10 - egui::containers::panel::TopBottomPanel::show_inside_dyn::{{closure}}::hbfe27be6b782af38
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/containers/panel.rs:747:13
  37:        0x104b62f10 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hd05647eab352387e
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
  38:        0x10520b0b4 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h598133341d38b247
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/boxed.rs:2020:9
  39:        0x105223240 - egui::containers::frame::Frame::show_dyn::h425e7cea0c1c9bf0
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/containers/frame.rs:270:19
  40:        0x104b31ef8 - egui::containers::frame::Frame::show::h982c0d469af27c21
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/containers/frame.rs:261:9
  41:        0x104973950 - egui::containers::panel::TopBottomPanel::show_inside_dyn::ha5c772662630ad2d
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/containers/panel.rs:744:30
  42:        0x1049742e0 - egui::containers::panel::TopBottomPanel::show_dyn::h8f4e6ace8e745697
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/containers/panel.rs:812:30
  43:        0x104974130 - egui::containers::panel::TopBottomPanel::show::hc5f0d892e2556fb3
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/containers/panel.rs:796:9
  44:        0x104b37514 - <er_save_editor::App as eframe::epi::App>::update::h067e6b43a361eeb9
                               at er-dlc-save-editor/src/main.rs:121:9
  45:        0x104ee6cf4 - eframe::native::epi_integration::EpiIntegration::update::{{closure}}::h2bf02334eaecfbec
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/epi_integration.rs:284:17
  46:        0x104edb23c - egui::context::Context::run::h002cbcc84c0ca0a3
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.26.2/src/context.rs:753:9
  47:        0x104ee69bc - eframe::native::epi_integration::EpiIntegration::update::h77942932cc6c5fa1
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/epi_integration.rs:277:27
  48:        0x104ebbb00 - eframe::native::glow_integration::GlowWinitRunning::run_ui_and_paint::h2a54342119428098
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/glow_integration.rs:578:13
  49:        0x104eba8f4 - <eframe::native::glow_integration::GlowWinitApp as eframe::native::winit_integration::WinitApp>::run_ui_and_paint::h0893e62079eb180a
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/glow_integration.rs:402:13
  50:        0x104ed1220 - eframe::native::run::run_and_return::{{closure}}::h9d5fb8eda7ea08b2
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:99:17
  51:        0x104ef826c - <winit::platform_impl::platform::app_state::EventLoopHandler<T> as winit::platform_impl::platform::app_state::EventHandler>::handle_nonuser_event::{{closure}}::h6a3e7828ceb5b474
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/app_state.rs:87:13
  52:        0x104efc0f8 - winit::platform_impl::platform::app_state::EventLoopHandler<T>::with_callback::h37d6070437bf6c33
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/app_state.rs:70:13
  53:        0x104ef8148 - <winit::platform_impl::platform::app_state::EventLoopHandler<T> as winit::platform_impl::platform::app_state::EventHandler>::handle_nonuser_event::hdc5a972b06f42499
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/app_state.rs:86:9
  54:        0x105087bbc - winit::platform_impl::platform::app_state::Handler::handle_nonuser_event::h2291bd83b5b89cc8
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/app_state.rs:318:13
  55:        0x1050898e0 - winit::platform_impl::platform::app_state::AppState::cleared::hb4ef04b3e0a8ca94
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/app_state.rs:647:13
  56:        0x10507ebf4 - winit::platform_impl::platform::observer::control_flow_end_handler::{{closure}}::h9fa80a0747fe73e0
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/observer.rs:79:21
  57:        0x10507ea4c - winit::platform_impl::platform::observer::control_flow_handler::{{closure}}::h496abdcc0a7cf0ad
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/observer.rs:41:9
  58:        0x1050a8584 - std::panicking::try::do_call::h65accbfd0b220231
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:552:40
  59:        0x1050ad93c - ___rust_try
  60:        0x1050a8384 - std::panicking::try::h2abeb3ce9ad889ba
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:516:19
  61:        0x1050778dc - std::panic::catch_unwind::hf245e60f7e43ce25
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panic.rs:146:14
  62:        0x10508a244 - winit::platform_impl::platform::event_loop::stop_app_on_panic::h6878d14c8a2aabea
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/event_loop.rs:469:11
  63:        0x10507e848 - winit::platform_impl::platform::observer::control_flow_handler::h45dd755bb0d917b0
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/observer.rs:39:5
  64:        0x10507eb74 - winit::platform_impl::platform::observer::control_flow_end_handler::hbef54a328ad5a27a
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/observer.rs:74:9
  65:        0x1900cd87c - <unknown>
  66:        0x1900cd768 - <unknown>
  67:        0x1900cce90 - <unknown>
  68:        0x1900cc434 - <unknown>
  69:        0x19a87019c - <unknown>
  70:        0x19a86ffd8 - <unknown>
  71:        0x19a86fd30 - <unknown>
  72:        0x19392bd68 - <unknown>
  73:        0x194121808 - <unknown>
  74:        0x19391f09c - <unknown>
  75:        0x1050ece60 - <() as objc2::message::MessageArguments>::__invoke::h33698c9396465128
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/message/mod.rs:531:39
  76:        0x1050dbcc8 - objc2::message::platform::send_unverified::hb7b93c73b60c2f73
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/message/apple/mod.rs:35:34
  77:        0x10506a7c0 - objc2::message::MessageReceiver::send_message::h7fd7aeb374cc5663
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/message/mod.rs:233:53
  78:        0x10506d590 - winit::platform_impl::platform::appkit::application::NSApplication::run::h6b60bc62ee44d14d
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/macros/extern_methods.rs:240:14
  79:        0x104efb48c - winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::{{closure}}::{{closure}}::h038ef51f97eeb3d8
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/event_loop.rs:310:26
  80:        0x104ef227c - core::ops::function::FnOnce::call_once::h9cad5fd3a3ec15da
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
  81:        0x104edcee0 - <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::hf15d724d041de8fd
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panic/unwind_safe.rs:272:9
  82:        0x104ef8860 - std::panicking::try::do_call::hac6de455f3c22135
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:552:40
  83:        0x104efd3d8 - ___rust_try
  84:        0x104ef86fc - std::panicking::try::hca45e5dda94a63ac
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:516:19
  85:        0x104eda464 - std::panic::catch_unwind::hdbcdf6a1bcf28d72
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panic.rs:146:14
  86:        0x104efb2f4 - winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::{{closure}}::hbeb9e5292c38f18a
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/event_loop.rs:299:32
  87:        0x104ec502c - objc2::rc::autorelease::autoreleasepool::had6e1acc3316cb29
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/rc/autorelease.rs:438:15
  88:        0x104efac6c - winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::hd52e813d86097b07
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/event_loop.rs:281:9
  89:        0x104f0104c - <winit::event_loop::EventLoop<T> as winit::platform::run_on_demand::EventLoopExtRunOnDemand>::run_on_demand::hf574c72329948d18
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform/run_on_demand.rs:80:9
  90:        0x104ed0c34 - eframe::native::run::run_and_return::ha5a8a79536c7c891
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:76:5
  91:        0x104ed3db8 - eframe::native::run::run_glow::{{closure}}::hbf931888b914ac2f
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:400:13
  92:        0x104ed09ac - eframe::native::run::with_event_loop::{{closure}}::he84e9b3afad897ee
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:58:12
  93:        0x104ef1260 - std::thread::local::LocalKey<T>::try_with::h65a33c058f66e3b0
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/thread/local.rs:284:16
  94:        0x104ef0f64 - std::thread::local::LocalKey<T>::with::h8fe869ef8824b12b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/thread/local.rs:260:9
  95:        0x104ed0838 - eframe::native::run::with_event_loop::h890a8378504b2de5
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:48:5
  96:        0x104ed3afc - eframe::native::run::run_glow::h4bad5e0c818682c1
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:398:16
  97:        0x104ee7494 - eframe::run_native::h380827857d072058
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/lib.rs:262:13
  98:        0x104b36c88 - er_save_editor::main::h63aa3f2eb8dc5ad1
                               at er-dlc-save-editor/src/main.rs:44:5
  99:        0x104b65134 - core::ops::function::FnOnce::call_once::h8cda317e205e9840
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
 100:        0x1049fbdec - std::sys_common::backtrace::__rust_begin_short_backtrace::h408844d981b09fea
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:155:18
 101:        0x1049fbdb0 - std::rt::lang_start::{{closure}}::h669c18e8947b181c
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:166:18
 102:        0x1053c7200 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::heaba8a29e0324069
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:284:13
 103:        0x1053c7200 - std::panicking::try::do_call::h6e5fac4f4884d97b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:552:40
 104:        0x1053c7200 - std::panicking::try::h2b98e2f3cf76cd78
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:516:19
 105:        0x1053c7200 - std::panic::catch_unwind::hba9c97319335c08b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panic.rs:146:14
 106:        0x1053c7200 - std::rt::lang_start_internal::{{closure}}::h18efdcfb68f002e8
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:148:48
 107:        0x1053c7200 - std::panicking::try::do_call::ha793e16770aada4d
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:552:40
 108:        0x1053c7200 - std::panicking::try::h8aa812e3e1310d12
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:516:19
 109:        0x1053c7200 - std::panic::catch_unwind::h38c4879f2623185e
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panic.rs:146:14
 110:        0x1053c7200 - std::rt::lang_start_internal::h39923ab4c3913741
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:148:20
 111:        0x1049fbd74 - std::rt::lang_start::hc12deb7b2f512b49
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:165:17
 112:        0x104b37ae8 - _main
thread 'main' panicked at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/app_state.rs:387:33:
called `Result::unwrap()` on an `Err` value: PoisonError { .. }
stack backtrace:
   0:        0x1053cca10 - std::backtrace_rs::backtrace::libunwind::trace::h6de1cbf3f672a4f8
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/../../backtrace/src/backtrace/libunwind.rs:105:5
   1:        0x1053cca10 - std::backtrace_rs::backtrace::trace_unsynchronized::hd0de2d5ef13b6f4d
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x1053cca10 - std::sys_common::backtrace::_print_fmt::h2a33510d9b3bb866
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:68:5
   3:        0x1053cca10 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h01b2beffade888b2
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:44:22
   4:        0x1053e8f9c - core::fmt::rt::Argument::fmt::h5ddc0f22b2928899
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/fmt/rt.rs:142:9
   5:        0x1053e8f9c - core::fmt::write::hbadb443a71b75f23
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/fmt/mod.rs:1153:17
   6:        0x1053ca724 - std::io::Write::write_fmt::hc09d7755e3ead5f0
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/io/mod.rs:1843:15
   7:        0x1053cc868 - std::sys_common::backtrace::_print::h3cd1786cbb1caf0f
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:47:5
   8:        0x1053cc868 - std::sys_common::backtrace::print::h28349e5c25acbac7
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:34:9
   9:        0x1053cdd7c - std::panicking::default_hook::{{closure}}::hd24b6196784d991e
  10:        0x1053cda60 - std::panicking::default_hook::hfcec80a2720c8c73
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:292:9
  11:        0x1053ce670 - std::panicking::rust_panic_with_hook::h84760468187ddc85
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:779:13
  12:        0x1053ce05c - std::panicking::begin_panic_handler::{{closure}}::he666a5eb600a7203
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:657:13
  13:        0x1053cce94 - std::sys_common::backtrace::__rust_end_short_backtrace::h592f44d2bf9f843f
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:171:18
  14:        0x1053cddd4 - rust_begin_unwind
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:645:5
  15:        0x105420af8 - core::panicking::panic_fmt::h98bbf7bdf4994454
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panicking.rs:72:14
  16:        0x105420f08 - core::result::unwrap_failed::h8e3b933261dd7fec
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/result.rs:1654:5
  17:        0x10508820c - core::result::Result<T,E>::unwrap::h64df12b210d2c568
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/result.rs:1077:23
  18:        0x10508820c - winit::platform_impl::platform::app_state::AppState::clear_callback::hf401c9391d185b3c
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/app_state.rs:387:9
  19:        0x104efb36c - winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::{{closure}}::hbeb9e5292c38f18a
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/event_loop.rs:329:13
  20:        0x104ec502c - objc2::rc::autorelease::autoreleasepool::had6e1acc3316cb29
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/rc/autorelease.rs:438:15
  21:        0x104efac6c - winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::hd52e813d86097b07
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/macos/event_loop.rs:281:9
  22:        0x104f0104c - <winit::event_loop::EventLoop<T> as winit::platform::run_on_demand::EventLoopExtRunOnDemand>::run_on_demand::hf574c72329948d18
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform/run_on_demand.rs:80:9
  23:        0x104ed0c34 - eframe::native::run::run_and_return::ha5a8a79536c7c891
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:76:5
  24:        0x104ed3db8 - eframe::native::run::run_glow::{{closure}}::hbf931888b914ac2f
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:400:13
  25:        0x104ed09ac - eframe::native::run::with_event_loop::{{closure}}::he84e9b3afad897ee
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:58:12
  26:        0x104ef1260 - std::thread::local::LocalKey<T>::try_with::h65a33c058f66e3b0
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/thread/local.rs:284:16
  27:        0x104ef0f64 - std::thread::local::LocalKey<T>::with::h8fe869ef8824b12b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/thread/local.rs:260:9
  28:        0x104ed0838 - eframe::native::run::with_event_loop::h890a8378504b2de5
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:48:5
  29:        0x104ed3afc - eframe::native::run::run_glow::h4bad5e0c818682c1
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/native/run.rs:398:16
  30:        0x104ee7494 - eframe::run_native::h380827857d072058
                               at .cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.26.2/src/lib.rs:262:13
  31:        0x104b36c88 - er_save_editor::main::h63aa3f2eb8dc5ad1
                               at er-dlc-save-editor/src/main.rs:44:5
  32:        0x104b65134 - core::ops::function::FnOnce::call_once::h8cda317e205e9840
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
  33:        0x1049fbdec - std::sys_common::backtrace::__rust_begin_short_backtrace::h408844d981b09fea
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:155:18
  34:        0x1049fbdb0 - std::rt::lang_start::{{closure}}::h669c18e8947b181c
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:166:18
  35:        0x1053c7200 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::heaba8a29e0324069
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:284:13
  36:        0x1053c7200 - std::panicking::try::do_call::h6e5fac4f4884d97b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:552:40
  37:        0x1053c7200 - std::panicking::try::h2b98e2f3cf76cd78
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:516:19
  38:        0x1053c7200 - std::panic::catch_unwind::hba9c97319335c08b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panic.rs:146:14
  39:        0x1053c7200 - std::rt::lang_start_internal::{{closure}}::h18efdcfb68f002e8
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:148:48
  40:        0x1053c7200 - std::panicking::try::do_call::ha793e16770aada4d
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:552:40
  41:        0x1053c7200 - std::panicking::try::h8aa812e3e1310d12
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:516:19
  42:        0x1053c7200 - std::panic::catch_unwind::h38c4879f2623185e
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panic.rs:146:14
  43:        0x1053c7200 - std::rt::lang_start_internal::h39923ab4c3913741
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:148:20
  44:        0x1049fbd74 - std::rt::lang_start::hc12deb7b2f512b49
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:165:17
  45:        0x104b37ae8 - _main

@eduarmreyes I have seen saves fail on that line before. I know ClayAmore is still working on a new update but if you only care about "reading" the data and not writing data I can probably patch it to pass.
You can DM me your save or upload it.
Also try the "Copy JSON" button at the bottom of eldenringcompass.com

I am actually looking to write data, I tried using eldenringcompass.com but it does not seem to support files exported from PS4Wizard, right?

eldenringcompass uses the same code as in this repo so it should support PS4 saves, though I haven't tested it so it may be broken in some way.
I think you will need to wait for ClayAmores update to write data anyway.

If you're looking for pure parsing of the save file, I've separated the editor and parser into two projects in the new release. The parser can be found in the er-save-lib repository.
The parser is located in the save part of the project, while the save-api is what I'm using to expose functions for use in the save editor. Currently, the save API is built specifically for my needs in the save editor, so it is not yet complete.
I may consider changing the access level of the raw save data to be public instead of restricting it within the crate. Let me know if this would be helpful.


Unable to find faces in some pictures

Hi,
I have an application that converts a byte[] using the methods described in #92. After loading the image in I am using the FaceRecognition.FaceLocations(image) method to detect faces. However I am experiencing that with multiple images I am not able to find faces. While the API from MicroSoft can find them. This happens not only when there are multiple persons in the picture but also on pictures with only one person.
This is a faulty picture for example:

Does the system needs a minimal size head or image? or did I not train Helen right? or is there something else that I am not doing?

@SamuelvVelzen
I tried the sample code.
using System;
using System.Drawing;
using System.IO;
using System.Linq;
using FaceRecognitionDotNet;

namespace Issue103
{

    internal class Program
    {

        private static void Main(string[] args)
        {
            var model = args[0];
            var image = args[1];

            var fr = FaceRecognition.Create(model);
            using(var img = FaceRecognition.LoadImageFile(image))
            {
                var faces = fr.FaceLocations(img);
                if (faces == null)
                {
                    Console.WriteLine($"face is not found from {image}");
                    return;
                }

                using(var bitmap = (Bitmap)System.Drawing.Image.FromFile(image))
                {
                    using(var g = Graphics.FromImage(bitmap))
                    foreach(var f in faces)
                        g.DrawRectangle(Pens.Red, new Rectangle(f.Left, f.Top, f.Right - f.Left, f.Bottom - f.Top));
                    bitmap.Save("FromFileResult.jpg");

                    unsafe
                    {
                        var content = File.ReadAllBytes(image);
                        using (var ms = new MemoryStream(content))
                        using(var bmp = new Bitmap(ms))
                        {
                            var width = bmp.Width;
                            var height = bmp.Height;

                            var data = bmp.LockBits(new System.Drawing.Rectangle(0, 0, width, height),
                                                    System.Drawing.Imaging.ImageLockMode.ReadOnly,
                                                    bmp.PixelFormat);

                            var stride = data.Stride;
                            var src = (byte*)data.Scan0;
                            var raw = new byte[width * height * 3];
                            fixed(byte* dst = &raw[0])
                            {
                                for (var h = 0; h < height; h++)
                                {
                                    var dstOffset = h * width * 3;
                                    var srcOffset = h * stride;
                                    for (var w = 0; w < width; w++)
                                    {
                                        // BGR to RGB
                                        dst[dstOffset + w * 3 + 0] = src[srcOffset  + w * 3 + 2];
                                        dst[dstOffset + w * 3 + 1] = src[srcOffset  + w * 3 + 1];
                                        dst[dstOffset + w * 3 + 2] = src[srcOffset  + w * 3 + 0];
                                    }
                                }
                            }

                            bmp.UnlockBits(data);

                            using(var img2 = FaceRecognition.LoadImage(raw, height, width, 3))
                            {
                                var faces2 = fr.FaceLocations(img2);
                                if (faces2 == null)
                                {
                                    Console.WriteLine($"face is not found from {image}");
                                    return;
                                }

                                using(var g = Graphics.FromImage(bmp))
                                foreach(var f in faces2)
                                    g.DrawRectangle(Pens.Red, new Rectangle(f.Left, f.Top, f.Right - f.Left, f.Bottom - f.Top));
                                bmp.Save("FromRawResult.jpg");
                            }
                        }
                    }
                }
            }
        }

    }

}

This code works fine on FRDN 1.3.0.

Does the system needs a minimal size head or image?

I don't know about limitation of minimum face size.

or did I not train Helen right?

No. Face detection does not matter about Helen training.

When I copy and paste your code it worked. however when I rewrote your code to use the FaceRecognition.LoadImage() function instead of the  FaceRecognition.LoadImageFromFile() function, it didn't work anymore.
Also I don't know if this is intended but if(faces == null) is always false. Because even when it finds 0 faces it still return a FaceRecognitionDotNet.FaceRecognition+<FaceLocations>d__30. So I did faces.Count()

I rewrote your code to use the FaceRecognition.LoadImage() function

My code already used LoadImage function at end of code.
You means that my code does not work, right?

if(faces == null) is always false.

Yeah, you are correct.
FaceLocation method never return null.

Your code works! but when I rewrite using(var img = FaceRecognition.LoadImageFile(image)) to while doing the #92 method using(var img = FaceRecognition.LoadImage(image)) it doesn't work

@SamuelvVelzen
You must take care of BitmapData.Stride property.
Windows Bitmap may contain additional padding.
from
System.Runtime.InteropServices.Marshal.Copy(data.Scan0, raw, 0, raw.Length);

to
                for (var y = 0; y < height; y++)
                {
                    var start = IntPtr.Add(data.Scan0, y * data.Stride);
                    var dst = y * width * 3;
                    System.Runtime.InteropServices.Marshal.Copy(start, raw, dst, width * 3);
                }

It works fine and detected 4 faces.

well thank you, I didn't know that was possible or even existed. Thanks for helping me solve this problem 😃


Automated Package Upgrade

:tada: This PR is included in version 5.0.321 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Feature/chatbot vision (unfinished)

Created ConverseWithImage block, currently shows up but doesn't do anything

Can one of the admins verify this patch?

@jisqyv This is the draft PR for the vision chatbot, could you take a look and comment what Catherine should do next? Or could you adjust things in the proxy server according to her implementation?

@catherinepaopao Thanks for demoing this at the team meeting yesterday. A few things are needed before we can merge this. In particular, since you are changing a component you will need to bump the version number for the ChatBot in YaVersion.java and then add code paths to handle upgrading to that version in YoungAndroidFormUpgrader.java and versioning.js. Adding a new block is effectively a "no-op" in these upgrade paths but it is still necessary to add them.

Btw, do we wan to finish the ios version in this branch? I assume it shouldn't be that much difficult to add?

Yes.

@AppInventorWorkerBee ok to test


fixes for setting layout and building problem fields

Added tensor constructor with layout field.
Correct BuildConvProblem for bwd and wrw configs.

@bghimireamd Please take some time to review this PR.

LGTM .. CI is failing on some minor issue. Once CI passed we can merge.


Backlog

Lots of small tasks have accumulated recently, just listing them here.

[x] Update the manifest for the GCP buckets
[ ] Set up automatic deploy for the test env too
[ ] Sort authority boundaries by size, so Derby is clickable on the choose area page again (see https://github.com/acteng/atip-data-prep/pull/50)
[ ] Change the default coloring on the browse page to funding scheme (will need some refactoring)
[ ] Assert scheme name is always filled out in atip-scheme-data, and change TS everywhere. We're assuming it's filled out in the browse sidebar UI now.
[ ] In the stats19 layer, also show vehicle types involved
[ ] In the vehicle count layer, style the points where the source is "manual / automatic count" with a thicker border, to show the "real" data and de-emphasize points where the count is just a forecast

Manifest updated
Auto deploy in progress: requested new service account. Once I've done that I'll update the README like I should've done last time 🙈
Might look into the colouring point and do the bucketing we discussed alongside that


Add example .py file for 1D Burgers problem

Migrate the example file fourier_1d.py from the old master branch to main:examples as plot_burgers.py [1].

Add .npz loader utilities to the datasets/ module. Reshape the old data for the newest version of the library.
Add support to layers/ for float64 and complex128 numbers.

Based on top of https://github.com/m4e7/neuraloperator/pull/5
Reviewer(s): @zongyi-li @JeanKossaifi
[1] plot_burgers.html.gz

Closing in favor of https://github.com/neuraloperator/neuraloperator/pull/211


I've fixed this problem :)

Thanks!


Report integration with Sphinx

Is your feature request related to a problem? Please describe.
Usually, all my Python projects are documented using Sphinx. Such a documentation contains also an auto generated Python Class Reference as well as multiple code quality indications / analysis reports. Currently this is: code coverage by coveragypy, unit tests by pytest, static typing analysis by mypy and documentation coverage by docstr_coverage.
Most tools provide a machine readable output format (e.g. in XML or JSON) and almost all are writing or converting them to an HTML report. This can be a single file or multiple files in a directory.
For integration into the overall documentation, multiple CI jobs generate the results and generated HTML pages and then a final CI job combines all artifacts to a combined static website for e.g. GitHub Pages.
In the last days I investigated and prototyped a new Sphinx extension, which integrates a documentation coverage report directly as native Sphinx content into the documentation. This offers some huge benefits:

reports are part of the overall design / no style break
reports are also part of other Sphinx backend outputs e.g. PDF documentation
parts of the report can be referenced by the main documentation
reports are part of the main navigation / table of content

I would like to discuss if and how to integrate coveragepy into such a Sphinx extension. My extension sphinx-reports is open to more report formats like code coverage.
This is an example from my prototype for documentation coverage:

Describe the solution you'd like
I would like to read and render code coverage results into Sphinx documentation pages.
I would like to address it in 2 steps:

Integrate coveragepy's summary page and then link to auto generated coverage pages.
(I haven't figured out how to write complex Sphinx content like colored source code.)
Also write source code files via Sphinx.

The extensions alpha code is here: https://pytooling.github.io/sphinx-reports
Describe alternatives you've considered
I checked, if auto generated HTML code from coveragepy could be copied into a placeholder Sphinx page. While content was transferred, I found huge problems with CSS and Javascript contents. It would results in dozens - if not hundreds - of regex-based rewrite and transformation rules. This can't be maintained.
An other alternative would be coveragepy offering ReST (Restructured Text) output and such files could be referenced by a toctree directive.
Additional context
I believe that expressing the quality of an open-source project is a need to convince others to use and maybe invest time in someone open-source project. It also can shorten some discussions if a library can be used easily and safely.

Where can I find the documentation of status.json written into the HTML output directory. It looks like .... "nums": [0, 1, 246, 0, 105, 86, 3, 33], contains a summary of total, covered and uncovered elements.

Update: status.json doesn't contain the correct (or final) coverage values. I'm now switching to a full coverage file in JSON format.

I think you've already worked this out, but status.json is not meant for external code to consume: it's a caching mechanism to speed up the HTML report.  The coverage json command writes out data you can use.
I'm not sure the simplest way to get what you need.  It seem to me like a niche need to have these reports included in Sphinx generated pages, so I want to find a path for you that doesn't change coverage too much.

As I transitioned to the "bigger" JSON, I'm already in the phase reading and using all coverage data. I hoped to get along with status.json as it's quite small compared to a full JSON or XML.
So I think ReST output or so from Coverage.py is not needed.
At next I want to figure out how to create subpages in Sphinx and how to colorize source code. This is currently black magic in Sphinx.
What might be interesting for me is the sorting feature that you use in your HTML tables.
Do you have suggestions on level for the coloring?
So what's bad, medium, good very good coverage?

Hi, I don't have suggestions for the levels for various colors.  Probably people will want it to be configurable, but that's up to you.  It sounds like you have everything you need from me?

Probably people will want it to be configurable

Yes, the number of levels and the percentage can be configured. I plan to have some kind of default coloring, but otherwise the user colors are used. Actually it's a percentage, description text (good, bad, very bad, ..) and a CSS class name.

It sounds like you have everything you need from me?

May be this part:

What might be interesting for me is the sorting feature that you use in your HTML tables.

The Javascript and column sorting is this code written/owned by you or some kind of library? I think it might be good to have a hierarchy and a sorted view. I see Coverage.py add a JS file into the out put directory.


Opt-in virtual DOM

What problem does this feature solve?
A lot of complex UI elements generally reside outside of v-for which is where virtual DOM may hypothetically be helpful, looking through ui frameworks few provide extensibility or that is the degree of freedom that you would see without virtual DOM, pretty much none of it relates to rendering lists.
What does the proposed API look like?
An option to render v-for with virtual DOM implying that virtual DOM is absent elsewhere, and is entirely opt-in.

vdom is already opt-in. It's ui's framework responsibility to make it easy to customise, not Vue's
We do provide scoped slots and props to make it customisable

I'm not sure I understand the problem, nor the conclusion that Virtual DOM should be optional.

CSS frameworks find it difficult to provide options or just as well port components or something because of virtual DOM where it basically is any good in lists, of which very small portion of CSS framework will in fact deal with- that is have a component for table.


About Us image alignment

I know you mentioned this in your post Chris but the About us page on desktop is not horizontally aligning the three "draft" images. Also do we need to use a higher resolution version of those images. I can reduce compression on them.

Yeah, need to do a little more work on this. However, each time I load the About page (both on my computer and in my IE9 emulator), the columns are vertically aligned for me. It's only when I start resizing my browser that they are off.

I've never really noticed anyone who wasn't a web designer resize their browser over and over.


Encryption in aes-gcm of large buffers not only by 16 bytes

Description
In case of large buffer, we can only encrypt it 16 bytes by 16 bytes except for the last one.
If we encrypt 15 bytes, the context is updated and the next bytes will be encrypted with the new context. I change the mbedtls_gcm_context and mbedtls_gcm_update to allow it to remember how many bytes it saws.
I had a problem when i changed the crypto library to mbedtls in the libsrtp of Cisco. One of the unit test encrypts a large buffer in one time then piece by piece and compares the results.
Todos

[ ] Documentation
[ ] Changelog updated

Additional comments
It's my first pull request. If it's not good enough, tell me the problem and i will do it again

Hi @Bizyroth Thank you for your contribution!
I would like to confirm that you have signed the Contributor's Licensse Agreement, and that this is your Mbed account

In addition, please resolve the CI failures.
You should revert the changes you did to the Makefiles. These are auto-generated by Clang, and should not be pushed. I believe that reverting the Makefile changes should resolve some of your CI failures. Some failures are GCM related, so I believe it is related to your change.
Before you push your changes, please run tests/scripts/check-names.sh to see what caused one of the CI failures

@hanno-arm @RonEld
Hello
I had to replace the crypto part from the libsrtp. The cisco libsrtp use OpenSSL as a crypto library and i wanted to use mbedtls to be coherent in my project.
I achieve to replace the crypto but when i run unit test from libsrtp, it failed. After debugging, i noticed that the behavior of mbedtls was different from OpenSSL.
Large buffer was cutted into many smaller buffer (to allow transfer to be efficient over the network) before encryption. The smaller buffer was not cutted into buffer with a size of a multiple of 16 bytes.
When the receiver receives this large buffer, he cuts it into small buffer too but not at the same location that the sender did. Here is a quick example:
I want to encrypt a buffer of 16 bytes:

With OpenSSL:

I have a context ctx and i encrypt the first 8 bytes from my buffer with the function encrypt(ctx, buffer[0:8])
I encrypt the last 8 bytes from my buffer with encrypt(ctx, buffer[8:16]). OpenSSL remember that at the last call of encrypt, he didnt see 16 bytes and dont have update the context.
So if i decrypt then the first 3 bytes with decrypt(ctx, buffer[0;3]) and the rest with decrypt(ctx, buffer[,3,16]) decryption will worked

With mbedtls:

I encrypt the first 8 bytes with encrypt(ctx, buffer[0:8])
Then when i encrypt the rest of the buffer, the context was update even if i didnt see 16 bytes
Afterthat when i do decrypt(ctx, buffer[0:3]) and decrypt(ctx, buffer[3:16]) decryption will failed because context used to encrypt buffer[3:8] was different of the context used to decrypt buffer[3:8].

To resume, context in mbedtls are automatically update at the end of a mbedtls_gcm_update (and its written in the documentation, so this behavior is expected) but i think we can add some information to the context to remember if the last buffer we update was not a multiple of 16 bytes to keep the context until we saw 16 bytes.
I hope my explanation are clear, if you want precision i will be able to answer you. I make the change requested soon as i can.

@RonEld
I just saw your comment about unprocessed_data in cipher_ctx. I didnt see this parameter and i think it will be a better approach to solve my problem. It is use with aes_CBC and aes_CTR but not with aes_GCM. I have to check that before i can have an opinion.

Superseded by #1731 so closing this PR.
If you believe this PR was mistakenly closed, please reopen.


I found some incompatibility..

Hi, I'm trying your framework with php and linux mint.
I am sad to say raylib release a new version, the 3.5, and there's a couple of incompatibilities with your framework. I was able to quick fix but I think some funcions would be redefinied or deleted because the changelog of november is about 150 lines of added / deleted functionalities.
Finally I was able, after a quick fix on code, to compile the .so library and start build a game, but still, some functions are not working perfectly.
Good work btw!
Greetings from Italy.

@ricky89 Thanks for your interest. I am closing this for #8 as its a bit more clear what needs to be done. Progress can be tracked there.


nixpkgs master no longer supports fileSystems.<name>.formatOptions

Attempting to use jetpack-nixos with nixpkgs master will fail this assertion:
https://github.com/NixOS/nixpkgs/blob/5d486408b510035c76b31d8d880c830d773b40a4/nixos/modules/tasks/filesystems.nix#L330-L332
It seems like it will be necessary to use some other mechanism to create the partition in question.
(Side note, the /dev/disk/by-partlabel/esp does not exist and is not mounted on my AGX anyhow. Not sure if this is just a step I missed when setting up jetpack-nixos or something else, though)

(Side note, the /dev/disk/by-partlabel/esp does not exist and is not mounted on my AGX anyhow. Not sure if this is just a step I missed when setting up jetpack-nixos or something else, though)

I have addressed this particular point by naming the esp partition with parted. The original point/issue still stands.


Feature Suggestion: split VMOT into VMOT+VAUX

Personally I'd like to be able to run my motors at 36v or 48v and I know there are TMC5160 drivers that support this, but the 6-Pack is limited by the onboard VR and a few other components.
What do you think about splitting VMOT into two rails, one rails specifically for the stepper drivers, another for the rest of board/aux power like fans, etc. This would allow the board to be powered by say, 12v which would allow the cheaper/easier to find fans, and the steppers could be up to 36v without any other changes to the board. It would also eliminate some noise on the AUX, as you could run separate power supplies (a single power supply can still power both).

These are some good suggestions for even more reasons than you have mentioned. I'll consider it for future revisions. FWIW: The next batch will allow 40V input, due to upgrading the obsolete p/s chip.
At some point you do have to consider the limitations of current and power dissipation in the Pololu socket.

At some point you do have to consider the limitations of current and power dissipation in the Pololu socket.
For me, this is most important when using a mixture of onboard and external drivers. E.g. When using JMC servos for the maix axes.

In this case, it would be nice to use a single motor power supply.

I totally agree on spliting VMOT into VMOT + VAUX. I use ~4A external drivers driven @ 48V on LinuxCNC . Depending on MOSFET used in tmc5160 the six-pack is a replacement candidate on my modified EMCO F1 mill.

Is there any news here yet? I am currently looking for a new cnc controller board. I would very much like to run tmc5160 driver with 60V.

I made a fork of the design here:
https://github.com/StephS/6-Pack_CNC_Controller/tree/Kicad-v1p8s/versions/V1p8s
It includes the split VMOT along with some layout changes.
I've already had 5 boards made, but I need to buy parts and assemble and test.
Gerbers are included, so feel free to download and send to your favorite fab. However I haven't rebuilt the BOM yet.

Hi Stephanie,That sounds great. I will order a few boards tonight.Is it possible to run the drivers at 60v with your modified board?In the PDF 6_axis_I2S_v1p8s.pdf vmot is labeled with 12-40v.Am 27.12.2021 22:03 schrieb Stephanie @.***>:
I made a fork of the design here:
https://github.com/StephS/6-Pack_CNC_Controller/tree/Kicad-v1p8s/versions/V1p8s
It includes the split VMOT along with some layout changes.
I've already had 5 boards made, but I need to buy parts and assemble and test.
Gerbers are included, so feel free to download and send to your favorite fab. However I haven't rebuilt the BOM yet.
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: @.***>

The limiting factor will be the capacitors for the stepper drivers, and the stepper drivers themselves.
That's one of the things I need to verify on the BOM.
The other would be all the footprints and make sure there aren't any manufacturing issues. Apparently the voltage regulator is hard to come by.
So just note that while the design passed DRC and ERC, it's still untested.
If you don't mind waiting a day, I'm thinking I can pull the parts off my old 6-Pack board.

So I took a quick look, and the result is that the stock capacitors are 330uF @ 50v. This is why the 40v max rating. I looked for replacement capacitors that are rated >60v and couldn't find any in the same package size. The closest was 150uF @63v which is a significant drop in capacity.
You could do a through hole cap as there are 270uF @ 80v which would work quite well. However this would require either modifying the board, or bending the leads and making a fixture to hold them and prevent damage.
Modifying the board would be the best route, by adding holes for through hole capacitors. It could cause an issue with the SMT caps sharing the same pads, but maybe that can be worked around.

Think also that Two capacitor in// give sum of the capacitor, this is what we do for our board here because of form factor :  https://github.com/Skywalkerf34/6-Pack_CNC_Controller/tree/master
With this way we can keep the capacitor under the Pololu socket

First of all, thank you for your quick response.
I would like to use the TMC5160 pro drivers from Bigtreetech. https://www.biqu.equipment/de/products/tmc5160-pro-v1-0 because they can be used up to 60V (56V).
If I understand correctly the problem with Stephanie's board are the capacitors.
Skywalkerf43 suggests to put two of the 63V capacitors suggested by Stephanie in // to get back the capacity that would be necessary.
I also like the board from Skywalker. Especially the fact that I could buy it directly on Tindie. Unfortunately, it will not be so easy to convert the board to 60V, right?
28. Dezember 2021 12:58, "Francis" @.*** @.@.>)> schrieb:
Think also that Two capacitor in// give sum of the capacitor, this is what we do for our board here because of form factor : https://github.com/Skywalkerf34/6-Pack_CNC_Controller/tree/master (https://github.com/Skywalkerf34/6-Pack_CNC_Controller/tree/master)
With this way we can keep the capacitor under the Pololu socket
—

Reply to this email directly, view it on GitHub (https://github.com/bdring/6-Pack_CNC_Controller/issues/29#issuecomment-1002056150), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ABPVDDA5ICHXKLUQR7XZL5TUTGQ4LANCNFSM4QPCVSAA).
Triage notifications on the go with GitHub Mobile for iOS (https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or Android (https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub).
You are receiving this because you commented.Message ID: @.***>

I don't know the details of that controller, but often the 5V DC-DC power supply can not handle inputs as high as 60V.
I would be careful running those drivers close to 60V. Back EMF from the drivers can causes spikes a few percent above the VMot. I would suggest 10% derating.

Completely agree. And I checked the biqu website, and while the driver states they support up to 60v, 56v is the recommended max. Looking at the TMC5160 datasheet, I have an idea why.
The VSA pin on the 5160 drives an 11.5v internal voltage regulator. On the datasheet section 3.2 it recommends not driving this more than 40v due to significant self-heating.
These stepstick style drivers aren't the best with heat dissipation either, so you'll likely need to derate your max current.
As for my fork of the board, the layout would need to be significantly changed to support two capacitors.
The fork by @Skywalkerf34 uses a voltage regulator with a max of 50v, so you'd be limited there.
If you really want 60v, the TMC5160 datasheet recommends 100uf of bulk capacitance per amp of drive current.
I can look into making room for a larger capacitor, but it definitely becomes a bit difficult with space and layout constraints.

If you power with 56 volts PSU, There might be a way to fork my design cutting some track, using external fuse  and use the footprint to modify power inlet , then change the 2 SMD capacitor for one 100 mF 63V wired in same place.
Of course this will be a  fork handMade for you....let me know if you can be interested in


Added '-nameopt' option to the verify command.

Checklist

[x] documentation is added or updated

Description of change
It makes possible to print the certificate's DN correctly in case of verification errors.

I'd say enhancement...

I had to make nmflags a "static unsigned long".  @dot-asm, okay?

@beldmit can you change nmflags like I did, and do commit --amend to update the single commit?

I hope I did what you wanted from me.

yes, that's good.  i'll merge/squash.  @openssl/committers  can anyone reconfirm?

Reconfirmed.

Now the s_cb.c file is the last one in the apps/ folder where the XN_FLAG_ONELINE is hardcoded.

ad39b31 on master; thanks!  Looking forward to your patch for s_cb.c :)


Line Numbering / Change Recommendations

Current state:

Showing line numbers works
When in original mode with line numbers shown outside (which is the default), it is possible to create change recommendations. They are after that shown to the left of the original text and the line numbers. Clicking on the annotation to the left of the line numbers changes into Diff view and scrolls that specific change recommendation into view.
In Diff view, the inline diff is shown, accepting/rejecting, editing and deleting change recommendations is possible.
Final and Changed view are implemented

Rebased

Not sure why the CategoryRepositoryService fails here due to the missing HttpClient, but not in the regular branch; I kind of doubt that's because of my changes, or has anyone any clue?

@CatoTH Can we review and rebase and merge this pull request? Or do you want to add more commits?

Yes, if the code is fine with you, you can go ahead.

Feel free to rebase and merge on your own

Ohh sorry, I did not expect that.
If you think the five commits are necessary I can merge it now. Otherwise please rebase them to a structure you find fitting.


[Event Hubs] EventHubConsumerClient subscribe() with EventPosition specified failing in nightly runs

Event Hubs nightly test runs are failing with:

Error message:
Error: Uncaught Error: Unhandled error. (undefined) (dist-test/index.browser.js:8092)

For more details check here:

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1830637&view=results

Addressed


Unable to update extension

Steps to reproduce
I'll add screenshot of the issue here

The first screenshot is before the update.
Second screenshot is while updating
And the last is AFTER updating it
I'll add another screenshot after doing this so check the time and the total extension count

It's happening to me for months now
Expected behavior
.
Actual behavior
.
Crash logs
.
Mihon version
Stable 0.16.5
Android version
Android 12
Device
Samsung F41
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have gone through the FAQ and troubleshooting guide.
[X] I have updated the app to version 0.16.5.
[X] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

Duplicate of #496


[W5][W10-4]Au Liang Jun

Added a simple sort command that lists all users in lexicographical order, based on name.
Ready for review.

Hi Liang Jun, you should update the I/O tests as well, but everything else looks good.

Resolved outdated I/O tests and fixed aforementioned documentation/style errors.
Thank you for the feedback!


Add headers to developer role dropdown menu

Example of how you’d add headers to dropdown menu. I’ll have to send
you data for the developer role groups shortly.

@asherzafar Example of how you'd add headers to dropdown menu


.github: remove workflows triggered by comments

These workflows are not executed in the v1.10 since GitHub only uses the
GH workflows available in the default branch to handle 'issue_comment'
events. For this reason these workflows will be removed from this branch
and will be re-created in the default branch.
Signed-off-by: André Martins<EMAIL_ADDRESS>FYI this is already taken care in the master branch with https://github.com/cilium/cilium/pull/16944

Should we also update the feature release docs to remember to remove these when we do the next release?

Should we also update the feature release docs to remember to remove these when we do the next release?

already part of https://github.com/cilium/cilium/pull/16944


fix(boot): show a warning instead of error if a Deployment is in progress when Deis Workflow is starting up

I did not manage to get my cluster into this state to properly test it. I may have too small of a cluster
The repro steps can be found at #903
Fixes #903
/cc @arschles

[Current coverage][cc-pull] is 85.70% (diff: 50.00%)

Merging [#906][cc-pull] into [master][cc-base-branch] will decrease coverage by 0.01%

@@             master       #906   diff @@
==========================================
  Files            30         30
  Lines          3012       3008     -4
  Methods           0          0
  Messages          0          0
  Branches        502        502
==========================================
- Hits           2582       2578     -4
  Misses          287        287
  Partials        143        143

Powered by Codecov. Last update [ecfcea6...5ca1403][cc-compare]
[cc-base-branch]: https://codecov.io/gh/deis/controller/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/deis/controller/compare/ecfcea6129e5ddced353aaa369cfd656f733d9bd...5ca14030a63cfa6a4743cefc18e2c5d7226f9380?src=pr
[cc-pull]: https://codecov.io/gh/deis/controller/pull/906?src=pr


String/byte prefix

What's the best way to separate out the string/byte prefixes (such as f, r, u and b before the quotes) from the string itself (maybe as a sub-node)? I understand from the Neovim TSPlayground plugin and the playground website that the prefixes are currently directly part of the string node.

At the moment you really can't without some weird injection logic, they're a part of the string_start node.

In case this helps anyone, I was able to achieve this with the following queries:
(
  (string
    (string_start) @keyword
  )
  (#match? @keyword "^([frub]|fr|rf)[\"']$")
  (#offset! @keyword 0 0 0 -1)
)

(
  (string
    (string_start) @keyword
  )
  (#match? @keyword "^([frub]|fr|rf)[\"']{3}$")
  (#offset! @keyword 0 0 0 -3)
)


DynamoDB Table resource's put_item() method has the wrong type for the ConditionExpression parameter

Describe the bug
The boto3.resource("dynamodb").Table("name").put_item() method takes a ConditionExpression parameter, which according to the boto3 documentation should be a boto3.dynamodb.conditions.ConditionBase object. (See: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/dynamodb.html#DynamoDB.Table.put_item)
Currently, in mypy_boto3_dynamodb.service_resource.Table, it is annotated as being str. (See: https://youtype.github.io/boto3_stubs_docs/mypy_boto3_dynamodb/service_resource/#tableput_item-method)
To Reproduce
Steps to reproduce the behavior:

Install boto3-stubs[...]
Run mypy/pyright on the following code sample

import boto3
from mypy_boto3_dynamodb.service_resource import Table
from typing import Mapping

def get_table(table_name: str) -> Table:
    return boto3.resource("dynamodb").Table("table_name")

def write_to_table(table: Table, item: Mapping[str, str], condition_attr: str, condition_value: str):
    condition = boto3.dynamodb.conditions.Attr(condition_attr).eq(condition_value)
    table.put_item(Item=item, ConditionExpression=condition)

Actual output
test.py:10: error: Argument "ConditionExpression" to "put_item" of "Table" has incompatible type "Equals";
expected "str"
Found 1 error in 1 file (checked 1 source file)

Expected output
Success: no issues found in 1 source file

Additional context
Mac OS 12.4, boto3-stubs[dynamodb]==1.24.23 , boto3==1.24.23, installed with pip-tools

Thank you for the report!
Fixed in the latest mypy-boto3-dynamodb 1.24.27 release. Please update boto3-stubs and subpackages. Let me know if it works as it should.


Update Preference List or View

Describe your suggested feature
Hi Devs ,
Hope you are dong well, any ways I wanted to raise a request if possible that we can add somewhere in the update tab a way to have a filter to stack all the incoming update and not just per chapter just like what we have in Tachi2JK.
Thank you for all your hard work and more power

Other details
Hi Devs ,
Hope you are dong well, any ways I wanted to raise a request if possible that we can add somewhere in the update tab a way to have a filter to stack all the incoming update and not just per chapter just like what we have in Tachi2JK.
Thank you for all your hard work and more power

Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with an official extension, I should be opening an issue in the extensions repository.
[X] I have updated the app to version 0.16.1.
[X] I will fill out all of the requested information in this form.

Duplicate of #44


Unable to use unions in any way, causes validation to think field is undefined

Hello There,
I really like this library and as a big user of zod, I was quite happy when I found a type safe way to deal with mongoose, so thank you for making it.
That being said, I have ran into a problem which I can not for the life of me figure out how to get around, that is if I try to use unions for my return objects the validation seems to think the field is empty.
initial schema
export const IssueSchema = z.object({
  id: IdentifierSchema,
  title: z.string(),
  type: z.nativeEnum(IssueType),
  content: z.string(),
  user: z.string(),
  metadata: MediaProviderUnionSchema,
});
export type Issue = z.infer<typeof IssueSchema>;

This schema is acts like a base schema, that is later extended by my DTO schema that is returned from the database, you'll notice that this schema has user set to just a string (this represents the reference from the db).
export const IssueDTOSchema = IssueSchema.extend({
  user: z.union([UserSchema, z.string()]),
});
export type IssueDTO = z.infer<typeof IssueDTOSchema>;

//
export const IssueDTOMongoSchema = IssueDTOSchema
  .mongoose({
    schemaOptions: {
      collection: 'issues',
      virtuals: {
        user: {
          options: {
            ref: 'user',
            localField: 'user',
            foreignField: 'id',
          }
        }
      }
    },
    typeOptions: {
      user: {
        ref: 'user',
      }
    }
  });
export type IssueDTOMongo = z.infer<typeof IssueDTOMongoSchema>;

The reason for extending was to get around the circular dependency issue, which I solved in this way by just extending it and overriding the initial field with a union, so the user schema can be be returned if it's populate method is used when pulling the data from the database, else it will just return the string as it would normally.
The problem is that no matter the combination, the validation errors out thinking the user field is undefined? Not sure if I have missed something in the documentation, or something long those lines.
  {
    "code": "invalid_union",
    "unionErrors": [
      {
        "issues": [
          {
            "code": "invalid_type",
            "expected": "object",
            "received": "undefined",
            "path": [
              "user"
            ],
            "message": "Required"
          }
        ],
        "name": "ZodError"
      },
      {
        "issues": [
          {
            "code": "invalid_type",
            "expected": "string",
            "received": "undefined",
            "path": [
              "user"
            ],
            "message": "Required"
          }
        ],
        "name": "ZodError"
      }
    ],
    "path": [
      "user"
    ],
    "message": "Invalid input"
  }
]

Here is also the seed data I am using to test with.
const IssueData: Issue[] = [
  {
    id: "8I6u5mg53wd0YXEHtCewb",
    title: "Problem with playing content",
    type: IssueType.BadVideo,
    content: "I am unable to play movie",
    user: 'H9ITrq4x2GQ2E_-XKUlIM',
    metadata: {
      tmdbId: 615656,
    }
  }
];

Any help with this is appreciated. Thanks.

Hey @ADRFranklin thank you for the nice words.
Could you please provide the code that would lead to that error, or ideally the repository with a minimal reproduction?
What I tried is creating a new IssueDTOMongo document using .save() method, and it worked just fine. I then tried to retrieve that document back, and it did not populate the user field (even though I also created a user with that ID) - likely because user virtual clashes with the field with the same name? When I renamed user virtual to something else, the population succeeded. Either way I haven't encountered any validation errors on my way.

 Since I posted this issue, I have done quite of bit of refactoring on my project, so it's totally possible I managed to fix the problem without really knowing it.
I had figured out a workaround which was to use the normal schema as the mongoose schema, as it didn't seem to error when returning populated fields that didn't match the schema, so then I would just re parse the output with the dto schema. But even changing back the data to what I previously had no longer gives errors, so it's probably safe to assume this was just user error and not the fault of the library,
Thanks anyway, if I do manage to trigger the same issue again, I will re-open with more info, just in case this might uncover some weird behaviour.


Source image outside of aws?

Is it in any way possible to call a image path that is not in a bucket but as a external url?

@WeAreHaus Thanks for contacting us. Unfortunately, the solution is getting images from S3 buckets only right now. If you want to get images from external url, you might need to change the source code which is related to getting original images from the S3 bucket.


Add jupyter lite & widgets applications ...

Jupyter Lite: Fix https://github.com/jupyterlite/jupyterlite/issues/1098
Jupyter Widgets: Companion the voila & respect width of 3 applications

Destination: https://jupyter.org/try
Source:

https://github.com/jupyterlite
https://ipywidgets.rtfd.io/en/latest/
https://jupyter.org/widgets

~Please squash these into 1 - the second commit doesn't do anything different - it's just i am not proficient in git~
2023-07-28: it was easy ... "open in codespaces" --> git rebase -i HEAD~2 --> reword, fixup --> git push --force-with-lease

ping @jasongrout 😃

ping @blink1073

I have rebased it to master (using github codespaces)
successful command log just for my own records
$ git switch master
$ git remote --verbose add -m master upstream https://github.com/jupyter/jupyter.github.io

$ git branch -u upstream/master master
branch 'master' set up to track 'upstream/master'.
$ git remote set-head upstream --auto
upstream/HEAD set to master
$ git pull --rebase
Updating 16be457..6454730
Fast-forward
$ git log --oneline -10
$ git switch lite-and-widgets
Switched to branch 'lite-and-widgets'
Your branch is up to date with 'origin/lite-and-widgets'.
$ git rebase master
Successfully rebased and updated refs/heads/lite-and-widgets.
$ git log --oneline -7
$ git push --force-with-lease

Failed commands
This block contains failed commands - hence commented out
.
$ # git pull --rebase upstream
You asked to pull from the remote 'upstream', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
$ # git pull --rebase upstream/master
fatal: 'upstream/master' does not appear to be a git repository
fatal: Could not read from remote repository.
$ # git remote set-head upstream --auto
upstream/HEAD set to master
$ # git pull --rebase
Already up to date.
$ # git fetch master/master
fatal: 'master/master' does not appear to be a git repository
fatal: Could not read from remote repository.

Hi @goyalyashpal, it looks like the png is corrupted:

it looks like the png is corrupted:
[screenshot of github diff not rendering for png]

umh, github is not rendering pngs for some 1 to 3 months now, not even in normal repo view.
is there some other way to verify if it's broken or not?

It looks like this now... the tile size doesn't look uniform..

Final would look like this:

@blink1073 it's ready from my side :)

hey @blink1073 - just wondering - was there an option to rebase & merge shown for this pr? if yes, then is there some particular reason for doing merge (which adds a merge commit to the history). thanks :)

Good catch, thanks, I've updated our settings.


Accept log messages via block

fixes #25

This patch allows a Dry-Logger instance to accept log messages via a block.
If a block is passed to #unknown, #debug, #info, #warn, #error, or
#fatal, the block's return value becomes the logged message much like the
Ruby standardlib Logger.
l = Dry.Logger(:testymctestface, template: :details)
# => #<Dry::Logger::Dispatcher ...

l.info('regular positional argument message')
# [testymctestface] [INFO] [2024-05-01 07:35:36 -0400] regular positional argument message
# => true

l.info { 'a block message' }
# [testymctestface] [INFO] [2024-05-01 07:35:50 -0400] a block message
# => true

l.info('sub-component') { 'fancy-pants block message' }
# [sub-component] [INFO] [2024-05-01 07:36:09 -0400] fancy-pants block message
# => true

I added two spec tests to ensure that block passing works, but I wasn't able to
quickly figure out how to check the value of progname.

Thank you for considering my patch!

@timriley this is ready for your eyes!

@komidore64 This is fantastic, thank you!
I've just pushed up some expanded (and passing) tests for the progname handling. Does that behaviour match your expectations?
If you're happy with that, then I can get this in and cut a new release.

@timriley do you need anything else from me to move this forward? I'm happy to help however I can.

@komidore64 Thank you for checking in! I've just got this ready now (had to sort out a few test failures on the main branch first). I'm going to merge this now and then cut a release. Thanks again!

This is released as v1.0.4. Thanks again @komidore64!


An error occurred when I tried to use it with the material theme UI (the enlarged icon in the main greedy)

Is your function request related to the problem? Please describe it
About beautification related content, such as large icon button, etc
Describe the solution you want
I hope this theme can be compatible and get along well with the material theme UI
Describe the alternatives you have considered
If it is not compatible with other themes, I hope to make large icons
I prefer to change the style of the icon freely
And more customized functions, such as title bar
Additional context
Finally, attach the screenshot of small bugs in the current combination
The latest version of idea2022 is used 1 can't use the plug-in option to change the large icon. I hope the author can deal with it. It's really nice

I hope this theme can be compatible and get along well with the material theme UI

I will not be supporting any integrations, fixing any bugs, or making the themes work well with the Material UI Theme installed along with the Doki Theme.
The Material UI Theme is a heavy weight plugin that does significant changes to the platforms look and feel. The way I see it, is if you are using the Material UI plugin, stick with those themes. You can always just add background images without this plugin.
Thank you for understanding.

And more customized functions, such as title bar

I made a plugin a while back that allows you to customize the title bar color. Feel free to take a look to see if it suites your needs.
https://github.com/Unthrottled/themed-components/#title-bar-color-customization


0.32.1 Sends multiple requests (7 to be exact) for every action

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version):
0.32.1
Python release (python3 --version):
3.4.2
Description of problem:
Every action sent to the Hass API is duplicated 7 times. If I send the action to turn on my dining room light, it sends "/api/services/switch/turn_on" request 7 times to my dining room lamp. I didn't notice this right away as most of my lights are Z-wave, and it seems to handle it well by ignoring the additional requests, but I have RF lights as well, and when I try to turn on that light, it sends the RF code 7 times immediately, which causes RF garble and none of the commands are received. This has also caused issues with notifications, as more than half of my notifications are sent to my phone 7 times.
My system is controlled by App Daemon and Node-Red, so this is coming across in the home-assistant stream feed, so I am not sure if this is only an issue with Home Assitant sending each command through the stream 7 times or what, but it has broken my system.
I tried downgrading to 0.32.0 to see if the problem went away, but it still exists, so I have now downgraded back to 0.31.1 and everything seems to be working fine.
Expected:
I expect every command to be sent only once.

We need more information. Who is sending 7 actions? How are you triggering actions?
Try to repro it without using appdaemon or node-red.
/api/services/switch/turn_on is our API endpoint that is indeed used for calling services - I am running 0.33.dev0 and I get 2 service call when I call this API: one to homeassistant/turn_on by the UI which then calls light/turn_on. This is as expected.

I agree, I was also receiving those calls exact calls on 0.32.1 and prior, but when I updated to 0.32.1 I began getting a slew of duplicate calls, something like:
domain=switch, service_data=entity_id=switch.jon_media_room_lamp, service_call_id=1976994992-36, service=turn_on domain=switch, service_data=entity_id=switch.jon_media_room_lamp, service_call_id=1976994992-37, service=turn_on domain=switch, service_data=entity_id=switch.jon_media_room_lamp, service_call_id=1976994992-38, service=turn_on domain=switch, service_data=entity_id=switch.jon_media_room_lamp, service_call_id=1976994992-39, service=turn_on domain=switch, service_data=entity_id=switch.jon_media_room_lamp, service_call_id=1976994992-40, service=turn_on domain=switch, service_data=entity_id=switch.jon_media_room_lamp, service_call_id=1976994992-41, service=turn_on domain=switch, service_data=entity_id=switch.jon_media_room_lamp, service_call_id=1976994992-42, service=turn_on
And this was occuring for every action. I was even receiving 7 notifications on my phone for things like the alarm arming, the garage door opening, etc.
When I downgraded to 0.32.0, I was continuing to get the same 7 calls for all kinds of events, but when I downgraded back to 0.31.1, everything was working correctly and I was only getting the expected number of calls.
In an attempt to get you more information, I upgraded at the newly released 0.32.2 and then rebooted my Raspberry Pi, but lo and behold, everything is working perfectly just as it did with 0.31.1, so I am not sure if it was something that was changed from 0.32.1 to 0.32.2 or if for some strange reason another reboot of the Raspberry Pi kicked something in, I don't know. But I can not longer reproduce the issue as everything appears to be running fine on 0.32.2


chore: bump nvd3 plugin version

SUMMARY
Propagate changes from the nvd3 plugin tooltip fixes
TEST PLAN
CI

Codecov Report

Merging #11947 (a7c255d) into master (14ea444) will decrease coverage by 2.81%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #11947      +/-   ##
==========================================
- Coverage   66.22%   63.40%   -2.82%
==========================================
  Files         937      465     -472
  Lines       45325    28528   -16797
  Branches     4341        0    -4341
==========================================
- Hits        30016    18088   -11928
+ Misses      15177    10440    -4737
+ Partials      132        0     -132

Flag
Coverage Δ

cypress
?

javascript
?

python
63.40% <ø> (-0.80%)
:arrow_down:

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

Impacted Files
Coverage Δ

superset/sql_validators/postgres.py
50.00% <0.00%> (-50.00%)
:arrow_down:

superset/views/database/views.py
62.30% <0.00%> (-25.14%)
:arrow_down:

superset/db_engine_specs/mysql.py
79.59% <0.00%> (-12.25%)
:arrow_down:

superset/db_engine_specs/sqlite.py
65.62% <0.00%> (-9.38%)
:arrow_down:

superset/db_engine_specs/presto.py
73.81% <0.00%> (-8.59%)
:arrow_down:

superset/databases/commands/create.py
83.67% <0.00%> (-8.17%)
:arrow_down:

superset/databases/commands/update.py
85.71% <0.00%> (-8.17%)
:arrow_down:

superset/db_engine_specs/base.py
80.73% <0.00%> (-6.87%)
:arrow_down:

superset/sql_validators/base.py
93.33% <0.00%> (-6.67%)
:arrow_down:

superset/views/database/forms.py
83.33% <0.00%> (-5.56%)
:arrow_down:

... and 491 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 14ea444...a7c255d. Read the comment docs.


Make react-scrolla work with react 15

Updates all dependencies
Fix lint parsing errors of es7 syntax
Fix lint warngings
Fix build step

ping @chentsulin

Published as v0.3.0 👍


After downloading curl-user-agents.txt, downloading device-links.txt sometimes fails

After downloading curl-user-agents.txt, downloading device-links.txt sometimes fails randomly or the IP changes while it does download the content. That brakes the download-stream and it will drop out a zero byte device-links.txt list.

Requires investigation

Maybe the --retry can help here: https://everything.curl.dev/usingcurl/downloads/retry.html


include image version info in output

per https://github.com/Senzing/aws-cloudformation-ecs-poc-simple/issues/21

PR merged.


Restructure tests to provide a test suite other parsers can use

We would like to provide a test suite that both us and community parsers can use to validate their parsers.
A proposed solution would look like:
/tests/data/
- v1.0/
  - parser/
    - {case name}.model.json
    - {case name}.model.openfga
  - checker/
    - dsl/
      - {case name}.results.json
      - {case name}.model.openfga
    - json/
      - {case name}.results.json
      - {case name}.model.json
  - formatter/
    - {case name}.input.json
    - {case name}.output.openfga
- v1.1/
  - parser/
  - checker/
  - formatter/

See Related Discussion

This is done and we have a set of tests we're actually leveraging in our implementations in multiple languages
https://github.com/openfga/language/tree/main/tests/data


Continuous Delivery UI - Reports wrong status

Internal reference: SURE-4198
On a cluster customer has deployed a GitRepo, and there is one job getting failed and other jobs are successful.
The UI reports all the jobs are failing and not updating the details of successful Jobs.
(more info available internally)

Possible duplicate: https://github.com/rancher/dashboard/issues/4681

We'll keep this ticket in lieu of #4681
Internal reference to track from that ticket: SURE-3568

Related backend (from the duplicate ticket): https://github.com/rancher/rancher/issues/36947
Listed as Next Up for 2.6.5 still

Based on how tickets have moved around, this ticket is either blocked or dependent on the transferred https://github.com/rancher/dashboard/issues/6117
@Shavindra should we get that ticket onto your backlog/next up soon?

Duplicate of https://github.com/rancher/dashboard/issues/6117, so that fix already merged should fix this 🙏

@AndrewHoffmanQA  Please refer to this duplicate ticket for the reproduction steps: https://github.com/rancher/dashboard/issues/6117
Additionally, just simply provide your results of testing in the comments section of this ticket once you are done testing. Thanks!

**tested on **
local:
Rancher version: v2.6-df1b20
Browser type & version: HA helm
rke - v1.3.13-rc3
result:
passed
the resource page correctly displayed which cluster was modified

this has been retested and passed. attached a video.  tested on rancher v2.6-68215bc
after following reproduction steps and viewing the fleet section of the UI it was clearly displaying which deployment failed.  closing this ticket.
https://user-images.githubusercontent.com/89030218/189724940-c3d3beaa-0e3d-43f8-bf86-12439c1ddb5f.mp4