text:
editor undo crash

I wasn't doing anything interesting when it happened. I think I undid a 'cut' operation.
index out of bounds: the len is 865 but the index is 872    0: std::backtrace::Backtrace::create
   1: lb_rs::service::log_service::panic_capture::{{closure}}
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::begin_panic_handler::{{closure}}
   4: std::sys_common::backtrace::__rust_end_short_backtrace
   5: _rust_begin_unwind
   6: core::panicking::panic_fmt
   7: core::panicking::panic_bounds_check
   8: lb_rs::text::buffer::Snapshot::apply_replace
   9: lb_rs::text::buffer::Buffer::undo

Just experienced an issue where an undo happened when I didn't undo. No unicode characters in my file - only headings, inline code, and bulleted lists as syntax.

Just got this crash on branch async-docs after replacing the contents of a document with ’, then undo'ing:
panic detected and logged: panicked at libs/lb/lb-rs/src/text/unicode_segs.rs:25:30:
index out of bounds: the len is 2 but the index is 3    0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/../../backtrace/src/backtrace/libunwind.rs:104:5
   1: std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2: std::backtrace::Backtrace::create
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/backtrace.rs:331:13
   3: lb_rs::service::logging::panic_capture::{{closure}}
             at /Users/travis/Code/lockbook/lockbook/libs/lb/lb-rs/src/service/logging.rs:53:13
   4: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2029:9
   5: std::panicking::rust_panic_with_hook
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:785:13
   6: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:659:13
   7: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/sys_common/backtrace.rs:171:18
   8: rust_begin_unwind
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:647:5
   9: core::panicking::panic_fmt
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/panicking.rs:72:14
  10: core::panicking::panic_bounds_check
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/panicking.rs:208:5
  11: <usize as core::slice::index::SliceIndex<[T]>>::index
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/slice/index.rs:255:10
  12: core::slice::index::<impl core::ops::index::Index<I> for [T]>::index
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/slice/index.rs:18:15
  13: <alloc::vec::Vec<T,A> as core::ops::index::Index<I>>::index
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/vec/mod.rs:2771:9
  14: lb_rs::text::unicode_segs::UnicodeSegs::offset_to_byte
             at /Users/travis/Code/lockbook/lockbook/libs/lb/lb-rs/src/text/unicode_segs.rs:25:30
  15: lb_rs::text::unicode_segs::UnicodeSegs::range_to_byte
             at /Users/travis/Code/lockbook/lockbook/libs/lb/lb-rs/src/text/unicode_segs.rs:31:36
  16: lb_rs::text::buffer::Snapshot::apply_replace
             at /Users/travis/Code/lockbook/lockbook/libs/lb/lb-rs/src/text/buffer.rs:86:26
  17: lb_rs::text::buffer::Buffer::undo
             at /Users/travis/Code/lockbook/lockbook/libs/lb/lb-rs/src/text/buffer.rs:383:29
  18: workspace_rs::tab::markdown_editor::input::mutation::<impl workspace_rs::tab::markdown_editor::editor::Editor>::calc_operations
             at /Users/travis/Code/lockbook/lockbook/libs/content/workspace/src/tab/markdown_editor/input/mutation.rs:614:29
  19: workspace_rs::tab::markdown_editor::input::events::<impl workspace_rs::tab::markdown_editor::editor::Editor>::process_events
             at /Users/travis/Code/lockbook/lockbook/libs/content/workspace/src/tab/markdown_editor/input/events.rs:27:25
  20: workspace_rs::tab::markdown_editor::editor::Editor::show_inner_inner
             at /Users/travis/Code/lockbook/lockbook/libs/content/workspace/src/tab/markdown_editor/editor.rs:264:13
  21: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  22: egui::containers::frame::Frame::show_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/frame.rs:280:19
  23: egui::containers::frame::Frame::show
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/frame.rs:270:9
  24: workspace_rs::tab::markdown_editor::editor::Editor::show_inner::{{closure}}::{{closure}}::{{closure}}
             at /Users/travis/Code/lockbook/lockbook/libs/content/workspace/src/tab/markdown_editor/editor.rs:225:34
  25: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/ops/function.rs:250:5
  26: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  27: egui::ui::Ui::with_layout_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/ui.rs:2286:21
  28: egui::ui::Ui::vertical_centered
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/ui.rs:2233:9
  29: workspace_rs::tab::markdown_editor::editor::Editor::show_inner::{{closure}}::{{closure}}
             at /Users/travis/Code/lockbook/lockbook/libs/content/workspace/src/tab/markdown_editor/editor.rs:218:28
  30: egui::containers::scroll_area::ScrollArea::show::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/scroll_area.rs:691:61
  31: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/ops/function.rs:250:5
  32: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  33: egui::containers::scroll_area::ScrollArea::show_viewport_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/scroll_area.rs:763:21
  34: egui::containers::scroll_area::ScrollArea::show
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/scroll_area.rs:691:9
  35: workspace_rs::tab::markdown_editor::editor::Editor::show_inner::{{closure}}
             at /Users/travis/Code/lockbook/lockbook/libs/content/workspace/src/tab/markdown_editor/editor.rs:213:42
  36: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/ops/function.rs:250:5
  37: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  38: egui::containers::frame::Frame::show_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/frame.rs:280:19
  39: egui::containers::frame::Frame::show
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/frame.rs:270:9
  40: workspace_rs::tab::markdown_editor::editor::Editor::show_inner
             at /Users/travis/Code/lockbook/lockbook/libs/content/workspace/src/tab/markdown_editor/editor.rs:212:14
  41: core::ops::function::FnOnce::call_once{{vtable.shim}}
  42: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  43: egui::ui::Ui::with_layout_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/ui.rs:2286:21
  44: egui::ui::Ui::vertical
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/ui.rs:2214:9
  45: workspace_rs::tab::markdown_editor::editor::Editor::show
             at /Users/travis/Code/lockbook/lockbook/libs/content/workspace/src/tab/markdown_editor/editor.rs:144:12
  46: core::ops::function::FnOnce::call_once{{vtable.shim}}
  47: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  48: egui::ui::Ui::with_layout_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/ui.rs:2286:21
  49: core::ops::function::FnOnce::call_once{{vtable.shim}}
  50: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  51: egui::ui::Ui::with_layout_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/ui.rs:2286:21
  52: core::ops::function::FnOnce::call_once{{vtable.shim}}
  53: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  54: egui::ui::Ui::with_layout_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/ui.rs:2286:21
  55: workspace_rs::workspace::Workspace::show
  56: lockbook_egui::account::AccountScreen::update::{{closure}}
             at ./src/account/mod.rs:185:27
  57: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/ops/function.rs:250:5
  58: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  59: egui::containers::panel::CentralPanel::show_inside_dyn::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/panel.rs:1104:13
  60: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/ops/function.rs:250:5
  61: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/alloc/src/boxed.rs:2015:9
  62: egui::containers::frame::Frame::show_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/frame.rs:280:19
  63: egui::containers::frame::Frame::show
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/frame.rs:270:9
  64: egui::containers::panel::CentralPanel::show_inside_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/panel.rs:1102:15
  65: egui::containers::panel::CentralPanel::show_dyn
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/panel.rs:1137:30
  66: egui::containers::panel::CentralPanel::show
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/containers/panel.rs:1114:9
  67: lockbook_egui::account::AccountScreen::update
             at ./src/account/mod.rs:173:14
  68: lockbook_egui::Lockbook::update
             at ./src/lib.rs:100:17
  69: <lockbook_egui::Lockbook as eframe::epi::App>::update
             at ./src/lib.rs:112:22
  70: eframe::native::epi_integration::EpiIntegration::update::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/epi_integration.rs:317:17
  71: egui::context::Context::run
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/egui-0.28.1/src/context.rs:753:9
  72: eframe::native::epi_integration::EpiIntegration::update
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/epi_integration.rs:310:27
  73: eframe::native::wgpu_integration::WgpuWinitRunning::run_ui_and_paint
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/wgpu_integration.rs:627:27
  74: <eframe::native::wgpu_integration::WgpuWinitApp as eframe::native::winit_integration::WinitApp>::run_ui_and_paint
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/wgpu_integration.rs:385:13
  75: eframe::native::run::run_and_return::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/run.rs:96:17
  76: <winit::platform_impl::platform::app_state::EventLoopHandler<T> as winit::platform_impl::platform::app_state::EventHandler>::handle_nonuser_event::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/app_state.rs:87:13
  77: winit::platform_impl::platform::app_state::EventLoopHandler<T>::with_callback
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/app_state.rs:70:13
  78: <winit::platform_impl::platform::app_state::EventLoopHandler<T> as winit::platform_impl::platform::app_state::EventHandler>::handle_nonuser_event
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/app_state.rs:86:9
  79: winit::platform_impl::platform::app_state::Handler::handle_nonuser_event
  80: winit::platform_impl::platform::app_state::AppState::cleared
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/app_state.rs:647:13
  81: winit::platform_impl::platform::observer::control_flow_end_handler::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/observer.rs:78:21
  82: winit::platform_impl::platform::observer::control_flow_handler::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/observer.rs:40:9
  83: std::panicking::try::do_call
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:554:40
  84: std::panicking::try
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:518:19
  85: std::panic::catch_unwind
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panic.rs:142:14
  86: winit::platform_impl::platform::event_loop::stop_app_on_panic
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/event_loop.rs:469:11
  87: winit::platform_impl::platform::observer::control_flow_handler
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/observer.rs:38:5
  88: winit::platform_impl::platform::observer::control_flow_end_handler
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/observer.rs:73:9
  89: <unknown>
  90: <unknown>
  91: <unknown>
  92: <unknown>
  93: <unknown>
  94: <unknown>
  95: <unknown>
  96: <unknown>
  97: <unknown>
  98: <unknown>
  99: winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::{{closure}}::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/event_loop.rs:310:26
 100: core::ops::function::FnOnce::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/ops/function.rs:250:5
 101: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/panic/unwind_safe.rs:272:9
 102: std::panicking::try::do_call
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:554:40
 103: std::panicking::try
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:518:19
 104: std::panic::catch_unwind
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panic.rs:142:14
 105: winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/event_loop.rs:299:32
 106: objc2::rc::autorelease::autoreleasepool
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.4.1/src/rc/autorelease.rs:438:15
 107: winit::platform_impl::platform::event_loop::EventLoop<T>::run_on_demand
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/macos/event_loop.rs:281:9
 108: <winit::event_loop::EventLoop<T> as winit::platform::run_on_demand::EventLoopExtRunOnDemand>::run_on_demand
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform/run_on_demand.rs:80:9
 109: eframe::native::run::run_and_return
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/run.rs:73:5
 110: eframe::native::run::run_wgpu::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/run.rs:424:13
 111: eframe::native::run::with_event_loop::{{closure}}
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/run.rs:58:12
 112: std::thread::local::LocalKey<T>::try_with
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/thread/local.rs:286:16
 113: std::thread::local::LocalKey<T>::with
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/thread/local.rs:262:9
 114: eframe::native::run::with_event_loop
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/run.rs:48:16
 115: eframe::native::run::run_wgpu
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/native/run.rs:422:16
 116: eframe::run_native
             at /Users/travis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eframe-0.28.1/src/lib.rs:268:13
 117: lockbook_egui::main
             at ./src/main.rs:42:5
 118: core::ops::function::FnOnce::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/ops/function.rs:250:5
 119: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/sys_common/backtrace.rs:155:18
 120: std::rt::lang_start::{{closure}}
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/rt.rs:166:18
 121: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/ops/function.rs:284:13
 122: std::panicking::try::do_call
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:554:40
 123: std::panicking::try
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:518:19
 124: std::panic::catch_unwind
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panic.rs:142:14
 125: std::rt::lang_start_internal::{{closure}}
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/rt.rs:148:48
 126: std::panicking::try::do_call
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:554:40
 127: std::panicking::try
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panicking.rs:518:19
 128: std::panic::catch_unwind
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/panic.rs:142:14
 129: std::rt::lang_start_internal
             at /rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/std/src/rt.rs:148:20
 130: _main

