Panic on send in channels by default?

Hi! This is somewhat of a continuation of "should dropping receiver close the sender" issue. I've migrated rust-analyzer to crossbeam-channel 0.3, and the thing I've noticed is that every .send is followed by .unwrap. Perhaps we should make this unwrapping behavior the default, and introduce a separate checked_send which returns a Result?
Sending to a channel without receivers seems to indicate a programmer's error in the majority of cases: there's either a bug in communication structure such that receivers exit too early (direct bug), or a reciver is closed due to a panic (indirect bug). In Rust it is OK to panic on bugs by default, while providing checked alternatives:

indexing a vector with [] panic on out of bounds, and has .get for check access
in debug, integer overflow panics and has checked_add

Returning a result by default seems to be bad:

it is confusing and is not a "pit of success": with Result<T, SendError> the user has choices:

forward error (boilerplate which just moves problem to the wrong place)
handle error, but correct handling is impossible in most cases
ignore error, which is OK (0.2 semantics EDIT: not exactly, 0.2 blocked), but not optimal: it's better to see a panic than a deadlock
unwrap: this I think is correct (propagates bugs), but is a hard choice to make, especially for novice user, because "unwraps are bad"

it significantly devalues unwrap: unwrap is indeed bad in a lot of places, and its much easier to spot one during code review if there are fewer of them.
unwrap happens in the wrong place. If we panic inside crossbeam, we can set a custom message of "sending to a closed channel" instead of a generic one "unwrapped Err".

As a counter point, a similar API is exposed by std's mutexes. They return Results by default, and almost all uses of .lock() are followed by .unwrap/.expect. I would argue that this design is also less ideal, and that std should have panicked by default, providing checked_lock methods for rare cases when you do want to handle this somehow.

Good example from standard library: RefCell::(borrow|try_borrow): https://doc.rust-lang.org/std/cell/struct.RefCell.html#method.try_borrow

We discussed crossbeam-channel during All Hands. Sometime this year I will write a blog post/RFC that lays out all the potential breaking changes and unresolved questions we have before publishing version 1.0. The libs team will then review and help us make final decisions.

My experience in Servo's use of unwrap() is that we've ended up with a lot of places where programmer's maintain invariants (e.g. "the matching receiver of this send is still alive") which is true during steady-state, but not during shutdown, so we end up with Servo panicking during shutdown quite regularly. There is a lot of Servo code that now looks like:
    let v = match chan.recv() {
        Ok(v) => v,
        Err(e) => return warn!("Receive failed ({}), e"),
    };

Another thing that might be worth discussing is that double-panic kills the entire process, so any panicking which runs during Drop is dangerous, e.g. a send to a thread to get it to do some resource reclamation.

There is a lot of Servo code that now looks like:

This is Err on recv, which is totally valid and required for
shutdown. Perhaps you've meant to show code with error on send
instead?
@asajeffrey would be cool to dig into these cases more. At least from
my experience with programming with channels in a medium-sized code
base, there are usually several ways to arrange communication between
parties.
There's a solution when you explicitelly code for shut-down, and it
sort-of works for planned shutdown, but fails miserably on unexpected
panic.
And there's a solution where you just rely on the ownership semantics
and "close on drop" behavior, where shutdown happens automatically and
works the same for panicing and non-panicking cases.
Panic on send definitely nudges me towards architectures of the second
kind. I don't know if this transfers to the servo-sized codebases, so
that's why it's interesting to see concrete cases here. It maybe the
case that large codebases just have different constraints, but it also
could be the case that channel ownership in Servo is not exactly
ideal :)
Here's a specific case where I believe panicking helped me to write
more robust code:
In rust-analyzer, I have a virtual file system, whose task is to
maintain a consistent snapshot of filesystem state, while watching for
changing files.
The interface to watcher/scanner "actor" of VSF (which is a separate
thread) is a pair of crossbeam channels channels: the actor receives a
directory to watch, scans it using walkdir and then watches for
changes. Results of the scan/watching are send to the output channel, OUT.
The file watching library I am using, notify, exposes notifications
as std::mpsc channel, so I have to burn an additional thread to
convert between the channels. Initially, I was going to send events
directly to OUT, with the following code:
loop {
    let event = match mpsc_receiver.recv() {
    	Ok(it) => it,
	Err(_) => break, // notify library was stopped, return
    };
    match OUT.send(transform_event(event)) {
    	Ok(()) => (),
	Err(_) => break, // the client of the VFS stopped, return
    }
}

However, I realized that the second Err case happens because I fail
to join this event-transforming thread when shutting down the VFS
itself. That is, I was going to leak a thread during shutdown.
So I refactored the code to make this helper thread and the VFS actor
thread essentially scoped threads, which are guaranteed to join on
exiting the scope (due to normal termination, ?, or panic). What
guided me through this refactoring was realization that .send should
never fail, which means that client should outlive VFS and VFS should
outlive the helper thread.

The matching code for send is either the same, or just let _ = chan.send(v); depending on what we want to do with the warning, and whether we want to continue in the case that the receiver has closed.
There are two cases where we need to ensure no panicking. The first is in any code which may run in panic-handlers, to avoid double-panic killing the entire process. The second is in any code which does crash-handling, e.g. by displaying a crash page which invites the user to submit an issue report. In particular the constellation (which manages the content threads) and webrender (which is responsible for painting) have to be robust against panic, even if content threads are panicking.
If I ruled the world then we'd have a deny(panic) attribute we could apply to functions where their robustness is important, but unfortunately it's not obvious how to interface this with (e.g.) generic types without ending up going full out into effect systems, effect polymorphism, effect algebras etc. etc. So we end up with lints that just ban syntax like .unwrap().

(I'm posting this here at @BurntSushi's suggestion, based on our discussion on Reddit. Note that a lot of this comment is in the context of tokio::mpsc, or even tokio::mpsc channels being used as streams, and so this may not always directly apply to crossbeam::mpsc. This is submitted as anecdotal evidence. Please take it with a grain of salt.)
At Faraday, we mostly work with tokio channels. And in almost every case, I've found that code calling send must make an explicit decision about how to handle failed send calls, and that panicking is virtually always the wrong answer.
Let me back up and provide a bit more context. Most of the channels and streams that I see in work are ultimately writing to either:
1. A network socket with a tokio::codec, where either of the ends of the codec may be attached to a channel.
We have a partial open source example of this, in our public fork of rust-amqp that uses tokio to implement true bidirectional channels. As you can see, we check the result of every call to send in this code, and either propagate it to our caller or log a warning.
Every one of these send failures can be see in our logs during a typical week, and it would be unacceptable for any of them to panic. A lost AMQP server connection means that the caller needs to either (a) wait, re-establish the connection, and retry, or (b) log a high-priority error indicating that a queue message has failed. The key insight here is that all of our channels, when they appear, are ultimately mapped to an underlying network socket, which can close unexpectedly with an ECONNRESET. And this maps directly to a send error.
And it's basically never acceptable to crash the server in question, because it may be managing a week-long job in another thread. So I'm forced to actually recover gracefully from a dropped AMQP server connection.
2. Channels being used to emulate Unix pipes.
These channels typically have a structure which conceptually looks something like this:
data_producer | data_transformer | data_sink

The code in data_producer will normally contain something like:
// Pseudo-code! Tokio channels are actually a bit trickier than this.
await!(dest.send(Ok(bytes)))
    .map_err(|_| format_err!("broken pipe in data_producer"))?;

There's generally also a Context type involved somewhere:
struct Context {
    error_channel: mpsc::Sender<Error>,
    log: slog::Logger,
}

The corresponding mpsc::Receiver<Error> is monitored by a supervisor task. We don't have a good open source example of this yet, but you might take a look at the Context type in our unfinished dbcrossbar tool. For the corresponding channel senders, see copy_reader_to_stream (for AsyncWrite) or sync_stream_writer (for SyncWrite).
Going back to our example:
data_producer | data_transformer | data_sink

If an error occurs in, say, data_sink, then data_sink will report the error on error_channel, and drop the receiver of the channel it uses to read from data_transformer. This will cause the broken pipe to propagate back through data_transformer and data_producer. This is exactly analogous to the traditional Unix EPIPE / SIGPIPE, which Unix uses to shut down pipe writers when a pipe reader fails unexpectedly.
In fact, it's actually really hard to shut down a loosely-coupled pipeline like this without using something like EPIPE to propagate the error. In the general case, data_producer is living off in it's own world, and it may look something like this code, which uses PostgreSQL copy_out to take a data stream from PostgreSQL and forward it directly to a tokio::mpsc::Sender<BytesMut, _>:
    // Use `pipe` and a background thread to convert a `Write` to `Read`.
    let url = url.clone();
    let (mut wtr, stream) = SyncStreamWriter::pipe(ctx.clone());
    thread::spawn(move || {
        // Run our code in a `try` block so we can capture errors returned by
        // `?` without needing to give up ownership of `wtr` to a local closure.
        let result: Result<()> = try {
            let conn = connect(&url)?;
            let stmt = conn.prepare(&sql)?;
            stmt.copy_out(&[], &mut wtr)?;
        };

        // Report any errors to our stream.
        if let Err(err) = result {
            error!(ctx.log(), "error reading from PostgreSQL: {}", err);
            if wtr.send_error(err).is_err() {
                error!(ctx.log(), "cannot report error to foreground thread");
            }
        }
});

Here, the actual send call is occurring deep inside stmt.copy_out, most of which is single-threaded C code. So there's no way to tell PostgreSQL to stop writing data onto that stream except by returning a Unix I/O error, and the classic error in this case is EPIPE.
Outside example: Servo
According to this comment by u/asajeffrey on r/rust, Servo has found that send(...).unwrap() is tricky to get right:

There were quite a few commits that did this, e.g. https://github.com/servo/servo/commit/01b6e4a2c110a5ec5f8651a257edc98ba76ccb85, but mostly they replaced ....unwrap() by if let Err(e) = ... { return warn!(...); }.
My feeling is that a lot of code is written using unwrap() on the basis of maintaining some invariant of the program, and normally we got that right during steady state, but not always during startup, and quite often not during shutdown. Servo still panics a lot during shutdown, due to code that assumes the other end of a channel is still alive, but the shutdown order ended up being an unanticipated one. Sigh.

This mirrors my experience: Many send failures only occur in exceptional circumstances, such as when an AMQP network connection needs to be restarted, or when the program is shutting down. But if you don't want your program to panic randomly in the middle of an "orderly" shutdown, you need to carefully think through what to do about each failed send. That may be as simple as logging it with error! so you can debug it when it starts failing in production 6 months from now.
 In my limited experience, the code involved in shutting down multiple goroutines often involves subtle channel-related bugs. (And these goroutine shutdowns may occur every time a connection to a server is lost and needs to be recreated, so abort is not an acceptable solution.)
