How can we share a bus between multiple drivers?

It is quite typical to have multiple I2C or SPI devices hanging on the same bus, but with the current scheme and move semantics the driver is taking possession of the handle, blocking the use of multiple chips at the same bus which is totally legal and (at least) for the blocking APIs should also be safe.
@japaric Should those bus types be made Copy?

How can we share a bus between multiple drivers?

There are a few ways:

You destruct the driver to get back the I2C handle and pass that to the other driver

let mut driver_a = DriverA::new(i2c);
driver_a.stuff();
let i2c = driver_a.release();

let mut driver_b = DriverB::new(i2c);
driver_b.other_stuff();

You use a RefCell

// these blanket implementations should be in embedded-hal
impl<'a, I> blocking::i2c::Write for &'a RefCell<I> where I: blocking::i2c::Write { .. }
// repeat for all the other traits

let shared_i2c = RefCell::new(i2c);

let mut driver_a = DriverA::new(&shared_i2c);
let mut driver_b = DriverB::new(&shared_i2c);

driver_a.stuff();
driver_b.other_stuff();

You tweak the driver API to not own the I2C bus (I think this may be the best approach)

let mut driver_a = DriverA::new(&mut i2c);
let mut driver_b = DriverB::new(&mut i2c);

driver_a.stuff(&mut i2c);
driver_b.other_stuff(&mut i2c);

for the blocking APIs should also be safe

Should those bus types be made Copy?

I'm not sure if it being Copy-able would be memory safe in every single scenario but it would certainly be error prone in the presence of preemption:
app! {
    resources: {
        statci A: DriverA;
        statci B: DriverB;
    },

    tasks: {
        EXTI0: {
            path: exti0,
            priority: 1,
            resources: [A],
        },

        EXTI1: {
            path: exti1,
            priority: 2,
            resources: [B],
        },
    },
}

fn init(p: init::Peripherals) -> init::LateResources {
    // ..
    let i2c_alias: I2c = i2c; // due to `Copy`-ness

    init::LateResources { A: DriverA::new(i2c), B: DriverB::new(i2c_alias) }
}

fn exti0(r: &mut EXTI0::Resources) {
    r.A.stuff();
}

fn exti1(r: &mut EXTI0::Resources) {
    // can preempt `exti0` midway some operation on the I2C bus
    r.B.other_stuff();
}

You destruct the driver to get back the I2C handle and pass that to the other driver

Sure, but that's quite useless.

You use a RefCell

That is interesting. I should have a play with that.

You tweak the driver API to not own the I2C bus (I think this may be the best approach)

I tried but couldn't get it to compile without nasty tricks. This is not easy to implement on chips that have freely selectable pins, at least that's my experience. I also haven't quite figured out how to implement the non-blocking trains; maybe you should try non-STM32 MCUs some time to get a feeling for the different peripheral implementations out there. 😉

I'm not sure if it being Copy-able would be memory safe in every single scenario but it would certainly be error prone in the presence of preemption:

Yes, I agree. Copy-able traits in the presence of preemption are probably a bad idea. You really don't want an interrupt handler to take over the bus in a middle of a transfer.

You use a RefCell

You tweak the driver API to not own the I2C bus (I think this may be the best approach)

How will this work with RTFM?
    let mut i2c = I2c::i2c1(
        p.device.I2C1,
        (scl, sda),
        &mut afio.mapr,
        i2c::Mode::Fast { frequency: 400000, duty_cycle: i2c::DutyCycle::Ratio16to9 },
        clocks,
        &mut rcc.apb1,
    );

    let si5351 = SI5351::new(&mut i2c, false, 25_000_000).unwrap();

    let _ = ssd1306::init(&mut i2c);
    let _ = ssd1306::pos(&mut i2c, 0, 0);
    let _ = ssd1306::print_bytes(&mut i2c, b"Send ASCII over serial for some action");'

    init::LateResources {
        SI5351: si5351,
        I2C: i2c
    }

Since the value i2c is move'd when constructing init::LateResources, all the references to it will break. Same for the RefCell solution.

@japaric I tried the RefCell approach and it works great (at least in my limited testing). I'll submit a PR for review later.

@therealprof awesome. I had this on my TODO list as well. My 2 cents why I think this will be the most flexible approach:

You destruct the driver to get back the I2C handle and pass that to the other driver

This is fine as long as the driver doesn't hold any state. For example: if you need the currently set measurement resolution to correctly interpret the sensor readings. You could probably design the driver to be able to attach/detach to a bus and manage the driver state independently. But this results in extra work for the driver implementer and the user.

You tweak the driver API to not own the I2C bus (I think this may be the best approach)

I first favored this method but then realized this would probably make hardware interface (I2C, SPI, ...) agnostic sensor traits impossible (I might have overseen sth. here, because of my not so extensive Rust knowledge). The trait methods would also need to pass the bus around and something like this would not work.
pub trait Thermometer {
    type Error;

    fn temp(&mut self) -> Result<f32, Self::Error>;
}

The RefCell approach would allow for minimal hardware interface management on the driver side and also allow bus independent trait implementation. I'm really looking forward to your PR and testing it.

And also let's not forget that it's quite common to need additional resources instead of just the bus itself. For I2C (and to a lesser extend) SPI there're often separate interrupt pin(s) and for SPI one often needs to worry about a chip select pin as well. The complexity of the solution to such an approach could explode rather quickly.

I left a comment in https://github.com/japaric/embedded-hal/pull/55#issuecomment-371998537 about the shortcomings of the "put the resource protection (e.g. RefCell) in the driver" approach.

You could probably design the driver to be able to attach/detach to a bus and manage the driver
state independently.

I think this might be the way to go. You design your driver as having two type states: one where it
owns the I2C bus and one where it doesn't. Something like this:
/* embedded-hal */

// imagine this is one of the blocking I2C traits
trait I2c {
    /* .. */
}

/* sensor1 */

// Only the sensor state
// The type parameter `I` is mainly to forbid the following scenario: you
// initialize the sensor using I2C1, then you perform some op on it using I2C2
// and then another op using I2C3.
pub struct State<I>
where
    I: hal::I2c,
{
    // ..
    i2c: PhantomData<I>,
}

pub fn init<I>(i2c: &mut I) -> State<I>
where
    I: hal::I2c,
{
    // ..
}

impl State<I> {
    pub fn take<I>(self, i2c: I) -> Owned<I>
    where
        I: I2c,
    {
        // ..
    }

    pub fn borrow<I>(&mut self, i2c: &mut I) -> RefMut<I>
    where
        I: I2c,
    {
        // ..
    }
}

struct Owned<I>
where
    I: hal::I2c,
{
    i2c: I,
    state: State,
}

impl Owned<I> {
    pub fn release<I>(self) -> (State, I)
    where
        I: I2c,
    {
        // ..
    }

    pub fn accel(&mut self) -> u16 {
        // defer to RefMut
        self.as_ref_mut(|s| s.accel())
    }

    fn as_ref_mut<R, F>(&mut self, f: F)
    where
        F: FnOnce(&mut RefMut<I>) -> R,
    {
        f(&mut RefMut {
            i2c: &mut self.i2c,
            state: &mut self.state,
        })
    }
}

pub struct RefMut<'a, I>
where
    I: hal::I2c,
{
    i2c: &'a mut I,
    state: &'a mut State,
}

impl RefMut<'a, I> {
    pub fn accel(&mut self) -> u16 {
        // ..
    }
}

/* app */
fn main() {
    let mut i2c: I2c1 = ..;

    // neither operation takes ownership of `i2c`
    let sensor1: sensor1::State<I2c1> = sensor1::init(&mut i2c);
    let sensor2 = sensor2::init(&mut i2c);

    // takes ownership of `i2c`
    let mut sensor1: sensor1::Owned<I2c1> = sensor1.take(i2c);
    let g = sensor1.accel();
    let (sensor1, mut i2c) = sensor1.release();

    // doesn't take ownership of `i2c`
    let m = sensor2.borrow(&mut i2c).mag();
    let ar = sensor2.borrow(&mut i2c).gyro();
}

The Owned variant is required to support async operations that involve Futures and/or
Generators: async code doesn't like (mutable) references (*) (unless they have 'static
lifetime) -- everything needs to be passed by value. RefMut is mostly a convenience to avoid
having to take - release on every I2C operation / handover. If you are going to deal with only
one I2C slave you can use the Owned variant and your code will look pretty much the same as it
looks today.
(*) Actually that's another reason why storing a reference to a RefCell / Mutex in the driver
is not as flexible as this approach.

@ilya-epifanov

How will this work with RTFM?

If you are going to do blocking operations in your tasks store I2c and State as resources and
use RefMut / borrow:
fn task1(r: EXTI0::Resources) {
    let g = r.SENSOR1.borrow(r.I2C1).accel();
}

fn task1(r: EXTI1::Resources) {
    let ar = r.SENSOR2.borrow(r.I2C1).gyro();
}

If you are going to use the DMA store Option<I2c> and Option<State> as resources and use
Owned / take:
fn task1(r: EXTI0::Resources) {
    let sensor1: sensor1::State<_> = r.SENSOR1.take().unwrap();
    let i2c = r.I2C.take().unwrap();

    let pending_transfer = sensor1.take(i2c).mag_dma();

    // send `pending_transfer` to some other task, etc.
}

@therealprof

And also let's not forget that it's quite common to need additional resources instead of just the
bus itself. For I2C (and to a lesser extend) SPI there're often separate interrupt pin(s) and for
SPI one often needs to worry about a chip select pin as well.