Minimal reproduction: new doc -> paste any multi-byte unicode char -> undo -> app crashes

repo: lockbook/lockbook

license: Unlicense


text:
Add manipulation example inside the new code structure

In GitLab by @cmastalli on Nov 9, 2018, 14:03
An important benchmarking task is the manipulation one. It also help us to debug the performance of the new code structure

In GitLab by @cmastalli on Nov 26, 2018, 10:10
assigned to @cmastalli

In GitLab by @cmastalli on Nov 27, 2018, 10:12
This task was tackled in !24. There is needed, as double check, to compare the derivatives against NumDiff.

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Added the frame velocity cost model + bindings - [merged]

In GitLab by @cmastalli on Aug 15, 2019, 13:23
Merges topic/frame-vel-cost -> cpp_devel
This PR solves #226. Additionally, it proposes to use pinocchio.utils.rand or pinocchio.utils.zero instead of NumPy for Pinocchio-based Python code.

In GitLab by @cmastalli on Aug 15, 2019, 13:23
enabled an automatic merge when the pipeline for e24c8439635f8cb369406fa53e5226f25a75bac4 succeeds

In GitLab by @cmastalli on Aug 15, 2019, 13:24
canceled the automatic merge

In GitLab by @cmastalli on Aug 15, 2019, 13:24
added 1 commit
6f770acc - [cleanup] Formatted c++ code
Compare with previous version

In GitLab by @cmastalli on Aug 15, 2019, 13:30
enabled an automatic merge when the pipeline for 6f770accab99e67fb977cf993dbdec43f9f32d63 succeeds

In GitLab by @cmastalli on Aug 15, 2019, 13:33
added 1 commit
81dce231 - [unittest] Added computeForwardKinematicsDerivatives which is needed for...
Compare with previous version

In GitLab by @cmastalli on Aug 15, 2019, 13:44
enabled an automatic merge when the pipeline for 81dce23110ae2e35ec575198805fd376111d4027 succeeds

In GitLab by @cmastalli on Aug 15, 2019, 13:44
merged

In GitLab by @cmastalli on Aug 15, 2019, 13:44
mentioned in commit 81b062abaa93aba6ea5cc3a51d736d77d4eec983


text:
Initializer Section in Settings

Description
Currently, configuration for initializers is required to use the custom settings which might lead to confusion about custom user settings and initializer settings.

@jondot Would you mind assigning the issue to me, please? Thanks!

repo: loco-rs/loco


text:
Type hinting for common functions

Now that we have updated to python 3.6 we can have sensible type hinting ("->" syntax for methods for example). We should add that.

Hey, I was hoping to pick this up ! What do you mean by "common" functions in this context ?

Hey, I was hoping to pick this up ! What do you mean by "common" functions in this context ?

I mean the ones exposed to the end user.
The end goal is that things like self.client.post() and basic Locust properties (like wait_time) should be picked up by a user's IDE (like vscode) and any errors be picked up when checked with MyPy (http://mypy-lang.org/).

Lets do this after 1.0. I tried some stuff, but it is harder than it seems and I dont want to delay 1.0

The API documentation should provide a good list of functions and methods that we would like to add type hinting for.

authors: anuj-ssharma cyberw heyman

repo: locustio/locust

license: mit

license_source: bigquery


text:
Fix formatting issue combining double dashes into single dash

Copying and pasting the command to get help into the console fails because of a formatting issue that combines the double dashes into a single dash.

you can leave it unquoted... just add a double-colon to the end of the previous line so it renders in a code block.  That will keep it more consistent with how nearby code looks.
To see all available options, type::

        locust --help

if you push a change for this, I'd be happy to merge it for you.

LGTM

source: gharchive/pull-request

authors: cgoldberg swoodford


text:
--silent doesn't hide [info] log messages when "devspace run xxxx" is used

What happened?
--silent doesn't hide [info] log messages when "devspace run xxxx" is used (devspace --silent enter works)
What did you expect to happen instead?
be silent
How can we reproduce the bug? (as minimally and precisely as possible)
➜  php-laravel-nginx-devspace git:(master) ✗ devspace --silent run artisan key:generate --show
[info]   Using namespace 'default'
[info]   Using kube context 'docker-desktop'
[info]   Opening shell to pod:container app-0:php
base64:xxxxxx
➜  php-laravel-nginx-devspace git:(master) ✗ devspace --silent enter -c php -- php artisan key:generate --show
base64:xxxxxxxx
➜  php-laravel-nginx-devspace git:(master) ✗
Local Environment:

DevSpace Version: devspace version 5.10.0
Operating System: mac
Deployment method: helm

Kubernetes Cluster:

Cloud Provider: docker-desktop
Kubernetes Version: [use kubectl version]
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.4", GitCommit:"e87da0bd6e03ec3fea7933c4b5263d151aafd07c", GitTreeState:"clean", BuildDate:"2021-02-18T16:12:00Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.7", GitCommit:"1dd5338295409edcfff11505e7bb246f0d325d15", GitTreeState:"clean", BuildDate:"2021-01-13T13:15:20Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

Anything else we need to know?

/kind bug

@leventogut thanks for opening this issue! I suspect you call devspace within the command, correct? You will need to set the --silent in the command as well as devspace is not passing this flag to the underlying command. E.g.:
commands:
- name: artisan
  command: "devspace --silent enter -c php -- php artisan key:generate --show"

I am very sorry, not sure how I thought there was a problem. My mistake

authors: FabianKramm leventogut

repo: loft-sh/devspace


text:
API Gateway Private Endpoints do not include 'x-forwarded-proto' leading to incorrect wsgi.url_scheme