For an academic example, see this paper, which includes bugs like:

To demonstrate errors in message passing, we use a blocking bug from Kubernetes in Figure 1. The finishReq function creates a child goroutine using an anonymous function at line 4 to handle a request—a common practice in Go server programs. The child goroutine executes fn() and sends result back to the parent goroutine through channel
ch at line 6. The child will block at line 6 until the parent pulls result from ch at line 9. Meanwhile, the parent will block at select until either when the child sends result to ch
(line 9) or when a timeout happens (line 11). If timeout happens earlier or if Go runtime (non-deterministically) chooses the case at line 11 when both cases are valid, the parent will return from requestReq() at line 12, and no one else can pull result from ch any more, resulting in the child being blocked forever. The fix is to change ch from an unbuffered channel to a buffered one, so that the child goroutine can
always send the result even when the parent has exit.

If you look at this closely, it's a classic EPIPE error. Specifically, the parent routine has exited, and the child routine is trying to write to a dead channel. The authors suggest fixing this by adding a buffer to ch, so that the child can write the result to a channel which will never be read. Personally, I would be happier if the child's send function failed outright with EPIPE, and the child was forced to figure out how to handle the error. Perhaps the child should just silently quit, or maybe it should log a message, or maybe it needs to use something like Context::error_channel to report the problem to a supervisor. However, one clearly wrong answer in this case would be for the child's send to abort the entire server process.
Note that if the child process were sending multiple messages (perhaps data chunks), the buffered channel workaround wouldn't be enough, and the only easy solution would be for send to fail with an error.
Summary
At least in my experience with tokio channels (and my more limited experience with Go channels), a majority of send calls can fail. This is often triggered when a network socket closes (ECONNRESET) or a pipe reader closes early (EPIPE). This may happen during application shutdown (as in the Servo case) or during a connection restart (our rust-amqp fork).
Because of this experience, my standard coding guiding is assume every send might fail, and decide how to handle it appropriately. 90% of the time, this may mean writing the error to a log somewhere and then giving up, or reporting it to a supervisory channel. But some decision needs to be made. So if there were a clippy::unchecked_send lint, I would definitely enable it as part of our company coding style.
Now, I'll be the first to admit that I'm dragging in examples from tokio::mpsc and even Go here. So maybe none of this applies directly to typical uses of crossbeam::mpsc! But I hope this explains why I consider send(...).unwrap() to be giant warning sign, especially once networks or pipes are involved. Basically, ECONNRESET and EPIPE both map pretty directly to a failed send. And so I've wound up distrusting unwrap() on channels almost as much I distrust it on function calls.
(Actually, I'm really curious about how I could design this kind of code so that sends could never fail! Maybe I'll learn something fascinating and useful today.)

Thank you so much for these examples, @emk! I think they fully apply to crossbeam-channel.
I think the most important case here is failable pipeline: producer | transformer | consumer, where consumer might legitimately fail due to external error. For example, consumer might be writing results to a database, and connection might die with io::Error.
Propagating send errors back from the consumer helps to tear down the pipeline, but several aspects of this approach are sub-optimal:

in-flight messages are lost. Specifically, every time a pipeline segment terminates when its sender fails, it drops all messages queued up in its receiver
no error information is propagated, only the mere fact that error occurred
bugs could be masqueraded as legitimate errors. Arguably, if consumer or transformer panics (that is, it has a bug), producer should panic by default as well.

If we want to maintain unidirectional dataflow (that is, treat closed sender as a bug), a possible solution would be for consumer, upon encountering an io::Error, to send it via an additional errors channel to the entity that spawned the pipeline in the first place, and then to error-log all pending messages. That is, something like this:
while let Some(msg) = receiver.recv() {
    match db.write(msg) {
        Ok(()) => (),
        Err(e) => {
            ctx.error_sink.send(e);
            break;
        }
    }
}

for msg in receiver {
    log::error!("failed to write message to db, db is dead: {:?}", msg)
}

The entity than can shut-down the pipeline at the beginning, by terminating the producer. In the database connection example we can be even fancier, and instead of logging all pending messages, we can send both the io::Error and the Receiver to the supervisor, which could create a new database connection and spawn a new consumer, without loosing the messages.
I do understand that this is a bit of "architecture astronaut" type of the solution, and I haven't actually tired in in practice, so I can't say if it'll work. Though remarkably the Context type you've mentioned seems to be a core part of this solution as well.
The second example is "panicking during shutdown". Here I think handling errors on send produces an objectively less than ideal solution: namely, messages are implicitly lost during shutdown. Maybe it's not a big deal, but maybe it's saving some user state to the database? The solution here seems to be to architecture shutdown sequence in such a way that you terminate producers first, wait for them to finish, and only after terminate consumers.
This is a situation where "panicking by default on send" might nudge you to a better architecture: if dropping receiver while sender is alive is an error, than you'll have to arrange a clean shutdown sequence in topological order. If send returns a result, the path of least resistance is to add logging on send.
Finally, the Go example also seems like the case where result on send is worse solution. Specifically, we have a parent coroutine and a child coroutine, and the problem is that, although parent has spawn the child, it's not interested in child's result for some reason. The proposed solution allows for the situation where the parent has finished, but the child is alive. That is, the child is effectively a zombie: it might hold onto some resources and it might do computations, but they are not interesting to anyone, and child will only know that once it attempts send. I think the better fix would be to make sure that parent just always joins the child in the end, even if it doesn't need the result anymore.
All that said, I am now not sure that panicking on send is the right choice for crossbeam =) I personally am still convinced that this is the right model to think about channels, but I also see that there's a large existing body of code which relies on handling errors on send.

Awesome exchange! Thanks so much to both of you for writing all that stuff out. It's a lot of work!
I just wanted to respond to a teeny detail:

but I also see that there's a large existing body of code which relies on handling errors on send.

I think if this were the only concern, we could say, "in crossbeam-channel 1.0, if your code depended on send returning an error, you should use checked_send instead." This is a viable migration since uses of send that check its error will fail to compile under your proposal. So I just mean to say that there does exist a reasonable migration path. Of course, this isn't to say that this is the only concern!

Thank you everybody for this wonderful discussion!
I spent much of today writing async code, and actually encountered the first time where I actually wanted to write tx.send(...).expect("..."). I now believe that some very common and totally legitimate uses of channels will always expect the receiver to be present.
But I still believe there other perfectly reasonable use cases where EPIPE is by far the easiest and most correct solution.
I'd like to respond to everybody's comments in more detail, with examples of each use case, but it may have to wait a day or two until I merge this branch, which uses @BurntSushi's csv library to parse a streaming CSV file and convert it to PostgreSQL BINARY format (the relevant code is here, but ignore the README). This will be plugged in between two tokio::sync::mpsc channels as a data_transformer, and it will count on receiving an io::ErrorKind::BrokenPipe if the data consumer fails.
So I hope to have more to say very soon, once I get this example hooked up and passing integration tests!

So I had a very busy week with channels and streams, and everything now seems to be running very nicely in production, so it's time write the follow-up I promised. :-)
I've written a blog post summarizing my experiences with send(...).unwrap(). The most interesting example from that post is the async function below, which I thought contained a safe send call. It actually panicked within the first hour. Can you find the bug?
/// Run a synchronous function `f` in a background worker thread and return its
/// value.
pub(crate) async fn run_sync_fn_in_background<F, T>(
    thread_name: String,
    f: F,
) -> Result<T>
where
    F: (FnOnce() -> Result<T>) + Send + 'static,
    T: Send + 'static,
{
    // Spawn a worker thread outside our thread pool to do the actual work.
    let (sender, receiver) = mpsc::channel(1);
    let thr = thread::Builder::new().name(thread_name);
    let handle = thr
        .spawn(move || {
            sender.send(f()).wait().expect(
                "should always be able to send results from background thread",
            );
        })
        .context("could not spawn thread")?;

    // Wait for our worker to report its results.
    let background_result = await!(receiver.into_future());
    let result = match background_result {
        // The background thread sent an `Ok`.
        Ok((Some(Ok(value)), _receiver)) => Ok(value),
        // The background thread sent an `Err`.
        Ok((Some(Err(err)), _receiver)) => Err(err),
        // The background thread exitted without sending anything. This
        // shouldn't happen.
        Ok((None, _receiver)) => {
            unreachable!("background thread did not send any results");
        }
        // We couldn't read a result from the background thread, probably
        // because it panicked.
        Err(_) => Err(format_err!("background thread panicked")),
    };

    // Block until our worker exits. This is a synchronous block in an
    // asynchronous task, but the background worker already reported its result,
    // so the wait should be short.
    handle.join().expect("background worker thread panicked");
    result
}

I didn't see the bug here. I mean, clearly, the receiver does nothing but block until it gets an answer, so how could it fail?
The problem, it turned out, was that the receiver was owned by a Future, and the Future could be canceled using drop(future) or future.timeout(...). And this drop or timeout might be happening very far away in the source code. So it's incredibly hard to guarantee that this code will never be reused in a way where the future might get destroyed early.
I could try to fix this with controls channels or orderly shutdowns, but it means that my APIs no longer compose as nicely, and that I have to painfully vigilant.
I think that these kinds of Future issues might be one of the big differences between @BurntSushi's experiences and my own. Futures are much more cancelable than threads, and this affects the entire design.
@matklad:

in-flight messages are lost. Specifically, every time a pipeline segment terminates when its sender fails, it drops all messages queued up in its receiver

Yes, this is normally the behavior that I want. The data on the channel might be, say, the second half of a database row in PostgreSQL BINARY format. And if PostgreSQL isn't accepting data any more data, then I'm just going to throw it away and recover at a much higher level.

no error information is propagated, only the mere fact that error occurred

I can think of some use cases where it would be nice to get a std::io::Error instead of a SendError, but it's usually not that important. Unix has survived for decades with the vague EPIPE (or SIGPIPE, because too many programs ignore write errors, which is less of a problem in Rust), and TCP stacks just send ECONNRESET.

bugs could be masqueraded as legitimate errors. Arguably, if consumer or transformer panics (that is, it has a bug), producer should panic by default as well.

In general, I set panic = "abort", so I'm 100% OK with send panicking if the receiver panicked. The more interesting case for me is when the receiver exited in an orderly fashion (maybe because PostgreSQL returned an error, or because the receiver was held by a Future that got dropped by future.timeout(...)). In cases like this, with an orderly drop(receiver), then I feel like send should return an error.

The entity than can shut-down the pipeline at the beginning, by terminating the producer. In the database connection example we can be even fancier, and instead of logging all pending messages, we can send both the io::Error and the Receiver to the supervisor, which could create a new database connection and spawn a new consumer, without loosing the messages.