The NSS / NCS / interrupt pin can be permanently stored in the State struct; no need to move them
out -- it's not like you are going to share any of those pins between different sensors.

@japaric I'll give your idea a spin.

The NSS / NCS / interrupt pin can be permanently stored in the State struct; no need to move them
out -- it's not like you are going to share any of those pins between different sensors.

I would not necessarily say that this is always the case. Pinsharing is not quite as uncommon as it seems and used for all kinds of stuff like measurements triggering, resets and sometimes they're also muxed (though in that case you'd probably need an alternative PIN driver anyway).

@japaric This puts quite a few additional requirements on each individual driver without explicitly defining what they are. I would rather prefer a solution that requires the driver HAL implementation to make sure shared use is safe (by disabling interrupts if necessary) or the user to use a safe mechanism for sharing the bus, same as we already do when sharing resources internally.

@japaric Just to float another idea: How about a generic proxy driver? The proxy would be initialised with some peripheral it would own, e.g. the initialised I2C bus and then you could use this proxy driver to request multiple proxy handles implementing the very same trait(s) which can be passed to a driver. Internally the proxy driver would ensure that only a single transfer is active at a time.

@therealprof That sounds like it would push all the synchronization concerns to the driver crate; meaning that the driver crate would have to be aware of rtfm::Resource, rtos1::Mutex, rtos2::Mutex, etc. and that it would need different proxy types -- one for each RTOS it supports. That still has the coupling problem I mentioned. Or did you mean something else? How would this proxy you are thinking of look like?

@japaric Well, the idea of the proxy is that only the proxy needs to be concerned with the locking of the multiplexed resources instead of each individual user of the traits so it can be generic and will only cause the overhead if it is actually used.
I'm toying around with an implementation of such a proxy for I2C but I'm not happy with the interface and not sure whether my Rust-Fu is already sufficient to make it work.

I'm giving up. I sunk the better part of 2 days into it but I cannot get it to work due to the freakiness of Rust around mutable sharing. Things I've tried including encapsulating the RefCell solution so I can add locking; this one failed due to the inability to hand out proper I2C handles implementing the traits. Another thing was handing out objects initialised with closures to implement the traits which doesn't work due to not statically known size of all parameters.
It's really sad that I'm not to solve such a critical issue with all the drivers being worked on. If we have to change the interfacing and break all drivers to support such an important thing that'd be really a blow to embedded Rust.

Roughly following the example by @wez, in JoshMcguigan/tsl256x@8315f1f2a92665107b17d9155053c8109524f6d1 I updated a driver I've been working on to borrow the I2C bus, rather than taking exclusive ownership.
To keep it simple, rather than implementing two structs (owned and borrowed) to wrap my sensor type, I just modified each method on the sensor struct to take a &mut i2c. I believe that makes my sensor struct analogous to the Borrowed struct. As for the Owned struct, it should be trivial for users of the driver to implement that behavior on their own, or for it to be added to the driver in the future, as shown below:
struct Owned<I2C> {
    sensor: Tsl2561<I2C>,
    i2c: I2C,
}

let mut i2c = I2c::i2c1(p.I2C1, (scl, sda), 400.khz(), clocks, &mut rcc.apb1);

let mut sensor = Tsl2561::new(&mut i2c).unwrap();

let mut sensor_with_bus = Owned { sensor, i2c };

sensor_with_bus.sensor.power_on(&mut sensor_with_bus.i2c);

My goal was to come up with a solution which minimizes the complexity of the driver crates, so as to not discourage people from creating drivers, while also solving the bus sharing problem. Admittedly, my knowledge of how async plays into this is weak, so I may be missing something significant on that front. Any good resources for learning more about async drivers would be appreciated.
That said, I do think it is important that we try as a community to standardize on a solution here, so that driver users are well as driver developers get a consistent feeling across the various drivers. Any thoughts on this approach vs  the approach taken by @wez vs the original suggestion by @japaric?

I think this is a very important issue and an a standardized and ergonomic solution is very much needed. Out of all the proposed solutions, I think @therealprof's proxy idea is the best. I wrote a little implementation to show how I would do it. You can find it here: i2c-proxy-demo
The concept consists of 3 components:
BusMutex
A trait which abstracts over different synchronization primitives.  It has two methods, one to create a mutex and one to lock the mutex for the duration of a closure:
pub trait BusMutex<T> {
    fn create(v: T) -> Self;
    fn lock<R, F: FnOnce(&T) -> R>(&self, f: F) -> R;
}

This trait is implemented in the device crates (eg. cortex_m) that define the Mutex types.
BusManager
The bus manager own the actual bus peripheral and hands out proxy objects for the devices.
When creating the bus manager, you have to specify, which mutex type you want to use:
// Init i2c bus

let bus = proxy::BusManager::<cortex_m::interrupt::Mutex<_>, _>::new(i2c);

let device_a = DeviceA::new(bus.acquire()).unwrap();
let device_b = DeviceB::new(bus.acquire()).unwrap();

The bus manager should ideally be a part of embedded_hal. This is not an issue, because it is very generic:
pub struct BusManager<M: BusMutex<cell::RefCell<T>>, T>(M, ::core::marker::PhantomData<T>);

BusProxy
The proxy object which will be created by the bus manager. This object implements all bus traits (eg. i2c::Write) that the underlaying peripheral implements.
Should also be a part of embedded_hal.

Examples for those types/traits can be found in proxy.rs
This design has a few advantages:

It solves the issue that a proxy would require knowledge of synchronization.
It works with all the other solutions proposed here, so driver crates written without any workaround, crates using RefCells, and crates using the type state approach can all be used with this implementation.
No additional work for either driver or application developers. The bus proxy handles synchronization transparently, so developers can focus on the logic of their code instead of how to manage access to the peripheral.

I feel like the type state approach lacks in the last point, both sides need to do a lot more work to do something, that is so fundamental to using i2c or other bus types.
The proxy approach does not require any additional code to be written, but it does have a runtime cost. I think that is ok, because with other approaches, the application developers would have to implement synchronization themselves which would end up looking similar. But this is definitely something, where the type state approach is better.

I'm running into a similar issue (and have discussed it in mozilla#rust-embedded). In my current, specific case, multiple peripherals need to rely on a configurable clock, and the peripherals must be invalidated if the clock changes. What doesn't work but I'd like to make work would be something akin to:
struct HSI16Clock {
    div4: bool,
}
struct LSEClock;

impl HSI16Clock {
    fn new(div4: bool) -> Self { HSI16Clock{ div4 } }
}

enum SerialClock<'clk> {
    HSI16(&'clk HSI16Clock),
    LSE(&'clk LSEClock),
}

impl<'clk> SerialClock<'clk> {
    fn release(self) {}
}

struct Serial<'clk> {
    clk: &'clk SerialClock<'clk>,
}

impl<'clk> Serial<'clk> {
    fn destruct(self) {}
}

fn main() {
    let sc = HSI16Clock::new(false);
    let c = SerialClock::HSI16(&sc);
    let mut s1 = Serial{ clk: &c };
    let mut s2 = Serial{ clk: &c };

    // time to reconfigure slow down the clock!
    s1.destruct();
    s2.destruct();
    c.release();
    let sc = HSI16Clock::new(true);
}

(that code doesn't work and I'm not sure how to make it work.)

I spent some time scratching this itch, and I think I've come up with a decent solution. It is an implementation of the concepts discussed here. This seems like a reasonable place to request feedback.
The actual crate itself is still very rough, but you can see an (untested) implementation of the ideas in this repository. The idea is this: when you configure a peripheral, you must operate within the context of that peripheral's configuration. A code example is probably the best way to explain it:
fn main() -> ! {
    let p = cortex_m::Peripherals::take().unwrap();
    let d = stm32l0x1_hal::stm32l0x1::Peripherals::take().unwrap();
    let mut syst = p.SYST;
    let mut rcc = d.RCC.constrain();
    let mut pwr = d.PWR.constrain();
    let mut flash = d.FLASH.constrain();

    // Configure the Power peripheral to raise the VDD. The VDD range has implications for the
    // maximum clock speed one can run (higher voltage = higher MHz). As such, you want to make
    // sure this cannot change unless you are prepared to invalidate your clock settings.
    pwr.set_vcore_range(stm32l0x1_hal::power::VCoreRange::Range1)
        .unwrap();

    pwr.power_domain(&mut rcc, |rcc, mut pwr_ctx| {
        // Within the closure, we are guaranteed that VDD will not change, as to do so requires
        // mutating `pwr`! The PowerContext `pwr_ctx` contains information we need to make
        // decisions based on the VDD and VCore levels available to us. Furthermore, a PowerContext
        // can only be obtained within this closure, and is required elsewhere.

        // Every time we loop, we will turn the LSE on and off. Use has_lse to track desired state.
        let mut has_lse = false;

        // Enable the system configuration clock so our changes will take effect.
        rcc.apb2.enr().modify(|_, w| w.syscfgen().set_bit());
        while !rcc.apb2.enr().read().syscfgen().bit_is_set() {}

        // Request that the HSI16 clock be turned on and divided by 4.
        rcc.hsi16.enable();
        rcc.hsi16.div4();

        // Use the prescaled 4 MHz HSI16 clock for SYSCLK (which drives SysTick)
        rcc.sysclk_src = stm32l0x1_hal::rcc::clocking::SysClkSource::HSI16;

        loop {

            if has_lse {
                rcc.lse = Some(stm32l0x1_hal::rcc::clocking::LowSpeedExternalOSC::new());
            } else {
                rcc.lse = None;
            }

            rcc.clock_domain(&mut flash, &mut pwr_ctx, |mut clk_ctx, _| {
                // Within this closure, similarly to `power_domain`, we are assured that the clock
                // configuration cannot change. You cannot turn a clock on or off because we've
                // already mutably borrowed `rcc`. The `clk_ctx` provides clock speed information
                // that would be useful to clocked peripheral busses.

                // Configure the SysTick frequency.
                syst.set_clock_source(SystClkSource::External);
                syst.set_reload(clk_ctx.sysclk().0 / 8); // 1s
                syst.clear_current();
                syst.enable_counter();
                syst.enable_interrupt();

                // Here we would construct I2C or Serial peripherals based on `clk_ctx`
                // let mut usart2 = Serial::usart2(d.USART2, (tx, rx), Bps(115200), clocking::USARTClkSource::PCLK, ...

                loop {
                    // main "application" loop to handle Serial tx/rx, etc.
                    asm::wfi();
                    break;
                }
            });

            has_lse = !has_lse;
        }
    });

    panic!("there is no spoon");
}

