Allow multiple read/write calls per transaction via SPI/I2C

Both SPI and I2C have some concept of a transaction. SPI you assert an enable pin before sending data, I2C has start and end messages.
I'm finding that as I write and review more crates, the ergonomics of requiring single fixed sized buffers for communication are becoming cumbersome or require a lot of code duplication for variably large receivers. An example of the latter is the required code duplication in the eeprom24x.
After some research, it looks like the buffer copy for SPI and I2C in Linux-land might be unavoidable because the I2C_RDWR ioctl support isn't required. That means it would need to be wrapped somehow in the linux-embedded-hal crate.
Looking at Arduino, they do have the concept of protocol transactions. I'm not sure if I agree with the API entirely, but the concept is good. I'm sure Rust opens up some interesting design improvements there.
Can someone poke holes in this idea for me? I'd like some sort of solution to allocating these extra buffers on memory constrained devices, especially when it leads to reading and writing different sized data.
Here's a list of code that I find where buffer copying was required but didn't need to be:

eeprom24x: For reading / writing arbitrarily large pages
pscontroller: For changing one byte in a constant buffer

Just some quick notes here, it looks like following what Linux does with I2C_RDWR might be a great way to go if we're okay implementing a fallback:
ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)
  Do combined read/write transaction without stop in between.
  Only valid if the adapter has I2C_FUNC_I2C.  The argument is
  a pointer to a

  struct i2c_rdwr_ioctl_data {
      struct i2c_msg *msgs;  /* ptr to array of simple messages */
      int nmsgs;             /* number of messages to exchange */
  }

  The msgs[] themselves contain further pointers into data buffers.
  The function will write or read data to or from that buffers depending
  on whether the I2C_M_RD flag is set in a particular message or not.
  The slave address and whether to use ten bit address mode has to be
  set in each message, overriding the values set with the above ioctl's.

(from https://www.kernel.org/doc/Documentation/i2c/dev-interface)
Probably borrowing the buffers as they go in would be a good plan. Again, we can allow better ergonomics than C but it shows the basic way this could work.
Here's an example

The buffer-copy issue is one that I've run into time and again with embedded C code. It would be really cool if Rust provided a way to elegantly deal with complex transactions without unnecessary allocation/copying.
I think it will be important to provide access to a lower-level API, for use-cases where the concept of a transaction breaks down.

Well, the i2c calls in Linux just take pointers to memory. I have a quick test I’m dabbling with to see. Because we need to stick to the common denominators I’m not sure what the final API should look like, but I’m not sure going to be faster for small buffers and instead it’ll just be more ergonomic.

Totally onboard with improved ergonomics as well.

Also totally onboard with improvements! For anyone else reading, there is related discussion in #64.
I've been wondering whether a builder-style API would work, something like SPI.start().write(&[W]).read(&mut[W]).end() could support transactions while allowing the underlying implementation to group operations if required/available?

A little update: After banging on it a few hours I’m stuck on getting the ioctl to play ball. I’ll reach out to the resident master of these things @posborne.

I'm back after yet more head bashing. I got stuck on a weird drop problem, but my weird little POC is working and there are no memory copies in userland.
Currently at its lowest level I think it could look like this:
        const ADDRESS = 0x53;
        const MESSAGE: &'static [u8] = &[0x01, 0x32, 0x04];
        let data = [0u8; 1];

        let bus = Bus::new(ADDRESS);

        let mut items = [
            bus::write(&MESSAGE),
            bus::read(&data),
            bus::custom_thing(_, _, _),
        ];

        bus.transfer(&items);

Is that a pattern that works for folks? I want to discuss implementation of this with @posborne for inclusion into his i2cdev then port the idea up the HAL once that's done. Does anyone have a better idea for the structure here? I'm not sure what the lowest common denominators are for this interface.

Hey @RandomInsano; this would definitely be a fine feature to add to the i2cdev crate.  If you have something I think we could probably move forward with a PR or proposal for an API on https://github.com/rust-embedded/rust-i2cdev/issues/42.

@RandomInsano: Your comment in #35 made me aware of this issue.  I am strongly against breaking downstream drivers.  One of the main reasons for the design of shared-bus was to keep API compatibility.  What about changing your API to something like this?
let data = [0u8; 1];

let bus = Bus::new(some_param_struct);

bus.transfer(0x53, &mut [
    bus::write(&[0x01, 0x32, 0x04]),
    bus::read(&mut data),
    bus::custom_thing(_, _, _),
]);

This would work perfectly fine with the existing ecosystem and would not reduce flexibility.  For example, some complex driver might need to talk to multiple devices.  Such a driver would then need multiple i2c peripherals/proxies for no real benefit.  I can see why you'd want to bind a bus to an address but I don't think the increase in usability would be big enough to warrant a breaking API change.

On a completely different note, I really like @ryankurte's API proposal so I gave it a shot.  What I came up with looks like this:
let mut buf = [0x00; 8];
bus.transaction(0x44)                  // Transaction for address 0x44
    .write(&[0xde, 0xad, 0xbe, 0xef])  // Write step
    .read(&mut buf)                    // Read step
    .commit().unwrap();                // Actually perform the transaction

The full implementation can be found here.
I think from a user's perspective this API looks a lot nicer.  Under the hood it is a lot more complex because of the use of a recursive type to circumvent the need for allocation but as this should not have too big of an effect on runtime/stacksize I would argue that it is ok.  The complexity is also hidden from peripheral implementations which would look like this:
impl Transactor for Bus {
    fn commit<'a, S: Transact<'a>>(&'a mut self, steps: &'a mut S) -> Result<(), ()> {
        println!("  I2C: Start");
        // The closure is called for each step of the transaction
        steps.transact(|s| match s {
            Step::Write(d) => println!("  I2C: Write {:?}", d),
            Step::Read(buf) => {
                println!("  I2C: Read {:?} bytes", buf.len());
                for b in buf.iter_mut() {
                    *b = 0xff;
                }
            }
        });
        println!("  I2C: End");
        Ok(())
    }
}

One big downside I can see right away is that transactions whose steps are not known at compile time are not easily possible.  I don't know how often they are needed though.

@Rahix I like your suggested alteration to @RandomInsano's suggestion, thought the address only makes sense for the i2c implementation anyway I think.
I think at the moment I am in favour of the array-of-parts approach for it's simplicity, as an additional trait. I wonder whether a default impl over other types would be viable, I think that raises the (SPI at least) question of from where and when the CS pin is controlled.
It should then be possible to experiment and implement a builder api on top as a separate crate if those ergonomics are preferred?

Ooo! I like the idea of something that actually works, and I'm really comfortable with the look of option number 2 it as it maps to other builder interfaces I've used.
I'll try to counter argue how we might benefit more from having an abstraction that owns the bus address / select lines. I've been mulling it over, and we don't need to break existing drivers and the porting effort would (hopefully) be minimal and beneficial.
In the end, this is a good thought exercise and as long as the community benefits it's all fun for me! I don't mind throwing my work out if it's not the right path.
Let's say we have a few abstractions:
I2CProxy(u16)
SPIProxy(OutputPin)
OneWireProxy(u64)

LegacySPIProxy(OutputPin)
LegacyI2CProxy(u16)

We should be able to have the Legacy flavors provide the familiar interface but no-op the addresses that are sent by the address parameter of read() and write(). This would allow backward compatibility with a new system while others opt-in to the new interface. The back end of this new system would ideally start by consuming the existing APIs provided by the device crates, but overtime implementations that work closer to the metal would surface. For i2c, it also allows for devices with multiple addresses to be selected by the consumer.
In the end, i2c, SPI, serial and 1-wire are all transferring either by full or half duplex. I like the idea of having a consistent experience across bus types even if access patterns under the hood are different.
I'm not aware of any devices that require two distinct addresses / busses. If anyone has one, that'll be a great curve ball to think through.
//! Device / Driver consumer examples for the legacy case

// SPI Example
let bus_master = BusManager::new(spi);
let select_eeprom = some_device::gimme_pin();
let bus_node = bus_master::LegacySPIProxy(select_eeprom);
let memory = Mcp3008::new(bus_node, BusManager::dummy_pin());

// I2C Example
let bus_master = BusManager::new(i2c);
let bus_node = bus_master::LegacyI2CProxy(Mag3110::ADDRESS);
let magna_doodle = Mag3110::new(bus_node);

// Multiple Light Sensors
let bus_master = BusManager::new(i2c);
let base_address = Tsl2561::BASE_ADDRESS;
let light_bright1 = Tsl2561::new(bus_master::LegacyI2CProxy(base_address), 0x00);
let light_bright2 = Tsl2561::new(bus_master::LegacyI2CProxy(base_address+0x10), 0x00);
let light_bright3 = Tsl2561::new(bus_master::LegacyI2CProxy(base_address+0x20), 0x00);

@Rahix That looks great already, but I'm wondering if there's a way to turn that into an iterator based approach, so instead of commit() you'd simply iterate on your iterator to do the read byte by byte lazily.

It should then be possible to experiment and implement a builder api on top as a separate crate if those ergonomics are preferred?

@ryankurte: Hmm, unfortunately the builder API can't easily be built ontop of a slice API.  The issue is that I cannot transform the builder type (which is recursive) into a slice without allocation.
I noticed both APIs could be implemented simultaneously if we were to add an impl for slices of Steps:
impl<'a> Transact<'a> for &'a mut [Step<'a>] {
    fn transact<F: FnMut(&mut Step<'a>)>(&'a mut self, mut f: F) -> F {
        for mut s in self.iter_mut() {
            f(s);
        }
        f
    }
}