I've written code like this, using things like Arc<AtomicBool> or control channels, and my experience is that it's really hard to get right. Or at least, that I can't get it right, and certainly not in the usual case where I'm mixing channels and futures.

Here I think handling errors on send produces an objectively less than ideal solution: namely, messages are implicitly lost during shutdown. Maybe it's not a big deal, but maybe it's saving some user state to the database?

As a general rule, most of my programs lean towards functional designs, idempotent designs, or proper transactions. If some data needs to be written to disk, I'm going to design around the fact that I need to see a return value from fsync or a successful transaction from my database library. This may mean not using channels for certain things.
Except for rendezvous channels, channels have buffers that can contain one or more items. If the receiver has already hit a hard error and given up, what happens to the contents of the channel buffer?
Basically, any work in progress inside the sender is essentially just an extension of the channel buffer. If the receiver needs to exit abruptly, then both the channel buffer and the sender's work will be lost. Or the receiver's error handling code will need to carefully shut down all active senders and drain the channel buffers. And error handling code tends to be poorly tested and buggy.

All that said, I am now not sure that panicking on send is the right choice for crossbeam =)

It might be the right choice for crossbeam, though I'd still be uneasy about it. But I'm pretty sure that it's not the right choice if receiver is ultimately owned by a future, or for tokio::sync::mpsc in general.

I'm beginning to suspect there's a deeper issue with await! here that I want to understand, and I think than send(...) returning an error isn't the only subtle interaction between channels and await!.
 Once again, thank you to everybody for participating in this discussion!

I'd like to weight-in against a default unwrapping on each send. The reason for that is that there are  use-cases were you don't actually want to panic when the receiver has already been dropped by the time the send is attempted. Those use-cases could be dealt with through something like checked_send I think is a bad trade-off in API complexity, because I find it more convenient to either handle or ignore a result, as opposed to having to use different functions. Also, the semantics of a default send will influence users of the library, who might somehow deduce that it's "bad" to send messages when the receivers has already been dropped.
An example use-case is orderly, yet asynchronous, shutdown, where some components might still be running and sending messages to other components which have already, and orderly, shutdown. If you panic on sends in that case, you're going to get a panic 1 out of 2 times when you do a crtl-c and shutdown the whole system.
Example: https://github.com/servo/servo/blob/681c0ebf4b5a4b5abf0843986036e3594cc193b8/components/background_hang_monitor/background_hang_monitor.rs#L253
(this actually involves in IpcSender, but it's the same logic).
The reason the result of the send is not handled, is because the component the message is being sent to, in the case of an orderly shutdown, is very likely to shut itself down, hence drop the receiver, before the component that is sending messages to it.
 Probably in the next iteration of it's event-loop:
https://github.com/servo/servo/blob/681c0ebf4b5a4b5abf0843986036e3594cc193b8/components/background_hang_monitor/background_hang_monitor.rs#L161
If the system is shutting itself down in an orderly fashion, any senders corresponding to the receiver of that component will be eventually dropped, and therefore the select! will eventually produce an Err.
So the shutdown doesn't depend on the Err of the send, in fact it is ignored on purpose, and the shutdown will follow an Err on the recv(of a different channel).
This isn't meant as a generally applicable recipe, just to show that the result of a send can mean different things based on the context, and that the current API allows this and that's a good thing.
The case in Servo mentioned above, which required wrapping an earlier version of crossbeam with something that was aware of when the receiver had been dropped, was because there are also use cases when you do want to panic, or otherwise handle the error, when you're trying to send a message to a component that has unexpectedly already dropped it's receiver.
An example: https://github.com/servo/servo/blob/681c0ebf4b5a4b5abf0843986036e3594cc193b8/components/script/script_thread.rs#L2667
In this case, if the receiving component has already shutdown, and a message is still attempted to be send to it, something is wrong hence the expect.
The previous crossbeam API which didn't return a Result on send made it harder to know if something had unexpectedly shutdown, while making send panic on an Err as a default will make it harder to ignore such errors in situations where they are expected, like orderly yet asynchronous shutdown of various communicating components.
The current middle ground, where you can either ignore, or expect on the result of a send, gives you in my opinion the flexibility that is required for various use cases.
 What's important is that you can do it all with one method that returns a Result, as opposed to building a more complicated API that aims to solve specific problems which can be easily dealt with by the user on a case-by-case basis.

If I understood everyone correctly, it seems no one strongly believes we should change the signature of send anymore. With that, I am closing the issue.
Thank you all for the great discussion!


/update-model-cache should be registered manually as per docs

We didn't want this view to be registered by default since it's easy
to bring down the service with it.  ;-)
Here's from the docs on how to register it manually:
'flask_add_url_rules': [
    {
        '__factory__': 'palladium.server.add_url_rule',
        'rule': '/update-model-cache',
        'view_func': 'palladium.server.update_model_cache',
        'methods': ['POST'],
    },
]

Coverage remained the same at 100.0% when pulling 5483bff3a4ff9de7c2220f0fe021c24c15fc627b on bugfix/dont-register-update-model-cache into 39d94d1e36b86325f63a8070711d0ee9ebe32a61 on develop.


Nsng 567 fe finetuning

Just marked few things:

we should split sections from items on api

if you talk about avoiding the delay after switch language - I think turning on cache or SSR is better solution

display items based on the span-x and span-y order

makes sense. but fixing this in admin takes just few minutes. and saves our time 😁

also changes to editor are desirable

I agree 😉
suggestions makes sense. but imho they are outside of the scope of this task and I suggest creating new tasks for them


Is Gemini Supported

Hi,
It's not clear from reading documentation here or searching for "gemini", that the javascript SDK works with the latest Leap Motion releases? Maybe Gemini isn't the latest latest, but you know what I mean. Does these JS bindings support the latest?

I've tried it and it works!! :)


Add Research issue template

Add research template based on doc from Victoria
Pull reviewers stats
Stats for the last 30 days:

User
Total reviews
Median time to review
Total comments

MauriceReeves-usds
37
18m
2

cwinters-usds
19
13m
2

sean-usds
18
13m
5

jimduff-usds
17
13h 14m
13

carlosfelix2
10
2h 58m
63

TomNUSDS
10
1h 6m
16

jorg3lopez
8
1h 22m
1

jbiskie
6
2h 8m
0

whytheplatypus
5
23h 29m
13

kevinhaube
5
10h 16m
5

brick-green-agile6
5
1h 26m
4

clediggins-usds
5
1h 14m
3

RickHawesUSDS
4
3h 17m
0

ahay-agile6
3
10h 22m
6

sethdarragile6
3
4h 52m
0

oslynn
2
18h 57m
38

jeremy-page
1
3m
0

@victorialb-usds Added a research issue template based on the doc you shared with me. Check out the "files changed" tab to see the template. Let me know if you want to make any edits!

@cwinters-usds
Looks like merging is blocked since my commits aren't signed. I made a small update in-browser based on feedback from Victoria, but I wasn't thinking about it not signing the commits when you use the GH editor. How do I fix that?

@drew-usds ...that is a really good question, I don't know. Will do some quick research and get back to you. Do you already have things setup to do verified commits if you make changes outside of the browser?

@drew-usds Interesting -- looks like they're Verified now! Did you modify something?
FWIW editing through the GitHub web interface is supposed to automatically verify commits if that's setup on your account (per these docs)

@cwinters-usds I pulled in master so this branch was up to date, and it's doing the signed commit error again. I'm closing this and reopening it with a PR I made (and signed) locally --> #3902 . Sorry for all the back and forth for this one file.


Switch to better package

There's plenty of other packages out there that - frankly - handle things better than this plugin which contains all the logic for conversions that we can rely on better brains for.
For Craft 4, we'll likely switch to https://github.com/ozdemirburak/iris which handles:
Conversion

hex
hexa
hsl
hsla
hsv
rgb
rgba

Manipulation

Saturation
Desaturation
Lightness
Darkness
Spin
Mix
Tint
Shade
Fade
FadeIn
FadeOut
Is Light
Is Dark

Added in 3.0.0


Add LUT1DEffect

Changes:

Fixes #368
Adds LUT1DEffect
Renames LUTEffect → LUT3DEffect (with deprecated alias)
Update DataTexture3D → Data3DTexture
Include 'inputEncoding' as a LUT3DEffect constructor parameter

Questions:

[x] I'm not sure how to update postprocessing.d.ts, which prevents me from testing the change in my own project — is that automated?
[x] I've omitted the input/output encoding steps in LUT1DEffect for now. Based on discussion in #370 it sounded like that might eventually be an Effect-level thing rather than living in LUT1DEffect and LUT3DEffect? It doesn't affect my current use case, but let me know what you'd prefer here.

I'm not sure how to update postprocessing.d.ts, which prevents me from testing the change in my own project — is that automated?

@superguigui used a tool for that but he had to adjust the result by hand. I've also updated some things manually by searching through postprocessing.d.ts. Feel free to ignore the types - I can adjust that part later.

I've omitted the input/output encoding steps in LUT1DEffect for now.

That's fine. Effect.processColorSpace will indeed add that functionality.

Ok, thanks! I'll work out how to test this change in my project locally (yarn link is behaving weirdly with my build tool for some reason...) and then un-draft the PR after that.

One important thing to note — WebGL 2 requires THREE.RGBAFormat when using texture.encoding = THREE.sRGBEncoding. Since these 1D textures use THREE.RedFormat, they must use THREE.LinearEncoding instead.

It's my understanding that most LUTs themselves use LinearEncoding and that their color values should be used as-is. If a user wants to convert a 1D LUT to sRGB on the fly via sRGBEncoding, then they could always convert it to RGBAFormat by duplicating the values for each color channel.

In my case the inputs are a custom log encoding, and the outputs of the 1D LUT are known to be sRGB (although I could also change that). I'm manually disabling this.fullscreenMaterial.encodeOutput to avoid double-encoding. This may be a bit hard to handle with just Effect.processColorSpace, as LUTs can change the data's color space.

We could also just ignore the LUT1D special case here, and I'll modify my LUTs to output Linear-sRGB, so the output encoding works as expected.

Maybe the approach with inputColorSpace & outputColorSpace would be better after all because that would explicitly inform the EffectPass about the output color space of each effect. That way we don't leave room for assumptions.

Reverted the DataTexture3D → Data3DTexture change.
I'm seeing the same error about LookupTexture using sRGB now too, because it's FloatType and not UnsignedIntType. But agreed, I'd be surprised if most users are encoding their display transform in the LUT, it seems fine to assume Linear-sRGB or no color space instead.
The inputColorSpace and outputColorSpace properties make sense then. These should probably be readonly, since it's not the right way for users to change the output color space of an effects stack?

Thanks!


SA1619 false alarm on partial classes