While I did a clean-sheet rewrite for this exploratory work, I think it wouldn't be too hard to refactor an existing reference crate (stm32f100?).

@thenewwazoo: What you brought up looks very interesting, but I think it deserves a separate issue, because it does not really solve the original problem here: That the current implementation does not allow to share a bus between multiple devices. It is however a very good point that a bus is not the only device that might need to be shared.

@Rahix I wanted to illustrate the approach more than a specific solution, namely that of decoupling the bus itself from operations on the bus, as well as experiment with the ergonomics of using move semantics and closures to provide exclusive access. For something like a shared SPI bus, I'm imagining (but haven't actually built) something like:
let gpioa = gpio::A::new(&mut clk_ctx.iop);
let mut dev1_cs = gpioa.PA0.into_output<...>(...); // device 1 chip select
let mut dev2_cs = gpioa.PA1.into_output<...>(...); // device 2 chip select
let mut spi_bus = spi::bus::new(clk_context, ...); // the bus itself

let mut device1 = device::new(device::Options{...});
let mut device2 = device::new(device::Options{...}); // note that the devices do not hold Tx, Rx

spi_bus.domain(&mut dev1_cs, |spi_ctx| {
    device1.issue(&mut spi_ctx.tx);
    device1.interrogate(&spi_ctx.rx);
}); // the spi bus is responsible for asserting/de-asserting the chip select pin

spi_bus.domain(&mut dev2_cs, |spi_ctx| {
    device2.issue(&mut spi_ctx.tx);
    device2.interrogate(&mut spi_ctx.rx);
});

It occurs to me that this approach may would technically be out of scope for embedded-hal specifically, since the traits here wouldn't need to change. This would just be a pattern used by HAL implementors.

@Rahix This looks fantastic. I definitely have to play with that. Just curious: Any reason why you didn't stick it in it's own library crate for easier reuse?
Note to self: pickup idea about embedded-hal-tools crate to offer a place for adapters like this. ;)

@therealprof I wrote it as a POC, just to see if it is even possible. My original idea was to include it in embedded-hal in the end. This is, because each device-hal crate needs to implement the BusMutex trait. If we have an external crate, we would either need to ensure all device-hal crate maintainers know to implement it or use some feature-madness to add implementations. Both options are less than ideal ...
Before adding to embedded-hal we should however think about something else: As seen in the comments above, a bus is not the only peripheral that might need to be shared. It would be good if an implementation in embedded-hal could be generic enough to allow sharing arbitrary devices. In practice this means, the proxy needs to implement Deref for the type of the device. Unfortunately this isn't easily possible in the current implementation, because the mutex abstraction looks like this:
fn lock<R, F: FnOnce(&T) -> R>(&self, f: F) -> R;

Which means we can't return a reference from inside the mutex. I tried changing this abstraction, but rust's borrowing rules do not allow a different solution at this time (unless someone who has a much better understanding of this knows of one ... I either got it to work with std::sync::Mutex or cortex_m::interrupt::Mutex but never both)
But I see that I should make the proxy available as a standalone crate asap, I will do so when I get home from work today, hopefully. I have a few ideas for workarounds for the moment.

Ok, I published a crate: shared-bus :tada:
For an example, I modified my demo to use the crate, take a look over here: i2c-proxy-demo
For now, I only added a mutex implementation for std::sync::Mutex and cortex_m::interrupt::Mutex because those are the platforms I mainly use at the moment. But I am more than happy to add more implementations! Also, feedback would be very much appreciated.

@Rahix I just had some time to try your shared-bus. This is totally awesome and solves this issue nicely! The overhead on Cortex-M is negligible in my opinion with around 150 bytes for a shared I2C bus, which is a complete must have as I2C busses with only a single device are not that common.
I'd love to share your solution with the world, would you mind writing something like a blog article and add it to https://github.com/rust-embedded/awesome-embedded-rust via PR?
I just built a little high precision power meter using a Nucleo32-STM32F042, a SSD1306 OLED display and an TI INA260 power meter. If there's interest I could turn this into the first OSS Hardware + Software project using Rust. ;)

If there's interest I could turn this into the first OSS Hardware + Software project using Rust

Yes please! I could use one to be honest.

@RandomInsano I'm having a hard time sourcing the INA260 at the moment and I don't really see any good alternatives at the moment.

No worries. I’m assuming it’s a different package than what’s offered on DigiKey?
https://www.digikey.ca/products/en/integrated-circuits-ics/pmic-current-regulation-management/734?keywords=INA260
If nothing comes of it, no worries on my side. Producting a product takes a lot of effort even after a prototype is done.

No, that's the one but I prefer different distributors due to shipping costs and neither of them has the INA260 in store at the moment.

TL;DR: Could transactions solve shared-buss last problem?

I just read the shared-bus blog post and it's fantastic. It solves the shared bus problem well but with one issue:

The much bigger issue is that this approach does not synchronize bus accesses. Even worse than the first solution of not owning the bus at all, with this one, an application developer can't even implement it manually

I think this aligns well with what I've been researching for #94. I originally wanted messages to be composed of smaller parts but what if the idea were extended to multiple messages? Something I've been grappling with is whether the code overheard of this is worth the effort:
bus_proxy.transfer([
    [
        bus::write(&MESSAGE),
        bus::read(&data)
    ]
]);

/// Or if you're not into that whole brevity thing:
let mut message = [
    bus::write(&MESSAGE),
    bus::read(&data),
    bus::custom_thing(_, _, _),
];

let transaction = [
    message
];

bus_proxy.transfer(&transaction);

Bundling reads and writes into transactions allows the driver author to have a guarantee on the grouping of their messages. The Mutex within BusManager would guard the whole transaction.
The BusProxy struct could own the device address which solves a problem in my planned implementation where the device author would have had to create and manage the message factory. If that ownership was passed up one level, the driver author would only need to write the code above. The consumer then would only need to provide the address (i2c) or select line (spi) at proxy instantiation time. If the BusProxy were implemented for various bus types (i2c, spi, 1wire), there could be significant code sharing both at the BusManager level, but also device driver level if the proxy trait only exposed transfer and an enum of what bus type it implemented.
My next step is to research how to structure an RFC and outline this. My plan would break a large chunk of the ecosystem of the current device crates, so I'll need help finding holes in my plan.

@RandomInsano: The statement you quoted is not a shared-bus issue, it is referring to the "RefCell-Approach".
You do however bring up an issue that I have not yet thought about which is the synchronization of multiple accesses to the same device.  If I understand correctly, this is what your transactions are trying to solve?

The BusProxy struct could own the device address which solves a problem in my planned implementation where the device author would have had to create and manage the message factory.

Hmm, you are right that one proxy would usually only talk to one address.  But the current I2C traits do not reflect this so it would need a breaking change.

My plan would break a large chunk of the ecosystem

I'd be very very careful about doing something like this.  One of the main reasons for the design of shared-bus is that I do not want to break the existing APIs (see here).  Are you sure this is really necessary?

For those not following the other thread it's possible to avoid breaking the ecosystem. I muddied the conversation up a bit by cross-posting.

Can this be closed now?

Yes, I believe it can.
The SpiDevice trait and the embedded-hal-bus now allow sharing SPI and I2C buses between multiple drivers.


ilastik: used channel priority might produce inconsistent environments

https://github.com/drpatelh/nf-core-imcyto/blob/2bb7dffe4d0cea14ced76fd296b098f2629a3240/environment_ilastik.yml#L2-L5
AFAIK channels are prioritized in the order as given in the config. For ilastik, you need to list ilastik-forge first. Otherwise "our" packages might be shadowed by the ones from conda-forge.
We have also updated all our dependencies recently on ilastik-forge and moved all "old" packages (that are not compatible with the current conda-forge ones) to the label cf201901. So in order to get a valid 1.3.2 environment, I think you'd have to use
     channels:
        - ilastik-forge/label/cf201901
        - conda-forge/label/cf201901
        - defaults