// ------------------------------------------------------------------------ //

bus.commit(&mut [
    Step::Write(&[0x35, 0xc3]),
    Step::Read(&mut buf1),
    Step::Write(&[0x35, 0xc3]),
].as_mut()).unwrap();

We could even go a step further and implement Transact for Iterators to allow for maximum flexibility:
impl<'a, T: std::iter::Iterator<Item = &'a mut Step<'a>>> Transact<'a> for T {
    fn transact<F: FnMut(&mut Step<'a>)>(&'a mut self, mut f: F) -> F {
        for mut s in self {
            f(s);
        }
        f
    }
}

// ------------------------------------------------------------------------ //

bus.commit(&mut [
    Step::Write(&[0x35, 0xc3]),
    Step::Read(&mut buf1),
    Step::Write(&[0x35, 0xc3]),
].iter_mut()).unwrap();

An updated playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=661c092720504bafc93bb2d9e7e07979

If you don't want this API in embedded-hal, we could alternatively use an iterator based API.  This would allow a separate crate for the builder to be implemented ontop.  The slice example would look like this:
bus.transaction([
    Step::Write(&[0x35, 0xc3]),
    Step::Read(&mut buf1),
    Step::Write(&[0x35, 0xc3]),
].iter_mut()).unwrap();

That looks great already, but I'm wondering if there's a way to turn that into an iterator based approach, so instead of commit() you'd simply iterate on your iterator to do the read byte by byte lazily.