SA1619 should consider documentation on partial classes.
File1.cs:
/// <summary>blablabla. </summary>
/// <typeparam name="TPaymentRequest"> aaa. </typeparam>
public abstract partial class BasePostRequestProcessor<TPaymentRequest>
{
}

File2.cs:
/// <summary>blablabla. </summary>
public abstract partial class BasePostRequestProcessor<TPaymentRequest> // SA1619	The documentation for type parameter 'TPaymentRequest' is missing
{
}

File2.cs after change:
 /// <summary>blablabla. </summary>
 /// <typeparam name="TPaymentRequest"> aaa. </typeparam> // CS1710 XML comment has a duplicate typeparam tag for 'TPaymentRequest'
public abstract partial class BasePostRequestProcessor<TPaymentRequest>
{
}

File2.cs should not have a <summary> element. Only one part of the partial type should have this documentation element, and the analyzers assume this is the same part that will document type parameters. Updating File2.cs to use <content> instead of <summary> should resolve this problem. See the documentation page of SA1619 for additional information.

@sungam3r Thanks for reporting this. I filed #2908 as a new analyzer idea to help users avoid this situation.

Thanks! Indeed, I had to carefully examine the documentation for the rule.


time series prediction

hi all,
just wondering if this library can be used for either multivariate or univariate time series prediction.
Is there already an example of this?
Many thanks,
best,
Andrew

Hi,
just trying to solve the same problem. Here are two links:
http://apaszke.github.io/lstm-explained.html (+comments)
https://github.com/DataToKnowledge/torch-lstm
But I don't know yet how to adapt it for multivariate time series, so I'd also greatly appreciate any help.
Regards,
Richard

@andrewcz The language model (LM) example if very simple to your time series prediction.
Language Model

object is to predict the next word given the previous words.
input for each time-step is the index of a word : an scalar integer
output for each time-step is the likelihoods over all words : a vector of floats
if your task is to find the most likely sequence of words to follow a known sequence, then you can perform a beam search over all possible combinations, keeping only the most likely sequences.

Time series

object is to predict the value of the next step given the previous steps
input for each time-step is a univariate/multivariate value : a scalar or vector float/integer
output for each time-step is the prediction of the next value : same as input

If your task is to find the most likely sequence of predictions for time series, not sure how this is done. Just feeding the prediction of next value as input to the RNN for the next time step, will not necessarily guarantee this, but it is an acceptable approach. You can consult http://www.ulb.ac.be/di/map/gbonte/ftp/time_ser.pdf (forecasting section, slide 88 and up) to get an idea of the different way the model can be used for forecasting.
In any case, we don't currently have examples of time-series prediction. But all the components should be there to build such a model and use it for forecasting.

I am also trying to achieve something similar (classification of multivariate time series).  Can you clarify what the structure of a batch of input sequences should be?  For example, I have 28-dimensional time series each with 28 time-steps.  If I want to input these in batches of 64 should my input table contain a tensor of size 64x28x28 or of 1792x28?  Or something else? Thanks!

Hi, I tried to simplify the example provided in the description of the Recurrent module by changing the inputs and outputs to scalars. Maybe it will be helpful:
https://github.com/rracinskij/rnntest01/blob/master/rnntest01.lua

thanks rracinskij!!!
is this a multivariate version through a numerical array?
Many thanks,
Andrew

No, it is univariate, but it should be probably easy to modify it to use multivariate time series.

Added link to your example @rracinskij https://github.com/Element-Research/rnn/blob/master/README.md . Thanks.

@andrewcz It looks like that building a model for a multivariate time series prediction is much trickier than it seemed at the beginning. A model should probably use a sequence of vectors as inputs and targets and it is quite unclear how to implement it.
Have you figured out something? Thank you.


[Bug]: spotlessCheck passes on CI but fails locally

Is there an existing issue for this?

[X] I have searched the existing issues

Is there a StackOverflow question about this issue?

[X] I have searched StackOverflow

What happened?
Our CI build runs the following command:
./gradlew spotlessCheck --init-script gradle/init.gradle.kts --no-configuration-cache (source),
however, running the same command locally results in failures.
$ ./gradlew spotlessCheck --init-script gradle/init.gradle.kts --no-configuration-cache
Type-safe project accessors is an incubating feature.
> Task :app-nia-catalog:spotlessKotlinCheck FAILED
> Task :lint:spotlessKotlinCheck FAILED
> Task :benchmarks:spotlessKotlinCheck FAILED
> Task :core:analytics:spotlessKotlinCheck FAILED

FAILURE: Build completed with 4 failures.