Furthermore,
https://github.com/drpatelh/nf-core-imcyto/blob/2bb7dffe4d0cea14ced76fd296b098f2629a3240/environment_ilastik.yml#L6-L7
we currently don't maintain the no-gui recipes as we are not using them atm.
Have you ever tried building your docker container just from the ilastik binary (and then running via run_ilastik.sh?

@k-dominik Thank you very much for the quick response, and for opening this issue.
I am hoping to write this pipeline in a way in which it can be used with conda, Docker or Singularity. The idea is to maintain a single conda environment file containing the software dependencies, and this is then subsequently built within a Docker container. This just means the end-user can execute the pipeline using various means. If you think its possible, what do you think is the easiest way to maintain the ilastik software using this approach? Unfortunately, I have had to create 2 conda environment files because cellprofiler and ilastik wont build in a single environment but I can deal with that.
I dont necessarily need to have version 1.3.2, it was just the latest at the time. I can update the conda file to version 1.3.3 if you think its best. Also, I selected ilastik-dependencies-no-solvers-no-gui because I will be running ilastik in --headless mode so thought it would be a slimmer install.
I have to admit that my knowledge of image analysis is slim at best! Any tips would be well appreciated. Id rather get it right based on your expert opinion. Thanks again.

Hi @drpatelh,
the ilastik-dependencies-no-solvers-no-gui was really just an explorative recipe to see, whether one can get rid of the gui depenencies in an easy way. I don't think it was a success. I've had a look at the dependencies that are installed and can see that qt for example is still in it. It is too integrated into ilastik atm to rip out. So I think you can safely resort to using ilastik-dependencies-no-solvers.
As for the idea to maintain a single environment I don't think that this is the easiest of all approaches. We are pretty strict on some of our dependencies and the folks at cellprofiler might be, too. If you want to use the headless mode, why don't you create dedicated docker containers for each tool you want to use? This would give you a bit of flexibility with your pipelining and you can then use something like kubernetes to automate your application.
Cheers

The pipeline doesnt support Conda to overcome the issues mentioned above. We are now directly using the Ilastik Docker builds available on Dockerhub via the official repo. Thanks @k-dominik !
https://github.com/nf-core/imcyto/blob/2e830372779df115b11871f58259d780c1ba02ac/conf/base.config#L47


after layout, changing step, minimum, maximum value does not has effect on component

Most of calculations are happening onLayout handler in component. after layout if we change step, minimumValue, maximumValue component would not show correct values and behaviours.
one work around is to set keys with relative props so it would force to trigger onLayout.
<Slider
      /**
       * This key is needed here though it looks useless.
       * slider library calculate values on layout...
       * to enforce the slider to calculate new values we need to pass this key so it would update itself when step or maximumValue or minimumValue changes
       */
      key={`${step}${wrapperMaximumValue}${wrapperMinimumValue}`}
      ... />

Hi, @mohammadalijf
Thank you for your feedback, If this solves your problem you are very welcome to submit a PR. and I will release a version later, very thanks!

created a PR that also has this #14

@mohammadalijf
Published to npm: https://www.npmjs.com/package/react-native-awesome-slider


OCPBUGS-8213: Ensure removal of security group rules on deleting load balancers

When the security group that an instance belongs to is not tagged with the cluster tag, the CCM will happily add a rule from the instance security group to allow traffic from the load balancer security group. However, when it comes to removing the load balancer, if it is intending to remove the security group, it currently does not take into account unmanaged groups where it must still remove the rules to allow the security group to be removed.
More details in the upstream PR and linked issue.

/label qe-approved

/jira refresh

@JoelSpeed - will this merge any time soon?

Still not getting any response upstream about the fix, will discuss with the team about merging it in the absence of upstream attention

just commenting here, i'm happy to bring this up with the sig again, but i feel that @JoelSpeed has done the due diligence on this patch and i would be comfortable carrying it. hopefully we can get upstream to accept it at some point.

Manually adding the jira labels since the bug report is restricted and not public
@elmiko are you comfortable to tag the approve/lgtm?


updated the nested menu plugin to latest

@sparkdevelopment can you review and sign off?

@marcincichon All good


Should be pointed at the live network

It's using live network when built for production (using this config file: https://github.com/stellar/basic-client/blob/master/config-prd.json).


buid skips corrupted files

first build stoped with a error or get killed by the user. it writes a corrupted file that is < 128 MB.
build started again and skips files identified by filename. it skips corrupted files as well.

Will always rebuild last block in case its corrupt. https://github.com/Storj/dataserv-client/commit/61f1e9ac6e0128d76c9eb68d01091f37dca116fd

i had 4 corrupted files cause of 4 stoped builds. with your change only one of the corrupted file would be generated again.

Yes that is correct. It fixed the inherent problem and prevents it in the future, but if you already have multiple corrupt block it is advised you rebuild.


Swap Lucene NIOFS to MMap

Swap directory implementation for memory-mapped version.
https://stackoverflow.com/questions/12343054/high-cpu-usage-on-search-over-lucene-index

Why was NIO used in the first place?  It is not the default.

I think when Suman first committed the codebase, this was what was added. I don't think it was done intentionally for a specific performance reason right @mansu ?


usql docker image

It would be great to have usql embeded in a docker image.
Thanks to this docker image it would be another way to install/uninstall the client (easily).

I built one:  ilaipi/xousql-docker

At the moment, I have no plans to build/create/support a docker image for usql.

At the moment, I have no plans to build/create/support a docker image for usql.

I just published https://github.com/davidecavestro/usql-docker in the hope it helps someway.


fix(junit-upload): Upload tests even if job failed on windows

What does this PR do?
Upload tests even if job failed on windows
Motivation
ACIX-417 Test results must be raised in all situations, even in case of failure
Tests

[Before] Run all windows tests and pretend failure on main here

Test result is 1
Tests failed 1
WARNING: **/junit-out-*.xml: no matching files. Ensure that the artifact path is relative to the working directory (C:\builds\-JJsYSDF\0\DataDog\datadog-agent)
ERROR: No files to upload

[After] Run all windows tests and pretend failure on current branch here

 Uploaded 1 files for windows-kernel-integrations_base
test failed 1
**/junit-out-*.xml: found 1 matching artifact files and directories
Uploading artifacts as "junit" to coordinator... 201 Created  id=618507809 responseStatus=201 Created token=glcbt-64

/merge


Release 2.3.0

Changes since version 2.0.1:

Fixed schedule generation #422
Updated to MP 2.0.0
Updated build

@mpgxvii were the cors issues that popped up again fixed now?

Btw: in radar-Kubernetes you can fix cors by using an annotation nginx.ingress.kubernetes.io/enable-cors: "true" to the ingress

Btw: in radar-Kubernetes you can fix cors by using an annotation nginx.ingress.kubernetes.io/enable-cors: "true" to the ingress

@yatharthranjan @blootsvoets Updating the ingress works. But I've also added the @CrossOrigin annotations to the controllers here: https://github.com/RADAR-base/RADAR-Appserver/pull/430/commits/8d274e46c8b4aef0ddeef842ef7f2ba917a798ee. The CORS issue might have to do with library issues (https://stackoverflow.com/questions/64892592/cors-enabled-in-spring-boot-with-angular-still-cors-errors). I've tried adding different configs to filter chain and cors configurer but no luck. I'll try to improve this later, but meanwhile adding the annotation to the controller fixes the issue.


restore k8s patch versions

What this PR does / why we need it: Restores referential integrity in acs-engine of prior working patch versions of Kubernetes. Also rationalized duplicate version constants (moved duplicates to pkg/api/common) and rationalized existing validations.
Release note:

NONE

@jackfrancis  on it.

@jackfrancis  1.7.4 built and uploaded.

@JiangtianLi thanks! is the artifact name v1.7.4-1intwinnat.zip ?

@amanohar @dmitsh @JackQuincy @weinong  One of you should take a look over the exact implementation of this patch version PR. Thanks!

@jackfrancis yes


Still active?

Hey, is this still active?
I've been looking for a standalone csi.exe alternative with a chocolatey installer.
Would you consider publishing there?

Hi @Manuel-S, no this project is no longer active. These days I download the Microsoft.Net.Compilers NuGet package and execute tools\csi.exe.
Would you like to take over the project? I can transfer it to you if you like.

In that case I would prefer to just make a chocolatey package that downloads and installs csi.exe from that nuget package, but thanks :)


[Dynamic Regions] Implement delete range in raftstorev2

Bug Report

Delete range request is dropped silently in raftstorev2 for now. We should implement it before release.
What version of TiKV are you using?

v7.0.0

Fixed by #14714


DBZ-5072 Config the cache size property for ByLogicalTableRouter caches

https://issues.redhat.com/browse/DBZ-5072

@harveyyue LGTM, thanks! Could you please also extend the documentation of the SMT?

! Could you please also extend the documentation of the SMT?

Yes, add schema.name.adjustment.mode and logical.table.cache.size to topic-routing doc.

@harveyyue Applied, thanks a lot


Improve Travis

Description
Improve Travis flow
Type of change
What is it?

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[x] Tests update

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I run go fmt ./... to check that my code is properly formatted
[ ] I run go vet ./... to check that my code is free of common Go style mistakes

Codecov Report

Merging #447 (5432983) into main (144df7a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #447   +/-   ##
=======================================
  Coverage   31.75%   31.75%
=======================================
  Files          31       31
  Lines        3174     3174
=======================================
  Hits         1008     1008
  Misses       2072     2072
  Partials       94       94

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 144df7a...5432983. Read the comment docs.


All technology outputs for financial models to be analysis period long or single values

The fuel cell model has fueldcell_dispatched output of length analysis period + 1 and is used for production o and m costs in financial models.
The convention for all technology model outputs that are used in financial models is:

analysis period for lifetime mode
single values for single year technology compute modules

See discussion at https://github.com/NREL/SAM/issues/659#issuecomment-1464105549 for more details

@sjanzou has this been fixed already in the hybrids work, by chance?

@sjanzou has this been fixed already in the hybrids work, by chance?