@therealprof: Yes, iterators would be way better here.  I have not yet gotten the implementation running with iterators (mainly because I haven't had time yet) but I am positive that it can be done.  Some design idea/proof of concept: https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=dbc4ee112032a569cd61d2ed224cb2a7
The more I think about it the more I'd like the transaction API to be fully Iterator based, kind of like this:
   User -> <Steps as Iterator> -> Bus -> <Bytes as Iterator> -> User

or in Rust (code not tested):
enum Step<'a> {
    Write(&'a mut std::iter::Iterator<Item = u8>), // Write bytes from an iterator
    WriteSlice(&'a [u8]),                          // Write a slice (mainly for convenience)

    Read(u8),                                      // Read N bytes, these will be available in the return iterator
    ReadSlice(&'a mut [u8]),                       // Read bytes into a buffer (for convenience again)
}

trait Transactor {
    type TransactionIterator: std::iter::Iterator<Item = u8>;

    pub fn transaction<'a, S: std::iter::Iterator<Item = Step<'a>>(&mut self, steps: S) -> Self::TransactionIterator;
}

@RandomInsano: I think we should move the discussion about owning addresses to a separate issue and keep this one purely about transactions.  Would you be ok with opening a new issue and pasting your arguments there?

Yup, can do. I’m just happy to see the transaction idea getting some love.

@ryankurte: Hmm, unfortunately the builder API can't easily be built ontop of a slice API. The issue is that I cannot transform the builder type (which is recursive) into a slice without allocation.

Ahh, right. I forget we can't do C99 style dynamically sized types on the stack.
Iterator based approach to transactions seems good to me! I have a few concerns about iterators instead of slices for data though:

I think the read function above would need to take a mutable iterator for ownership to make sense?
Does using an iterator (ie. not having the knowledge of how long a transfer is) preclude any use cases or optimisations? For examples:

As you mentioned earlier / iirc linux spi and i2c require a buffer to be allocated and copied for use with the ioctl?
-As raised on the other thread, I suspect DMA read or copy can't work from an iterator? Which would preclude automated transfers with yeilds which might be nice for large transfers and multitasking.

Linux's i2c_rdwr ioctl receives an array of pointers to buffers which is what my proposal was based on. You could use the standard read/write interface with single byte buffers, but the context switch overhead between userland/kernel for individual bytes is inefficient.
I agree on the DMA issue. Technically, the HAL doesn't support this as it stands AFAICT but it would be nice to allow consistency in interfaces when it does.
I suppose, what is the value of iterators in this use case? What are the benefits versus the drawbacks?

Aha, I thought this was familiar, we've already had this discussion wrt. iterator based SPI which was designed to address part of this issue https://github.com/rust-embedded/embedded-hal/pull/47 (both the linux overhead and DMA were raised, I am back to my original perspective that I much prefer passing known-sized types).
Agreed about interface consistency. The kind of use case I am thinking in an embedded context is if an OS wanted to provide SPI/I2C either backed by DMA or using a syscall (both needing understanding of size), it should be possible to build that to the same interface and hide the implementation detail so any other SPI consumer is still compatible with it.
The benefits of an iterator I can see are that you can build arbitrary iterator types (and probably compute things on the fly if that was a requirement), that you get all the magic iterator operations, and that you can assemble things (but imo the transaction approach achieves that more ergonomically).

Well, I don't think we actually need transactions in the form start/commit to do the iterators. Instead I'd simply map what's happening on the I2C bus directly into an iterator interface which works lazily with writes acting as a sort of barrier and read returning an iterator. I also wouldn't allow to make this endless, i.e. one "transaction" can either be:

read
write
write then read
Dropping of the transaction or iterator would clean up the I2C peripheral for the next transaction, i.e. also if the iterator is not exhausted for some reason.

I also wouldn't specify the amount of bytes to read() but leave that to iterator operations or the peripheral. So your example would look like:
for (i, b) in bus.transaction()
    .write(&[0xde, 0xad])
    .read()
    .enumerate() {
        println!("Byte [{:02}]: 0x{:2X}", i, b);
    }

for (i, b) in bus.transaction()
    .write(&[0xbe, 0xef])
    .read()
    .enumerate() {
        println!("Byte [{:02}]: 0x{:2X}", i + 4, b);
    }

or
for (i, b) in bus.transaction()
    .write(&[0xde, 0xad])
    .read()
    .chain(bus.transaction()
        .write(&[0xbe, 0xef])
        .read())
    .enumerate() {
        println!("Byte [{:02}]: 0x{:2X}", i, b);
    }

or similar, there're tons of options how to use the iterator. NB: I assume you left off the address for brevity reasons?
But yes, this is a blocking operation. For async I'd also go the Future route.

read does not take input, so it does not need an iterator. Instead it returns an iterator of bytes. Take a look at the second playground link for clarification (sorry for the messy code ...).

I can't seem to grasp from the example how the iterator over those returned bytes could be used? Also if we return an iterator it seems to me like the .next() function would hide the bus timing?

Hmm, DMA is asynchronous which this API is not. At least that is what I had in mind while designing my proposal.

The HAL API is synchronous / blocking, passing iterators precludes the HAL internals being asynchronous. This is an important distinction imo, the caller shouldn't have to know what occurs underneath.

I also wouldn't allow to make this endless

I don't know about endless, but I don't see any reason to limit it, and have SPI use cases that are WriteRead(cmd, &mut status) -> Read(&mut len), Read(&mut data[0..len]) and WriteRead(cmd, &mut status) -> Write(body) -> Write(crc).

I also wouldn't specify the amount of bytes to read() but leave that to iterator operations or the peripheral. [...]

I also vastly prefer handling explicitly sized buffers rather than unknown-length iterators.

But yes, this is a blocking operation. For async I'd also go the Future route.

I agree, but, async is a different problem.

Also if we return an iterator it seems to me like the .next() function would hide the bus timing?

I'm sorry I don't follow. You don't see the bus timing anyway, that's why you have to set a speed at the master and let the peripheral work at it's own pace.

This is an important distinction imo, the caller shouldn't have to know what occurs underneath.

I disagree, a caller always needs to know whether a call is blocking or non-blocking even if just for the error handling. (A-)synchronicity is often related to blocking / non-blocking but not always the same thing.

I also vastly prefer handling explicitly sized buffers rather than unknown-length iterators.

Why? You can still easily transfer the values into your sized buffer, like:
let mut vales : [u8; 8] = [0; 8];
for (v1, v2) in values.iter_mut().zip(bus.transaction()
    .write(&[0xde, 0xad])
    .read()
    .take(8)) {
        *v1 = v2;
}

Why? You can still easily transfer the values into your sized buffer, like:

I'd agree that we don't need size specifications if we were to only allow single reads in a transaction.  But that would entirely miss the point of transactions: To allow more complex bus operations to be done atomically.

I don't know about endless, but I don't see any reason to limit it, and have SPI use cases that are WriteRead(cmd, &mut status) -> Read(&mut len), Read(&mut data[0..len]) and WriteRead(cmd, &mut status) -> Write(body) -> Write(crc).

This is exactly what transactions are for.  Limiting would miss the point; in that case you could simply use the existing traits.
Because of this, I agree with @ryankurte that we need size specifications.
We could allow iterating beyond the length of the transactions steps and map that to further reads, but that could get confusing/lead to bugs, that aren't easy to see.

I disagree, a caller always needs to know whether a call is blocking or non-blocking even if just for the error handling. (A-)synchronicity is often related to blocking / non-blocking but not always the same thing.

I agree with you on that, we should not hide this implementation detail.

I'm sorry I don't follow. You don't see the bus timing anyway, that's why you have to set a speed at the master and let the peripheral work at it's own pace.

I was imagining the returned iterator being returned directly and passed into other read functions or something, but, maybe that's not possible?

I disagree, a caller always needs to know whether a call is blocking or non-blocking even if just for the error handling. (A-)synchronicity is often related to blocking / non-blocking but not always the same thing.

Agreed, but, a function that appears blocking could have other scheduling underneath it, an OS with a syscall based approach to peripheral access could preempt the running thread and schedule something else, or put itself to sleep, while the transfer occurred. To the caller, this appears blocking, but on the processor other things can be happening while it blocks. Similar to the linux example, it's not possible to implement this effectively without knowing the transfer size.

Why? You can still easily transfer the values into your sized buffer, like:

I'm not good enough at rust to work out what your iterator example is doing :-/
As opposed to something like this?
let mut values : [u8; 8] = [0; 8];
bus.transaction([
    Step::Write(&[0xde, 0xad]),
    Step::Read(&mut values),
].iter_mut()).unwrap();

We could allow iterating beyond the length of the transactions steps and map

Sounds v complicated, I think I agree / don't think that's ideal for the hal?

I was imagining the returned iterator being returned directly and passed into other read functions or something, but, maybe that's not possible?

Oh, in theory it is possible but passing Iterators is a bit iffy (especially in embedded) so unless absolutely necessary I wouldn't think anyone does that on purpose.

Agreed, but, a function that appears blocking could have other scheduling underneath it, an OS with a syscall based approach to peripheral access could preempt the running thread and schedule something else, or put itself to sleep, while the transfer occurred. To the caller, this appears blocking, but on the processor other things can be happening while it blocks.

How's this different from embedded? You can also serve other interrupt, or if you're handling it in an interrupt handler, run stuff from your main routine.

Similar to the linux example, it's not possible to implement this effectively without knowing the transfer size.

Well, the other side could throw you a curveball and simply not comply with what you're expecting in transfer size so you (and the system) need to be prepared to handle other amounts as well.

I'm not good enough at rust to work out what your iterator example is doing :-/

It packs 8 bytes from a write-then-read operation into an array of your choosing (you can leave out the take(8) actually, I just added it for more clarity that you can limit the amount of data read explicitely).
Iterators allow you to so just so much more than fixed arrays:

Variable amounts of data
On the spot data conversion and processing
... with early abort on faulty data
introspection of incoming data while it is coming in (for me this is huge!)

In many cases I'm just reading into arrays/slices so I can then iterate over the data which is rather annoying.

I'd agree that we don't need size specifications if we were to only allow single reads in a transaction. But that would entirely miss the point of transactions: To allow more complex bus operations to be done atomically.

Okay, my point is you're trying to model something that the hardware does not guarantee you. In I2C there's exactly the three mentioned cases of write/read/write-then-read which can be considered one transaction. So from my perspective it does not make too much sense to build an abstraction of a "super-transaction" on top of that.

How's this different from embedded? You can also serve other interrupt, or if you're handling it in an interrupt handler, run stuff from your main routine.

Only in that you can't make a syscall with knowing how much memory to transfer. I think that's an argument for using slices for both steps and data. Also if a similar works for linux maybe it's a design worth considering?

Well, the other side could throw you a curveball and simply not comply with what you're expecting in transfer size so you (and the system) need to be prepared to handle other amounts as well.

Sure, but it should always be less than expected, and knowing the size lets you work out whether it's ok or not.

Iterators allow you to so just so much more than fixed arrays:

They do, but they're also more complicated, and imo less easy to write determinate code around. You cant rationalise about the size until they're evaluated, as you mentioned you can't really pass them. Slices imo are a simpler thing to base everything on. I'm also worried that having both could be bad for compatibility between hal dependents?

Variable amounts of data

Interesting, I'm not sure how to handle this in a single transaction with slices. ime I usually read the size in one transaction from one memory location, then the data in a separate one from another location, in which case it's not a huge issue.

On the spot data conversion and processing

I like in place / zero copy parsing of data to structs, I think they're mutually exclusive?

early abort on faulty data

Like, in between operations in a transaction?

introspection of incoming data while it is coming in (for me this is huge!)

Yeah, that'd be neat, what do you usually use it for?

In many cases I'm just reading into arrays/slices so I can then iterate over the data which is rather annoying.

I find the opposite :-/

In I2C there's exactly the three mentioned cases of write/read/write-then-read which can be considered one transaction

I think maybe the term transaction is not clear here, my understanding is that we're talking about one transaction as one of the listed write/read/write-then-read, but, assembled from a set of different slices to make the hal more friendly? For example am eeprom read might consist of a const address slice, an immutable offset slice, and a mutable data slice for returned data.
I had a bash at a slice based transactional api over the existing SPI trait, though it's not quite expressive enough I think.

I think maybe the term transaction is not clear here, my understanding is that we're talking about one transaction as one of the listed write/read/write-then-read, but, assembled from a set of different slices to make the hal more friendly?

This is my definition. See the OP for two examples, I should go looking around for more.

They do, but they're also more complicated, and imo less easy to write determinate code around.

I could not disagree more.

You cant rationalise about the size until they're evaluated

Well, you can evaluate them in place, same as the transaction with slices.

as you mentioned you can't really pass them.

You can pass them but it's not really a good idea, but the same can be said for slices. You really want to parse your data into useful structures ASAP.

Slices imo are a simpler thing to base everything on.

You can still use slices if you want to do that. I do find them rather annoying, converting them into anything useful is a major PITA and often involves iteration anyway, cf. https://github.com/rust-embedded/cortex-m-rt/pull/107/files#diff-cdc6ef2a70d26bf65a4057f6a49a336d

I like in place / zero copy parsing of data to structs, I think they're mutually exclusive?

Not sure what you're trying to say. With iterators everything is happening in place, no need to create a buffer on the stack, fill it and then pull out the relevant data. If you have a huge dump of data with iterators you can simply skip the irrelevant data (or just validate that you get what you're expecting).

Like, in between operations in a transaction?

As in: You're reading a record of data and there's an invalid flag pretty much in the beginning of it (like GPS records). In that case you can simply abort the bus operation by exiting the iteration.

Yeah, that'd be neat, what do you usually use it for?

Debugging. When you're working with devices which have less than optimal documentation it's great if you can simply pop in aninspect() in your iterator chain and have a peek at the data you're getting. The next best way to debug data on a bus is to physically hook up a logic analyser or my oscilloscope with a protocol decoder to look at the communication. (Yeah, I know some people really enjoy running a dev build in a debugger but I'm not one of them and sometimes it's not even possible because that seriously screws with the timing).
IIRC there were a few discussions about iterator interfaces in other issues. Maybe it'd be worth looking through these...

Taking a step back from the conversation and surveying the landscape of it so far, it looks like the sides of the argument are driven by personal preference. One is traditional to interfaces in other languages and seems simpler to implement. The other allows an interface and usage style that models more to how the way physical busses actually operate.
These kinds of arguments are fun and are a great way to find limitations in either implementation but usually spinlock with neither side wanting to yield. We need @japaric to do the BDFL thing and pick a baby or put it up to a community vote so we can all work together to implement a solution to this problem.
I don't have a heck of a lot of time lately due to work and life commitments but I think both sides (slices vs iterators) need to polish up proposals from what's been said back and forth here to make it digestible for either Jorge or that vote. Then it's pistols at dawn!
Is November 9th a good date? That'll be a little under three weeks, and it's two months after I opened this guy.

FYI this is now supported in rust-i2cdev (docs)

I put together a PR (https://github.com/rust-embedded/embedded-hal/pull/178) with simple transactional I2C and SPI traits for discussion / review.
@eldruin i'm not totally clear on the need for the I2CMessage trait here, is there a reason we would need to promote something like this to the embedded-hal crate?

@ryankurte Sounds good. From the top of my head I do not think we need the I2CMessage trait but honestly I do not remember why I chose that solution for linux-embedded-hal right now. I would need to think about it again.

Does this still need to be open?

Indeeed. We support I2C and SPI transactions now.
Thank you to everybody involved for the fruitful discussion.
Also thanks @Dominaezzz for noticing.


Items appear incorrectly in Chrome

Items disappear from the left side when they reach the edge of the screen (right direction) on first load and/or page reload (Chrome only). Appear only when the mouse cursor moves or another action (click or scroll, for example)

Fixed in 1.4.0


Support Keyed Data

As of right now, the data table component does not support the ability to load data into a separate domain for redux applications.
This makes it difficult should the component be mounted twice in the same view, or is having data prefetched for a view that will be loaded in the future. There are ways around this, but the much simpler solution is to support multiple states.
This PR is non-breaking.
Related issues: #37
/cc @carlosrocha

@carlosrocha Any chance to look at this? I'm having to bounce from this project in a few days and wanted to land this.


split path differently in SOR

Path in the SOR should be split proportional to the amount of normalizedLiquidity and not 50/50

handled by sdk team


Patch function DRAFT

This is work in progress but I want to get some feedback from reviewers.
Some of my questions/concerns/comments:

Two Patch implementations for now:

Patch(record, record)
Not the focus although it is going to be implemented anytime soon.

Patch(dataSource, record, arg1, arg2, ...)
The priority one.

In order to update a record, I'm simply removing the old record (ICollection.Remove(T)) and adding a new version of it. Is there a better/prettier way to do this?
I'm still working on the CheckInvocation implementations.
I'm still working on how to handle errors.
A new handler has been added for test units. Is this the way or is there a better approach?
Any other major concerns?

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220825-318698.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220825-318698.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

@MikeStall about this binary compatibility issue, this is happening because Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction was previously merged into main and now it has been removed due to the new EnableMutationFunctions method. Should I bring back the EnableCollectFunction method just for compatibility purposes?

This breaking change is ok. We just introduced the function, PowerApps doesn't depend on it yet.

In reply to:<PHONE_NUMBER>

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220826-318850.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220826-318850.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220828-318998.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220829-319146.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

Move Patch (and Collect) to \Functions\Mutation folder.
Change their namespaces to Microsoft.PowerFx.Functions

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220829-319193.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220830-319326.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220830-319360.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220830-319375.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220830-319390.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220830-319441.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220830-319453.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220830-319453.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:x: 1 Binary Compatibility issues for Microsoft.PowerFx.Interpreter compared against version 0.2.2-preview.20220830-319453.

MembersMustExist : Member 'Microsoft.PowerFx.PowerFxConfigExtensions.EnableCollectFunction(Microsoft.PowerFx.SymbolTable)' does not exist in the implementation but it does exist in the contract.

:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.LanguageServerProtocol.dll**
:heavy_check_mark: No Binary Compatibility issues for **Microsoft.PowerFx.Transport.Attributes.dll**


Consider a more user-friendly interface for the Edmonds-Karp max flow algorithm

It is tedious having to add reverse edges to a graph when they do not exist. Look if there is a way to do the same without losing performance.

A flow_network class was added for the sake of simplicity :)


Update flame graph

:tada: This issue has been resolved in version 0.92.0 :tada:
The release is available on:

v0.92.0
GitHub release

Your semantic-release bot :package::rocket:


pam_ssh_agent_auth: Honour services.openssh.authorizedKeysFiles

If a system administrator has explicitly configured key locations this should be taken into account by sudo.
Note This needs some things before merging:
~- A test~  - see comment

[x] A release note with big fat red warning stickers :warning: :rotating_light:

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

I gave up on writing a test after battling segmentation faults in sudo that I could not reproduce outside of the VM...

If you get around fixing the segfaulting test feel free to reopen the discussion.

@SuperSandro2000 I don't think the segfaulting tests are super important to fix. It was a while ago since I looked at this but iirc I concluded that it was an upstream bug in sudo and had nothing to do with the PAM module, and it was absolutely unrelated to anything this PR touches.


WHERE NOT EXISTS in INSERT is not supported ?!!

I have watched most of your talks and I was keen to try sqlpp11, I recommended sqlp11 for CPP client API for our Postgres DB in my company. today a couple of my teammates came to me asking if the library supports a simple query as follows:
"INSERT INTO GroupPathMapping(unique_gid, path_id) "
" SELECT %(unique_gid)s, %(path_id)s "
" WHERE NOT EXISTS (SELECT * FROM GroupPathMapping "
" WHERE unique_gid=%(unique_gid)s "
" AND path_id=%(path_id)s);"
at the moment I haven't found anything in the tests and examples and also the online documents poiting at this, so I decided to ask a question here

Personally, I would not consider this a simple query :-)
You could do something like this:
const auto x = 17;
custom_query(insert_into(foo).columns(foo.omega),
       select(sqlpp::value(x).as(foo.omega))
           .from(foo)
           .where(not exists(select(foo.omega).from(foo).where(foo.omega == x))));

I added small fix on develop.  Thanks. I really wish you had better documentation for this library, but at the same time, I understand writing the documentation is probably the least interesting and most time-consuming part of building a library.

We tried what you suggested, but in postgres, we get the custom query serialized to:
INSERT INTO tab_foo (omega) VALUES
SELECT 17 AS omega FROM tab_foo
WHERE (NOT EXISTS(SELECT tab_foo.omega FROM tab_foo WHERE (tab_foo.omega=17)))
which throws an exceptio because of bad syntax

Better documentation is on the wish list I am currently compiling.


Support for S6 MaxV

Support for S6 MaxV.
Handling for custom fan and water speed modes (can the custom s6 mode also used for the s5 ?) right now, I implemented a new water speed array.
Timeout problem with pause mode.
Add S6 MaxV picture
Update Changelog (please check version number)
Update readme with S6 MaxV picture
SetSpeed and SetWaterSeed can also handle set by mode name( e.g. Custom, Balanced,...)

Btw. that should also fix "Roborock S6 MaxV | Model does not support the water mode #233"


doc: add install steps

doc: add install steps
describe installation steps and define internal convention to assign tag of release

Actually i would describe in a distinct place like, e.g. README.iflix to not to mess with upstream one


137 | Single Number II | Python

Single Number II
What will change -
Type of Issue -

Adding New Code

Programming Language

Python

Self Check

Ask for issue assignment and wait to get assigned to it before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Discord server ✉ - https://discord.gg/CXksGdn
Happy Coding,

plz assign it to me

Actually I want to do this. Please let me work on this

[x] Assigning to @JayeshSareen for issue creation

bruh i asked first. orelse he must have mentioned that he is doing this during issue creation.

@Nithin005 The first preference will be given to the issue creator, always.

Can I be assigned to this?

Please assign it to me. I will give my best for the contribution.
Thank You.

@adhamale2810 you can create your own issue.


share file to multiple user at a time

share function should able to take email of multiple users and share the file with all of them.

@raghav-dalmia Sorry for the delayed response. You can start working on this.
Thanks.

at this time I am focusing on google doc's issue. I will do it later. If someone wants to solve this issue can solve it after taking permissions from collaborators.

I also solve this issue.


promote_type is not supposed to be overloaded

Several methods are added for promote_type in src/libarb/promote.jl. Xref JuliaLang/julia#54138

This was intentional.  At the time it was written, this approach worked best. It may well be that over time, as Julia evolved, it is no longer needed.


Fix Windows support, expand GHA platform coverage

Global cLocale constant was broken on Windows and was actually unused, it made sense to remove it.
Additionally, I've expanded macOS Xcode version matrix to include 12.4, 12.5, and 13.0 for testing with different Swift versions. Now all Xcode version values are quoted, since YAML automatically parses 13.0 as a number not a string, converting it to plain 13, which breaks the build.
For testing on Windows I'm MaxDesiatov/swift-windows-action which invokes swift test automatically, but let me know if you'd like that to be more explicit.

Global cLocale constant was broken on Windows and was actually unused, it made sense to remove it.

Good catch, thanks! That was a relic from when we used strtod_l, but that was causing problems, so we decided to manually parse doubles instead, which wasn't actually so bad from a performance perspective compared to strtod_l.

Would it be possible to tag a new release that includes this change anytime soon? This would allow code depending on Swift parsing to specify this version instead of the branch for Windows support, which I'd assume is much safer from the API breakage perspective.

@MaxDesiatov Done! https://github.com/pointfreeco/swift-parsing/releases/tag/0.2.0
Are you using swift-parsing in an open source project? Would love to see :smile:

It's very early stage, not much to see there yet or to be shared widely, but I'll just leave it here https://github.com/MaxDesiatov/Kara

Thanks for sharing! If you hit any stumbling blocks or develop any interesting parsers that would be useful to contribute back, please open a discussion here if you find the time.

One interesting approach I came up with is using a specific structure for line/column counting that I then utilize for diagnostics and LSP support:
public struct ParsingState: Equatable {
  let source: String
  var index: String.UTF8View.Index
  var column = 0
  var line = 0
}

defined here https://github.com/MaxDesiatov/Kara/blob/main/Sources/Syntax/Parsing/StatefulParser.swift
I didn't not come up with a better name for it. I then use it as an input for all other parsers:
struct StatefulParser<P: Parser>: Parser where P.Input == UTF8SubSequence {
  let inner: P

  func parse(_ state: inout ParsingState) -> SourceRange<P.Output>? {
    let startColumn = state.column
    let startLine = state.line

    var substring = state.source.utf8[state.index...]
    let initialCount = substring.count

    guard let output = inner.parse(&substring) else {
      return nil
    }

    state.index = substring.startIndex
    state.column += initialCount - substring.count

    return SourceRange(
      start: .init(column: startColumn, line: startLine),
      end: .init(
        column: state.column - 1,
        line: state.line
      ),
      content: output
    )
  }
}

extension Parser where Input == Substring.UTF8View {
  func stateful() -> StatefulParser<Self> {
    .init(inner: self)
  }
}

This only works for wrapping parsers that don't consume newlines at all. I have a few other helpers for that if you're interested.

Overall, I found Swift Parsing to be super flexible and composable, and I'm very glad that I've chosen it for my project. The consensus on the internet seem to be that programming language parsers should be hand-written, and parser combinators are not a good fit because of their lack of diagnostics customization. This is definitely not the case here. Given that Parser type can accept any arbitrary input, I can easily add diagnostics infrastructure on top of it and it's very composable and flexible.
Thanks for the fantastic library and for tagging the new release promptly! As usual, your work is amazing!

Glad to hear it! We have big plans for the project and will hopefully give it more attention soon.

Invertible parsing is probably the thing we've had the most experience with (getting a printer for free when you define a parser, which is helpful for things like URL request routing, but also you could potentially get a pretty printer or minifier with little work).
Error handling is a little vaguer, but we want parsing to support throwing in the future, rather than rely on nil.
Async/await support is vaguer still, but something we definitely want to figure out for parsing streams of bytes.

Invertible parsing is probably the thing we've had the most experience with (getting a printer for free when you define a parser, which is helpful for things like URL request routing, but also you could potentially get a pretty printer or minifier with little work).

Oh my, I would love to see this! I saw your printers work in the other branch, but didn't know that printers can be inferred from parser definitions. I'm definitely interested to know how performant it is though.

Error handling is a little vaguer, but we want parsing to support throwing in the future, rather than rely on nil.

I wish this would be opt-in only. Throwing a single error from the parsing process is not desirable in my situation. For good diagnostics I need to collect multiple errors if possible. Overall, I think that error handling should not be implemented on the parsing level at all. As in, if we fail to consume all input, yes that's an error. But ideally I want my programming language parsers to be flexible enough to consume as much as possible of the "broken" input. Then on the higher level, after parsing is finished, I can go through invalid syntax nodes and audit them as needed, producing multiple detailed error messages. I'm following the approach described here https://duriansoftware.com/joe/constructing-human-grade-parsers

Async/await support is vaguer still, but something we definitely want to figure out for parsing streams of bytes.

Not really relevant for me personally, and I'm not sure what the use case could be, unless some async operations like file/network IO are needed for a parser to proceed. But then why wouldn't I get that data before the parsing started and feed that data to a parser synchronously?
Another thing I found useful I recalled just now is debugging parsers. It's very similar to Combine's print operator, I just stick it on top of any parser I find behaving erratically to help me diagnose issues https://github.com/MaxDesiatov/Kara/blob/main/Sources/Syntax/Parsing/Debug.swift

I hope this would be opt-in only. Throwing only a single error from the parsing process is not desirable in my situation. For good diagnostics I need to collect multiple errors if possible. Overall, I think that error handling should not be implemented on the parsing level at all, at least for any non-trivial parser. As in, if we fail to consume all input, yes that's an error. But ideally I want my programming language parsers to be flexible enough to consume as much as possible of the "broken" input. Then on the higher level, after parsing is finished, I can go through invalid syntax nodes and audit them as needed, producing multiple detailed error messages. I'm following the approach described here https://duriansoftware.com/joe/constructing-human-grade-parsers

I don't think adding throws would change things drastically. I think your experience would be the same, but you'd catch upstream errors and accumulate them rather than nil-test. Introducing a dedicated parsing error type would come with more benefits, like a better default debugging experience and the ability to generate pretty errors pointing to where parsing failed and why.

Not really relevant for me personally, and I'm not sure what the use case could be, unless some async operations like file/network IO are needed for a parser to proceed. But then why wouldn't I get that data before the parsing started and feed that data to a parser synchronously?

It would allow you to drastically reduce the memory footprint of the application. If an app wanted to parse gigs of data, for example.

Another thing I found useful I recalled just now is debugging parsers. It's very similar to Combine's print operator, I just stick it on top of any parser I find behaving erratically to help me diagnose issues https://github.com/MaxDesiatov/Kara/blob/main/Sources/Syntax/Parsing/Debug.swift

Nice! Yeah we've defined a similar parser in a project.

It would allow you to drastically reduce the memory footprint of the application. If an app wanted to parse gigs of data, for example.

Right, I initially thought you'd handle this by parsing asynchronous chunks independently, which could work for CSV, but now thinking about it, is obviously not gonna work for JSON/YAML or XML.


[wrangler] feat: Support for Browser Workers

What this PR solves / how to test:
Adds support for the browser workers binding.
Author has included the following, where applicable:

[x] Tests
[x] Changeset (Changeset guidelines)

Reviewer has performed the following, where applicable:

[ ] Checked for inclusion of relevant tests
[ ] Checked for inclusion of a relevant changeset
[ ] Checked for creation of associated docs updates
[ ] Manually pulled down the changes and spot-tested

a bit more details about the discussion and how we decided on the shape of the public API in this PR: https://github.com/cloudflare/workers-sdk/pull/3135#discussion_r1191387232


sw-7008 updating packages #minor

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (db932d9) 74.66% compared to head (06490ac) 74.66%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #435   +/-   ##
=======================================
  Coverage   74.66%   74.66%
=======================================
  Files          35       35
  Lines        1950     1950
=======================================
  Hits         1456     1456
  Misses        405      405
  Partials       89       89

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


made docsearch attribute reflect version of page

Signed-off-by: thisisobate<EMAIL_ADDRESS>

[ ] I added CHANGELOG entry for this change.
[x] Change is not relevant to the end user.

Changes
Made docsearch attribute reflect the version of the page

Verification
Works on local

it will result in meta tags with values v0.2

cool, just tested this and it works perfectly in the preview :)