1: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':app-nia-catalog:spotlessKotlinCheck'.
> The following files had format violations:
      src/main/kotlin/com/google/samples/apps/niacatalog/NiaCatalogActivity.kt
          @@ -23,11 +23,11 @@
           import·com.google.samples.apps.niacatalog.ui.NiaCatalog

           class·NiaCatalogActivity·:·ComponentActivity()·{
          -····override·fun·onCreate(savedInstanceState:·Bundle?)·{
          -········super.onCreate(savedInstanceState)
          +\toverride·fun·onCreate(savedInstanceState:·Bundle?)·{
          +\t\tsuper.onCreate(savedInstanceState)

          -········WindowCompat.setDecorFitsSystemWindows(window,·false)
          +\t\tWindowCompat.setDecorFitsSystemWindows(window,·false)

          -········setContent·{·NiaCatalog()·}
          -····}
          +\t\tsetContent·{·NiaCatalog()·}
          +\t}
           }
      src/main/kotlin/com/google/samples/apps/niacatalog/ui/Catalog.kt
          @@ -58,316 +58,316 @@
           @OptIn(ExperimentalLayoutApi::class)
           @Composable
           fun·NiaCatalog()·{
          -····NiaTheme·{
          -········Surface·{
          -············val·contentPadding·=·WindowInsets
          -················.systemBars
          -················.add(WindowInsets(left·=·16.dp,·top·=·16.dp,·right·=·16.dp,·bottom·=·16.dp))
          -················.asPaddingValues()
          -············LazyColumn(
          -················modifier·=·Modifier.fillMaxSize(),
          -················contentPadding·=·contentPadding,
          -················verticalArrangement·=·Arrangement.spacedBy(16.dp),
          -············)·{
          -················item·{
          -····················Text(
          -························text·=·"NiA·Catalog",
          -························style·=·MaterialTheme.typography.headlineSmall,
          -····················)
          -················}
          -················item·{·Text("Buttons",·Modifier.padding(top·=·16.dp))·}
          -················item·{
          -····················FlowRow(horizontalArrangement·=·Arrangement.spacedBy(16.dp))·{
          -························NiaButton(onClick·=·{})·{
          -····························Text(text·=·"Enabled")
          -························}
          -························NiaOutlinedButton(onClick·=·{})·{
          -····························Text(text·=·"Enabled")
          -························}
          -························NiaTextButton(onClick·=·{})·{
      ... (598 more lines that didn't fit)
  Run './gradlew :app-nia-catalog:spotlessApply' to fix these violations.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
==============================================================================

2: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':lint:spotlessKotlinCheck'.
> The following files had format violations:
      src/main/kotlin/com/google/samples/apps/nowinandroid/lint/designsystem/DesignSystemDetector.kt
          @@ -34,87 +34,87 @@
           ·*/
           class·DesignSystemDetector·:·Detector(),·Detector.UastScanner·{

          -····override·fun·getApplicableUastTypes():·List<Class<out·UElement>>·{
          -········return·listOf(
          -············UCallExpression::class.java,
          -············UQualifiedReferenceExpression::class.java,
          -········)
          -····}
          +\toverride·fun·getApplicableUastTypes():·List<Class<out·UElement>>·{
          +\t\treturn·listOf(
          +\t\t\tUCallExpression::class.java,
          +\t\t\tUQualifiedReferenceExpression::class.java,
          +\t\t)
          +\t}

          -····override·fun·createUastHandler(context:·JavaContext):·UElementHandler·{
          -········return·object·:·UElementHandler()·{
          -············override·fun·visitCallExpression(node:·UCallExpression)·{
          -················val·name·=·node.methodName·?:·return
          -················val·preferredName·=·METHOD_NAMES[name]·?:·return
          -················reportIssue(context,·node,·name,·preferredName)
          -············}
          +\toverride·fun·createUastHandler(context:·JavaContext):·UElementHandler·{
          +\t\treturn·object·:·UElementHandler()·{
          +\t\t\toverride·fun·visitCallExpression(node:·UCallExpression)·{
          +\t\t\t\tval·name·=·node.methodName·?:·return
          +\t\t\t\tval·preferredName·=·METHOD_NAMES[name]·?:·return
          +\t\t\t\treportIssue(context,·node,·name,·preferredName)
          +\t\t\t}

          -············override·fun·visitQualifiedReferenceExpression(node:·UQualifiedReferenceExpression)·{
          -················val·name·=·node.receiver.asRenderString()
          -················val·preferredName·=·RECEIVER_NAMES[name]·?:·return
          -················reportIssue(context,·node,·name,·preferredName)
          -············}
          -········}
          -····}
          +\t\t\toverride·fun·visitQualifiedReferenceExpression(node:·UQualifiedReferenceExpression)·{
          +\t\t\t\tval·name·=·node.receiver.asRenderString()
          +\t\t\t\tval·preferredName·=·RECEIVER_NAMES[name]·?:·return
          +\t\t\t\treportIssue(context,·node,·name,·preferredName)
          +\t\t\t}
          +\t\t}
          +\t}

          -····companion·object·{
          -········@JvmField
      ... (117 more lines that didn't fit)
  Violations also present in:
      src/main/kotlin/com/google/samples/apps/nowinandroid/lint/designsystem/DesignSystemIssueRegistry.kt
  Run './gradlew :lint:spotlessApply' to fix these violations.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
==============================================================================

3: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':benchmarks:spotlessKotlinCheck'.
> The following files had format violations:
      src/main/kotlin/androidx/test/uiautomator/UiAutomatorHelpers.kt
          @@ -27,22 +27,22 @@
           ·*·Condition·will·be·satisfied·if·given·element·has·specified·count·of·children
           ·*/
           fun·untilHasChildren(
          -····childCount:·Int·=·1,
          -····op:·HasChildrenOp·=·AT_LEAST,
          +\tchildCount:·Int·=·1,
          +\top:·HasChildrenOp·=·AT_LEAST,
           ):·UiObject2Condition<Boolean>·{
          -····return·object·:·UiObject2Condition<Boolean>()·{
          -········override·fun·apply(element:·UiObject2):·Boolean·{
          -············return·when·(op)·{
          -················AT_LEAST·->·element.childCount·>=·childCount
          -················EXACTLY·->·element.childCount·==·childCount
          -················AT_MOST·->·element.childCount·<=·childCount
          -············}
          -········}
          -····}
          +\treturn·object·:·UiObject2Condition<Boolean>()·{
          +\t\toverride·fun·apply(element:·UiObject2):·Boolean·{
          +\t\t\treturn·when·(op)·{
          +\t\t\t\tAT_LEAST·->·element.childCount·>=·childCount
          +\t\t\t\tEXACTLY·->·element.childCount·==·childCount
          +\t\t\t\tAT_MOST·->·element.childCount·<=·childCount
          +\t\t\t}
          +\t\t}
          +\t}
           }

           enum·class·HasChildrenOp·{
          -····AT_LEAST,
          -····EXACTLY,
          -····AT_MOST,
          +\tAT_LEAST,
          +\tEXACTLY,
          +\tAT_MOST,
           }
      src/main/kotlin/com/google/samples/apps/nowinandroid/GeneralActions.kt
          @@ -37,8 +37,8 @@
           ·*·-·or·(preferred)·executing·the·grant·command·on·the·target·package.
           ·*/
           fun·MacrobenchmarkScope.allowNotifications()·{
          -····if·(SDK_INT·>=·TIRAMISU)·{
          -········val·command·=·"pm·grant·$packageName·${permission.POST_NOTIFICATIONS}"
          -········device.executeShellCommand(command)
          -····}
          +\tif·(SDK_INT·>=·TIRAMISU)·{
          +\t\tval·command·=·"pm·grant·$packageName·${permission.POST_NOTIFICATIONS}"
          +\t\tdevice.executeShellCommand(command)
      ... (2 more lines that didn't fit)
  Violations also present in 10 other files.
  Run './gradlew :benchmarks:spotlessApply' to fix these violations.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
==============================================================================

4: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':core:analytics:spotlessKotlinCheck'.
> The following files had format violations:
      src/demo/kotlin/com/google/samples/apps/nowinandroid/core/analytics/AnalyticsModule.kt
          @@ -24,6 +24,6 @@
           @Module
           @InstallIn(SingletonComponent::class)
           abstract·class·AnalyticsModule·{
          -····@Binds
          -····abstract·fun·bindsAnalyticsHelper(analyticsHelperImpl:·StubAnalyticsHelper):·AnalyticsHelper
          +\t@Binds
          +\tabstract·fun·bindsAnalyticsHelper(analyticsHelperImpl:·StubAnalyticsHelper):·AnalyticsHelper
           }
      src/main/kotlin/com/google/samples/apps/nowinandroid/core/analytics/AnalyticsEvent.kt
          @@ -27,32 +27,32 @@
<EMAIL_ADDRESS>           ·*/
           data·class·AnalyticsEvent(
          -····val·type:·String,
          -····val·extras:·List<Param>·=·emptyList(),
          +\tval·type:·String,
          +\tval·extras:·List<Param>·=·emptyList(),
           )·{
          -····//·Standard·analytics·types.
          -····class·Types·{
          -········companion·object·{
          -············const·val·SCREEN_VIEW·=·"screen_view"·//·(extras:·SCREEN_NAME)
          -········}
          -····}
          +\t//·Standard·analytics·types.
          +\tclass·Types·{
          +\t\tcompanion·object·{
          +\t\t\tconst·val·SCREEN_VIEW·=·"screen_view"·//·(extras:·SCREEN_NAME)
          +\t\t}
          +\t}

          -····/**
          -·····*·A·key-value·pair·used·to·supply·extra·context·to·an·analytics·event.
          -·····*
<EMAIL_ADDRESS>          -·····*·however,·if·no·suitable·key·is·available·you·can·define·your·own·as·long·as·it·is·configured
          -·····*·in·your·backend·analytics·system·(for·example,·by·creating·a·Firebase·Analytics·custom
          -·····*·parameter).
          -·····*
          -·····*·@param·value·-·the·parameter·value.
          -·····*/
          -····data·class·Param(val·key:·String,·val·value:·String)
          +\t/**
          +\t·*·A·key-value·pair·used·to·supply·extra·context·to·an·analytics·event.
          +\t·*
<EMAIL_ADDRESS>          +\t·*·however,·if·no·suitable·key·is·available·you·can·define·your·own·as·long·as·it·is·configured
          +\t·*·in·your·backend·analytics·system·(for·example,·by·creating·a·Firebase·Analytics·custom
      ... (19 more lines that didn't fit)
  Violations also present in:
      src/main/kotlin/com/google/samples/apps/nowinandroid/core/analytics/AnalyticsHelper.kt
      src/main/kotlin/com/google/samples/apps/nowinandroid/core/analytics/NoOpAnalyticsHelper.kt
      src/main/kotlin/com/google/samples/apps/nowinandroid/core/analytics/StubAnalyticsHelper.kt
      src/main/kotlin/com/google/samples/apps/nowinandroid/core/analytics/UiHelpers.kt
      src/prod/kotlin/com/google/samples/apps/nowinandroid/core/analytics/AnalyticsModule.kt
      src/prod/kotlin/com/google/samples/apps/nowinandroid/core/analytics/FirebaseAnalyticsHelper.kt
  Run './gradlew :core:analytics:spotlessApply' to fix these violations.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
==============================================================================

BUILD FAILED in 2s
23 actionable tasks: 4 executed, 1 from cache, 18 up-to-date```

### Relevant logcat output

_No response_

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

Spotless was recently updated from 6.13.0 to 6.22.0. If I revert the Spotless version back to 6.13.0 I no longer experience this issue.

Found the issue: gradle somehow cached my user ~/.editorconfig settings (which had indent_type = tab). Deleting the build cache (rm -rf .gradle) solved it.


Unclear Syntax on BoxBlacklist.txt

I'm trying to blacklist decocraft items on the box blacklist due to it crashing the client (due to many structures taking up more than one block). This particular mod uses the same itemID, but different damage values to differentiate between the 500+ items in its repertoire.
BoxBlacklist.txt has this comment:
Use this file to tell Mekanism which blocks should not be picked up by a cardboard box.
Proper syntax is "NAME:META". Example (for stone):
stone:0
Yet, the CSV file generated by NEI's item panel dump generates this type of info:
Item Name,Item ID,Item meta,Has NBT,Display Name
props:blockProps,963,0,false,"Unnamed Block, report to mod author."
props:blockFake,964,0,false,"Unnamed Block, report to mod author."
props:props,4553,0,false,Stuffed Creeper
props:props,4553,1,false,Wine Bottle
props:props,4553,2,false,Grandfather Clock
props:props,4553,3,false,Wood Blocks
...etc
Nothing I input works, so what is the proper syntax for blacklisting the items and can it be written into the comment of BoxBlacklist.txt?

Seems pretty straightforward. itemName:metaValue.
So if you wanted to blacklist Stuffed Creeper you would use:
props:0
And for Grandfather Clock
props:2
What have you been trying?

Updated to be a bit more clear. Correct syntax is now "NAME META" instead of "NAME:META" to avoid domain confusion- for example, an entry for stone would be "minecraft:stone 0".


Add support for CloudSearch

Description of your changes
Implements basic support for CloudSearch domains.
Some implementation details still up for discussion.
Fixes #1007.
I have:

[X] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

I will:

[x] Write tests for the code in setup
[x] Add examples

How has this code been tested
Simple create/delete/update procedures with test resources.
End-to-end testing from creating a domain up to using it to query data using curl and anonymous access (index fields not covered by this PR).

Discussion
The AWS API for CloudSearch does provide a lean data model for Domains (name, region, current scaling values, endpoints). Other parameters (like scaling options, access policy, availability options, index fields) are handled through separate Define/Describe functions, which therefore are excluded from the generated domain data model.
In this PR, I chose the approach to include some of those parameters in the custom domain parameters and to use (sometimes contextless) sub-calls to handle late-init, isUpToDate and update.

Thanks @mhoff for your contribution! Good first PR.
I added some remarks to your code.

Many thanks for your remarks! I have resolved the few minor ones and will continue with the rest.

@haarchri I have updated the PR according to what we have discussed. This PR should properly implement alpha-support for AWS CloudSearch. Review would be very much appreciated.

NAME                                                           READY   SYNCED   EXTERNAL-NAME
domain.cloudsearch.aws.crossplane.io/cloudsearch-test-anonym   True    True     cloudsearch-test-anonym
domain.cloudsearch.aws.crossplane.io/cloudsearch-test-domain   True    True     cloudsearch-test-domain


Does the misMatchTolerance Number actually work?

misMatchTolerance Number
Overrides the global misMatchTolerance value for this command. Pass in a number between 0 and 100 that defines the degree of mismatch to consider two images as identical.
I can't seem to get this to actually work in Spectre - any advice on how to pass the value in my command?
browser.checkViewport({misMatchTolerance: 50});
seems to do nothing.

I think you're right about misMatchTolerance not working for the Spectre commands. It looks like fuzzLevel is the primary driver for mismatch. The command submits the screenshot to Spectre with the given fuzz level and uses the diff amount that Spectre returns as the actual misMatchTolerance.

Would it be work to tweak the README to mention that Spectre uses fuzzLevel while other methods use misMatchToerlance? I think that would clear up confusion and not require any code change :slightly_smiling_face:


Updating with a new stack not supported?

Looking at pre-start, it's just un-taring when [ ! -d $ROOTFS_DIR ].
Does that mean, stack deployment always assumes a fresh environment? i.e. updating not supported? maybe stack update implies stemcell update, which would always cause a deployment on a new VM?

Hi, @tomoe,
The full rootfs directory is /var/vcap/packages/cflinuxfs2/rootfs, but /var/vcap/packages/cflinuxfs2 is a symlink to a specific version of the cflinuxfs2 package (for example, /var/vcap/data/packages/cflinuxfs2/a48cedf96fa738616b8f3a36980a5cac60a7e909.1-aa783c48dc40730ce51e3ae119ec18b8903b0c74). So if the rootfs contents are updated, the package version will be different, and /var/vcap/packages/cflinuxfs2 will not have a rootfs subdirectory after BOSH updates the VM with the new package.
Best,
Eric, CF Runtime Diego PM

Thanks for the thorough explanation, @ematpl !
Closing as it's my misunderstanding.

To be fair, that's a subtle enough BOSH-ism that it may be worthy of a succinct comment. :)

:-) I need to be more brainwashed by BOSH-ism


[release-1.5] disable enforcing success rate based outlier detection

Manual cherry pick of https://github.com/istio/istio/pull/25534
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

@istio/release-managers can you please approve this for 1.5?


Gap appears between first and last item when looping

I'm using an out of the box setup for embla react:
<Box className="embla">
  <Box className="embla__viewport" ref={emblaRef}>
    <Box className="embla__container" px={0} mx={0}>
      {packs.map((p, index) => (
        <Box
          bg={'red'}
          px={5}
          className="embla__slide"
          key={index}
          w={'33.33%'}
          maxW={'33.33%'}
        >
          <YoloPack pack={p} />
        </Box>
      ))}
    </Box>
  </Box>
</Box>

Options are loop=true and align='center'.
No matter what I do I can't get rid of the gap between the first and last items when the carousel is looping:

I found this issue but couldn't figure out what the solution is. Sorry I must be missing something really obvious.
How do I get rid of the gap?
My versions
"embla-carousel-autoplay": "7.0.9",
"embla-carousel-react": "7.0.9",

Hi @ilmoi,
Thank you for your question. It’s required to provide a CodeSandbox when creating a bug report. Otherwise it will not be processed. Let me know if you intend to do that.
Best,
David

@ilmoi have you seen my response?


Windows binary

Feel free to use this issue to let me know if you are interested in a Windows binary package.

Yes, I would be interested in a Windows binary package. WordPress developers would also love this.

I also do interest. Thanks for such a great lib!

@w33zy @eness
From upstream it looks that I could build a Windows binary. Of course I need to give it a try but it seems that soon we could get native Windows support for xrDebug!

Hey @eness and @w33zy
Have you tried running this via WSL?
To run via WSL simply download the Linux binary for your CPU arch and run this on CMD:
wsl ./xrdebug <options>

I ask because the Windows binary will complain to run this and will panic all over Windows Defender which is far from what end users are expecting.
I tried yesterday and apart from configuring WSL the process was quite easy and now I can run any Linux binary on Windows.

I just wanted to follow up on the request for a Windows build of xrdebug. @eness @w33zy
Initially, I thought, ‘Sure, how hard can it be?’ Turns out, extremely hard. After jumping through endless hoops to compile it for multiple OSs, I finally got it working… only to have Windows Defender enthusiastically label it as malware but despite that, the actual issue is that such way of compiling the software is too much hassle and breaks too often.
So, naturally, I did what any reasonable person would do: I learned an entirely new programming language, rewrote the entire project from scratch, and built a native Windows binary. It's been quite a journey, but now I can distribute native binaries for all platforms!
xrdebug_x86.exe.zip
Let me know how it goes.

🎄 Release 3.0.0 introduces native Windows binaries. Happy debugging.


sriov-network-config-daemon POD/DS are not running.

After deploying (make deploy-setup-k8s) sriov-network-operator ,  sriov-network-config-daemon is not running ( No errors/logs and no information ).
$kubectl get -n sriov-network-operator all
pod/sriov-network-operator-5c7cb646dc-vkpqk   1/1     Running             0          15m
NAME                                         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/network-resources-injector-service   ClusterIP   XX.XX.XX.XX             443/TCP   15m
service/operator-webhook-service             ClusterIP   XX.XX.XX.XX           443/TCP   15m
NAME                                         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                                 AGE
daemonset.apps/network-resources-injector    3         3         0       3            0           beta.kubernetes.io/os=linux                                   15m
daemonset.apps/operator-webhook              3         3         0       3            0           beta.kubernetes.io/os=linux                                   15m
daemonset.apps/sriov-network-config-daemon   0         0         0       0            0           beta.kubernetes.io/os=linux,node-role.kubernetes.io/worker=   15m
NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/sriov-network-operator   1/1     1            1           15m
NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/sriov-network-operator-5c7cb646dc   1         1         1       15m
Describe DS of sriov-network-config-daemon , shows no error/log.
Desired Number of Nodes Scheduled: 0
Current Number of Nodes Scheduled: 0
Number of Nodes Scheduled with Up-to-date Pods: 0
Number of Nodes Scheduled with Available Pods: 0
Number of Nodes Misscheduled: 0
Pods Status:  0 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:

@zeeke Thanks for the Response. Please find node data and k8s version.
Kubelet Version:            v1.26.1
Node_Description.txt

The node has been labeled with node-role.kubernetes.io/worker=worker, while the daemonset looks for node-role.kubernetes.io/worker=. That's why the daemonset has no pods, I guess.

The node has been labeled with node-role.kubernetes.io/worker=worker, while the daemonset looks for node-role.kubernetes.io/worker=. That's why the daemonset has no pods, I guess.

Thanks For the response.


StreamCopyHttpContent.CreateContentReadStreamAsync() not implemented stops signing code that needs to get a hash of the request body

Description
I'm writing a proxy with YARP that signs requests for an upstream service. The proxy needs to take all request types and paths and simply send them upstream - the proxy may be reused as a sidecar in a number of projects, so must handle any kind of request.
The signature is derived from a hash of: an external key, request method, request path, request headers, and the body itself. The resulting signature is added to the request headers and is validated by the remote server (approximately - the exact details are specified in https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html)
I'm currently using https://github.com/FantasticFiasco/aws-signature-version-4 to do the signing, and am integrating it into YARP by using a Request Transform.
Within the transform, the signing library calls requestContext.ProxyRequest.Content.ReadAsStreamAsync() so it can then calculate a SHA256 on the request body as part of the signing algorithm.
The problem here is that ProxyRequest.Content is implemented as StreamCopyHttpContent from YARP, and the method ReadAsStreamAsync() on that class simply throws a NotImplementedException().
I'm happy to raise a PR in https://github.com/FantasticFiasco/aws-signature-version-4 if there is a better way of getting the body that works, or failing that, how else should I address the problem of needed to read the request content to add an additional header?
To Reproduce
A simple approximation of the issue of getting the content stream to hash can be shown by the following:
public void ConfigureServices(IServiceCollection services)
{
    var proxyBuilder = services.AddReverseProxy();
    proxyBuilder.LoadFromConfig(Configuration.GetSection("ReverseProxy"));

    proxyBuilder.AddTransforms(context =>
    {
        context.AddRequestTransform(async requestContext =>
        {
            using (SHA256 hash = SHA256.Create())
            {
                if (requestContext.ProxyRequest.Content != null)
                {
                    var contentStream = await requestContext.ProxyRequest.Content.ReadAsStreamAsync();
                    var value = await hash.ComputeHashAsync(contentStream);
                    requestContext.ProxyRequest.AddHeader("X-Hash", BitConverter.ToString(value));
                }
            }
        });
    });
}

That throws the following:
System.NotImplementedException: The method or operation is not implemented.
   at Yarp.ReverseProxy.Forwarder.StreamCopyHttpContent.CreateContentReadStreamAsync()
   at System.Net.Http.HttpContent.CreateContentReadStreamAsync(CancellationToken cancellationToken)
   at System.Net.Http.HttpContent.ReadAsStreamAsync(CancellationToken cancellationToken)
   at System.Net.Http.HttpContent.ReadAsStreamAsync()
   at BasicYARPSample.Startup.<>c.<<ConfigureServices>b__7_1>d.MoveNext() in /Users/Edouard.Poor/Projects/YarpPoc/YarpPoc/Startup.cs:line 46
--- End of stack trace from previous location ---
   at Yarp.ReverseProxy.Transforms.Builder.StructuredTransformer.TransformRequestAsync(HttpContext httpContext, HttpRequestMessage proxyRequest, String destinationPrefix)
   at Yarp.ReverseProxy.Forwarder.HttpForwarder.CreateRequestMessageAsync(HttpContext context, String destinationPrefix, HttpTransformer transformer, ForwarderRequestConfig requestConfig, Boolean isStreamingRequest, ActivityCancellationTokenSource activityToken)
   at Yarp.ReverseProxy.Forwarder.HttpForwarder.SendAsync(HttpContext context, String destinationPrefix, HttpMessageInvoker httpClient, ForwarderRequestConfig requestConfig, HttpTransformer transformer)
   at Yarp.ReverseProxy.Forwarder.ForwarderMiddleware.Invoke(HttpContext context)
   at Yarp.ReverseProxy.Health.PassiveHealthCheckMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

because StreamCopyHttpContent.CreateContentReadStreamAsync's implementation is:
// this is used internally by HttpContent.ReadAsStreamAsync(...)
protected override Task<Stream> CreateContentReadStreamAsync()
{
    // Nobody should be calling this...
    throw new NotImplementedException();
}

Further technical details

YARP 1.1
macOS

Closest I can come up with for something that seems to work is to read the Request body, then monkey patch that back into the ProxyRequest:
proxyBuilder.AddTransforms(context =>
{
    context.AddRequestTransform(async requestContext =>
    {
        using (SHA256 hash = SHA256.Create())
        {
            if (requestContext.ProxyRequest.Content != null)
            {
                // Replace the ProxyRequest.Content with bytes derived from the Request.Body
                // and monkey patch all the content related headers back again.
                using var reader = new BinaryReader(requestContext.HttpContext.Request.Body);
                using var ms = new MemoryStream();
                await reader.BaseStream.CopyToAsync(ms);
                var bytes = ms.ToArray();
                var oldContentHeaders = requestContext.ProxyRequest.Content.Headers;
                requestContext.ProxyRequest.Content = new ByteArrayContent(bytes);
                requestContext.ProxyRequest.Content.Headers.Clear();
                foreach(var contentHeader in oldContentHeaders)
                    requestContext.ProxyRequest.Content.Headers.Add(contentHeader.Key, contentHeader.Value);

                var contentStream = await requestContext.ProxyRequest.Content.ReadAsStreamAsync();
                var value = await hash.ComputeHashAsync(contentStream);
                requestContext.ProxyRequest.AddHeader("X-Hash", BitConverter.ToString(value));
            }
        }
    });
});

Not feeling like that a good long term solution for production code, but interested in the YARP teams thoughts.

That's about what's recommended in our docs:
https://microsoft.github.io/reverse-proxy/articles/transforms.html#request-body-transforms
The one improvement I'd suggest if you don't need to actually modify the body is to use HttpRequest.EnableBuffering() instead of a MemoryStream. That makes the HttpRequest.Body buffer in place and all you need to do is seek back to the beginning.
That said, there's a bug with EnableBuffering right now that I'm fixing in AspNetCore. https://github.com/microsoft/reverse-proxy/issues/1657#issuecomment-1104481211

@Tratcher can we add a warning to that sample about the potential for poor performance of the sample? We need to call out performance considerations (and security implications) of things that blindly buffer the entire request body like that.

Triage: Let's be more specific in the docs about the warning.

Generating a header based on the contents of the request body fundamentally buffering the entire response. You can incrementally generate the hash, but the request headers can't be sent until that header is generated, so I'm not sure what an efficient API looks like in this case.


Toggle note pins on click, not hover

This PR updates some pin behavior on the front end.
Previously, no pins were selected by default, and a user could select pins from the Pin List in the sidebar. Additionally, a user could hover over one pin on the map to view its note contents.
Now, when an investigation is loaded, all pins that can be selected are selected by default. This means that pins are rendered as features on the geojs map automatically. Users can still unselect pins. A selectable pin is defined (for now) as a pin whose parent dataset is the currently active dataset. Pin notes are now toggled by clicking on the pin in the map. This allows viewing several different notes at once.
This PR is strongly in the camp of "function over form," and as a result pin notes are not super pretty. I think a follow up PR could address this in the future.
In order to test this with the test data created by the populate script, you will need to open an investigation with pins that contain notes, and whose parent dataset is part of the investigation. That dataset will need to be selected as the active/root dataset. Upon loading such a dataset:

Verify that you see the pins as point annotations on the map
Verify that all pins that are selectable are shown
Click the pins
Verify that a card shows up with the clicked pin's note text
Click those pins again
Verify that the card with the note text is hidden
Zoom/pan on the map
Verify that the note cards move accordingly
Zoom/pan such that some pins move outside of the view window
Verify that cards belonging to pins who are no longer visible are hidden
Open the sidebar and deselect some pins
Verify that the pins and the note cards are hidden.

We're starting to leak quite a bit of any out of useGeoJS, but that's OK. Maybe at some point when we have time we can go through and change things up to prevent that. That effort is simply so we can have a good file to copy/paste into other GeoJS based projects. Not necessary.

Would the fix for this any leakage be creating interfaces in useGeoJS.ts for things like layers and features? I can open an issue to track this, and I  want to understand what the best way forward is.

I'm not really sure what The Right Way™ is. And I'm not sure it's very straightforward. We might need to get a bit creative.
One small example. Two ways to do the same task.

exporting zoomLevel as a ref and then allowing components to watch that ref.
exporting and typing the GeoJS map object and using its callback infrastructure to trigger events when the zoom changes.

I think the first is a more natural Vue pattern. That's all fine and good for the GeoJS map object. What about the layer(s)? We've discussed a bit on how to handle this, but I don't think we've come up with a good plan yet.

Opened #128 to keep track of the issue brought up regarding poor usage of useGeoJS.


LSP integration: inconsistent handling of goto-definition for selected text

VSCode Version: 1.43.0
OS Version: macOS Catalina 1.15.3

Triggering goto-definition on selected (e.g. to copy) text depends upon how the text itself was selected.
This is because the goto definition request uses a different text position depending upon the end point of the selection. For a fix, I think it should always use the beginning of the selection as judged by earlier file offset.
Steps to Reproduce:

Use any LSP that's available within VSCode. For my example, I'll be using https://github.com/apple/sourcekit-lsp on itself
I'll be using the text here:

extension BuildServerBuildSystem: BuildSystem {
Examples:

extension BuildServerBuildSystem: BuildSystem {
--------------------- ^
----------- double click to select
Goto-definition doesn't work (VSCode appears to send the position at char :)

extension BuildServerBuildSystem: BuildSystem {
------------ ^------------------------^
------------start------------------- end
Goto-definition doesn't work (VSCode appears to send the position at char :)

extension BuildServerBuildSystem: BuildSystem {
------------ ^------------------------^
------------end------------------- start
Goto-definition does work (VSCode appears to send the position at char  )

For these cases VSCode should also send the position at char   before the selection

From Selection this might to be due to getPosition() returning the ending column + line.
There's also SingleCursorState which references cursor information but I'm not sure how that is used

Actually this needs to be addressed in the LSP libs since LSP doesn't have the concept of a selection direction.


Adding scraper for HI.

@qgolsteyn @lazd, Changes have been submitted. Please take a look and let me know if there is anything else we need to address. Thanks!


Schedule signer if GL::connect() has seed and creds

Include a GL API call on Greenlight::connect, for the case when we already know the seed node credentials.
This ensures network connectivity is there and starts a signer, so our sdk.connect() returns only with a running signer.

When trying to connect without network, we immediately get an error:
sdk> connect

Error: Service connectivity: (Greenlight) Failed to connect: Service connectivity: status: Unavailable, message: "error trying to connect: dns error: failed to lookup address information: Name or service not known", details: [], metadata: MetadataMap { headers: {} }


feat: add cors utils

Resolves #82
Related: https://github.com/NozomuIkuta/h3-cors/issues/10
This PR is created according to @pi0's comment to my package.
I have upgraded h3 version in my package (and improved code coverage to 100% 👍).
Now, please review this PR and check whether I'm doing as you intended.

Thanks for PR dear @NozomuIkuta.
Can we please directly inline the logic in h3 package? This way we can directly test and release it.

It's worth merging content of https://github.com/NozomuIkuta/h3-cors/pull/8 into this PR.
I will apply it as well as your feedback. 🙋♂

https://github.com/unjs/h3/pull/322#issuecomment-1422349046 is fixed: bb7af39.

@pi0
I applied your feedback and the remaining PR (https://github.com/NozomuIkuta/h3-cors/pull/8).
Let me request your review again. 🙋♂

I added prefix "H3" to type names: 6f4bdc0
@pi0
Is there any more things that I should do for this PR?

I have pushed couple of refactors. Really nice stuff thanks for helping to bring it to the core 👍🏼


Redesign error reporting

I see three problems with the current error reporting system in PEG.js:

Actions report errors by returning null
Reporting using null is inflexible (it doesn't allow to carry any information about the kind of error) and makes it impossible to return null as a regular value from actions, which would be useful sometimes (for example in a JSON parser).
See also #17.

There is no way to produce errors with completely custom messages
For example, imagine a HTTP 1.1 parser that wants to report an error about missing Host header in a HTTP request with a message like "A HTTP 1.1 request must contain a Host header". Currently the only way to do this is to throw an exception with desired message manually. This is cumbersome and it does not interact well with the backtracking behavior (throwing an exception halts the parsing completely, even when it is possible to backtrack and try another alternatives).

The expected property of SyntaxError is hard to process mechanically
The expected property of SyntaxError is either an array of expectations (each describing one alternative which the parser expected at the position of error) or null (meaning that the end of input was expected).
Each expectation is represented by a string. This string can mean an expected literal (represented using its PEG.js syntax — a quoted string), character class (represented using its PEG.js syntax — [...]), or any character (represented by string "any"). To differentiate between these cases, one has to parse the string representations manually, which makes building tools based on PEG.js such as autocompleters unnecessarily hard.

I plan to redesign the error reporting system to fix these problems. Before I describe the changes I am thinking about, a little description how the current system works is needed.
How Error Reporting Currently Works?
When a PEG.js parser tries to match a string literal, character class, or ., and fails, it produces a match failure. It consists of a position and an expectation (description of what the parser tried to match).
After producing a match failure, the parser backtracks and possibly tries another alternatives. If none of them succeeds and there is nothing more to try, the parser throws the SyntaxError exception. When setting its properties (such as position, expectations, error message, etc.), the parser considers only the furthest match failure (the one with the greatest position). If there are more such failures, their expectations are combined.
The situation is little bit more complicated if named rules are used, but this is irrelevant for this discussion.
Proposed Changes
I am thinking about the following changes in the error reporting system:

Expectations in SyntaxError.expected won't be represented by strings, but by objects. The objects will have a type property (with values like "literal", "class", "any", "eof") which will determine expectation type. For some expectation types, other properties will conain the details (e.g. for "literal" expectation where would be a value property containing the expected string). This will simplify mechanical processing of the expectations.
An alternative to the type property is to use classses. But I think the type property will be easier to handle for users.

Actions will be allowed to return null. It will be a regular value and won't signify an error.

Actions will be able to trigger a match failure using a new error function. It will take an error message as its parameter. Failures triggered by this function (called custom match failures) will consist of a position and an error message. They won't have any expectation.
The error function won't interrupt the action execution, it will just mark it as failing and save the error message. The actual failure will be produced only after the action execution finishes. If the error function is invoked multiple times, the last invocation will win (its error message will be used).
Custom match failures will be handled like regular match failures, meaning they won't halt the parsing completely and let the parser backtrack and possibly try another alternatives. There is one difference though — when finally throwing the SyntaxError exception, the expectation combination rule which applies to regular match failures won't apply to the custom ones. If in the set of match failures with the furthest position there is at least one custom one, it will simply override the regular ones completely. If there are more custom failures, the one that was produced last will win.
A SyntaxError exception based on a custom match failure will differ from exceptions based on a regular failure. It's message property will be equal to the failure's error message and its expected property will be null.
Example
start = sign:[+-]? digits:[0-9]+ {
  var result = parseInt((sign || "") + digits.join(""), 10);

  if (result % 2 == 0) {
    error("The number must be an odd integer.");
  }

  return result;
}

On input 2, the parser generated from the grammar above will produce a SyntaxError with message set to "The number must be an odd integer." and expected set to null

Actions will also be able to to trigger a regular match failure using the expected function. It will take an expected value description as a parameter. This function will be provided mainly as a convenience for situations where one doesn't need to generate a full error message and automatically generated form "Expected X but "2" found." is enough.
A SyntaxError exception based on a match failure generated by the expected function will be similar to exceptions based on a regular failure.
Example
start = sign:[+-]? digits:[0-9]+ {
  var result = parseInt((sign || "") + digits.join(""), 10);

  if (result % 2 == 0) {
    expected("odd integer");
  }

  return result;
}

On input 2, the parser generated from the grammar above will produce a SyntaxError with message set to "Expected odd integer but "2" found." and expected set to [ { type: "user", description: "odd integer" } ]

Next Steps
I welcome any notes to the proposed changes — please add them as comments. I plan to start implementing the proposal (or some modified version based on feedback) soon.

So, there is no "warning" function yet?

The warning function topic is tracked at #325


[WIP] Features/upgrade7/open stack services/openstack services ui

Looks good so far. Minor comments, please address them.
Also, unit test are missing


fill match arms assist should work with default arm

We have two features which interract not as good as the could.
.match postfix completion turns foo.match into match foo { _ => ()}
fill match arms assits allows one to fill empty match arms with all variants in match foo {}
Because .match adds a catch all branch, it prevents the assist from firing. We should fix the assist to also trigger in the case where there's only a single trivial _ => () branch.
The relevant bit of code is here:
https://github.com/rust-analyzer/rust-analyzer/blob/a3a03b65dca9dc174bd58cd3d877ede18fc58637/crates/ra_assists/src/fill_match_arms.rs#L15-L20
The tests can be fond in the same file.

I'd like to take this one :smiley:

It looks like the unit type () doesn't have it's own token. Is it correct to match it like a empty tuple?

There are different ways to check if the match arm is trivial, and I don't know which is the best.
I think the high order bit is to have
fn is_trivial_arm(arm: &ast::MatchArm) -> bool {
  ...
}

function which we can adjust later. The simplest first step would be comparing the text of match arm to "_ => ()". The more robust way would be to check that the ast::Pat is trivial and that ast::Expr is either a unit or an empty block

@kanru are you still working on this? I want to work on this too 😃

@ironyman feel free to take it! I probably won't be able to work on it for a couple days.

This issue is now fixed. Please could someone with perms close it.


Zephyr 3.2 module updates overview

Umbrella issue for tracking requests for updating various modules before Zephyr 3.2, listing all modules and an overview of the status compared to the correseponding upstream. Checkbox tick for modules where don't need extra work for 3.2 (up to date or no plan/need for an update for this release).

[x] canopennode

last updated somewhere in 2020
upstream at https://github.com/CANopenNode/CANopenNode
currently tracking https://github.com/CANopenNode/CANopenNode/commits/v1.3-master

[x] chre
[x] cmsis

at 5.8.0, 5.9.0 avilable
https://github.com/ARM-software/CMSIS_5/releases
https://github.com/zephyrproject-rtos/zephyr/issues/45279

[x] edtt
[x] fatfs
[ ] fff (@yperess)

checked out at 2019, upstream has recent commits
https://github.com/meekrosoft/fff

[ ] hal_altera (@nashif)

link in the README not working, references quartus v17.0, 21.1.1 is available
https://www.intel.com/content/www/us/en/collections/products/fpga/software/downloads.html?s=Newest

[ ] hal_atmel (@nandojve)

current version unclear, latest v3.52.0
https://www.microchip.com/en-us/tools-resources/develop/libraries/advanced-software-framework

[ ] hal_espressif (@sylvioalves @glaubermaroto @uLipe)

on 4.3, 4.4 available
https://github.com/espressif/esp-idf

[x] hal_gigadevice
[x] hal_infineon
[x] hal_microchip

upstream seems stale https://github.com/MicrochipTech/Peripheral-mec1701

[x] hal_nordic
[ ] hal_nuvoton (@MulinChao @ChiHuaL @WealianLiao)

never been updated, upstream has recent commits
https://github.com/OpenNuvoton/M480BSP

[x] hal_nxp
[x] hal_openisa

upstream is stale https://github.com/open-isa-rv32m1/rv32m1_sdk_riscv

[ ] hal_quicklogic (@kowalewskijan)

upstream has recent commits
https://github.com/QuickLogic-Corp/qorc-sdk/commits/master/HAL/src

[ ] hal_rpi_pico (@yonsch)

at 1.3.0, 1.4.0 just released
https://github.com/raspberrypi/pico-sdk/commits/master

[ ] hal_silabs (@yonsch @mnkp @chrta)

at 3.1.0 (?), 4.1.0 available
https://github.com/SiliconLabs/gecko_sdk

[x] hal_st
[x] hal_stm32
[x] hal_telink
[ ] hal_ti (@cfriedt @gmarull)

at simplelink <IP_ADDRESS>, # out of date, simplelink <IP_ADDRESS> available
https://www.ti.com/tool/SIMPLELINK-CC13XX-CC26XX-SDK#downloads

[ ] hal_xtensa (@dcpleung)

can't quite tell where upstream is

[x] libmetal
[x] liblc3
[ ] littlefs (no maintaner)

at v2.4, v2.5 available
https://github.com/littlefs-project/littlefs

[x] loramac-node
[ ] lvgl (@brgl)

at v8.2.0, v8.3.1 is available
https://github.com/lvgl/lvgl

[ ] lz4 (@Navin-Sankar)

local repo is somewhere around 1.9.3, v1.9.4 available
https://github.com/lz4/lz4

[ ] mbedtls (@d3zd3z @ceolin)

at v3.1.0, v3.2.1 available
https://github.com/Mbed-TLS/mbedtls

[x] mcuboot
[x] mipi-sys-t
[x] nanopb
[x] net-tools

no upstream

[x] nrf_hw_models
[x] open-amp
[x] openthread
[x] picolibc
[ ] segger (@nordic-krch)

at v3.30, v3.32 available
https://www.segger.com/downloads/systemview/

[x] sof
[ ] tflite-micro (@laurenmurphyx64)

out of date, stuck somewhere in 2021
https://github.com/tensorflow/tflite-micro

[x] tinycbor

deprecated

[x] tinycrypt

upstream last commit in 2019
https://github.com/intel/tinycrypt

[ ] TraceRecorderSource (@tleksell-pe)

at 4.6.3, 4.6.6 available
https://github.com/percepio/TraceRecorderSource

[x] trusted-firmware-m
[x] tf-m-tests
[ ] psa-arch-tests (@microbuilder)

mostly updated, few new upstream commits
https://github.com/ARM-software/psa-arch-tests/commits/main

[ ] uoscore-uedhoc (@rlubos)

out of date, more commits upstream
https://github.com/eriptic/uoscore-uedhoc/commits/main

[x] zcbor
[x] zscilib

no upstream

[ ]  canopennode

last updated somewhere in 2020
upstream at https://github.com/CANopenNode/CANopenNode

We are tracking upstream v1.3-master (https://github.com/CANopenNode/CANopenNode/commits/v1.3-master) and as such we are up-to-date (except a couple of commits which breaks the upstream API).

[ ] cmsis

at 5.8.0, 5.9.0 avilable
https://github.com/ARM-software/CMSIS_5/releases

There is already an issue open for this:
https://github.com/zephyrproject-rtos/zephyr/issues/45279
Unfortunately, it does not look like it will be done for 3.2.

@yperess @nashif @nandojve @sylvioalves @glaubermaroto @uLipe @MulinChao @ChiHuaL @WealianLiao @kowalewskijan @yonsch @yonsch @mnkp @chrta @cfriedt @gmarull @dcpleung @brgl @Navin-Sankar @d3zd3z @ceolin @nordic-krch @laurenmurphyx64 @tleksell-pe @microbuilder @rlubos
Hi! If you are listed here you are listed as maintainer for a Zephyr module that has updates available upstream. The merge window closes on September 9th, does any of these needs an update? Feel free to tick the corresponding item, add a comment, open an issue, a PR or whatever suits.
Thanks!

@fabiobaltieri fff's commit is just a restructure of the directory and CI, there's another on the way which I hope to merge shortly. That last one will actually change the header and I'll pull both at the same time.

[ ] hal_silabs (@yonsch @mnkp @chrta)
at 3.1.0 (?), 4.1.0 available
https://github.com/SiliconLabs/gecko_sdk

I do not plan to update the sdk. The version information (that the currently used version is 3.1.0) is correct. See also https://github.com/zephyrproject-rtos/zephyr/issues/43139

Hi @fabiobaltieri ,

hal_atmel (@nandojve)
current version unclear, latest v3.52.0

hal_atmel did not track ASF versions. The hal_atmel only have registers files and are added/updated based on http://packs.download.atmel.com. I think there won`t be any new activity for v3.2.
hal_gigadevice is usually tracked by @gmarull and me and I believe there is no pending things till moment.

upstream of hal_xtensa is https://github.com/foss-xtensa/xtensa-hal, which has no update.

@fabiobaltieri, hal_espressif will be update to v4.4.1 with this PR: https://github.com/zephyrproject-rtos/zephyr/pull/49682

[ ] hal_nuvoton (@MulinChao @ChiHuaL @WealianLiao)
never been updated, upstream has recent commits
https://github.com/OpenNuvoton/M480BSP

Actually, We (@MulinChao and @ChiHuaL) are not maintainers for the HAL.
We maintain Nuvoton EC series chip (NPCX series) and put everything in the Zephyr repository based on the disscussion here. We didn't use the hal for EC chip.
The Hal part is used for general MCU chips (Numicro) in Nuvoton.
The hal maintainer should be @ssekar15.

hal_nuvoton (@MulinChao @ChiHuaL @WealianLiao)
never been updated, upstream has recent commits
https://github.com/OpenNuvoton/M480BSP

@fabiobaltieri
I will do it

There is no rush to update hal_ti right now. I am in discussion with 2 candidates (TI employees) who may be better as maintainers.

No need to update hal_rpi_pico for now


Black camera view after denying permission

Bug Description
A completely black camera view is shown when you deny the request to use the camera.
The app should check whether the camera is enabled and never show the black camera view.
NB: Users can manually enable the camera permissions in Settings > Concordium
Steps to Reproduce

Install the wallet
When creating an identity, the app will ask for permission to use the camera: click 'Don't allow'
Try to take a photo of your id document

Expected Result
The app will tell you that it is not possible to create an identity without the use of a camera and prompt you for permissions again.
Actual Result
The camera opens up, but everything is black:

Versions

Software Version: 10.0.14 (testnet), 1.0.4 (mainnet)
OS: 14.6
Browser: Safari / Brave Browser (not sure which one is used when a webpage is loaded within an app)
Mobile device, if applicable: iPhone 11 Pro

@kristiyandobrev, @concordium-cl
Findings from testing:
The fix was to ask the user for permission to use the camera at the beginning of the identity creation flow, and simply block them from continuing if they didn't allow camera access. However, the app will just crash if access to the camera is denied.

@jens-concordium
Aren't you getting this message if the camera access is denied ?

@kristiyandobrev, when I press deny the app crashes. When I then re-open the app and get to this point in the flow, the dialog is shown as intended.

@kristiyandobrev, @concordium-cl
I still get an unwanted pending account in v1.0(17), if

I deny the camera access
use the deeplink to go Settings
and allow the camera, and then go

It looks like this:
https://user-images.githubusercontent.com/76045015/134358783-b6e7a9e9-dbeb-4937-8f5f-b8f0f1a67ab7.mov

Could not reproduce the above scenarios.
However, the app is still not robust enough in this context. After few minutes of exploratory testing, I've ended in a very similar scenario as Jens showed above, which is reproducible and eventually crashes the app:

start identity flow with camera allowed
after reading NB statement and before "getting started" with NB flow, disallow camera
Actual result: Identity fails with support dialog. Click "cancel" to close dialog. Account stays pending. When selecting it, the app crashes.
Expected result: The app should never crash. An identity should never fail unless there are problems with the identity verification. Notabene will not have any entries in their logs beforehand and cannot answer such support requests.

@concordium-cl I see. Although #61 is potentially fixing this. Should we revise it once the PR is merged and deployed ? 🙂

This seems to be working as intended in 1.0(19). I haven't been able to provoke any unwanted pending accounts, and I can't start the identity flow without allowing camera access first, so I think it's in place.


dont work startRingtone in IOS

the only thing that can't make it work, could you give me a hand.
incall.startRingtone('DEFAULT', 'default', 30);

The plugin works well on Android, on IOS there is no ringi g. May you give directions on selecting default ring tone on IOS.. Thanx in advance

The plugin works well on Android, on IOS there is no ringi g. May you give directions on selecting default ring tone on IOS.. Thanx in advance