Not yet fixed in hybrid branch


Disabled SIP but Yabai act as if SIP is still enabled.

Hello.
I'm on MacOs 12.5 with Silicon. I've run terminal in "startup option" with command:
csrutil disable --with kext --with dtrace --with basesystem

Like mentioned in the Wiki guide. I restarted and then I also run the command
sudo nvram boot-args=-arm64e_preview_abi

and restarted again.
I've added to yabai config file things such as window opacity and set the animation to 0.0 but nothing change. Also on skhd I've created a shortcut to focus on a certain space, all shortcut works fine but that one (which requires SIP) not. So apparently I've disabled SIP but it's not effective.
Any guidance? Thank's.
EDIT: Just to confirm:
$ csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: enabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: enabled
	NVRAM Protections: disabled
	BaseSystem Verification: enabled
	Boot-arg Restrictions: disabled
	Kernel Integrity Protections: disabled
	Authenticated Root Requirement: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Is there anyone?? I would really like to use features that requires SIP disabled.


Python course which one?

https://www.edx.org/course/introduction-to-computer-science-and-programming-using-python-2?fbclid=IwAR3keVqSLl-9ijNKPJA2QUHIjA6JxBQLkGZ0ElOcodB3emed_fx0ge6ZKUI

www.tutorialspoint.com/python/
www.codecademy.com/learn/learn-python
www.dbader.org
www.python.org


Disable Dynamic partitioning tests on CDH

Fixes #7693.
This commit disables two (failing) tests on CDH.

test_partitioned_sql_parquet_write() fails on CDH just like it fails on Databricks. This is because SQL partition writes are routed through the InsertIntoHiveTable instead of InsertIntoHadoopFSRelation as on Apache Spark. GpuInsertIntoHiveTable only supports Hive text tables at the moment. Further, the exec is disabled even for Hive text tables on CDH. This test would be testing disabled functionality on CDH.

test_partitioned_hive_text_write() should have been disabled on CDH as part of #7556. This was an oversight. CDH does not currently support acceleration for reads or writes of Hive delimited text.

Signed-off-by: MithunR<EMAIL_ADDRESS>

Build


Nscale revision deploy command now outputs npm warn messages

Hi,
I've recently updated from nscale v0.15 to 0.16. I've noticed now that when I run a nscale rev dep latest command it has started to output npm warn messages:
add www-306968a5$090789a6262c562e44ae0890a6a8eb8af8f24ba1 process
deploying
building
checked out 090789a6262c562e44ae0890a6a8eb8af8f24ba1
npm

WARN package.json<EMAIL_ADDRESS>No README data

npm WARN package.json<EMAIL_ADDRESS>No README data

npm WARN package.json<EMAIL_ADDRESS>No README data

start www-306968a5$090789a6262c562e44ae0890a6a8eb8af8f24ba1 process
starting
> tail -f '/Volumes/Data/Users/fabera/.nscale/log/www-306968a5$090789a6262c562e44ae0890a6a8eb8af8f24ba1.log' # to access the process log

It's not a big thing by any means, but it makes the deployment messages harder to read and to locate the tail command to grab the log files. Was this a deliberate change to the way the messages are outputted when running a deployment?

Hey,
Will take a look at this. No deliberate change IIRC but will check for you.
Cheers.
Peter.

The deliberate thing was to run the build at every deploy for process containers. This might be wrong, though. @shnist a nice thing you might want to try is to resolve that warnings, i.e. seeing if there is an updated version of those packages that have the README.

@mcollina @pelger - thanks guys. So just to clarify, in v0.16 it runs an npm installation on every deploy now? And this wasn't the case in 0.15?

Only for process-containers. Not sure why it was added, @pelger can you please clarify?

hi @pelger - any update on this?
cheers


location bias feature implementation

@parasharrajat @thienlnam
Details
This PR implements the feature of location bias in the following way:

When no waypoints are set and the user’s current location is unavailable, the App behaves as it happened before the fix.
When no waypoints are set but the user’s current location is available, set a rectangular boundary around the current location coordinates (with a width/height of 1 degree).
When only one waypoint is set, ignore the user’s current location and set a rectangular boundary around the only available waypoint coordinates (with a width/height of 1 degree)
When two or more waypoints are set, calculate the min and max values of the latitude/longitude from the available waypoints. Then, enlarge the arrived rectangular boundary by 1 degree.
The rectangular area in the above cases reflects the extreme north, south, west, and east coordinates.

Fixed Issues
$ https://github.com/Expensify/App/issues/32068
PROPOSAL: https://github.com/Expensify/App/issues/32068#issuecomment-1831511942
Tests
Precondition:
Enable Location Access by giving all necessary permissions
Steps:

Click on Global FAB —> Request Money
Select Distance tab.
Click on the Start waypoint so that the Address Search view is shown.
In the Address text input, enter a search text.

Expected Result 1: The search results should be such that it is nearer to the user’s current location

Enter a search text and select a Start waypoint that is far from the current user’s location(maybe in another city)
Click on the Finish waypoint so that the Address Search view is shown.
In the Address text input, enter a search text.

Expected Result 2: The search results should be nearer to the Start waypoint

Select a Finish waypoint from the available options so that both Start and Finish waypoints are filled.
Click on the Add stop button so that the Address Search view is shown.
In the Address text input, enter a search text.

Expected Result 3: The search results should be nearer to the Start and Finish waypoints
Test Notes:

The search results can be compared with the search results in the current staging or production version to notice the impact of location bias implementation.

Development Testing

On the Android Emulator, user’s location I was not able to set the . So, tests were conducted using the default user location.
On the Desktop, the user’s location could not be set. So, tests were done with the default location.

[x] Verify that no errors appear in the JS console

Offline tests
Above tests cannot be used as internet connection is required.
QA Steps
Same as the Steps for Tests Section.

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes

[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)