Awesome!


Transport protocol, port number & encryption method for PowerToys update

Provide a description of requested docs changes
Hi,
Can I check what's the transport protocol (TCP/UDP/both), port number, and encryption method (SSL? TLS?) to update PowerToys?
Update is blocked by company cybersecurity, will require these info to unblock.
Thanks!

literally a restful API call to PowerToys and we download the file in the release associated with your proc & installer type.  all stock https, nothing magic
https://github.com/microsoft/PowerToys/blob/4743632dfad38ac0a895bd48754b3ff5e3831586/src/common/updating/updating.cpp#L19


GAWB-3081: Add Codecov

Addresses

https://broadinstitute.atlassian.net/browse/GAWB-3081

See Also

https://github.com/DataBiosphere/consent-ontology/pull/92

[ ] Submitter: Include the JIRA issue number in the PR description
[ ] Submitter: Make sure Swagger is updated if API changes
[ ] Submitter: Check documentation and code comments. Add explanatory PR comments if helpful.
[ ] Submitter: JIRA ticket checks:

Acceptance criteria exists and is met
Note any changes to implementation from the description
Add notes on what you've tested

[ ] Submitter: Update RC_XXX release ticket with any config or environment changes necessary
[ ] Submitter: Update FISMA documentation if changes to:

Authentication
Authorization
Encryption
Audit trails