When using an API Gateway configured with a private endpoint (https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-private-endpoints/) and in lambda proxy integration, the event object does not contain a header with 'x-forwarded-proto', even though calling the api over the private endpoint can only be done via HTTPS (I guess you could consider this an oversight by AWS, it is an undocumented quirk). This leads to serverless-wsgi defaulting to the incorrect protocol (http) for setting wsgi.url_scheme in serverless_wsgi.py. The detection logic for setting this value should perhaps be updated to not solely depend on the presence of 'x-forwarded-proto', or perhaps default to https instead of http in the absence of the header as API gateway doesn't support http only connections directly.

I just checked and API Gateway doesn't listen on port 80, and the FAQ states that API Gateway doesn't support unencrypted endpoints.
One way to do this would be to check for the requestContext.apiId field and if present, set the wsgi.url_scheme to https if it has not already been done. I'm not sure whether this would open up a security hole however, so it might be safer to enable this behavior via an environment variable or configuration override.

A very simple workaround for this is to modify the lambda handler function to set event['headers']['X-Forwarded-Proto'] = 'https' and/or event['multiValueHeaders']['X-Forwarded-Proto'] = 'https' immediately before calling serverless_wsgi.handle_request.

authors: JordanLoehr gcochard

repo: logandk/serverless-wsgi


text:
versioning of membership change protocol

part of #99

Relatedly, how would we add entry types for cluster-wide settings?

I think both of these could follow similarly to how state machine upgrades are triggered:

The servers advertise a capability to the leader in the heartbeat responses
The leader waits until everyone has the required capability
The leader starts using the new log entry format. Ideally, servers that no longer support the new log entry format would PANIC (in case someone somehow rolls back a server real quick in here - TOCTOU)

So closing for now as nothing is required just yet.

repo: logcabin/logcabin

license: isc


text:
Consider ignoring .babelrc on publish

React Native's made the migration to Babel 6, which has the unfortunate side effect of finding .babelrc files in node_modules and attempting to use those configurations (see this issue for more details).
As a result, Babel 5 configs break RN builds, and the team's official fix is to ask module authors if they would consider adding .babelrc to .npmignore.
Wanted to ask if you'd be up for it — no problems otherwise using this lib with RN :)

Thanks!  This will be in v6.0.0 which should be released within the next few days, hopefully.

authors: jonlong timbur

repo: loggur/react-redux-provide


text:
Fresh instance of docker container fails and exits immediately