[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web - Safari
https://github.com/Expensify/App/assets/3004659/ec5494db-eb98-42a7-a5ad-cd8ee1e7325f

Mobile Web - Safari
https://github.com/Expensify/App/assets/3004659/a852d5d3-b766-4f1e-b4e0-39eb88a0d535

Desktop
https://github.com/Expensify/App/assets/3004659/119a8f61-084b-4b5f-8ce3-756fc43729fa

iOS
https://github.com/Expensify/App/assets/3004659/e777c81e-702a-4dd1-8d0b-e754808273c1

Android
https://github.com/Expensify/App/assets/3004659/ffeb0ba7-87ef-474b-8cae-a8a27d57adfb

Mobile Web - Chrome
https://github.com/Expensify/App/assets/3004659/30841a16-0e13-46c9-8899-1575ca5b2205

@parasharrajat
PR is ready for review
Over to you

@parasharrajat
I have updated the description in the PR author checklist to reflect the recently agreed changes.
Also, I have tested it across all platforms, and works well.
Looking forward to your test results.

I was testing this and I noticed that it is not giving the best results as per my expectations.
For example in the below video when I typed HDFC bank, I expected HDFC bank sector 70 to show up in the list As it is closest to the previous two selected points.

@parasharrajat
Thanks for the tests. I also tried this on similar lines. Since HDFC Bank is a very popular bank with many locations within the rectangular bounds that we have set, I am not sure how Google determines which ones to display from the available locations within the rectangular bounds. Maybe there could be additional parameters that can be set for Google search to be even more precise. I am not sure of any approach currently. Do you have ideas on this to make it more precise?
But, given that we wanted to take a straightforward approach initially, doesn’t our solution meet the intended purpose of showing locations closer to the location than faraway absurd search results?
I gave numbers in the search as in the OP and it showed up search results near the locations we are in.
Here is a test video demonstrating this.
https://github.com/Expensify/App/assets/3004659/ee61d94d-9974-40dc-a81c-623bb30617fa

I can only think of https://developers.google.com/maps/documentation/places/web-service/search-nearby#rankby.

@parasharrajat
I just did a quick check.
rankby is used in Nearby Search whereas we have used locationbias in Find Place.
As shown in the attached screenshot, Nearby Search does not support Ambiguous text but is keyword based search. And, in our use case, ambiguous text search makes more sense as User can enter address as mentioned in OP.
So, I think our current implementation of locationbias is better than rankby.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/thienlnam in version: 1.4.21-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/marcaaron in version: 1.4.21-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
cancelled 🔪

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/marcaaron in version: 1.4.21-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
cancelled 🔪

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/marcaaron in version: 1.4.21-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Not able to center lottie animation in screen

I already asked this question on Stackoverflow but seems like nobody was able to help me there. (https://stackoverflow.com/questions/48070527/not-able-to-center-lottie-animation-and-text-in-screen-react-native)
How is it possible to center both a text and an animation from lottie? My loading animation is a bit cut of to the right side. I tried to following here but it didn't work https://github.com/airbnb/lottie-react-native/issues/143
My class looks like this:
import React, { Component } from 'react';
import { connect } from 'react-redux';
import PropTypes from 'prop-types';
import { StyleSheet, View } from 'react-native';

import Loading from '../Components/Loading';

var styles = StyleSheet.create({
  viewAlignments: {
    width: 300,
    height: 300,
  },
  containterAlignments: {
    width: 300,
    height: 300,
  },
});

const LoadingWithMessage = props => {
  const { authSuccess } = props;

  const text = authSuccess ? 'Success!...'
    : 'Checking you against your information...';

  return (
    <Loading text={text} />
  );
};

LoadingWithMessage.propTypes = {
  authSuccess: PropTypes.bool.isRequired,
};

const LoadingMessageContainer = connect(state => ({
  authSuccess: state.authUi.authSuccess,
}))(LoadingWithMessage);

export default class AuthenticationLoading extends Component {
  static navigationOptions = {
    header: null,
  };

  render() {
    return (
      <View style={{ flex: 1, flexDirection: 'row', justifyContent: 'center', alignContent: 'center', alignItems: 'center' }}>
        <View style={styles.viewAlignments}>
          <LoadingMessageContainer style={styles.containterAlignments} />
        </View>
      </View>
    );
  }
};

And the screen looks like this. So you can see that the animation is a bit cut of to the right. Also without the height and width = 300 it is very to the right shifted.

what are StandardWrapper and ScreenWrapper? simple View's ?


cache-ttl in 4d provider

[ ] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

Here is a brief summary of what I did:

 TerraNova-Daten investigieren/integrieren

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

8 of 16 (50.0%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.002%) to 88.918%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

services/src/datasets/external/netcdfcf/mod.rs
3
11
27.27%

Files with Coverage Reduction
New Missed Lines
%

operators/src/source/ogr_source/mod.rs
1
95.43%

Totals

Change from base Build<PHONE_NUMBER>:
0.002%

Covered Lines:
105899

Relevant Lines:
119098

💛  - Coveralls


libsodium build script not properly detect CPU feature

Describe the bug
When I  (static) link my program with the libsodium.a library,  running my program lead to core dump.
Environment

OS: Ubuntu 18.04.3 LTS
Compiler: gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0

To Reproduce
Steps to reproduce the behavior:

./vcpkg install libsodium

Expected behavior
Failure logs
Illegal instruction (core dumped)
core dump stack:

│0x562887b92931  vmovdqa 0x464ad7(%rip),%xmm0        # 0x562887ff7410                │

Additional context
cat /proc/cpuinfo

processor	: 19
vendor_id	: GenuineIntel
cpu family	: 15
model		: 6
model name	: Common KVM processor
stepping	: 1
microcode	: 0x1
cpu MHz		: 2297.338
cache size	: 16384 KB
physical id	: 1
siblings	: 10
core id		: 9
cpu cores	: 10
apicid		: 25
initial apicid	: 25
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni cx16 x2apic hypervisor lahf_lm cpuid_fault pti
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips	: 4594.67
clflush size	: 64
cache_alignment	: 128
address sizes	: 40 bits physical, 48 bits virtual
power management:

@valbendan Could you provide the sample code?
Thanks.

https://github.com/valbendan/LibsodiumVcpkg

This might be the same as https://github.com/microsoft/vcpkg/issues/7308 . A quick fix for this is using vcpkg_*_make functions on *nix.

@myd7349 Maybe we missed something in CMakeLists.txt.


Add multi-node InsertAfter variants

@pgavlin PTAL

I added multi-node InsertBefore variants as well, for symmetry. Only the 2-node variant is currently used.

LGTM.


Replace FieldExtractor with guava Function interface

In order to be able to use the utilities like Functions.constant

ack


Text pulled from TheMovieDB contains unsupported characters

I recently added a number of episode descriptions to TheMovieDB using copy and paste.
I didn't notice that the text contained angled quotation marks which have unique character codes.
These characters are supported by TheMovieDB but not by Streama.
The characters used to be converted to straight quotation marks (") when imported into Streama, however now they are turned in this ���.

Hm, what collation does your database have?

I don't think it has anything to do with my database because some episode descriptions I have now have the angled quotations in them and Streama is displaying them fine. So I was wrong when I said Streama doesn't support the characters, it does. But something about the process of pulling the descriptions from TheMovieDB has changed, which now causes the angled quotations to be converted ��� along the way.

Ok I have just refetched some episodes and the ��� have disappeared. Looks like the problem was on TheMovieDB's side. Sorry!

This was fixed in #536


[MM-28217] Front-end for displaying company info

Summary
System Console components to display Company Information from the CWS to the admins.
Edit is coming later.
Ticket Link
https://mattermost.atlassian.net/browse/MM-28217
Related Pull Requests

Has server changes (https://github.com/mattermost/mattermost-server/pull/15646)
Has redux changes (https://github.com/mattermost/mattermost-redux/pull/1249)

NOTE: Not ready for review until we have a way to setup a link to the CWS on the SpinWick.

/update-branch

NOTE: Not ready for review until we have a way to setup a link to the CWS on the SpinWick.

Given that we still don't have the ability to set this up easily, let's merge and cherry pick this and we can do a QA Review and UX Review on the cloud-ga branch. I will be setting up a "epic PR" just so we can a do a full review


--prod meta flag no longer working as expected

Versions
<!--
 Normally this includes a stack trace and some more information. -->

That's a lot more chunks than on v 1.x
Desired behavior

Mention any other details that might be useful (optional)
The --prod flag should work as desribed in https://angular.io/guide/deployment#build-with---prod

The --prod option is shorthand for --configuration=production; it provides no other special processing.  Please provide the option set for the project's production configuration.

then why does it state otherwise in the docs ?  https://angular.io/guide/deployment#build-with---prod

A newly generated project will provide the documented behavior as the following options are automatically defined:
          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true
            }
          }

@clydin thanks a lot !
This should be added as a story in the cli's own docs like "building for production"

I agree on the additional docs.  There is currently work underway for an expansion of the CLI documentation.
Closing this as resolved.


How to keep the server unclosed to run scripts multi times?

I first executed a program,
Beamng.open(launch=True)
......
Beamng.close()

I want to execute this program again without closing beamng
But the program that started the second time got stuck in this position:

BeamNG <IP_ADDRESS>.15021
beamngpy 1.26

Hi, we found the source of the issue, it will be fixed in the next version of BeamNGpy.

This is fixed in BeamNG.tech 0.30 and BeamNGpy 1.27, you can update to the latest versions. Feel free to reopen this issue if the problem persists for you.


More refactor

Hi everyone,
first: this PR is intended more to get the discussion going rather than being a complete and finished change (even though I tried to keep things green).
The discussion's topic should be: How many deployment methods should be shipped with the actual DefectDojo repository, knowing that all of them need to be maintained.
Currently, there are three different ansible folders. Only one of them (legacy) seems referenced from within the Vagrantfile (but the path has changed and Vagrantfile wasn't updated).
Also, there are several different scripts triggering Docker image builds (I think two or three of them). Some work, some don't.
The currently documented way of running the "all-in-one" container doesn't work, since the script has moved to a subfolder (from /django-DefectDojo to /opt/django-DefectDojo). A bit worse: Some of the scripts have the old path hardcoded, which makes the scripts fail out-of-the-box. Also, having to adjust paths in scripts at many places makes it hard to maintain.
I've addressed some of these points with this PR (but not all of them - I'm not fit enough with Ansible, for example). So, my suggestion would be:
Let's remove unused deployment methods and move them to dedicated repos (including this repo as a submodule). Instead, let's provide a clean sample Dockerfile, which we can use at the same time for integration tests.
So, here's what I did in this PR:

I deleted seemingly unreferenced files in a quite aggressive manner

I adapted the getting-started doc to point the docker-startup script's real path

I moved most scripts to a folder entrypoint_scripts. That folder has 4 subfolders:

run: to keep scripts that run things (running servers etc.)
test: scripts to test something (i.e. for travis)
misc: scripts that didn't fit elsewhere
common: source-able scripts defining functions and variables which can (should?) be reused in other scripts

I didn't modify a lot in the docker directory (except for the said file removal), since I was not sure about the logic that was followed when these scripts were contributed.

I did change the Dockerfile towards running as few commands as root user as possible. Instead, I've added a (improveable) sudoers file for the dojo user.

The approach I followed was to move as much bash-logic as possible to shared-functions and to eliminate duplicates there. This probably impacts setup.bash most.
With this, I think that we should keep DefectDojo installable as non-root user with some (listable) sudo privileges.
The refactoring process is not quite finished yet, but I find it hard and time consuming to go on without any feedback at this point.
Looking forward to hear from you - feedback welcome.
PS: I realize this text and PR mix together a lot of stuff, so thanks already for your patience.

@maennel very interesting. Will review and discuss. Not too long ago we were discussing how to consolidate the install dependencies as much as possible (ansible, docker, bash, etc), but ran into architectural issues with ansible that ended up being left as a TODO. Will be back shortly with my thoughts

@maennel planning to meet Monday with @mtesauro and @aaronweaver to really review

@devGregA Great to see you guys taking this so seriously. I, and I believe many others, appreciate this a lot. Thank you!
My 2 cents:
I was thinking about the matter again during the last couple of days.
Maybe it would be an approach to keep this repo as clean as possible and focus on creating a clean python wheel, which can be uploaded to PyPi. This wheel would clearly state OS requirements that need to be present when installing and running DefectDojo. Initial configuration would take place through a config file (for example in json, xml or ini-format) at some predefined location.
Additional repositories could provide sample deployments, for example all-in-one Dockerfiles, a distributed Docker setup, a setup with Vagrant, etc. These deployments would have a common point in installing DefectDojo via pip.
Best,
-Manuel
PS: I think I was a bit quick in adding another commit to this branch - I'll take care of bringing this back to green ;)

@maennel If you have time next week maybe we can meet together with @devGregA and @mtesauro on a hangout and figure out a strategy.

Will clone & test

Is this going to be merged as is, or in feature specific chunks?

@t3h2mas I didn't plan to split it up for now - so rather the first one, merge as is.

@maennel something introduced is breaking sed usage of setup.bash
sed: 1: "dojo/settings/settings.py": extra characters at the end of d command

Sounds good. Looks like I'll be waiting until after the merge to do any local or PR development. That way a big merge conflict is avoided.

@devGregA Can you please indicate the version of sed and what system you're using it on? Thanks

@maennel I believe it is 10.6, but it is BSD sed which OSX uses. Currently the if clause here: https://github.com/DefectDojo/django-DefectDojo/blob/master/setup.bash#L204 handles the sed check.

@devGregA Thanks for the info.
Indeed, going into the man pages for GNU sed and BSD sed shows that the argument to the -i flag is optional for GNU and mandatory for BSD. Will adapt this.

@maennel testing

Talked with Aaron, merging.


Duplicate image detection

Start Date
Project Lead
Actual Ship Date

2023-08-01
TBD
TBD

Description

We need to prevent duplicate images from being added to Openverse. This is useful both for content safety (to prevent already reported media from being added, even with different metadata) and for search result relevancy (having duplicate media in the results makes the experience worse).
We also have existing duplicates we would need to address. In the future, we will need to come up with a more robust solution for determining the ‘canonical’ piece of media in the case of duplicates. A possible heuristic for this is to use a preference for the media from "authoritative" sources like museums over social media sources.
Prerequisites

Perceptual hashing and/or literal hashing with tolerances
https://github.com/WordPress/openverse/issues/417

Documents

[ ] Project Proposal
[ ] Implementation Plan

Issues

Prior Art

This project was not completed in 2023 and we are closing it in favor of prioritizing other work. Closing this issue.


Analyze solidity code for tron blockchain

Description
Tron blockchain support the same solidity language as etherium, but with some differences. For example, it doesn't have the keyword ether, it replaced by trx. Would be nice to have mythril to analyze solidity code for tron blockchain too

Should probably just work as-is already? Try connecting to a Tron fullnode RPC in a way you'd connect to an Ethereum fullnode RPC?

@bogatyy It should be possible to analyze, but some issues might crop up as this tool is written solely on the assumption of it being run on the Ethereum blockchain. Like with the creation of contract using create2 opcode the contracts generated by EVM and tron VM will be different

It's worth mentioning that the Tron blockchain is different in several ways from a standard Ethereum fork, having its own RPC formats etc. and a native token standard (TRC10), as well as a separate sidechain implementation.
The TVM is indeed a fork of EVM, but with notable differences being support for TRC10 tokens (you can call a contract using TRC10 instead of TRX, get the ID/amount of TRC10 token passed by caller, and get the TRC10 balance of an account).  The Solidity compiler was obviously forked as well to handle such features (for a nonpayable function it is not sufficient to only check the TRX value passed by caller, but also the TRC10 value), and wasn't kept up to date with upstream Solidity.  Funnily enough the TRC10 fell out of favour due to the existence of the more flexible/compatible/expensive TRC20 (ERC20 equivalent).  I haven't looked at Tron for at least a year, maybe other stuff has changed since.
Also I discovered something quite odd in their precompiled contract implementation - still not fixed it seems!


Expiring Data

Not sure if you feel this fits within the scope of this module. But I'd quite like to wrap my database queries in a cache to prevent hitting the db too often. What would be really cool is if I could use this library but set expiry times on data ie
store.set("key", "value",1000) # 1000ms optional, otherwise forever

If this isn't inline with your aims, let me know as I may create a module to wrap yours to add this functionality to those who want it.
Thanks.

Hey) Sorry for the delay.
I guess it might be useful.  I don't mind such thing, if it can be somehow modular.


Installation + InstallationTemplate and APNS headers

I want to use templates, Installation API and provide apns-collapse-id header to APNS for Apple notifications. Is the code below a proper way of doing so? The docs say InstallationTemplate.Headers property is for MPNS-targeted notifications, so not sure if this would work for Apple (APNS) as well.
var installation = new Installation
{
    InstallationId = "myId",
    Platform = NotificationPlatform.Apns,
    PushChannel = "xxx",
    Templates = new Dictionary<string, InstallationTemplate>
    {
        {
            "hello",
            new InstallationTemplate
            {
                Body = @"{ ""aps"": { ""alert"": ""Test"" } }",
                Headers = new Dictionary<string, string> { { "apns-collapse-id", "myCollapseId" } }
            }
        }
    }
};
await _hub.CreateOrUpdateInstallationAsync(installation);

After testing I can answer the question myself: it's not possible. When trying to provide headers I'm getting the following error:
Template 'hello is invalid: 'Headers' only acceptable for WNS and MPNS...


noswhere.com and nostr.wine

Apparently these two relays also support NIP-50 search. It would be good to have them added to the default list of searchable relays.

Thank you to informing me!
relay.noswhere.com does not seem to be working at this moment. It might be a temporary failure, or I have the wrong address?
❯ echo '["REQ", "_", {"search":"noostr"}]' | websocat --no-close wss://relay.noswhere.com
["NOTICE","internal error on filter 0"]
["EOSE","_",{"debug":["filters: ok","ok"]}]

filter.nostr.wine requires NIP-42 authentication and nos.today doesn't support NIP-42  (and NIP-07):
❯ echo '["REQ", "_", {"search":"test"}]' | websocat --no-close wss://filter.nostr.wine
["AUTH", "2e6f85e2-982a-41e3-8b16-4d842e3d86a7"]

nostr.wine does not support NIP-50:
❯ echo '["REQ", "_", {"search":"test"}]' | websocat --no-close wss://nostr.wine
["NOTICE","ERROR: bad req: unrecognised filter item"]

Anyway I didn't know about relay.noswhere.com and will try again later!


Feat: Creating API/fetching in card status successfully Issue 365

Pull Request Resolves [#365 ]
Title: Creating API/fetching in card status successfully.
Description

I created a controller and route for getting the total counts for totalUsers, totalPosts, totalComments, totalReactions, messages, favorites.
And I am fetching it in the StatusCard.
I had used appropriate icons for the cards.
Here the messages are those which are sended from the contact us form.

Related Issues
Fixes #365
Changes Made
New features: Creating API/fetching in card status.
Screenshots

I certify that I have carried out the relevant code of conduct and provided the requisite screenshot for validation by submitting this pull request.
Thank You for this contribution.

rename messages to contact messages, the rest is good

@VaibhavArora314 Done the changes 👍

@MeetDOD kindly resolve the merge conflicts

Done please add level 3 label because of api + frontend 😄

@MeetDOD kindly resolve the merge conflicts

Done please add level 3 label because of api + frontend 😄

Merge conflicts are still present

@MeetDOD kindly resolve the merge conflicts

Done please add level 3 label because of api + frontend 😄

Merge conflicts are still present

ya its happened because you merge the 2 PR of admin,
Done @Ultimateutkarsh11 !

@MeetDOD kindly resolve the merge conflicts

Done please add level 3 label because of api + frontend 😄

@Ultimateutkarsh11 please consider my request if possible 👍


Allow random extensions

We may want to pass a custom extension such as .foobar.
In that case, we could pass an extra flag to provide the format (such as --yaml) or be smart and guess.

This would also be useful for being able handle process substitution without so much song and dance to get extensions sorted:
TMPSUFFIX=.yml
tera -t template <(command_that_generates_context)
unset TMPSUFFIX

Could be:
tera -t template --yaml <(command_that_generates_context)

Personally I would suggest not trying to be smart and guess the type if it isn't noted as an extension. YAML is a disaster to detect because it's technically a superset of JSON, so most JSON is valid YAML and YAML can be made to look very much like JSON but actually work the same way a JSON parser would handle it.

I agree, I am only using the detection based on the extension so spare the user yet another flag but the current rules are rather tight.


refactor(icon): id attribute not being cleared completely

Currently when we clear the id of an icon, we set it to an empty string which still keeps it on the element. This change removes the attribute altogether.

@crisbeto Please fix the test?

Looks like just a saucelabs flake

@crisbeto can you take a look at the failing tests? seems like a legit failure

Looks like something in the testing setup that got renamed in another PR. Should be good to go now.

@crisbeto still seeing an error:
should allow multiple icon sets in a namespace (35ms)
	Expected null to be ''.


Develop consensus approach

Identify approach to combine predictions from multiple species distribution model methods into a single "consensus" approach. First pass would be a majority-rules based on presence / absence thresholds from each SDM method.

Created a test version of a script that creates consensus distributions for any number of species and climate models. See eb05c7b

Modified create-consensus-distributions script and moved to the src/summary folder. See 4ab118f. @jcoliver: feel free to move if you think this script fits better elsewhere.

Nice. Probably worth while to save distribution rasters with terra so they are SpatRasters, to reduce dependency on raster package, but that's a separate issue.


Add keyboardAppearance prop to TextInput component.

Resolves #3649.

Looks good and is consistent with the other APIs. If you have time, could you add an example to the UIExplorer too?

As @ide says, an example would be great. Other than that, looks good to me.

@ide @nicklockwood Done.

Thanks!

@facebook-github-bot import

Note: I removed the "alert" style, as it's deprecated.


feat: Add Popover component

Issue #, if available: https://github.com/aws/aws-northstar/issues/66
Description of changes: Added a Popover component that can be used to display some content on top of another.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


numpy convention --> colon spacing should be verified for parameters and return sections

The following is an example of a numpy convention parameter documentation:
"""
Parameters
----------
a : int
    The value of a.
"""

The numpy docs say the following about that:

The colon must be preceded by a space, or omitted if the type is absent.

(source: https://numpydoc.readthedocs.io/en/latest/format.html#sections)
However, pydocstyle does not seem to verify this.
For example, take a file smalltest.py with the following contents:
"""Test some."""

def no(a):
    """Do it.

    Parameters
    ----------
    a: int
        Print a.
    """
    print(a)

running pydocstyle --convention=numpy smalltest.py does not show any errors, but it should.
version: 5.1.1 on ubuntu 18.04

On the other hand, using numpydoc for validation reveals the issues appropriately:
python -m numpydoc smalltest.no --validate

smalltest.no:GL01:Docstring text (summary) should start in the line immediately after the opening quotes (not in the same line, or leaving a blank line in between)
smalltest.no:ES01:No extended summary found
smalltest.no:PR01:Parameters {'a'} not documented
smalltest.no:PR02:Unknown parameters {'a: int'}
smalltest.no:PR10:Parameter "a" requires a space before the colon separating the parameter name and type
smalltest.no:SA01:See Also section not found
smalltest.no:EX01:No examples section found

On the other hand, using numpydoc for validation reveals the issues appropriately:
python -m numpydoc smalltest.no --validate

smalltest.no:GL01:Docstring text (summary) should start in the line immediately after the opening quotes (not in the same line, or leaving a blank line in between)
smalltest.no:ES01:No extended summary found
smalltest.no:PR01:Parameters {'a'} not documented
smalltest.no:PR02:Unknown parameters {'a: int'}
smalltest.no:PR10:Parameter "a" requires a space before the colon separating the parameter name and type
smalltest.no:SA01:See Also section not found
smalltest.no:EX01:No examples section found


Full localization and OwinEnvironementService with LocalizationService example

I used a IdentityServer3.Contrib.Localization to provide localization for identityserver but i have 3 questions:
1- IdentityServer3.Contrib.Localization provide only translations for scopes,messages,events so it's ok but it's not provide a full localization that we want for example localization for a login and logout page, so how can i provide a localization for the text that it inside the html?
2- I know that i can provide a custom views so i can change the text inside the html views but i want to do a localization for example for Arabic language and English language so can i create an owin middleware to provide a localization for a specific strings inside html or is it an example for this?
3- is this an example on how to use OwinEnvironementService  with LocalizationService to determine the browser accept-language cause i searched for an example but i didn't found any?

1: you'd have to do that via a custom view service.
2: no
3: you can inject the OwinEnvironmentService into the ctor of your LocalizationService.


add deprecation note to the TV Devices guide

This PR adds deprecation note to the Building For TV Devices guide according to 0.62 release blog post, refs #1279.

Deploy preview for react-native processing.
Building with commit cd9b66fee6863c5bebcf48afd8864a0b973614b4
https://app.netlify.com/sites/react-native/deploys/5e98bf7f7d029f0006a85e29

Great catch! I was thinking: we should remove this from the sidebar as well or we should retool the page as a jumping off point for those other community projects. What do you think?

From the information I have acquired only tvOS platform has been deprecated and building for Android TV instead of phones requires small amount of changes in the code so, as is it for now, it stays within core.
This also means that the whole page is NOT deprecated, so at least for now, page should remain in the sidebar.
I have also renamed the page in current and next docs from building-for-apple-tv to more general and more accurate building-for-tv name, this change also fixes #333.

How about adding a redirect from the old building-for-tv to the new as well?

@rachelnabors Unfortunately Docusaurus do not have an ability to generate redirects. Only thing that I could do I revert building-for-apple-tv files and replace the content with note with link. Example:

https://reactnative.dev/docs/navigator

Check the redirects in website/static/docs as per our chat!


How to register a custom python operation with variadic input/output and homogeneity?

it's only supported in C++/C API, it hasn't been ready in Python yet.

it's only supported in C++/C API, it hasn't been ready in Python yet.

How about @onnx_op mentioned in https://onnxruntime.ai/docs/extensions/add-op.html ?
Doesn't it works?


Use "internal" backend also as authorizer

https://groups.google.com/d/msgid/search-guard/a54d77e5-9ffe-4fc1-b4a6-2cd64911d283%40googlegroups.com?utm_medium=email&utm_source=footer

@jochenkressin @nibix can you have a look? (no tests yet, but should be pretty straight forward)


Instance variable @digest_username not initialized

Hi, I'm getting this warning on my environment.
.rvm/gems/ruby-2.3.1@aa-service-bus/gems/rack-test-0.6.3/lib/rack/test.rb:284: warning: instance variable @digest_username not initialized
I also find this message on some public buildings in Travis CI.

@celsoMartins thank you for your report, I would close this issue page, we fixed by https://github.com/rack-test/rack-test/commit/21784987fbf53ad5f9dc30adb915a193d3141131 .


tf.keras.models.model_from_json() missing a safe_mode parameter

When loading a model with a lambda layer from a json model config, TensorFlow/Keras 2.13 provides the following error:
ValueError: Requested the deserialization of a Lambda layer with a Python 'lambda' inside it. This carries a potential risk of arbitrary code execution and thus it is disallowed by default. If you trust the source of the saved model, you can pass  'safe_mode=False' to the loading function in order to allow Lambda layer loading.
However tf.keras.models.model_from_json() does not have a safe_mode parameter. So there does not seem to be a way to load models with lamda layers using a json config. This issue does not appear in TensorFlow/Keras 2.12
Standalone code to reproduce the issue
from tensorflow.keras import Model
from tensorflow.keras.layers import Dense, Input, Lambda

inputs = Input(shape=(1,))
x = Lambda(lambda x: x*2)(inputs)
out = Dense(1)(x)
model = Model(inputs=inputs,outputs=out)

model_config = model.to_json()
tf.keras.models.model_from_json(model_config)

@epetrovski,
This issue has been tracking internally. We will provide much more information once it gets resolved. Thank you!

Hi the model_from_config() is also missing this parameter

i have the smae issues, what is the newest progress of it,  is it solved??  or what is the temporary solution? ? I'm new to this. BTW, i know the old version can work, but i am M2 sillcon which only have 2.13.0 version.

Same problem for me. Any news? Thanks. Giorgio


How to use my own texture?

I ran the code and got the animated result, but I don't know how can I have a result with my own SMPL texture.

I think I need to make my question more specifically. How can I erase the black dot on the model?

Sorry to bother, I have solved the problem which dues to Blender setting.


[clipboardjs] Copy multiple target elements.

Is't possible coping multiple target elements?
Like, data-clipboard-target="#data-*"

Make a test!

Simply it's not working.
Need a sample demo.

You can't copy multiple target elements at once. But you can use the imperative API for that, for example:
new Clipboard('.btn', {
    text: function(trigger) {
        var a = document.querySelector('#a').value;
        var b = document.querySelector('#b').value;
        return a + b;
    }
});

I modified what he did, in order to use in multiple places...
pasting here if somebody need:
new Clipboard('.btn-copy-mutiple', {
text: function (trigger) {
var targets = $(trigger).data('clipboard-targets');
targets = targets.split(',');
var copyString = '';
var qtd = targets.length;
for (var i = 0; i < qtd; i++) {
copyString += ' ' + $(targets[i]).text();
}
return copyString;
}
});
button:

ps:
.text() or val(), depending on what you're going to copy

I have generated a list of user emails (based on role) from WordPress. I'm trying to get a button on the page that will "copy all" emails. Thoughts on this?


[AOMP][ASan] Providing Instrumentation Libraries for roct,rocr & comgr.

ASan instrumented libraries of roct,rocr(hsa-runtime) and comgr(compiler-support) can now be enabled with the env variable AOMP_BUILD_SANITIZER=1.

Hi Ron ,
Can we land this PR?
Thanks
Amit

@estewart08  can you look this one over please ?


Fix macOS builds

Steamworks needs C++11 and clang by default uses 98 iirc

C++ 14 has been the default since 6.0.0 / circa 2018, but looks like bindgen supports using older versions, and so should we. Thanks for the PR, sorry it took a while to check it! 😄


[v2.7] feat: bump harvester node driver to v0.6.7

Issue:
https://github.com/rancher/rancher/issues/44312
Releated Harvester issues:

https://github.com/harvester/harvester/issues/4588
https://github.com/harvester/harvester/issues/2764
https://github.com/harvester/harvester/issues/4777

This PR bump Harvester Node Driver to version v0.6.7

Hopefully this is an easy review based on past efforts in #43595

It looks like Harvester has been bumped to 0.6.7 in the release/v2.7 branch (code).
hi @FrankYang0529 , can you confirm and close this PR if that is true?

It looks like Harvester has been bumped to 0.6.7 in the release/v2.7 branch (code).
hi @FrankYang0529 , can you confirm and close this PR if that is true?

Yeah, it looks like it has been updated. Not sure whether there it's backport from v2.7.11.
https://github.com/rancher/rancher/commit/d65a22e2886bfebe67780aff5695a140459e7917

Close the PR as we already have the change in v2.7.


chore(deps): upgrade configuration

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-configuration-k8s-26-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2972

Questions ?
Please refer to the Backport tool documentation


npm run build exited with return -1

npm install
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules\sane\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules\chokidar\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.
npm WARN<EMAIL_ADDRESS>No repository field.
error MSB3073: The command "npm install" exited with code -1.

You can ignore the fsevents dependency because it is macOS (or iOS) only.
As for the prettier-loader, that isn't used in this project, so I'm guessing you added it yourself. Did you add it in dependencies or devDependencies ?

Did you run a fresh npm install on the project to get started? It seems like it is not finding any of the dependencies.

Closing this because of no activity. Think this is done now. Feel free to open up another issue if you encounter problems.