[ ] Submitter: If you're adding new libraries, sign us up to security updates for them
[ ] Tell the tech lead (TL) that the PR exists if they wants to look at it
[ ] Anoint a lead reviewer (LR). Assign PR to LR

Review cycle:

LR reviews
Rest of team may comment on PR at will
LR assigns to submitter for feedback fixes
Submitter rebases to develop again if necessary
Submitter makes further commits. DO NOT SQUASH
Submitter updates documentation as needed
Submitter reassigns to LR for further feedback

[ ] TL sign off
[ ] LR sign off
[ ] Product Owner sign off
[ ] Assign to submitter to finalize
[ ] Submitter: Verify all tests go green, including CI tests
[ ] Submitter: Squash commits and merge to develop
[ ] Submitter: Delete branch after merge
[ ] Submitter: Test this change works on dev environment after deployment. YOU own getting it fixed if dev isn't working for ANY reason!
[ ] Submitter: Verify swagger UI on dev environment still works after deployment
[ ] Submitter: Inform other teams of any API changes via hipchat and/or email
[ ] Submitter: Mark JIRA issue as resolved once this checklist is completed

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop@d485fcf). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop     #253   +/-   ##
==========================================
  Coverage           ?   56.81%
  Complexity         ?       58
==========================================
  Files              ?      242
  Lines              ?     7806
  Branches           ?      731
==========================================
  Hits               ?     4435
  Misses             ?     3016
  Partials           ?      355

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 d485fcf...484e9dc. Read the comment docs.

I like the reports, and it's nice to see the visual+stats right in the PR instead of needing to link over to the other service. I'd also love to hear from peers (including outside our immediate team) if anyone has opinions on codecov vs. coveralls vs. something else.

closing in favor of https://github.com/DataBiosphere/consent/pull/254


Differentiate icon colors between Comment and Submit

Curently the two icons share the same colors: black on the list and Grey on the file detail page.
It would be good to have two different colors to better distinguish them because the two black icons are very close when looking quickly:

e.g. the comment icon could have black outline and white inside
or the submit icon could be in yellow

It's not an important request but an easy one to implement ;)

Comment made blue.


Error while adding user with - in the name

Describe the bug
The bot add @Wei instead of @Wei-1 while using the command in a PR.
To Reproduce
Steps to reproduce the behavior:

Go to any repo with @all-contributors bot
Use @all-contributors please add Wei-1 for maintenance
Check the PR created by @all-contributors bot
See that it add @wei instead of @Wei-1

Expected behavior
It should add @Wei-1 instead
Screenshots
https://github.com/Curt-Park/rainbow-is-all-you-need/pull/12
Additional context
Probably caused by - sign

Fixed at https://github.com/Curt-Park/rainbow-is-all-you-need/pull/32

@Wei-1 bot needs @ before user name. Had same problem - check here: https://github.com/all-contributors/all-contributors-cli/issues/225#issuecomment-552918505
So you should use: Use @all-contributors please add @Wei-1 for maintenance and it should work correctly.

@Wei-1 as you can see above ;)
Please somebody delete that PR :D
BTW: How did you manage to create this issue without genrating new bot PR :) ?

That's a very good question @marekrozmus I have no idea though..
btw, should we close this issue?

I think there is still an issue with "-" see this:
https://github.com/ComplianceAsCode/content/issues/5355#issuecomment-605331289
And it created https://github.com/ComplianceAsCode/content/pull/5480

@Wei-1 as you can see above ;)
Please somebody delete that PR :D
BTW: How did you manage to create this issue without genrating new bot PR :) ?

I think that's because the issue / PR needs to exist before quoting the bot, see https://github.com/all-contributors/all-contributors/issues/380#issuecomment-619587900

I believe this needs fixing in the parseAddComment(), but on a side note; GitHub won't let you register such account names (anymore?) as per:

Username may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.

Thank you @Wei-1

Fixed in #307

Does that make my username valuable? :) thanks for fixing @baikho


[Bug]: Class "Filament\Plugin\ModulesPlugin" not found

What happened?
When performing a dump-autoload and have already registered the pluggin in your panel. When you try to do a install the plugin with: php artisan module:filament:install MyModule, you get this error.
How to reproduce the bug
Add the package and configure
composer require coolsam/modules
php artisan vendor:publish --tag="modules-config"
Register the plugin
// e.g. in App\Providers\Filament\AdminPanelProvider.php

use Filament\Plugin\ModulesPlugin;
public function panel(Panel $panel): Panel
{
    return $panel
        ...
        ->plugin(ModulesPlugin::make());
}

Create a Module
php artisan module:make MyModule
Install the Module
php artisan module:filament:install MyModule
Package Version
4.0
PHP Version
8.0
Laravel Version
11.9
Which operating systems does with happen with?
Linux
Notes
##Solution
When registering the plugin in your panel, one should use the package namespace rather than filament namespace
// e.g. in App\Providers\Filament\AdminPanelProvider.php

use Coolsam\Modules\ModulesPlugin;
public function panel(Panel $panel): Panel
{
    return $panel
        ...
        ->plugin(ModulesPlugin::make());
}

@bacipher I was facing the same issue. Upon investigation I have found that I was using  "coolsam/modules": "4" in my composer.json. I updated it to  "coolsam/modules": "^v4.0.6". And it works.

try
use Coolsam\Modules\ModulesPlugin;


Update multiselect string in en.json

Summary
Updated string for ""multiselect.numPeopleRemaining": "Use ↑↓ to browse, ↵ to select. You can add {num, number} more {num, plural, one {person} other {people}}. "," in line with suggestions in the Jira ticket but slightly edited.
Ticket Link
https://mattermost.atlassian.net/browse/MM-23406
Related Pull Requests
Screenshots

I think the JIRA ticket proposed "You can add up to 20 new members at a time"?
Using the word "invitation" is confusing to me since it's not an "invitation", the user is being added directly

I think the JIRA ticket proposed "You can add up to 20 new members at a time"?
Using the word "invitation" is confusing to me since it's not an "invitation", the user is being added directly

Yep, that is what the Jira ticket proposed and I started with that but when applying it to the singular it didn't seem to read well so I went with "invitation" as an alternative.
For the option suggested in the Jira ticket, using the string below and the suggestion in the Jira ticket, it would read:
"multiselect.numPeopleRemaining": "Use ↑↓ to browse, ↵ to select. You can add up to {num, number} more {num, plural, one {person} other {people}}. ","
"You can add up to one more person" and "you can add up to 20 more people".
One option could be to break that up and have one string for singular "you can add one more person at a time" and one for plural "you can add up to 10 more people at a time".
That isn't how the rest of the singular/plural strings are written and I don't want to introduce unnecessary complexity. Happy to go with the original suggestion if it works best. :)

I gave this some more thought and a less complicated option would be to have a static message of "You can add up to 20 people at a time", cutting out the need for singular and plural. So, disregard my previous comment.

"You can add up to 20 people at a time"

Works for me :)

@justinegeffen can you help make the updates discussed above and then move this to dev review? Thanks!

Thanks, @esethna. Update is done; added @jespino as reviewer, let me know if anyone else should be added. Thanks!

Thanks everyone for the reviews, looks like this is good to go so I changed it to reviews complete. :)

/update-branch


mounted on Blog model acts_as_followable returns applicationrecord for followable_type

i mounted on my Blog model, now acts_as_followable returns applicationrecord for followable_type

Nevermind, I thought it was ok to inherit from ApplicationRecord but that was wrong


Add a .onion link

This is so people can access the site using tor, might make some people feel safer.
This would need a separate frontend that doesn't contain any tracking and no links to anything but out service

I dont think it would tho, the front end stuff.

Otherwise good idea, but there is no tracking in the current website?

It would be worth it just to make sure that visitors are not exposed by mistake in our code

Onion is a little TOO extreme for this, something like wikileaks or something using onion would make sense, this wouldnt...............

At the current state it might be, But adding it is effortless and some people might appreciate it.


No documentation of the migration's name

It must start with 3 numbers, like 001_something.py

in line 195 of router.py is the regex r"[\d]{3}_[^\.]+\.py$".
3 numbers, underscore, every char except "." for one or more times, ".py" and the end of string.
so... these would be possible:
999_a.py 001_foo_bar-foo.py 001_helloWorld.py
and even 1000_a-foobar.py would match


rc2 operator crashes

upgraded the deployment from rc.1 to rc.2 and added the --haproxy-image-tag=1.8.8-7.0.0-rc.2-alpine param to the operator
there are two ingress' registered but the operator crashes when checking the first

the crash log
I0523 07:43:37.093998       1 run.go:21] [Starting voyager...]
I0523 07:43:37.113848       1 http.go:97] [Running http server provider...]
I0523 07:43:38.320327       1 audit.go:229] No audit policy file provided for AdvancedAuditing, no events will be recorded.
I0523 07:43:38.355065       1 operator.go:107] [Ensuring CRD registration]
W0523 07:43:41.511949       1 servicemonitors.go:17] Skipping watching non-preferred GroupVersion:monitoring.coreos.com/v1 Kind:ServiceMonitor
I0523 07:43:41.513714       1 serve.go:96] Serving securely on [::]:8443
W0523 07:43:41.548495       1 validator.go:52] Checking ingress test/test-ing
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x10bee89]
 goroutine 147 [running]:
github.com/appscode/voyager/apis/voyager/v1beta1.Ingress.IsValid(0xc4202c1058, 0x7, 0xc420296940, 0x1c, 0xc4202c1350, 0xc, 0x0, 0x0, 0xc4202c1369, 0x5, ...)
	/go/src/github.com/appscode/voyager/apis/voyager/v1beta1/validator.go:336 +0x5999
github.com/appscode/voyager/pkg/operator.(*Operator).ValidateIngress(0xc4203b3c00, 0x0, 0x0)
	/go/src/github.com/appscode/voyager/pkg/operator/validator.go:53 +0xb59
github.com/appscode/voyager/pkg/operator.(*Operator).Run(0xc4203b3c00, 0xc420054960)
	/go/src/github.com/appscode/voyager/pkg/operator/operator.go:167 +0x35
created by github.com/appscode/voyager/pkg/server.(*VoyagerServer).Run
	/go/src/github.com/appscode/voyager/pkg/server/server.go:58 +0x51