Describe the bug
I was experiencing some issues that I think were similar to #604. Since I previously had the mirror enabled, I wanted to disable that, delete all files and simply start fresh. However, my instance fails immediately with
fail: Microsoft.EntityFrameworkCore.Database.Command[20102]
      Failed executing DbCommand (13ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
      CREATE TABLE "__EFMigrationsHistory" (
          "MigrationId" TEXT NOT NULL CONSTRAINT "PK___EFMigrationsHistory" PRIMARY KEY,
          "ProductVersion" TEXT NOT NULL
      );
Unhandled exception. Microsoft.Data.Sqlite.SqliteException (0x80004005): SQLite Error 14: 'unable to open database file'.
   at Microsoft.Data.Sqlite.SqliteException.ThrowExceptionForRC(Int32 rc, sqlite3 db)
   at Microsoft.Data.Sqlite.SqliteCommand.PrepareAndEnumerateStatements(Stopwatch timer)+MoveNext()
   at Microsoft.Data.Sqlite.SqliteCommand.GetStatements(Stopwatch timer)+MoveNext()
   at Microsoft.Data.Sqlite.SqliteDataReader.NextResult()
   at Microsoft.Data.Sqlite.SqliteCommand.ExecuteReader(CommandBehavior behavior)
   at Microsoft.Data.Sqlite.SqliteCommand.ExecuteReader()
   at Microsoft.Data.Sqlite.SqliteCommand.ExecuteNonQuery()
   at System.Data.Common.DbCommand.ExecuteNonQueryAsync(CancellationToken cancellationToken)
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteNonQueryAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteNonQueryAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteNonQueryAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator.MigrateAsync(String targetMigration, CancellationToken cancellationToken)
   at BaGet.Core.AbstractContext`1.RunMigrationsAsync(CancellationToken cancellationToken) in /src/BaGet.Core/Entities/AbstractContext.cs:line 36
   at BaGet.Hosting.IHostExtensions.RunMigrationsAsync(IHost host, CancellationToken cancellationToken) in /src/BaGet.Hosting/Extensions/IHostExtensions.cs:line 35
   at BaGet.Program.<>c__DisplayClass0_0.<<Main>b__1>d.MoveNext() in /src/BaGet/Program.cs:line 53
--- End of stack trace from previous location where exception was thrown ---
   at McMaster.Extensions.CommandLineUtils.CommandLineApplicationExtensions.<>c__DisplayClass9_0.<<OnExecuteAsync>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.ExecuteAsync(String[] args, CancellationToken cancellationToken)
   at BaGet.Program.Main(String[] args) in /src/BaGet/Program.cs:line 56
   at BaGet.Program.<Main>(String[] args)

To Reproduce
I have baget deployed in a k8s cluster with the following specification:
apiVersion: v1
kind: Pod
metadata:
  name: nuget
  labels:
    app: nuget
spec:
  volumes:
    - name: nuget-storage
      persistentVolumeClaim:
        claimName: nuget-storage
  containers:
    - name: nuget-container
      image: loicsharma/baget
      resources:
        requests:
          memory: "200Mi"
          cpu: "25m"
        limits:
          memory: "200Mi"
          cpu: "300m"
      env:
      - name: ApiKey
        value: will-not-tell-you
      - name: Storage__Type
        value: FileSystem
      - name: Storage__Path
        value: "/data/"
      - name: Database__Type
        value: Sqlite
      - name: Database__ConnectionString
        value: "Data Source=/data/baget.db"
      - name: Search__Type
        value: Database
      - name: PackageDeletionBehavior
        value: HardDelete
      ports:
        - containerPort: 80
      volumeMounts:
        - mountPath: "/data/"
          name: nuget-storage

I have deleted all database&package files, so there shouldn't be anything for baget to get confused by.
Any help would be highly appreciated.
Thanks
Stefan

Nevermind. A reboot of my host machine resolved the issue. My best guess is that this is completely independent of baget.

Nevermind. A reboot of my host machine resolved the issue. My best guess is that this is completely independent of baget.

repo: loic-sharma/BaGet

license: MIT


text:
Q: carbonzipper ->carbonserver occasional timeouts

Hi,
I have carbonzipper pointing at 3 carbonserver instances (from 0.9.1 go-carbon) and it's occasionally reporting timeouts.
I don't see anything in carbonserver logs that's helpful.  Any suggestions on what I should look at/do to troubleshoot this?
Thanks!

Closing out.  I discovered via carbonzipper that timeouts were happening.  More investigation is showing higher disk writes on one backend server for some reason.  I have an investigation path now.

repo: lomik/go-carbon


text:
setup live reload

Jup, you read that right and I am eating my hat on this one.
I stated pretty loudly that I am against a live reload feature, but I have to admit that watchfiles works pretty good these days and the feature is pretty neat.

Codecov Report
Patch coverage: 27.77% and project coverage change: -0.11% :warning:

Comparison is base (88c8076) 71.82% compared to head (73153fd) 71.72%.

:exclamation: Current head 73153fd differs from pull request most recent head 835a775. Consider uploading reports for the commit 835a775 to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #473      +/-   ##
==========================================
- Coverage   71.82%   71.72%   -0.11%
==========================================
  Files          84       84
  Lines        5746     5761      +15
  Branches     1235     1238       +3
==========================================
+ Hits         4127     4132       +5
- Misses       1339     1349      +10
  Partials      280      280

Files Changed
Coverage Δ

lona/command_line/handle_command_line.py
0.00% <0.00%> (ø)

lona/command_line/run_server.py
25.45% <0.00%> (-0.97%)
:arrow_down:

lona/app.py
57.92% <25.00%> (-0.84%)
:arrow_down:

lona/default_settings.py
100.00% <100.00%> (ø)

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

authors: codecov-commenter fscherf

repo: lona-web-org/lona


text:
Socratic Seminar #22 Topics

Gathering topics to discuss.
Categories:

News
New Work/Research, ML posts
Bitcoin Projects
Lightning Projects
Client Software Projects

https://github.com/BitDevsNYC/BitDevsNYC.github.io/pull/124

News

Voltage releases new LSP on testnet
The top wallets used to make bitcoin lightning payments
Mastering Bitcoin v3 early release

Research

Doing a simulation for upfront probing success rates

Bitcoin Projects

BDK 1.0 Incoming, the road to BDK 1.0

Lightning Projects

LDK Node

Bitcoin Projects

Liana: 0.2: now with multisig! (+ general discussion about degrading timelocks and how taproot partially improves that but still requires periodically respending UTXOs without some kind of covenant)
Ordinals and Inscriptions (and now also https://openordex.org/ with PSBTs)
OP_CTV and SIGHASH_ANYPREVOUT merged in bitcoin-inquisition
Bitcoin Core: p2p, validation: Don't download witnesses for assumed-valid blocks when running in prune mode merged
Bitcoin Core: Signing support for Miniscript Descriptors merged

Research

Fedipool: Fedimint Could Mitigate Bitcoin Mining Pool Concerns (not sure if really "research" but probably more so than news?)

New Work

BitcoinSearch.xyz is a recently-launched search engine for Bitcoin technical documentation and discussions.

authors: ConorOkus glozow stickies-v

repo: londonbitdevs/londonbitdevs-website


text:
ImportError: No module named gpu_nms

When I checked the log of ./make.sh, I found that, g++: error: unrecognized option ‘-R, how could I solve it?
running build_ext
cythoning utils/bbox.pyx to utils/bbox.c
building 'utils.cython_bbox' extension
creating build
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/utils
{'gcc': ['-Wno-cpp', '-Wno-unused-function']}
gcc -pthread -B /home/yinst/Public/anaconda2/compiler_compat -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/numpy/core/include -I/home/yinst/Public/anaconda2/include/python2.7 -c utils/bbox.c -o build/temp.linux-x86_64-2.7/utils/bbox.o -Wno-cpp -Wno-unused-function
gcc -pthread -shared -B /home/yinst/Public/anaconda2/compiler_compat -L/home/yinst/Public/anaconda2/lib -Wl,-rpath=/home/yinst/Public/anaconda2/lib,--no-as-needed build/temp.linux-x86_64-2.7/utils/bbox.o -L/home/yinst/Public/anaconda2/lib -lpython2.7 -o /home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/utils/cython_bbox.so
cythoning utils/nms.pyx to utils/nms.c
building 'utils.cython_nms' extension
{'gcc': ['-Wno-cpp', '-Wno-unused-function']}
gcc -pthread -B /home/yinst/Public/anaconda2/compiler_compat -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/numpy/core/include -I/home/yinst/Public/anaconda2/include/python2.7 -c utils/nms.c -o build/temp.linux-x86_64-2.7/utils/nms.o -Wno-cpp -Wno-unused-function
gcc -pthread -shared -B /home/yinst/Public/anaconda2/compiler_compat -L/home/yinst/Public/anaconda2/lib -Wl,-rpath=/home/yinst/Public/anaconda2/lib,--no-as-needed build/temp.linux-x86_64-2.7/utils/nms.o -L/home/yinst/Public/anaconda2/lib -lpython2.7 -o /home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/utils/cython_nms.so
cythoning nms/cpu_nms.pyx to nms/cpu_nms.c
building 'nms.cpu_nms' extension
creating build/temp.linux-x86_64-2.7/nms
{'gcc': ['-Wno-cpp', '-Wno-unused-function']}
gcc -pthread -B /home/yinst/Public/anaconda2/compiler_compat -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/numpy/core/include -I/home/yinst/Public/anaconda2/include/python2.7 -c nms/cpu_nms.c -o build/temp.linux-x86_64-2.7/nms/cpu_nms.o -Wno-cpp -Wno-unused-function
gcc -pthread -shared -B /home/yinst/Public/anaconda2/compiler_compat -L/home/yinst/Public/anaconda2/lib -Wl,-rpath=/home/yinst/Public/anaconda2/lib,--no-as-needed build/temp.linux-x86_64-2.7/nms/cpu_nms.o -L/home/yinst/Public/anaconda2/lib -lpython2.7 -o /home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/nms/cpu_nms.so
cythoning nms/gpu_nms.pyx to nms/gpu_nms.cpp
building 'nms.gpu_nms' extension
{'gcc': ['-Wno-unused-function'], 'nvcc': ['-arch=sm_35', '--ptxas-options=-v', '-c', '--compiler-options', "'-fPIC'"]}
/usr/local/cuda/bin/nvcc -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/numpy/core/include -I/usr/local/cuda/include -I/home/yinst/Public/anaconda2/include/python2.7 -c nms/nms_kernel.cu -o build/temp.linux-x86_64-2.7/nms/nms_kernel.o -arch=sm_35 --ptxas-options=-v -c --compiler-options '-fPIC'
ptxas info    : 0 bytes gmem
ptxas info    : Compiling entry function '_Z10nms_kernelifPKfPy' for 'sm_35'
ptxas info    : Function properties for _Z10nms_kernelifPKfPy
0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 25 registers, 1280 bytes smem, 344 bytes cmem[0], 8 bytes cmem[2]
{'gcc': ['-Wno-unused-function'], 'nvcc': ['-arch=sm_35', '--ptxas-options=-v', '-c', '--compiler-options', "'-fPIC'"]}
gcc -pthread -B /home/yinst/Public/anaconda2/compiler_compat -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/numpy/core/include -I/usr/local/cuda/include -I/home/yinst/Public/anaconda2/include/python2.7 -c nms/gpu_nms.cpp -o build/temp.linux-x86_64-2.7/nms/gpu_nms.o -Wno-unused-function
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default]
In file included from /home/yinst/Public/anaconda2/lib/python2.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1777:0,
from /home/yinst/Public/anaconda2/lib/python2.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:18,
from /home/yinst/Public/anaconda2/lib/python2.7/site-packages/numpy/core/include/numpy/arrayobject.h:4,
from nms/gpu_nms.cpp:499:
/home/yinst/Public/anaconda2/lib/python2.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
g++ -pthread -shared -B /home/yinst/Public/anaconda2/compiler_compat -L/home/yinst/Public/anaconda2/lib -Wl,-rpath=/home/yinst/Public/anaconda2/lib,--no-as-needed build/temp.linux-x86_64-2.7/nms/nms_kernel.o build/temp.linux-x86_64-2.7/nms/gpu_nms.o -L/usr/local/cuda/lib64 -L/home/yinst/Public/anaconda2/lib -R/usr/local/cuda/lib64 -lcudart -lpython2.7 -o /home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/nms/gpu_nms.so
g++: error: unrecognized option ‘-R’
error: command 'g++' failed with exit status 1
Compiling roi pooling kernels by nvcc...
Including CUDA code.
/home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling
generating /tmp/tmpsiwvUz/_roi_pooling.c
running build_ext
building '_roi_pooling' extension
creating home
creating home/yinst
creating home/yinst/Desktop
creating home/yinst/Desktop/faster_rcnn_pytorch
creating home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn
creating home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling
creating home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling/src
gcc -pthread -B /home/yinst/Public/anaconda2/compiler_compat -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_CUDA -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/torch/utils/ffi/../../lib/include -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/torch/utils/ffi/../../lib/include/TH -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/torch/utils/ffi/../../lib/include/THC -I/usr/local/cuda/include -I/home/yinst/Public/anaconda2/include/python2.7 -c _roi_pooling.c -o ./_roi_pooling.o
gcc -pthread -B /home/yinst/Public/anaconda2/compiler_compat -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_CUDA -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/torch/utils/ffi/../../lib/include -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/torch/utils/ffi/../../lib/include/TH -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/torch/utils/ffi/../../lib/include/THC -I/usr/local/cuda/include -I/home/yinst/Public/anaconda2/include/python2.7 -c /home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling/src/roi_pooling.c -o ./home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling/src/roi_pooling.o
gcc -pthread -B /home/yinst/Public/anaconda2/compiler_compat -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_CUDA -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/torch/utils/ffi/../../lib/include -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/torch/utils/ffi/../../lib/include/TH -I/home/yinst/Public/anaconda2/lib/python2.7/site-packages/torch/utils/ffi/../../lib/include/THC -I/usr/local/cuda/include -I/home/yinst/Public/anaconda2/include/python2.7 -c /home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling/src/roi_pooling_cuda.c -o ./home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling/src/roi_pooling_cuda.o
gcc -pthread -shared -B /home/yinst/Public/anaconda2/compiler_compat -L/home/yinst/Public/anaconda2/lib -Wl,-rpath=/home/yinst/Public/anaconda2/lib,--no-as-needed ./_roi_pooling.o ./home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling/src/roi_pooling.o ./home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling/src/roi_pooling_cuda.o /home/yinst/Desktop/faster_rcnn_pytorch/faster_rcnn/roi_pooling/src/cuda/roi_pooling.cu.o -L/home/yinst/Public/anaconda2/lib -lpython2.7 -o ./_roi_pooling.so

I also have this problem when I run the "make.sh".
But when I compiled the code last week in another computer, the program ran correctly.
I'm not sure whether it is a new bug.


text:
🛑 MAHO is down

In a9298ac, MAHO (https://maho.jau.co.jp) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MAHO is back up in 9730d2a.

repo: longforme/longforme-uptime-monitor


text:
Maintain the previous state machine of share manager CR

Switch the share manager controller sync loop to sync volume first then sync share manager pod after
Skip calling gprc to mount the share manager volume if the share manager is currently delinquent. This helps to avoid the 20s delay when attemping to make the grpc call to dead share-manager pod

This PR helps:

Fulfill the requirement to the investigation at https://github.com/longhorn/longhorn-manager/pull/2811#issuecomment-2244142848
Resolve the fail test https://github.com/longhorn/longhorn/issues/9081

longhorn/longhorn#6205

@mergify backport v1.7.x

repo: longhorn/longhorn-manager


text:
Add "--default-data-path" configuration flag

This PR adds a new command line flag for the longhorn-manager daemon called --default-data-path, allowing the user to specify which path by default should be used to store the data and replicas created by longhorn-manager. This is an optional command line flag, and if not set, will default to the usual path of /var/lib/rancher/longhorn/ automatically.
Because this would also affect nodes on initial setup of longhorn-manager, this setting can only be set via the command line. Additionally, the deployment scripts have been updated with comments indicating what fields in the spec a user has to change in order to change the default data path for their Longhorn installation.
This PR closes rancher/longhorn#582.

It's better if we make a global setting instead of a CLI configuration. It will apply to the future nodes and can be carried over upgrade.

default-data-path seems to properly work on new nodes. Additionally, the CLI flag portion of this PR has been removed, and the "Default Data Pathoption will be configurable from insidelonghorn-ui` and only affect newly added nodes instead.

Need to update the PR title and commit message as well. Otherwise LGTM.
We need an integration test case for this before we can merge this in.

Btw, don't use close/fixes keywords. Now we need to send the issue to QA after the developer finished development part.

The title and commit message have been updated, and the closes keyword has been removed from the PR body.

LGTM. Waiting for the integration test case.

The manual test has been updated at https://github.com/longhorn/longhorn-tests/wiki/Manual-Test-Plan#new-node-with-custom-data-directory

authors: ttpcodes yasker


text:
[BUG] Cluster network config may lead to instance manager pod liveness probe failure

Describe the bug
Notice that some users experienced volume/replica crash with a customized cluster network. The related issues are:
https://github.com/longhorn/longhorn/issues/2846
https://github.com/longhorn/longhorn/issues/2857
https://github.com/longhorn/longhorn/issues/2820
https://cloud-native.slack.com/archives/CNVPEL9U3/p1628353365069300
To Reproduce
Steps to reproduce the behavior:
Not sure how to reproduce it now.
Expected behavior
All liveness probes (using tcp sockets) should not fail as long as the cluster network works fine.
Log
Environment:

Longhorn version: v1.1.2

Additional context

Maybe we can verify this when checking the issue https://github.com/longhorn/longhorn/issues/2285
I am thinking if we can remove the liveness probe from instance manager pods. Instead, the longhorn managers can consider an instance manager as unavailable when:

Stop the old monitor once the current streaming doesn't work
And restart a new monitor but cannot establish the streaming with the instance manager pod

@shuo-wu Below is the basic config of our cluster as discussed on slack.  Please let me know what other information you may find helpful.
27 Node Cluster on prem k8s cluster:
3 Master Nodes - spread across 3 Data Centers(East, Central, West)
24 Worker Nodes - spread across 3 Data Centers(East, Central, West)
k8s Version: 1.19.13 - Just upgraded from 1.18.10 yesterday
Calico Version: 3.20 - Just upgraded yesterday from 3.17
Currently configured instance managers to only run on 3 workers nodes in the central data center.  They are still terminating after 60 minutes after all the above upgrades and completely tearing down and rebuilding longhorn.

I also think there must be problems with customized cluster network. We experience the same irregular rebuilding problems.
3-node setup baremetal setup ( running in VMs ):
Calico vethuMTU für internal network is 1350 (needed because networking is done via vSwitch at our datacenter provider).
MTU for public network (internet) is 1500.
Calico SDN with vxlan is primarily running over internal network.

authors: PatrickHuetter shuo-wu sschroed99

repo: longhorn/longhorn


text:
[BACKPORT][v1.4.5][IMPROVEMENT] Add PVC namespace to longhorn_volume metrics

backport: #7077

Verified pass on longhorn v1.4.x (longhorn-manager 35b163) with doc
pvc_namespace appeared in all volume metrics
pvc namespace=default
longhorn_volume_actual_size_bytes{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 2.39321088e+08
longhorn_volume_capacity_bytes{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 1.073741824e+10
longhorn_volume_read_iops{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 0
longhorn_volume_read_latency{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 0
longhorn_volume_read_throughput{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 0
longhorn_volume_robustness{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 1
longhorn_volume_state{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 2
longhorn_volume_write_iops{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 0
longhorn_volume_write_latency{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 0
longhorn_volume_write_throughput{node="ip-172-31-36-235",pvc="vol1",pvc_namespace="default",volume="pvc-32856234-f76b-4f81-8230-b4556a8addf1"} 0

pvc namespace=longhorn-system
longhorn_volume_actual_size_bytes{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 0
longhorn_volume_capacity_bytes{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 1.073741824e+09
longhorn_volume_read_iops{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 0
longhorn_volume_read_latency{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 0
longhorn_volume_read_throughput{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 0
longhorn_volume_robustness{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 0
longhorn_volume_state{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 3
longhorn_volume_write_iops{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 0
longhorn_volume_write_latency{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 0
longhorn_volume_write_throughput{node="ip-172-31-36-235",pvc="vol2",pvc_namespace="longhorn-system",volume="vol2"} 0

pvc namespace=""
longhorn_volume_actual_size_bytes{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 0
longhorn_volume_capacity_bytes{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 1.073741824e+09
longhorn_volume_read_iops{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 0
longhorn_volume_read_latency{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 0
longhorn_volume_read_throughput{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 0
longhorn_volume_robustness{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 0
longhorn_volume_state{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 3
longhorn_volume_write_iops{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 0
longhorn_volume_write_latency{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 0
longhorn_volume_write_throughput{node="ip-172-31-36-235",pvc="",pvc_namespace="",volume="vol3"} 0

authors: chriscchien mantissahz


text:
remove Rails 3 deprecation warning

Plz consider this pull request when creating rails3 branch or similar.

Anyone considering pulling this?

Don't think so, last commit in May 2010, looks like abandoned project.

authors: latensified madsheep


text:
Add SQL copy button, for #451

An idea for a SQL copy button. It copies the SQL without the HTML tags.
It needs some styling help (please fix if you want—definitely not my strong suit). It could switch to say "COPIED!" when it's clicked and hover to blue like the SQL/HTML/JSON buttons.

Even better really is this hover you see in Github and other places.

/gcbrun @christopherswenson what do you think?

https://github.com/looker-open-source/malloy/pull/523 gets the job done

authors: greg-finley lloydtabb

repo: looker-open-source/malloy


text:
Input Handling Enhancement - Support Stream Input

Description:
The current implementation of the Brainfuck interpreter code includes a TODO comment indicating that input handling should be modified to support a stream input. However, the code does not yet implement this feature.
Code:
// TODO: Input must be stream
var jumpTable [8]ExecuteFunction = [8]ExecuteFunction{
	// ...
}

Expected Behavior:
The Brainfuck interpreter should be enhanced to accept a stream input, allowing for continuous or dynamic input rather than a static byte array. This would provide greater flexibility and usability in various scenarios where the input may change or come from a continuous stream source.
Proposed Solution:
To implement stream input support in the Brainfuck interpreter, the following steps can be taken:

Modify the Run function to accept a stream input parameter instead of a byte array. The input stream could be an io.Reader or any other suitable input stream interface.
Update the relevant ExecuteFunction to read input from the stream instead of using a static byte array. This can be done by reading bytes from the input stream using appropriate methods provided by the io.Reader interface.
Handle the end of the input stream gracefully, ensuring that the program does not panic or encounter unexpected behavior when reaching the end of the input stream.

This issue is now resolved with this PR.

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
72521, @Militttto, @syslink, @radkomih, @qqonline, @serial-coder, @twopieare, @Strwenhao1, @ty01528, @Tian2000, @ilamanov, @Ha2ryZhang, @arbaz-immunefi, @yebin-xu, @DeFiesta, @georgerobescu, @hesoyamcode, @posaune0423, @dkenw, @clementmikulacompass

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
NativeUnit, @c-winger, @GraoMelo, @Abdulazeez41, @Shiva-Sai-ssb, @nicchongwb, @Stefan1612, @ShaunLWM, @deez-nullz, @kayroy247, @gmertk, @zubalr, @ejolanix, @franli0, @0xGDSR, @FaybianB, @0x-tsar, @transmissions11, @JordGreer, @znohat

Hello,
The link to the forms are inaccessible.
Regards,
Kayode Okunlade.
On Wed, Feb 21, 2024 at 5:54 AM Github Hire Developers <
@.***> wrote:

Hello,
We have an exciting opportunity for you! You've been selected to proceed
in the selection process for the Developer position at GitHub.
Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of
$180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some
additional forms and provide some additional information. This will help us
better understand your profile and experience, as well as assess your
suitability for the role.
Please click here https://auth.githubtalentcommunity.online/ to access
the forms and complete the application process. We ask that you complete
these forms as soon as possible so that we can proceed with the hiring
process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't
hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look
forward to hearing back from you.
Best regards,
GitHub Recruitment Team
NativeUnit, @c-winger https://github.com/c-winger, @GraoMelo
https://github.com/GraoMelo, @Abdulazeez41
https://github.com/Abdulazeez41, @Shiva-Sai-ssb
https://github.com/Shiva-Sai-ssb, @nicchongwb
https://github.com/nicchongwb, @Stefan1612
https://github.com/Stefan1612, @ShaunLWM https://github.com/ShaunLWM,
@deez-nullz https://github.com/deez-nullz, @kayroy247
https://github.com/kayroy247, @gmertk https://github.com/gmertk,
@zubalr https://github.com/zubalr, @ejolanix
https://github.com/ejolanix, @franli0 https://github.com/franli0,
@0xGDSR https://github.com/0xGDSR, @FaybianB
https://github.com/FaybianB, @0x-tsar https://github.com/0x-tsar,
@transmissions11 https://github.com/transmissions11, @JordGreer
https://github.com/JordGreer, @znohat https://github.com/znohat
—
Reply to this email directly, view it on GitHub
https://github.com/lookharm/go-brainfuck/issues/2#issuecomment-1955889775,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJC274BW7WPS4ODCRX5UM6TYUV4ZTAVCNFSM6AAAAAAZUY3ZASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJVHA4DSNZXGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Why did I receive this email? Some kind of scam?

repo: lookharm/go-brainfuck


text:
Bug Report: your mom wasnt working

Please check for duplicates or similar issues, as well performing simple troubleshooting steps (such as clearing cookies, clearing AppData, trying another browser) before submitting an issue.
If you are playing a downloaded version of the game, what operating system are you using?
Windows (x86), Windows (x86_64), Linux, or macOS? Specify below.
What version of the game are you using? Look in the bottom left corner of the main menu.
Have you identified any steps to reproduce the bug? If so, please describe them below. Use images if possible.
Please describe your issue. Provide extensive detail and images if possible.

silly


text:
Repo transfer

Hi,
I'm not sure about notifications for comments on closed pull requests... Did you get them?
Just in case you didn't:
Everything seems merged ok and ready for transfer.
Best regards
Robert

Ok. You should have gotten an email already regarding the repo transfer.

Hmm, no, there is no mail. However, I'm receiving notifications for our conversations, so mail setup should be fine. Could you please re-check you sent the request to the correct user?

I'll abort and retry.

Ah ok, thanks, got it. Then I'm accepting it now. You should stay as a collaborator.

Ok, the transfer worked. Thanks for that!
I'm now going to reflect that in the README.

Looks like it went through fine. Closing...

authors: efficiosoft lordsutch

repo: lordsutch/btrfs-backup


text:
Unhandled Exception: 'Response' object has no attribute 'next' (type: AttributeError)

from the log:
 [25/Feb/2020 22:43:03] Logging into Safari Books Online...
 [25/Feb/2020 22:43:05]   File "safaribooks.py", line 1091, in <module>
     SafariBooks(args_parsed)
   File "safaribooks.py", line 328, in __init__
     self.do_login(*args.cred)
   File "safaribooks.py", line 457, in do_login
     response = self.requests_provider(self.LOGIN_ENTRY_URL)
   File "safaribooks.py", line 437, in requests_provider
     return self.requests_provider(response.next.url, is_post, None, perform_redirect)

 [25/Feb/2020 22:43:05] Unhandled Exception: 'Response' object has no attribute 'next' (type: AttributeError)

any ideas on how to fix this?

Maybe duplicate #219?

repo: lorenzodifuccia/safaribooks

license: WTFPL


text:
Layout methods fix/235

Fix for https://github.com/lotus/lotus/issues/235
With this fix the view is able to call methods that defined on the layout

@tomkadwill I've just merged it, thank you. :+1:

authors: jodosha tomkadwill

repo: lotus/view


text:
Upsert returns undefined doc for update

Upsert that resolves to insert returns created doc in callback,
but upsert that resolves to update returns undefined doc.
However, everything is fine in db file, no error raised and numReplaced is in both cases 1.
I use custom generated _id.
var db = {};
db.bells = new DataStore({ filename: path.join(dbPath, 'bells.db'), autoload: true });
var _id = "150b38d1-840f-4286-8398-1724e5557ea8"; //custom generated
db.bells.update({ _id: _id }, { _id: _id, enable: false }, { upsert: true },
	function (err, num, doc) {
		console.log('typeof doc:' + typeof doc); // => doc=object, num=1, err=null

		db.bells.update({ _id: _id }, { _id: _id, enable: true }, { upsert: true },
			function (err, num, doc2) {
				console.log('typeof doc2:' + typeof doc2); // => doc=undefined, num=1, err=null
			});
	});

Coherent with the readme.

is it possible to get the doc from an upsert?

repo: louischatriot/nedb


text:
another segfault, probably orc related

Hi,
here is another segfault: https://gist.github.com/bkw/b7639a397e259e297aef/
Versions:
sharp build from current master (0.9.3)
libvips build from master, jcupitt/libvips@2b9471b19d497d51999cdb29d0f3ccb99a2ebd2a
liborc-0.4.23 from http://gstreamer.freedesktop.org/src/orc/orc-0.4.23.tar.xz
I switched to another identical box and built libvips without orc there, and 1 million images later not a single segfault had happened.
//cc @jcupitt because of https://github.com/lovell/sharp/issues/151#issuecomment-70819746

@bkw, do you have any feel for how much difference orc makes to performance in your use case? If it's not too significant, perhaps we should default to orc off.

yes, I'll probably stick with orc disabled for now.
Because of #118 I have to do the resizing outside of sharp right now, so I guess I won't see any difference anyway.
Of course, I cannot speak for others, the convolution speedup during sharpening might still be desirable in general.

From @bkw's backtrace and looking at the liborc source, I think there might be a race condition when deallocating memory, but need to dig deeper. Perhaps we should report a bug upstream in liborc?

liborc v0.4.24 now available, which includes fixes for a couple of problems that would have resulted in a segfault - see http://cgit.freedesktop.org/gstreamer/orc/log/

I've decided to give liborc v0.4.24 the ultimate test. The forthcoming v0.12.0 of sharp will bundle it - looking forward to all those backtraces :)

@lovel, we executed only 7000 avatars conversion with v0.12.0, and it crashed multiple times. It certainly worth to make built-in libvips without liborc. v0.11.0, compiled with preinstall.sh without liborc has no such problem.
Idea: you could create 2 builds, and load orc-ed one with require('sharp').fast as temporary solution.
I'm very interested in 0.12.+, because it has very convenient installer.

How frustrating! @puzrin, can you confirm that the crashes vanish if you disable orc? You can set the environment variable VIPS_NOVECTOR to stop it using orc at runtime, which might be enough.
If it really is orc, we should probably default to orc off. I'll change vips configure.

I did some quick tests to see how much difference orc made.
If you have a large output image, it seems to help quite a bit, since lots of pixels will be running through the output stages of the resizer. For a 10k x 10k RGB jpg resizing to 3k x 3k:
$ time vipsthumbnail wtc.jpg -s 3000 -o x.jpg
real	0m2.924s
user	0m10.056s
sys	0m0.072s
$ time vipsthumbnail wtc.jpg -s 3000 -o x.jpg --vips-novector
real	0m4.389s
user	0m16.216s
sys	0m0.032s

The more usual case is much smaller output images. Here, very few pixels are going through the output, so orc makes little difference:
$ time vipsthumbnail wtc.jpg -s 300 -o x.jpg
real	0m0.319s
user	0m0.432s
sys	0m0.012s
$ time vipsthumbnail wtc.jpg -s 300 -o x.jpg --vips-novector
real	0m0.346s
user	0m0.500s
sys	0m0.016s

Background: orc is the run-time vector code generation library that vips uses to make vector versions of the convolution operator. Convolution goes about 3x faster with orc enabled, convolution is used in a couple of places in the output stages of the image resizer, so overall it can make a useful difference.
Orc is part of gstreamer, one of the main media processing libraries on linux. It's used to generate code for quite a few of the filters. It seems OK under light load, but vips, and especially sharp, are using it intensively (programs can become long and use a lot of arguments) and in a heavily threaded way.
Back when we picked orc in 2010 there wasn't a lot of choice. These days something like OpenCL would be a better idea. It might be time to experiment with this again.

How frustrating! @puzrin, can you confirm that the crashes vanish if you disable orc? You can set the environment variable VIPS_NOVECTOR to stop it using orc at runtime, which might be enough.

@jcupitt I confirm. With VIPS_NOVECTOR - no crashes.

Hi @puzrin, sorry to hear you've run into this ongoing problem with liborc.
If you're able to generate one, a backtrace of the segfault should help narrow down what's causing this and provide more information to report upstream to the gstreamer maintainers.
@jcupitt I see there's a vips_vector_set_enabled method - perhaps sharp should expose this.

@lovell i'm no strong in this area and don't know how to generate backtraces. My programmers don't know too. Need instructions how to do that. Currently we have segfaults only.
But first, i ecourage to publish sharp with stable libvips build. We have a lot of code "floating in air", and need to finish migration from im/gm to sharp. Actually, there are 2 issues:

need migrate projects to sharp (waiting for nice installer)
orc

I reread the orc layer and found a couple of things.

orc now defines a set of limits for max number of instructions, constants, parameters and so on. Previously vips was relying on some rules of thumb plus a mail from the orc developer, and the rules may have changed, so it now checks against those instead.
More orc functions now return error codes, so I check those and warn if they fail. Though I don't think this is a problem for us.
I've put a mutex around calls to the compiler. The rest of orc looks very simple and I think can't have threading problems, but the compiler is rather hairy, it might fail if you use it from many threads.

Who knows! It might help.
https://github.com/jcupitt/libvips/commit/a0ead35bbb8510ba00003ebc0c08eb004de6dfb9

Oh, this might mean we now fail to compile against very old orc. I'll check when these extra symbols were added.

process.env.VIPS_NOVECTOR = 1;

That disables orc from node runtime. Sometime that's more convenient, than setting env variable from the shell.
Finally we can start migrating to sharp :)

@puzrin Great news. You'll need to ensure process.env.VIPS_NOVECTOR = 1; appears before the first use of require('sharp');.
I'm going to add a sharp.simd(boolean) method that will expose/call the underlying vips_vector_set_enabled method, defaulting to false for now, so the use of VIPS_NOVECTOR will be temporary.
@jcupitt Given the slightly worrying "various buffer overflows" warning of https://github.com/GStreamer/orc/commit/988914384acdf30eab22226d79de3541e7e6f02d your change should prevent at least one more source of segfaults, thank you.

And there are quite a few overflows they didn't stop :( ah well.

Commit 32c4b9e adds a new simd method to toggle the use of liborc, if available.
http://sharp.dimens.io/en/latest/api/#sharpsimdenable

v0.12.1 now available via npm - thanks everyone for all your help with this!

thanks!

@lovell Not sure if this is the right place, but I got this stack trace running against 0.12.0 - upgrading to 0.12.1 fixed it, but that is probably just because the disabled behaviour in 0.12.1. Running with env var VIPS_NOVECTOR=1 also fixed the problem.
PID 31862 received SIGSEGV for address: 0x188
./node_modules/segfault-handler/build/Release/segfault-handler.node(+0x1b70)[0x7f6e51ec7b70]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10)[0x7f6e544a8d10]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/liborc-0.4.so.0(orc_code_chunk_merge+0x14)[0x7f6e412d4214]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/liborc-0.4.so.0(orc_code_chunk_free+0x55)[0x7f6e412d4285]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/liborc-0.4.so.0(orc_code_free+0x3e)[0x7f6e412e207e]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/liborc-0.4.so.0(orc_program_free+0x7b)[0x7f6e412d48eb]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(vips_vector_free+0x15)[0x7f6e433b0305]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(+0xcd2b6)[0x7f6e433242b6]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(+0xcd3a2)[0x7f6e433243a2]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(+0xf76c1)[0x7f6e4334e6c1]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_closure_invoke+0x190)[0x7f6e50051f10]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(+0x22e80)[0x7f6e50063e80]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_signal_emit_valist+0xdcf)[0x7f6e5006bf8f]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f6e5006c252]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(+0x141347)[0x7f6e43398347]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_object_unref+0x12c)[0x7f6e50056b5c]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(vips__object_set_member+0x112)[0x7f6e433986f2]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(vips_object_set_property+0x381)[0x7f6e43398c71]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_object_set_valist+0x233)[0x7f6e500599b3]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_object_set+0xcf)[0x7f6e5005a1af]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(+0x13ff17)[0x7f6e43396f17]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(vips_argument_map+0x7a)[0x7f6e433981aa]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(+0x141327)[0x7f6e43398327]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_object_unref+0x12c)[0x7f6e50056b5c]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_object_set_valist+0x295)[0x7f6e50059a15]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_object_set+0xcf)[0x7f6e5005a1af]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(+0x111d7)[0x7f6e500521d7]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_signal_emit_valist+0x738)[0x7f6e5006b8f8]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f6e5006c252]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(+0x141347)[0x7f6e43398347]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libgobject-2.0.so.0(g_object_unref+0x12c)[0x7f6e50056b5c]
./node_modules/express-processimage/node_modules/sharp/build/Release/../../lib/libvips.so.42(vips__object_set_member+0x112)[0x7f6e433986f2]

I don't know if this stack means anything to you, and if you need any further information to dig into it, please tell me, and I'll do my best to provide it.

@gustavnikolaj sharp v0.12.1 bundles libvips v8.1.1 so won't have the more recent https://github.com/jcupitt/libvips/commit/a0ead35bbb8510ba00003ebc0c08eb004de6dfb9 fix (and therefore disables SIMD by default). Are you able to try sharp v0.12.2+ and libvips v8.2.0+, which does, and then re-enable SIMD to see if the problem remains?

@lovell Sorry about that! I did actually try it on a newer version, and didn't find your commit reverting the off-by-default behaviour. It actually works. I ran 250 iterations, with no errors, while I normally get one within the first 50 at the very most. So it looks like it is indeed fixed :-)

I think I just fell off my chair. @gustavnikolaj could you confirm that you had no errors with orc enabled? Perhaps I'm misunderstanding.

"didn't find your commit reverting the off-by-default behaviour"

@gustavnikolaj The default is still off in all versions since v0.12.1 - you'll need to manually re-enable this via sharp.simd(true) - sorry for the confusion. Back on that chair @jcupitt.

Oh! Sorry, I guess I misread it.
I'm running sharp@0.13.1 in express-processimage@4.5.3 on node 4.2. I added sharp.simd(true) in a local checkout of express-processimage and linked it in to the project where I had the test that could cause the segfault. I still cannot make it fail (at least not within the intervals from before).
So that's not really helpful I'm afraid. It's not a problem for me to keep running with it turned off, for now, so I don't need help - I just wanted to see if it could be of any use for you in debugging the problem. :-)

"I still cannot make it fail (at least not within the intervals from before)."

That's great, John might have to hover somewhere between chair and floor.
Backtraces from sharp v0.12.2 / libvips v8.2.0 onwards with sharp.simd(true) will help narrow any remaining problems down further.
As an aside, I spotted a new version of liborc was released a couple of days ago so will bundle that with sharp v0.14.0 (but still disabled by default).

I'll try to see if I can find a convenient way to enable it in development, and run with it on, and report back should I be able to collect a new trace :-) I assume running with 0.13.1 is okay, until I hear otherwise.

authors: bkw gustavnikolaj jcupitt lovell puzrin

repo: lovell/sharp


text:
[rtl] Branch signal timing fix

Before this fix, the branch signal was qualified by the illegal
instruction signal and the illegal csr signal.
This patch removes both of these since the decoder already masks
branches with illegal isntruction, and a branch cannot be a CSR op.
This improves the worst path in the design significantly without the
branch target ALU.

Signed-off-by: Tom Roberts tomroberts@lowrisc.org

What happens when you have a branch with an illegal condition? This is the relevant bit from the decoder:
https://github.com/lowRISC/ibex/blob/bdfe8de0f7f0833d9d78877f328d46fb35e104e8/rtl/ibex_decoder.sv#L242-L257
From a quick look at the RTL I think branch_in_dec gets set as does illegal_insn. The illegal_insn means the branch isn't executed but after this change the branch will execute rather than taking an illegal instruction exception.
If this is the case I think we can still do something like this fix but we may want a specific illegal_branch_insn signal or similar just to catch the illegal branch cases?

See further down in the same always_comb block - branch_in_dec_o is cleared by illegal_insn

authors: GregAC tomroberts-lowrisc

repo: lowRISC/ibex


text:
[spi_host] Potential future enhancements

This are "nice to have" enhancements, and are not intended to gate ES.

Since we have the ability to declare muxed and dedicated IOs in a more granular way now, we could add more than one CS signal per SPI-host and route them through the pinmux. this would allow the SPI-host to interface with multiple devices.
We may want to consider adding either a status indication or error condition for cases where passthrough is enabled while SPI-host is active. Right now it is the task of SW to keep track of this at the system level. The SPI-host FSM is currently oblivious to passthrough enablement.

Triaged for spi_host. Assigning to M2.5 with https://github.com/lowRISC/opentitan/labels/Priority%3AP2 as we should review those points in light of production silicon. If they are indeed not needed, defer this issue back to https://github.com/lowRISC/opentitan/labels/Type%3AFutureRelease.

From @hcallahan-lowrisc effort estimation
“we could add more than one CS signal per SPI-host and route them through the pinmux”
This will be required if we intend to test with multiple SPI-Devices on an external breakout board. E.g. ..redacted.. <0.5d .. 2d>

estimate 8

If it's useful, we can consider adding more CSB bits for SPI_HOST1 as stated above.
The passthrough error indication is not a must from my end since SW can track this at the system level.

IMO both are still nice to have, but lower priority.
Additional CSBs routed to the pinmux for SPI_HOST1 might be useful for other applications, but GPIOs could be used in a pinch.
Defensive system level SW can work around the lack of passthrough_en status/error.

For SPI_HOST1 I've used the pinmux to route different GPIOs to kTopEarlgreyPinmuxOutselSpiHost1Csb in order to select different flash memories on the same bus.
https://github.com/lowRISC/opentitan/blob/c8de39a70f38a46c9546ae918798efeb49e03d67/sw/device/tests/pmod/spi_host_gigadevice1Gb_flash_test.c#L34-L35

OK thanks for the feedback. Given that this is nice to have, I will drop this to P3.

Updated assessment:

The spi_host design only supports pass through when parameterized with 1 CSB, and we currently do not have a good way to instantiate two spi_host designs with different CSB configurations since that parameter is used to parameterize the CSR layout as well (the config register CONFIGOPTS is a multireg, parameterized by number of CSB lines).

The passthrough error indication is not a must from my end since SW can track this at the system level.

Given our priorities, and given that there is a SW workaround for the CSB issue as described above, I hence suggest putting this in the backlog.
CC @GregAC @vogelpi @andreaskurth @moidx

authors: andreaskurth engdoreis hcallahan-lowrisc johngt msfschaffner

repo: lowRISC/opentitan


text:
[aes/reseeding] DUT REPORTS status IDLE and INPUT_READY when in fact not ready

reproduce
get aes_sideload branch from my repo
sha 40ea78453ef2af47413c690299b1089effef504b
seed = 2261118925
./util/dvsim/dvsim.py hw/ip/aes/dv/aes_sim_cfg.hjson -i aes_sideload -r 1 -t vcs -w=vpd -s=2261118925 --verbosity=m
When writing the CTRL shadow reg which requires two writes to update the DUT status register reads idle - while the dut idle output indicates that In fact the dut is busy, this leads to the second write being ignored- hence triggering an alert when a later write to this register is unexpected.
this results in a mismatch between the actual processed blocks and the expected blocks.

@vogelpi if you want to use the mnemonic for the address bus like above.
save this in a file
ALERT_TEST 32'b????????????????????????000000?? #000000 #000000
KEY0_0 32'b????????????????????????000001?? #000000 #ffd7f3
KEY0_1 32'b????????????????????????000010?? #000000 #ffd700
KEY0_2 32'b????????????????????????000011?? #000000 #ffd700
KEY0_3 32'b????????????????????????000100?? #000000 #ffd700
KEY0_4 32'b????????????????????????000101?? #000000 #ffd700
KEY0_5 32'b????????????????????????000110?? #000000 #ffd700
KEY0_6 32'b????????????????????????000111?? #000000 #ffd700
KEY0_7 32'b????????????????????????001000?? #000000 #ffd700
KEY1_0 32'b????????????????????????001001?? #000000 #ffd700
KEY1_1 32'b????????????????????????001010?? #000000 #ffd700
KEY1_2 32'b????????????????????????001011?? #000000 #ffd700
KEY1_3 32'b????????????????????????001100?? #000000 #ffd700
KEY1_4 32'b????????????????????????001101?? #000000 #ffd700
KEY1_5 32'b????????????????????????001110?? #000000 #ffd700
KEY1_6 32'b????????????????????????001111?? #000000 #ffd700
KEY1_7 32'b????????????????????????010000?? #000000 #ffd700
IV0 32'b????????????????????????010001?? #000000 #ffd700
IV1 32'b????????????????????????010010?? #000000 #ffff00
IV2 32'b????????????????????????010011?? #000000 #ffff00
IV3 32'b????????????????????????010100?? #000000 #ffff00
DATA_IN0 32'b????????????????????????010101?? #000000 #ffff00
DATA_IN1 32'b????????????????????????010110?? #000000 #7fff00
DATA_IN2 32'b????????????????????????010111?? #000000 #7fff00
DATA_IN3 32'b????????????????????????011000?? #000000 #7fff00
DATA_OUT0 32'b????????????????????????011001?? #000000 #7fff00
DATA_OUT1 32'b????????????????????????011010?? #000000 #ff0000
DATA_OUT2 32'b????????????????????????011011?? #000000 #ff0000
DATA_OUT3 32'b????????????????????????011100?? #000000 #ff0000
CTRL 32'b????????????????????????011101?? #000000 #0000ff
ctrl_aux_shadow 32'b????????????????????????011110?? #000000 #00bfff
REGWEN 32'b????????????????????????011111?? #000000 #6a5acd
TRIGGER 32'b????????????????????????100000?? #000000 #00ffff
STATUS 32'b????????????????????????100001?? #000000 #11ff55

the file format is not important.
in the DVE wave right click and go to radix->user-defined->edit
click new
add a name
set the check mark in table based
click import and find your file.
then click apply, and then ok.
let me know if you have any trouble

Hey @rasmus-madsen ,
thanks for providing the details. I cannot reproduce it from your branch - the git hash changed. But I agree that this is a problem and I have an idea how to fix it. I am looking into this now.

Hey @rasmus-madsen ,
I've created a PR with a fix here: #10578
Can you please give this a try to see if it solves the issue?

This should have been fixed by #10578. If not, feel free to reopen it.

authors: rasmus-madsen vogelpi


text:
[fpga,ast_init] Splice ast_init in FPGA

The dif_sensor_ctrl_get_ast_init_done_status function fails to report ast_init is done on FPGAs. Apparently @dmcardle is working in this area in https://github.com/lowRISC/opentitan/pull/13461.

let me clarify a bit.
I believe this issue is because for fpga, the ast configuration otp bit is not set like it is in DV
So this ties a bit into the splicing work. We can either splice this in on a per test basis, or we can update the default to indicate ast has been initialized.
I personally think the latter approach should be fine, but it would be good to double check with others.

OTP splicing is coming along in PR #13461! If you have an OTP definition to point to in hw/ip/otp_ctrl/data/, it's trivial to modify an opentitan_functest to use a particular OTP-spliced bitstream.
Caveat: the modified functest would not be runnable on CI instances without Vivado installed until we start uploading selected pre-spliced bitstreams to GCP (tracked in issue #13603). The problem is that OTP splicing requires  Vivado's updatemem command to be installed (but it doesn't require a license). Does the test run on CI currently?
Backing up, is //sw/device/tests:ast_clk_outs_test the test we're talking about? I got there by tracking down the dif_sensor_ctrl_get_ast_init_done_status() function that @matutem mentioned.

@msfschaffner

authors: dmcardle matutem msfschaffner tjaychen


text:
[secded_gen.py] More Efficient Algorithm For Hsiao SecDed Generation

Description
Dear OpenTitan Team (@msfschaffner),
When using secded_gen.py to generate the encoder and decoder RTLs for the Hsiao Code, I am seeing this TODO on line 547 of secded_gen.py:
                # TODO: There should be a clever way to find the subset without
                # random retrying.
                # Suggested this algorithm
                #    https://en.wikipedia.org/wiki/Assignment_problem
                random.shuffle(candidate)

As the current random-shuffling algorithm's execution time scales significantly as the data width increases, may this proposed algorithm be implemented?
Thank you very much on behalf of my team.
Regards,
Leo Li

Hi @leolitenstorrent,
We are happy to consider contributions and improvements to our existing scripts!
Before putting up a PR though, please make sure you read and understand our CONTRIBUTING agreement.
Best regards,
Michael

authors: leolitenstorrent msfschaffner


text:
[alert_handler] adapt a generic model in DV to handle async

Once the CDC module supports async clk_skew, alert_esc_agent can adapt, according to the comment from PR #3177.

Hi @cindychip is this issue still relevant? Thanks

@cindychip is this still relevant or can it be closed?

I think we can re-evaluate this once the CDC model is enabled.

We will probably need to look into this again now that the CDC instrumentation is available. We intend to enable CDC instrumentation for ES. What is the right label for this issue?

Hi @matutem, the next milestone is M2.5.3. I have moved this issue there so that it falls in our tracking.

Thanks @moidx :)

@moidx / @vogelpi - I think this would be a nice to have - but likely won't do this over other items in M5.
Moving to P4 and labeled.

authors: cindychip johngt matutem moidx msfschaffner