the ingress in question
kubectl describe ingress.voyager.appscode.com -n test test-ing
Name:         test-ing
Namespace:    cloud
Labels:       <none>
Annotations:  ingress.appscode.com/type=HostPort
              kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"voyager.appscode.com/v1beta1","kind":"Ingress","metadata":{"annotations":{"ingress.appscode.com/type":"HostPort","kubernetes.io/ingress....
              kubernetes.io/ingress.class=voyager
API Version:  voyager.appscode.com/v1beta1
Kind:         Ingress
Metadata:
  Cluster Name:
  Creation Timestamp:  2018-05-17T09:23:42Z
  Finalizers:
    voyager.appscode.com
  Generation:        1
  Resource Version:  1310104
  Self Link:         /apis/voyager.appscode.com/v1beta1/namespaces/test/ingresses/test-ing
  UID:               fd6f903e-59b3-11e8-933a-9600000a4865
Spec:
  Frontend Rules:
    Port:  80
    Rules:
      log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ {%[ssl_c_verify],%[ssl_fc_has_crt],%{+Q}[ssl_c_s_dn],%{+Q}[ssl_c_i_dn]}\ %{+Q}r
      http-request redirect prefix http://%[hdr(host),regsub(^www\.,,i)] code 301 if { hdr_beg(host) -i www. }
      http-request lua.auth-request oauth /auth/verify_token
      use_backend oauth if ! { var(txn.auth_response_successful) -m bool }
    Port:  443
    Rules:
      log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ {%[ssl_c_verify],%[ssl_fc_has_crt],%{+Q}[ssl_c_s_dn],%{+Q}[ssl_c_i_dn]}\ %{+Q}r
      http-request redirect prefix http://%[hdr(host),regsub(^www\.,,i)] code 301 if { hdr_beg(host) -i www. }
      rspadd Strict-Transport-Security:\ max-age=15768000;\ includeSubDomains;\ preload;
      http-request lua.auth-request oauth /auth/verify_token
      use_backend oauth if ! { var(txn.auth_response_successful) -m bool }
  Node Selector:
    Ingress:  test-voyager
  Rules:
    Host:  test.int
    Http:
      Alpn:
        h2
        http/1.1
        http/1.0
      Paths:
        Backend:
          Backend Rules:
            compression algo gzip
            compression type text/html text/plain text/css application/javascript
          Service Name:  api
          Service Port:  8080
    Host:                test.int
    Http:
      Alpn:
        h2
        http/1.1
        http/1.0
      Paths:
        Backend:
          Backend Rules:
            compression algo gzip
            compression type text/html text/plain text/css application/javascript
          Name:          oauth
          Service Name:  oauth
          Service Port:  8080
        Path:            /auth
  Tls:
    Hosts:
      test.int
    Secret Name:  tls-test
Events:
  Type    Reason                         Age   From              Message
  ----    ------                         ----  ----              -------
  Normal  DeploymentReconcileSuccessful  50m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   50m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  DeploymentReconcileSuccessful  50m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   50m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  DeploymentReconcileSuccessful  40m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   40m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  DeploymentReconcileSuccessful  40m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   40m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  DeploymentReconcileSuccessful  30m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   30m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  DeploymentReconcileSuccessful  30m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   30m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  StatsServiceDeleteSuccessful   20m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  StatsServiceDeleteSuccessful   20m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  DeploymentReconcileSuccessful  20m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  DeploymentReconcileSuccessful  20m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  DeploymentReconcileSuccessful  10m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   10m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  DeploymentReconcileSuccessful  10m   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   10m   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  DeploymentReconcileSuccessful  53s   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   53s   voyager operator  Successfully deleted stats Service voyager-test-ing-stats
  Normal  DeploymentReconcileSuccessful  53s   voyager operator  Successfully patched HAProxy Deployment voyager-test-ing
  Normal  StatsServiceDeleteSuccessful   53s   voyager operator  Successfully deleted stats Service voyager-test-ing-stats

oh! We are fixing it.

Hi, try https://github.com/appscode/voyager/releases/tag/7.0.0-rc.3 . Should be fixed now.

Hey,
already on it, just waiting for the image to show up on the registry :)
thanks

Pushed the image. Try now.

works like a charm, tyvm

Thanks for all the help and support!


Using a key to avoid the problem of different Steps amounts generates another problem, that of the TextField losing focus every time something is typed. There's any solution?

A solution is needed, because as commented in this answer, using a key to avoid the problem of different Steps amounts generates another problem, that of the TextField losing focus every time something is typed...

Give random key every time widget rebuild
Stepper(key: Key(Random.secure().nextDouble().toString())

I used this solution for some time, there is one problem though:
If there is a input field inside a Step and you try to input data, the keyboard immediately closes, probably as the key is regenerated due to changing viewport dimensions and therefore focus to the input element is lost.
Originally posted by @janhaa in https://github.com/flutter/flutter/issues/27187#issuecomment-883172307

That's the error showed when a different amount of steps is given to the Stepper:

On line 338:     assert(widget.steps.length == oldWidget.steps.length);
This try to assert to "1 == 2", causing the error...

The workaround given was:

Workaround
Give random key every time widget rebuild
Stepper(key: Key(Random.secure().nextDouble().toString())

Originally posted by @gersur in https://github.com/flutter/flutter/issues/27187#issuecomment-562827277

But this causes the behavior mentioned in this issue, and already commented on in the previous issue, but no solution was given...

(Here you can see the focus loss behavior in the textfield)

flutter doctor -v
[✓] Flutter (Channel stable, 3.3.2, on macOS 12.5.1 21G83 darwin-x64, locale pt-BR)
    • Flutter version 3.3.2 on channel stable at /Users/armstrongquintino/fvm/versions/stable
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision e3c29ec00c (11 days ago), 2022-09-14 08:46:55 -0500
    • Engine revision a4ff2c53d8
    • Dart version 2.18.1
    • DevTools version 2.15.0

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0-rc1)
    • Android SDK at /Users/armstrongquintino/Library/Android/sdk
    • Platform android-31, build-tools 33.0.0-rc1
    • ANDROID_HOME = /Users/armstrongquintino/Library/Android/sdk
    • ANDROID_SDK_ROOT = /Users/armstrongquintino/Library/Android/sdk
    • Java binary at: /Users/armstrongquintino/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/212.5712.43.2112.8815526/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.0)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14A309
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2021.2)
    • Android Studio at /Users/armstrongquintino/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/212.5712.43.2112.8815526/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)

[✓] Android Studio (version 2021.2)
    • Android Studio at /Users/armstrongquintino/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/212.5712.43.2112.8609683/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)

[✓] VS Code (version 1.71.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.48.0

[✓] Connected device (3 available)
    • iPhone 14 Pro Max (mobile) • FAAC4E85-28AF-466A-822A-0C61E4BBA099 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-16-0 (simulator)
    • macOS (desktop)            • macos                                • darwin-x64     • macOS 12.5.1 21G83 darwin-x64
    • Chrome (web)               • chrome                               • web-javascript • Google Chrome 105.0.5195.125

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

@lohhans
Can you provide complete minimal reproducible code sample that shows the error you are reporting ?
Also, when you open an issues, please don't use an existing comment as issue description, but use new issue template and fill out requested details so that we can address it in proper way.

@darshankawar
Ok, sorry about that...
Here has a code sample who shows the behavior when UniqueKey() is used to avoid the another error mentioned...

main.dart

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});
  @override
  Widget build(BuildContext context) {
    return MultiProvider(
      providers: [
        ChangeNotifierProvider(
          create: (context) => BothPagesController(),
        ),
      ],
      child: MaterialApp(
        title: 'Flutter - Stepper bug',
        theme: ThemeData(
          primarySwatch: Colors.blue,
        ),
        home: const SecondPage(title: 'Flutter - Stepper bug'),
      ),
    );
  }
}

class SecondPage extends StatefulWidget {
  const SecondPage({super.key, required this.title});
  final String title;

  @override
  State<SecondPage> createState() => _SecondPageState();
}

class _SecondPageState extends State<SecondPage> {
  int _index = 0;
  Map<String, TextEditingController> textEditingControllers = {};
  Map<String, TextField> textFields = {};
  late final BothPagesController controller;
  var listOne = ["A", "B", "C"];
  bool enableNextButton = false;

  @override
  void initState() {
    controller = context.read<BothPagesController>();

    // need to be on initState because receives diferents lists (its a form)
    listOne.forEach((string) {
      var aFieldController = TextEditingController(text: '');
      textEditingControllers.putIfAbsent(
        string,
        () => aFieldController,
      );
      textFields.putIfAbsent(string, () {
        return TextField(
          controller: aFieldController,
          onChanged: (value) => _validateFields,
        );
      });
    });
    super.initState();
  }

  // The validate with state changes makes the textfield loose focus when has UniqueKey
  get _validateFields {
    var isAllFilled = <bool>[];
    textEditingControllers.forEach((key, value) {
      isAllFilled.add(value.text.isNotEmpty);
    });
    if (mounted && isAllFilled.every((boolean) => boolean == true)) {
      setState(() {
        enableNextButton = true;
      });
    } else {
      setState(() {
        enableNextButton = false;
      });
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisSize: MainAxisSize.min,
          children: [
            Flexible(
              child: Stepper(
                currentStep: _index,
                onStepCancel: () {
                  if (_index > 0) {
                    setState(() {
                      _index -= 1;
                    });
                  }
                },
                onStepContinue: () {
                  if (_index <= 0) {
                    setState(() {
                      _index += 1;
                    });
                  }
                },
                onStepTapped: (int index) {
                  setState(() {
                    _index = index;
                  });
                },
                type: StepperType.horizontal,
                steps: listOne
                    .map((string) => Step(
                          title: Text(string),
                          content: Container(
                            alignment: Alignment.centerLeft,
                            child: textFields[string],
                          ),
                        ))
                    .toList(),
                key:
                    UniqueKey(), // need to be unique to avoid metioned previous error (workaround citted)
              ),
            ),
            Flexible(
              child: ElevatedButton(
                // 3
                onPressed: enableNextButton
                    ? () {
                        print('Create');
                      }
                    : null,
                child: const Text('Click Me!'),
              ),
            ),
            const Text('(Enables if all textfields are filled)'),
          ],
        ),
      ),
    );
  }
}

// Example of structure used on real app
enum ControllerOfBothPagesState { idle, success, error, loading }

class BothPagesController extends ChangeNotifier {
  var state = ControllerOfBothPagesState.idle;
  GenericModel _genericModel = GenericModel(
    listData: [],
  );
  GenericModel get genericModel => _genericModel;
  void setExperimentRequestModel(
    GenericModel genericModel,
  ) {
    _genericModel = genericModel;
    notifyListeners();
  }
}

class GenericModel {
  List listData;

  GenericModel({required this.listData});
}

pubspec.yaml

name: stepper_bug
description: A new Flutter project.

version: 1.0.0+1

environment:
  sdk: '>=2.18.1 <3.0.0'

dependencies:
  flutter:
    sdk: flutter

  cupertino_icons: ^1.0.2
  provider: ^6.0.2

dev_dependencies:
  flutter_test:
    sdk: flutter

  flutter_lints: ^2.0.0

flutter:
  uses-material-design: true

Thanks for the details @lohhans
Does the same behavior occur without using provider library ? If so, please provide us updated code sample because we want to make sure that the error is not causing due to external library and to narrow it down to framework.

Yes, the same happens without provider! See the code below...

main.dart

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter - Stepper bug',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const SecondPage(title: 'Flutter - Stepper bug'),
    );
  }
}

class SecondPage extends StatefulWidget {
  const SecondPage({super.key, required this.title});
  final String title;

  @override
  State<SecondPage> createState() => _SecondPageState();
}

class _SecondPageState extends State<SecondPage> {
  int _index = 0;
  Map<String, TextEditingController> textEditingControllers = {};
  Map<String, TextField> textFields = {};
  var listOne = ["A", "B", "C"];
  bool enableNextButton = false;

  late GenericModel genericModel;

  @override
  void initState() {
    genericModel = GenericModel(
      listData: [],
    );

    // need to be on initState because receives diferents lists (its a form)
    listOne.forEach((string) {
      var aFieldController = TextEditingController(text: '');
      textEditingControllers.putIfAbsent(
        string,
        () => aFieldController,
      );
      textFields.putIfAbsent(string, () {
        return TextField(
          controller: aFieldController,
          onChanged: (value) => _validateFields,
        );
      });
    });
    super.initState();
  }

  // The validate with state changes makes the textfield loose focus when has UniqueKey
  get _validateFields {
    var isAllFilled = <bool>[];
    textEditingControllers.forEach((key, value) {
      isAllFilled.add(value.text.isNotEmpty);
    });
    if (mounted && isAllFilled.every((boolean) => boolean == true)) {
      setState(() {
        enableNextButton = true;
      });
    } else {
      setState(() {
        enableNextButton = false;
      });
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisSize: MainAxisSize.min,
          children: [
            Flexible(
              child: Stepper(
                currentStep: _index,
                onStepCancel: () {
                  if (_index > 0) {
                    setState(() {
                      _index -= 1;
                    });
                  }
                },
                onStepContinue: () {
                  if (_index <= 0) {
                    setState(() {
                      _index += 1;
                    });
                  }
                },
                onStepTapped: (int index) {
                  setState(() {
                    _index = index;
                  });
                },
                type: StepperType.horizontal,
                steps: listOne
                    .map((string) => Step(
                          title: Text(string),
                          content: Container(
                            alignment: Alignment.centerLeft,
                            child: textFields[string],
                          ),
                        ))
                    .toList(),
                key:
                    UniqueKey(), // need to be unique to avoid metioned previous error (workaround citted)
              ),
            ),
            Flexible(
              child: ElevatedButton(
                // 3
                onPressed: enableNextButton
                    ? () {
                        print('Create');
                      }
                    : null,
                child: const Text('Click Me!'),
              ),
            ),
            const Text('(Enables if all textfields are filled)'),
          ],
        ),
      ),
    );
  }
}

class GenericModel {
  List listData;

  GenericModel({required this.listData});
}

Thanks for the details. Can you also provide exact steps to replicate the error ?

Yes, now try to digit anything on textfield, the focus scope will unfocus the textfield, so, you can't type a word at once, like "flutter", it will be typed letter by letter instead of normal typing, try to do it and you'll see.

Can you take a look at this and see if it helps ?


tar_prune after PR #120

Pruning to clean up targets objects after the renaming in #130.
Consider also deleting outdated files in the /out/ directories. Might be able to automatically delete based on a specified date (e.g., delete all files in /out/ that are older than date). Need to check if that's possible.
Jake Zwart suggested calling tar_meta() pre- and post- tar_prune(), and getting rid of all the files that are in the pre- tar_meta() and not the post- tar_meta(). The format column in tar_meta() would tell you if it's a file, and path column will tell you where it is.

I think we all have to run tar_prune() in our forks, and would have to delete the same files you deleted. The transfer_targets_main_fork.slurm moves new and outdated targets and files to the fork, but would not delete missing files. Did you save the code that you used to check the meta file for files targets?

I did not save the code seeing as it didn't work correctly. Some out files were correctly identified as outdated (all the "########_dv.csv" and "########_pk.csv" files that have since been combined) but others were incorrectly identified (all of the moving window plots). I'm not really sure it is a big deal to keep the old files that are no longer relevant, as long as they are not accidentally referenced in the pipeline.
Yes, tar_prune() will need to be run on each fork. If we really want to delete all the irrelevant out files, the best thing to do would probably be to delete everthing, tar_prune(), then re-run the entire pipeline (on the main repo). Then, delete all out files on our forks, tar_prune() the forks, then the tar_transfer_main_fork.slurm so we don't have to re-run the entire pipeline again on our forks. It's probably not worth it at this stage, but maybe as a final check before we submit any of our manuscripts or submit our data releases for colleague review.


[pwrmgr] Low power entry gated by OTP ctrl lci_idle signal

It is currently tied off to 0 in otp_ctrl_lci.sv. It gates the pwrmgr from entering low power mode. Filing an issue for now. Seems like some design details are missing.

Filing an issue because this gates pwrmgr V1.

Hm, can you tell in which state the otp_ctrl_lci FSM is? The signal should be driven 1 once the OTP controller and the LCI FSM have initialized:
https://github.com/lowRISC/opentitan/blob/69cb1f868be7af691d619f517a14aaf021197c83/hw/ip/otp_ctrl/rtl/otp_ctrl_lci.sv#L132

Aah, looks like I need to rebase and rerun. THanks.

This was fixed recently in #4675.

My apologies, this is no longer a gating item. Closing.


Windows - Logging process never releases log file sink

Temporarily disabled logging with Sidecar v0.1.4. This issue can be used to track the re-implementation of logging.


Refactor client into algebra

DisposableResponse is gone
Client is a trait with no concrete methods
DefaultClient implements them all in terms of a run: Request[F] => Resource[F, Response[F]]
Client no longer has a shutdown: we create clients as Resources.

I have not tried the metrics, I have only compiled them.
This is going to cause a merge conflict with #2094, so we need to give one of them the right of way.

Similar to, and supersedes, #1772.


Chrome 129 Headless shows blank window

Latest version of selenium running chromedriver 129 in headless using --headless=new produces a blank white window.
This is a bug with selenium/chromedriver. Will monitor and remove it with a work around in case it is not fixed by selenium/chromedriver devs.
More details here: https://stackoverflow.com/questions/78996364/chrome-129-headless-shows-blank-window

This PR request is already merged by the chromium team. That means this will be fixed soon. Likely when Chrome 130 or 131 are released.

Fixed in latest chromedriver/chrome version.


Change contact's uuid field to be nullable

We want to be allow Casepro to create contacts. The second step to this is to allow the UUID field on contacts to be nullable. This way, we can create a contact with a null UUID field, and have the field be set to the appropriate value when it is pushed to the backend.

@KaitCrawford Ready for review.
@rowanseymour Also ready for you to look at.

:+1:

👍


Delete from query documentation

Reading https://docs.vespa.ai/en/reference/document-v1-api-reference.html, I could not understand if deleting from query is possible.
My use case is to delete all documents with a specific document type.

Yes, deleting with document/v1 is supported: https://docs.vespa.ai/en/reference/document-v1-api-reference.html#delete

https://docs.vespa.ai/en/reference/document-v1-api-reference.html#delete-where - maybe the doc should be clearer, feedback welcome

Thanks.
Indeed the documentation seems to lead to https://docs.vespa.ai/en/reference/document-v1-api-reference.html#selection, then to https://docs.vespa.ai/en/reference/document-select-language.html. But no examples.
Until I found in https://docs.vespa.ai/en/document-v1-api-guide.html:
curl http://localhost:8080/document/v1/namespace/music/docid?selection=music.genre=='blues'
I adapted it to my use case:

Delete all documents of a type
/document/v1/mynamespace/mytype/docid?cluster=mycluster&selection=true

12 Delete products or orders
/document/v1/mynamespace/mytype/docid?cluster=mycluster&selection=mytype.wpsolr_type = "product" or mytype.wpsolr_type = "shop_order"