RFC: a convention for error handling

This RFC proposes a convention for structuring methods in SciRust
which can cater to the conflicting needs of efficiency, easy of use
and effective error handling.
For the impatient:
// Efficient access without bound checks
unsafe fn get_unchecked(&self, r : usize, c : usize) -> T;
// Safe access with bound checks, raises error if invalid address
fn get_checked(&self, r : usize, c : usize) -> Result<T, Error>;
// User friendly version. Panics in case of error
fn get(&self, r : usize, c : usize) -> T;

// Efficient modification without bound checks
unsafe fn set_unchecked(&mut self, r : usize, c : usize, value : T);

// Safe modification with bound check
fn set(&mut self, r : usize, c : usize, value : T);

Detailed discussion
The audience of SciRust can be possibly divided into
two usage scenarios.

A script style usage, where the objective is to quickly
do some numerical experiment, get the results and analyze them.
A library development usage, where more professional libraries
would be built on top of fundamental building blocks provided
by SciRust (these may be other modules shipped in SciRust itself).

While the first usage scenario is important for getting new users hooked
to the library, the second usage scenario is also important for justifying
why Rust should be used for scientific software development compared
to other scientific computing platforms.
In context of the two usage scenarios, the design of SciRust has three conflicting goals:

Ease of use
Efficiency
Well managed error handling

While ease of use is important for script style usage,
efficiency and well managed error handling are important
for serious software development on top of core components
provided by SciRust.
We will consider the example of a get(r,c) method
on a matrix object to discuss these conflicting goals.
Please note that get is just a representative method
for this discussion. The design ideas can be applied in
many different parts of SciRust once accepted.
If get is being called in a loop, usually the code
around it can ensure that the conditions for accessing
data within the boundary of the matrix are met correctly.
Thus, a bound checking within the implementation of get
is just an extra overhead.
While this design is good for writing efficient software,
it can lead to a number of memory related bugs and goes
against the fundamental philosophy of Rust (Safety first).
There are actually two different options for error handling:

Returning either Option<T> or Result<T, Error>.
Using the panic mechanism.

Option<T> or Result<T, Error> provides the users a
fine grained control over what to do when an error occurs.
This is certainly the Rusty way of doing things. At the
same time, both of these return types make the user code
more complicated. One has to add extra calls to .unwrap()
even if one is sure that the function is not going to fail.
Users of scientific computing tend to prefer an environment
where they can get more work done with less effort. This is
a reason of the success of specialized environments like
MATLAB. Open source environments like Python (NumPy, SciPy)
try to achieve something similar.
While SciRust doesn't intend to compete at the level of
simplicity provided by MATLAB/Python environments, it does
intend to take an extra effort wherever possible to address
the ease of use goal.
In this context,  the return type of a getter should
be just the value type T. This can be achieved
safely by using a panic if the access boundary
conditions are not met.
The discussion above suggests up to 3 possible ways of
implementing methods like get.

An unchecked (and unsafe) version for high efficiency code
where the calling code is responsible for ensuring that
the necessary requirements for correct execution of the
method are being met.

A safe version which returns either Option<T> or
Result<T, Error> which can be used for professional
software development where the calling code has full control
over error handling.

Another safe version which panics in case of error but provides
an API which is simpler to use for writing short scientific
computing scripts.

Proposed convention
We propose that a method for which these variations
need to be supported, should follow the convention defined below:

A method_unchecked version should provide basic implementation
of the method. This should assume that necessary conditions
for successful execution of the methods are already being
ensured by the calling code. The unchecked version of method
MUST be marked unsafe. This ensures that the calling code
knows that it is responsible for ensuring the right conditions
for calling the unchecked method.

A method_checked version should be implemented on top of
a method_unchecked method. The checked version should
check for all the requirements for calling the method safely.
The return type should be either Option<T> or
Result<T, Error>. In case the required conditions for
calling the method are not met, a None or Error
should be returned. Once the required conditions are met,
method_unchecked should be called to get the result
which would be wrapped inside Option or Result.

A method version should be built on top of method_checked version.
It should simply attempt to unwrap
the value returned by method_checked and return as T.
If method_checked returns an error or None, this version
should panic.

First two versions are suitable for professional development
where most of the time we need a safe API while at some times
we need an unsafe API for efficient implementation.
The third version is suitable for script style usage scenario.
The convention has been illustrated in the three versions of
get at the beginning of this document.
API bloat
While this convention is expected to lead into an API bloat,
but if the convention is followed properly across the library,
then it should be easy to follow (both from the perspective
of users of the library and from the perspective of developers
of the library).

Just food for thought, what if the safety was baked into the type? E.g. have a Matrix<T> type and an UncheckedMatrix<T> type. That way the API would be identical across the board, you would just choose which one you need, and since the data layout would be identical converting between the two shouldn't be too expensive.

Think a bit further into it, you could still have the three methods by doing something along the lines of
impl Checked for Matrix {
    fn get(...) {
        // ...
    }
}

impl Unchecked for UncheckedMatrix P
    fn get(...) {
        // ...
    }
}

fn get<T: Checked>(m: T, c: usize, r: usize) -> ... {
    match m.get(c, r) {
        Ok(v) => v,
        Err(_) => panic!(),
    }
}

Obviously that's only a rough thought but I think it might make a much cleaner API.

Does this mean that a higher level function would either work with a safe matrix or an unsafe matrix only?   I was thinking in the lines of linear algebra code where most of the time, one would use the safe matrix API (like elementary row/column operations), while occasionally getting dirty with the unsafe API for efficiency purposes.

Hi, I also am not sure how I would use the matrix type based API. Seems
like the matrices would not be easy to replace, having different apis.
On Aug 11, 2015 7:02 AM, "Shailesh Kumar"<EMAIL_ADDRESS>wrote:

Does this mean that a higher level function would either work with a safe
matrix or an unsafe matrix only? I was thinking in the lines of linear
algebra code where most of the time, one would use the safe matrix API
(like elementary row/column operations), while occasionally getting dirty
with the unsafe API for efficiency purposes.
—
Reply to this email directly or view it on GitHub
https://github.com/indigits/scirust/issues/25#issuecomment-129835684.

Rust slices have both get_unchecked() and get() methods. https://doc.rust-lang.org/std/primitive.slice.html#method.get_unchecked . The proposed design is not very different. But rather than having 2 versions of get, here 3 versions are being suggested. The panic version is meant primarily for making writing scripty code easier.

TL;DR:

I think that "get" and "get_checked" have completely different use cases,
having nothing to do with scripts.

"get_unchecked" should replace "get" only under pretty special
circumstances.

I am not sure we need such a convention for every function, maybe we
should discuss a few different functions before generalizing (a kind of
"rule of three" [1])

We might want to replace get_unchecked with a type level solution for
vetting indices safely outside the access.

Reasoning:
get_checked: indices are input from untrusted source, like file or a user.
There is no reason to expect them to be correct, and we need the program to
do something sophisticated (like gve the user another chance to input) if
they are wrong. This is mainly useful in programs (where we know what to do
if indices are wrong). In libraries, if your using program gives wrong
indices, all you need is to help find the bug by giving a clear message and
a stack trace.
get: every other case. So I expect my indices to be correct, but I want
them checked just in case. Wrong indices indicate a bug somewhere, hence
panic is appropriate.
get_unchecked: this is only for optimization purposes, so should be used
only when some profiling shows that bounds checks are a problem. The
"unsafe" property should be considered a burden on the provider of indices
to prove (informally, of course) that they are within bounds, and thus
avoided whenever possible.
About other functions: get and set are potentially cheap enough that bounds
checking overhead might be significant, and some access patterns are
obvious enough safe that these per-element bounds checks should be avoided.
For example, a column iterator will access contiguous memory, hence be very
cheap, and it is easy to ensure the start and end points are correct. On
the other hand, the column iterator function itself probably doesn't need a
"get_unchecked" version, simply because the relative cost of checks to work
is nothing (unless used a lot to access 1-row matrices, in which case the
user should find a more appropriate implementation).
I've had a different idea btw. We could associate to a matrix two new
types: a checked_row_index and a checked_column_index. Then create versions
of get that accept those types without checking. Then create values of
those types only through known safe sources: col_index_iter,
check_col_index, first_col_index etc. Then we can use optimally fast code,
but move most of the burden of proof to the type system. This depends on
some details about the type system that I don't know, and I'm not sure
whether the pattern generalizes, but it tries to follow "Make illegal
states unrepresentable" [2]. For example, we probably want safe_indices to
borrow the shape of the matrix, to prevent it from changing shape (don't
know if we can borrow a field).
Daniel
[1] https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)
[2] https://blogs.janestreet.com/effective-ml-revisited/
On Aug 10, 2015 4:46 PM, "Shailesh Kumar"<EMAIL_ADDRESS>wrote:

This RFC proposes a convention for structuring methods in SciRust
which can cater to the conflicting needs of efficiency, easy of use
and effective error handling.
For the impatient:
// Efficient access without bound checks
unsafe fn get_unchecked(&self, r : usize, c : usize) -> T;
// Safe access with bound checks, raises error if invalid address
fn get_checked(&self, r : usize, c : usize) -> Result<T, Error>;
// User friendly version. Panics in case of error
fn get(&self, r : usize, c : usize) -> T;
// Efficient modification without bound checks
unsafe fn set_unchecked(&mut self, r : usize, c : usize, value : T);
// Safe modification with bound check
fn set(&mut self, r : usize, c : usize, value : T);
Detailed discussion
The audience of SciRust can be possibly divided into
two usage scenarios.

A script style usage, where the objective is to quickly do some
numerical experiment, get the results and analyze them.
A library development usage, where more professional libraries would
be built on top of fundamental building blocks provided by SciRust (these
may be other modules shipped in SciRust itself).

While the first usage scenario is important for getting new users hooked
to the library, the second usage scenario is also important for justifying
why Rust should be used for scientific software development compared
to other scientific computing platforms.
In context of the two usage scenarios, the design of SciRust has three
conflicting goals:

Ease of use
Efficiency
Well managed error handling

While ease of use is important for script style usage,
efficiency and well managed error handling are important
for serious software development on top of core components
provided by SciRust.
We will consider the example of a get(r,c) method
on a matrix object to discuss these conflicting goals.
Please note that get is just a representative method
for this discussion. The design ideas can be applied in
many different parts of SciRust once accepted.
If get is being called in a loop, usually the code
around it can ensure that the conditions for accessing
data within the boundary of the matrix are met correctly.
Thus, a bound checking within the implementation of get
is just an extra overhead.
While this design is good for writing efficient software,
it can lead to a number of memory related bugs and goes
against the fundamental philosophy of Rust (Safety first).
There are actually two different options for error handling:

Returning either Option or Result<T, Error>.
Using the panic mechanism.

Option or Result<T, Error> provides the users a
fine grained control over what to do when an error occurs.
This is certainly the Rusty way of doing things. At the
same time, both of these return types make the user code
more complicated. One has to add extra calls to .unwrap()
even if one is sure that the function is not going to fail.
Users of scientific computing tend to prefer an environment
where they can get more work done with less effort. This is
a reason of the success of specialized environments like
MATLAB. Open source environments like Python (NumPy, SciPy)
try to achieve something similar.
While SciRust doesn't intend to compete at the level of
simplicity provided by MATLAB/Python environments, it does
intend to take an extra effort wherever possible to address
the ease of use goal.
In this context, the return type of a getter should
be just the value type T. This can be achieved
safely by using a panic if the access boundary
conditions are not met.
The discussion above suggests up to 3 possible ways of
implementing methods like get.

An unchecked (and unsafe) version for high efficiency code
where the calling code is responsible for ensuring that
the necessary requirements for correct execution of the
method are being met.
A safe version which returns either Option or
Result<T, Error> which can be used for professional
software development where the calling code has full control
over error handling.
Another safe version which panics in case of error but provides
an API which is simpler to use for writing short scientific
computing scripts.
Proposed convention
We propose that a method for which these variations
need to be supported, should follow the convention defined below:

A method_unchecked version should provide basic implementation
of the method. This should assume that necessary conditions
for successful execution of the methods are already being
ensured by the calling code. The unchecked version of method
MUST be marked unsafe. This ensures that the calling code
knows that it is responsible for ensuring the right conditions
for calling the unchecked method.
A method_checked version should be implemented on top of
a method_unchecked method. The checked version should
check for all the requirements for calling the method safely.
The return type should be either Option or
Result<T, Error>. In case the required conditions for
calling the method are not met, a None or Error
should be returned. Once the required conditions are met,
method_unchecked should be called to get the result
which would be wrapped inside Option or Result.
A method version should be built on top of method_checked version.
It should simply attempt to unwrap
the value returned by method_checked and return as T.
If method_checked returns an error or None, this version
should panic.
First two versions are suitable for professional development
where most of the time we need a safe API while at some times
we need an unsafe API for efficient implementation.
The third version is suitable for script style usage scenario.
The convention has been illustrated in the three versions of
get at the beginning of this document.
API bloat
While this convention is expected to lead into an API bloat,
but if the convention is followed properly across the library,
then it should be easy to follow (both from the perspective
of users of the library and from the perspective of developers
of the library).
—
Reply to this email directly or view it on GitHub
https://github.com/indigits/scirust/issues/25.

Seems like the matrices would not be easy to replace, having different apis.

I was actually thinking the opposite, that the two types would have exactly the same API and only the implementations would differ. Consider the following workflow:
// let's say, for example, that matrix_from_file() is guaranteed to return a 20x20 matrix or larger
let m: Matrix<f64> = matrix_from_file("filename");

// this element is not guaranteed to be there
if let Ok(element) = m.get(50, 50) {
    println!("m[50, 50] = {}", element);
}

// we can guarantee that this is in bounds so we start using UncheckedMatrix
let m = m as UncheckedMatrix;
let mut i = 0.0;
for j in 0..20 {
    i += m.get(j, j);
}

I think it would make a cleaner API but actually the more of this I write out the more error prone it seems for the user. I just always feel like the type system isn't being used properly when I have to write things like get_checked rather than just get.

let Ok(element) = m.get(50, 50)
i += m.get(j, j);

These two functions called get do not have the same return type, hence the
APIs are not compatible. This is what I meant by not easy to replace.
On Tue, Aug 11, 2015 at 2:04 PM, Sean Marshallsay<EMAIL_ADDRESS>wrote:

Seems like the matrices would not be easy to replace, having different
apis.
I was actually thinking the opposite, that the two types would have
exactly the same API and only the implementations would differ. Consider
the following workflow:
// let's say, for example, that matrix_from_file() is guaranteed to return a 20x20 matrix or largerlet m: Matrix = matrix_from_file("filename");
// this element is not guaranteed to be thereif let Ok(element) = m.get(50, 50) {
println!("m[50, 50] = {}", element);
}
// we can guarantee that this is in bounds so we start using UncheckedMatrixlet m = m as UncheckedMatrix;let mut i = 0.0;for j in 0..20 {
i += m.get(j, j);
}
I think it would make a cleaner API but actually the more of this I write
out the more error prone it seems for the user. I just always feel like the
type system isn't being used properly when I have to write things like
get_checked rather than just get.
—
Reply to this email directly or view it on GitHub
https://github.com/indigits/scirust/issues/25#issuecomment-129996412.

--
Daniel Vainsencher

Of course. Sorry, I completely missed that (it's been a long week already).

No problem. I wonder if its possible to flesh out the shape-borrowing
safe-by-type indices I proposed above. Something like
get<C: SafeColIndex, R: SafeRowIndex>(col: C, row: R) -> ... (doesn't need
checking)
and
get<C, R>(col: C, row: R) -> ... (checks and panics if needed)
On Tue, Aug 11, 2015 at 3:52 PM, Sean Marshallsay<EMAIL_ADDRESS>wrote:

Of course. Sorry, I completely missed that (it's been a long week already).
—
Reply to this email directly or view it on GitHub
https://github.com/indigits/scirust/issues/25#issuecomment-130043565.

--
Daniel Vainsencher

That's a good idea, maybe it could be done as a newtype, something like
struct Safe(usize);

fn get(self, c: Safe, r: Safe) -> ...

Then you could call it like
let el = mat.get(Safe(3), Safe(4));

Sure, but what I would love is if we can arrange that users cannot create
them! users can only receive them from the Matrix, which actually verifies
that they actually are correct.
Something like
let c = m.min_col() // has type SafeColIndex, so can be used in unchecked
indexing.
In Haskell it is possible to not export the constructors for types, and
then library users cannot (easily) create invalid instances, and you can
enforce various invariants. Here we would want each such index to borrow a
reference for the "shape" field of the matrix, so that shape cannot change
while safe indices exist.
On Tue, Aug 11, 2015 at 4:52 PM, Sean Marshallsay<EMAIL_ADDRESS>wrote:

That's a good idea, maybe it could be done as a newtype, something like
struct Safe(usize);
fn get(self, c: Safe, r: Safe) -> ...
Then you could call it like
let el = mat.get(Safe(3), Safe(4));
—
Reply to this email directly or view it on GitHub
https://github.com/indigits/scirust/issues/25#issuecomment-130068829.

--
Daniel Vainsencher

Just to clarify on one point. The RFC doesn't intend to suggest that three versions of a method should be considered for each method.
Typical development would go like this.

Start with a single method like method_name() returning Option<T> or Result<T, Error>.  This is a standard Rust style approach. panic() should be avoided in basic development.

If using the method is becoming cumbersome for writing straight-forward scripts, then we need two versions. One version as the above and the other version which panics. The panicky version has a return type of T. The panicky version in turn uses the implementation of the version returning Option<T> or Result<T, Error>.  The preference would be to use the method_name() for the panicky version. The question here is how the method should be named for resulty/optiony version. The RFC above suggests the name to be method_name_checked.

In very rare circumstances, for efficiency purposes, we need an unsafe version of the method also which skips some of the parameter validation. This version would be named as method_name_unchecked. In this case, the optiony / resulty version would build on top of it by adding extra parameter validation.

So in summary:

all methods should by default be optiony or resulty.
if optiony / resulty version is difficult to use for script style usage, then introduce a panicky version which in turn uses the optiony / resulty version.
In extremely rare circumstances an unchecked version is also introduced for efficiency purposes. This is done by refactoring the implementation from the optiony / resulty version.

The objective of this RFC is to develop a guideline for the development process.

So looks like we agree that the unsafe version should be a rarity.
I think that if most methods should be optiony/resulty, we should strive
for Results with clearly explained error types, to enable users to do
something smarter than unwrap.
For example, I would make the get have "column/row out of bounds" error.
What would a resulty matrix inversion return as error types? or dot
product? What is some concrete code where you would handle these Results,
and not by panic! ?
Daniel
On Tue, Aug 11, 2015 at 8:01 PM, Shailesh Kumar<EMAIL_ADDRESS>wrote:

Just to clarify on one point. The RFC doesn't intend to suggest that three
versions of a method should be considered for each method.
Typical development would go like this.

Start with a single method like method_name() returning Option or Result<T,
Error>. This is a standard Rust style approach. panic() should be
avoided in basic development.
If using the method is becoming cumbersome for writing
straight-forward scripts, then we need two versions. One version as the
above and the other version which panics. The panicky version has a return
type of T. The panicky version in turn uses the implementation of the
version returning Option or Result<T, Error>. The preference would
be to use the method_name() for the panicky version. The question here
is how the method should be named for resulty/optiony version. The RFC
above suggests the name to be method_name_checked.
In very rare circumstances, for efficiency purposes, we need an unsafe
version of the method also which skips some of the parameter validation.
This version would be named as method_name_unchecked. In this case,
the optiony / resulty version would build on top of it by adding extra
parameter validation.
So in summary:

all methods should by default be optiony or resulty.
if optiony / resulty version is difficult to use for script style
usage, then introduce a panicky version which in turn uses the optiony /
resulty version.
In extremely rare circumstances an unchecked version is also
introduced for efficiency purposes. This is done by refactoring the
implementation from the optiony / resulty version.

The objective of this RFC is to develop a guideline for the development
process.
—
Reply to this email directly or view it on GitHub
https://github.com/indigits/scirust/issues/25#issuecomment-130115954.

--
Daniel Vainsencher

Please look at src/error.rs type SRError for the current list of error codes.  This certainly would be extended further. There is also a to_string method available for the SRError type which presents a human readable string for it. It is expected that some of these error codes will have additional parameters also attached with them in due course. For their usage, just search on SRError in the code base. You will see plenty of examples.

Ah, looks pretty good! Already had the pleasure to encounter
DimensionMismatch, so I changed it to also store and print the dimensions
of the participating matrices, since this makes it much easier to find the
originating bug. I'll send a PR with that.
On Wed, Aug 12, 2015 at 10:55 PM, Shailesh Kumar<EMAIL_ADDRESS>wrote:

Please look at src/error.rs type SRError for the current list of error
codes. This certainly would be extended further. There is also a to_string
method available for the SRError type which presents a human readable
string for it. It is expected that some of these error codes will have
additional parameters also attached with them in due course. For their
usage, just search on SRError in the code base. You will see plenty of
examples.
—
Reply to this email directly or view it on GitHub
https://github.com/indigits/scirust/issues/25#issuecomment-130512755.

--
Daniel Vainsencher


Please, add new chains to the dApps V2

Recommended chains to add to the React dApp v2:

Polygon Amoy
BNB Chain
BNB Chain Testnet
ZetaChain
ZetaChain Testnet

dApps:
React dApp (with standalone client) - v2 (Demo)

Is near protocol still in?


add links to contributors guide

What does this PR do?

updates the maintainers documentation to reference the contributors guide repo
updates the submitting-pull-requests documentation to ref. the contributors guide repo

Motivation
the contributors guide repo being made public!

More

[ ] Added/updated tests
[x] Added/updated documentation

Additional Notes

In my opinion, it is not necessary to remove this part of the documentation from the Traefik project.
Adding a link (for more details/ if you want more ...) to the experimental repository contributor guide is sufficient.

In my opinion, it is not necessary to remove this part of the documentation from the Traefik project.
Adding a link (for more details/ if you want more ...) to the experimental repository contributor guide is sufficient.

The content that I removed was duplicated in the new contributors guide repo, and for the benefit of the reader, it seemed logical to present the information in one place rather than two. Does it make more sense to have the information in both places?

Yes, it seemed coherent to me because the contributor can have a quick view in the Traefik project directly and go to see the details and/or participate in proposing improvements on the contributor guide.
Having said that, in both cases it suits me. :smile:


docs(README): Update README to include links to our wiki

This PR update the README to:

Include the project's Logo
Include a screenshot of the project
Describe shortly the project
Give an overview of the different repositories that compose the project
Link to the relevant wiki pages

The list of related repos is outdated. I'll update this as soon as I have the documentation ready￼


Curly Braces

Hello. First of all, thanks a lot for publishing the library. Please mark this post as question and I'm sorry if this is a noob question (I am not from C background). While reading your example sketch: ConnectEsp8266WiFiClient.ino, I noticed the following codes in the loop() :
// Start new MQTT connection
MqttClient::ConnectResult connectResult;
 // Connect
 {
MQTTPacket_connectData options = MQTTPacket_connectData_initializer;
options.MQTTVersion = 4;
options.clientID.cstring = (char*)MQTT_ID;
options.cleansession = true;
options.keepAliveInterval = 15; // 15 seconds
MqttClient::Error::type rc = mqtt->connect(options, connectResult);
if (rc != MqttClient::Error::SUCCESS) {
LOG_PRINTFLN("Connection error: %i", rc);
return;
}
}
I don't understand what is the meaning of curly braces "without parent" right just below //Connect. As per my understanding, curly braces normally encapsulate code inside if, loop, function declaration, etc. But in your example, it's just simply a pair of curly braces. If I remove the curly braces, the code will also compile fine. I must be missing something, please enlighten me.
Also I am planning to use qos 2. I noticed in the description that this library support "simplified" qos 2. What does it mean? Lastly, is this library stable for production use?

Oh I see, thanks a lot for the explanation. Lastly, is the library stable for production use?

@albertlt
The library is stable enough. I am using it for my pet projects. Messages encoder/decoder is based on Eclipse Paho MQTTPacket library that is very well tested.
If you find an issue please report.

Great. Will do. Thanks a lot =)

@albertlt
No problem :-) Let me know if you have questions.

Hello again. I was trying to use this library for communicating with Home Assistant embedded MQTT server. While I could see from Serial that the command was sent correctly, it was not read by Home Assistant. I tried Qos 1 on the PUB and I could see ACK received in terminal, proving that server was responding. However, there might be problem with the topic or payload as receive was not responding. I then tried the PubSubClient by Knolleary and it worked. The Home Assistant server is responding to the client. What could be wrong here?

@albertlt
It could be a problem with your broker.
Does the broker support QoS2?
Does the pubsubclient publishes with QoS2?
Could you please try with test.mosquitto.org broker and share logs with MQTT_LOG_ENABLED defined to 1.
If QoS1 publish works fine, that means the communication with the broker is definitely OK.

@albertlt
Did you try QoS2 publishing with test.mosquitto.org broker?
In my case, it works well.


Make ribAddFn support >1 address family.

commit 2001e03fc68c61a478c1639efb851e3fa4b867f7
Author: Rob Shakir<EMAIL_ADDRESS>Date:   Sat Sep 2 00:36:02 2023 +0000

    Change signature of ribAddFn to support non-IPv4.

     * (M) gribi/gribi.go
      - Adopt an upstream change from gribigo to make the function
        called after an entry is found to be resolvable support more
        than just IPv4. This is required to support other address families
        in lemming.

Upstream PR needs to be submitted before tests will pass.

You could get this to build by go getting the sha of the commit in the gribigo branch with the change.

Thanks -- good idea.
It looks like there's an issue with the gobgp imports that are being used:
[18:26] robjs@aardvark:github.com/openconfig/lemming   gribigochg ✔                                                                                12d ⚑
▶ go mod tidy
go: downloading cloud.google.com/go/cloudbuild v1.13.0
go: downloading cloud.google.com/go/longrunning v0.5.1
go: finding module for package github.com/wenovus/gobgp/v3/pkg/table
go: finding module for package github.com/wenovus/gobgp/v3/pkg/bgpconfig
go: github.com/openconfig/lemming/bgp imports
	github.com/wenovus/gobgp/v3/pkg/bgpconfig: module github.com/wenovus/gobgp/v3@latest found (v3.0.0-20230816063421-5f01c74a5b06), but does not contain package github.com/wenovus/gobgp/v3/pkg/bgpconfig
go: github.com/openconfig/lemming/bgp imports
	github.com/wenovus/gobgp/v3/pkg/table: module github.com/wenovus/gobgp/v3@latest found (v3.0.0-20230816063421-5f01c74a5b06), but does not contain package github.com/wenovus/gobgp/v3/pkg/table

Should we be updating the wenovus/gobgp fork to use an updated module name to make this work as expected?

worked for me, I pushed the changes to your branch

Ah, thanks! Not sure what went wrong there.


Emoji doesn't render correctly in PDF

If you think there is a bug in MigraDoc then please use the IssueSubmissionTemplate to make the issue replicable.
http://www.pdfsharp.net/wiki/IssueSubmissions.ashx
Thanks.
Resources
The official project web site:
http://pdfsharp.net/
The official peer-to-peer support forum:
http://forum.pdfsharp.net/
Reporting an Issue Here
I'm unable to get the Emoji to appear in a pdf
Expected Behavior
to have such an icons to appear in the generated pdf as follow
👀 😀 💨 ♡
Actual Behavior
�� �� �� ♡
Steps to Reproduce the Behavior
`
         // Create a new MigraDoc document
        Document document = new Document();
        //document.UseCmykColor = true;

        // Add a section to the document
        Section section = document.AddSection();

        // Add a paragraph to the section
        Paragraph paragraph = section.AddParagraph();

        paragraph.Format.Font.Color = Color.FromCmyk(100, 30, 20, 50);

        // Add some text to the paragraph
        paragraph.AddFormattedText("Hello, World!", TextFormat.Bold);
        paragraph.AddFormattedText("👀 😀 💨 ♡", new Font("Segoe UI Emoji"));

        // Create a renderer for the MigraDoc document.
        PdfDocumentRenderer pdfRenderer = new PdfDocumentRenderer(true);

        // Associate the MigraDoc document with a renderer
        pdfRenderer.Document = document;

        // Layout and render document to PDF
        pdfRenderer.RenderDocument();

        // Save the document...
        const string filename = "HelloWorld.pdf";
        pdfRenderer.PdfDocument.Save(filename);
        // ...and start a viewer.
        Process.Start(filename);

`
IssueSubmission.zip

This is a known limitation of PDFsharp. Surrogate pairs do not work yet and Unicode chars that require two 16-bit values (above 0xffff) will not show correctly.

See also:
https://github.com/empira/PDFsharp/issues/63

Any progress;  Has this been fixed yet? This is major blocking issue for me :(

This is a major blocking issue for me too


Invalid char in role name

Provider Version
0.25.12
Terraform Version
v0.15.5
Describe the bug
When granting a role that to a role that is managed (provisioned through SCIM) outside of Snowflake, the terraform provider complains about invalid char. The role that I want to grant role is managed by Okta and we have a naming convention that contains chars that are not allowed by the terraform provider. Changing the convention is impossible without a lot of work on our side and I do not think that the provider should block certain char if the user wants to have certain chars that are accepted by the Snowflake API.
Expected behavior
The role grant or creation should work from terraform managed resources with spaces and hyphens
Code samples and commands
resource "snowflake_role_grants" "okta_admin_role_grant" {
  role_name = "APP - SNOWFLAKE ADMIN"
  roles     = ["ACCOUNTADMIN"]
}

Additional context
I do see that the validation is somewhat generic but if spaces and hyphens is accepted by the snowflake api, why would one limit it?
If the limitation apply to other apis, I suggest a specific validation char set for affected resources.

The only reference to above validation function is at https://github.com/chanzuckerberg/terraform-provider-snowflake/blob/main/pkg/resources/role_grants.go#L27
name isn't even validated when role is configured https://github.com/chanzuckerberg/terraform-provider-snowflake/blob/main/pkg/resources/role.go#L15
The simple update here might be to remove above validation and let this fail in the Snowflake layer making this consistent with processing of other identifiers

That makes sense to me

We're replicating our role names over from azure active directory. Because we have many existing groups that are already managed and governed, we cannot simply change the names of the roles to avoid these characters. This has been open for over a year now. Is it on the backlog?

We are closing this issue as part of a cleanup described in announcement. If you believe that the issue is still valid in v0.89.0, please open a new ticket.


Saa 74 refactoring the model

Codecov Report
Base: 62.84% // Head: 71.68% // Increases project coverage by +8.83% :tada:

Coverage data is based on head (ad52d29) compared to base (7eef15c).
Patch coverage: 96.93% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##               main      #28      +/-   ##
============================================
+ Coverage     62.84%   71.68%   +8.83%
- Complexity      147      165      +18
============================================
  Files            39       39
  Lines           611      611
  Branches          2        2
============================================
+ Hits            384      438      +54
+ Misses          226      172      -54
  Partials          1        1

Impacted Files
Coverage Δ

.../hmppsactivitiesmanagementapi/entity/Attendance.kt
0.00% <0.00%> (ø)

.../hmppsactivitiesmanagementapi/entity/Allocation.kt
94.44% <66.66%> (ø)

...ctivitiesmanagementapi/entity/ScheduledInstance.kt
92.30% <66.66%> (ø)

...ps/hmppsactivitiesmanagementapi/entity/Activity.kt
100.00% <100.00%> (ø)

...activitiesmanagementapi/entity/ActivitySchedule.kt
95.45% <100.00%> (ø)

...sactivitiesmanagementapi/entity/PrisonerWaiting.kt
81.81% <100.00%> (ø)

...pps/hmppsactivitiesmanagementapi/model/Activity.kt
96.96% <100.00%> (ø)

.../hmppsactivitiesmanagementapi/model/ActivityPay.kt
94.11% <100.00%> (ø)

...psactivitiesmanagementapi/model/ActivityPayBand.kt
100.00% <100.00%> (ø)

...sactivitiesmanagementapi/model/ActivitySchedule.kt
100.00% <100.00%> (ø)

... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


useMutation cacheTime not work

Describe the bug
In my understanding, after setting cacheTime, the data should return the value  from the previous request, rather than undefined.
Your minimal, reproducible example
https://github.com/ShiChenCong/useMutation-cacheTime-demo
Steps to reproduce

reproduce repo
pnpm install
pnpm run dev
click button
log undefined
log [1,2,3]
click button again
log undefined(this step, In my understanding, should log [1,2,3] directly)
log [1,2,3]

Expected behavior
return previous value rather undefined
How often does this bug happen?
None
Screenshots or Videos
No response
Platform
macOS
TanStack Query version
4.24.10
TypeScript version
No response
Additional context
reproduce repo https://github.com/ShiChenCong/useMutation-cacheTime-demo, and mutation did not show in the devtool too.

no, that's just a misunderstanding of how useMutation works. Every time you call mutate by clicking the button, a new entry in the mutationCache is created. cacheTime just decides how long that entry will stay in the cache after you've unmounted the component

@TkDodo so, there is no way that mutation can cache data

it does cache, but each call to mutate is a different cache entry:
const { mutate } = useMutation({
  mutationFn: updateName
})

mutate('hello')
mutate('world')

creates two cache entries, one where the variables are hello and one where they are world. it's two different things, like as if you're switching between two cache keys.
I think I can better help if you're describing the problem you're trying to solve rather than asking a specific question about caching mutations

Thank you for your kindness , I’d like to cache data like useQuery in useMutation. when fetch data again ,return previous cache data first , and then fetch new data

okay but that's not how mutations work, sorry. Each invocation is a separate thing. Also, "I want to cache data in useMutation" is not your problem - it's a potential solution that you think will solve your problem...

So can't this effect be achieved?

@TkDodo After looking at some articles, I found that I misunderstood, when I want to cache data, I should use useQuery, even if it is the post。

@TkDodo  I'm trying to get a cache-able callback function returning a promise.  Is this supported by your library?  What is actually being cached here if not the data returned from the promise?
My use case is to call the mutateAsync with a value 'hello' and return the response of an api call,  the next time I call it with 'hello' I would expect to get the cached response.  Then when another value is passed 'goodbye' I would expect a different cache entry to be created and a new api call to be made with different response.
I'll illustrate:
const a = await mutateAsync('hello');
// makes a call and returns 'hi'
const b = await mutateAsync('goodbye');
// makes a call and returns 'bye'
const c = await mutateAsync('hello');
// finds entry in cache and returns 'hi'
If this is not the intended behavior then I am not sure what the purpose of the cache would be, am I missing anything?

mutations don't cache like that because mutations are imperative. You would sure get that behaviour if you use const data = await queryClient.fetchQuery(...), given that you pass a sufficient staleTime to it.
https://tanstack.com/query/v5/docs/reference/QueryClient#queryclientfetchquery

Thanks @TkDodo this looks like what I was incorrectly trying to do with useMutation.  I’ll go in that direction.  Out of curiosity I am wondering what is getting cached with the mutation.  Is it just a record of the calls?  If there’s further reading I’d be grateful.

the mutation is cached alongside its state (pending / success / error), it has callbacks that will still run even if the component was already unmounted when it finishes (needed for invalidation), you can read in other components with useMutationState etc


Use simple feature flags for extern definitions

This implements a simple version of feature flags for externs.
Syntax
extern def infixAdd(a: Int, b: Int): Int =
     js "${a} + ${b}"
     llvm (someEffektExpression)
     else "${a} + ${b}"

(Note: You might not want to use 'else' like this... Just an example.)
The old syntax should still work and is equivalent to having just an else clause.
This also exists for imports like this:
extern js """
...
"""
extern include js " ... "

Current behaviour
Current behaviour is:

Extern includes with non-matching flags are ignored
Extern defs without matching flag give out a warning during naming (for now; ideally: Check if it is actually used!)
Extern defs without matching flag currently might fail in the backends, since I do not know how to panic in the backends.
Using Effekt expressions might be weird in some cases (depending on backend), since this might break some assumptions of specific backends about externs. Especially: LLVM cannot handle them at all, since I don't know how to implement them there.

Future work

Output warnings only if we (transitively) use unsupported externs from main

Design decision reg. Effekt code in extern definitions:
Currently, the syntax is just (expr) (forced parentheses for parsing) instead of a string.
They (all of them) are passed through to the backends and transformed on the way, the backend can then choose.
Upside: The backends can do whatever they want with it.
Downside: This has to be handled in the backends, which is non-trivial at least in LLVM.
Alternative: Choose the "correct" extern definition in core. Then make the pseudo-extern definitions normal definitions.
(Pro/con as above but reversed)

I don't think I understand your proposal. Do you have an example of how this looks like?

Note to self: Add a simple phase on core to select & desugar extern defs (the backends can decide to use it or not)

Changed:

Now uses { stmt } instead of ( expr ) for effekt-defined externs; this makes the second point easier and seems more natural to me
Added a Core -> Core phase that selects the correct definitions and makes them "normal" definitions if they are defined using Effekt code

At some point we might want to move the warnings at
https://github.com/effekt-lang/effekt/blob/5646f6731f7983dcead702a6e60321f9cc9186c2/effekt/shared/src/main/scala/effekt/Namer.scala#L294-L304
and
https://github.com/effekt-lang/effekt/blob/5646f6731f7983dcead702a6e60321f9cc9186c2/effekt/shared/src/main/scala/effekt/Namer.scala#L385-L389
from Namer to a separate phase with more of those smaller checks.
Maybe there are also other checks that would fit there?

Tests are failing because of tests that use definitions like
https://github.com/effekt-lang/effekt/blob/5646f6731f7983dcead702a6e60321f9cc9186c2/examples/pos/capture/resources.effekt#L3
which will potentially never work on some backends.
Potentially some can be rewritten to use Effekt definitions instead (i.e., extern def ... = else { ... }).

else -> default

Maybe it would be better to move the Resolving further to the front after all.
I would still prefer it to be after Typing, but we could do it in Middleend on Typechecked.

The approach of adding it after Typer does not work properly either: The calling-convention issue hinges on the symbol type used in core.Transformer:
https://github.com/effekt-lang/effekt/blob/ee905df3182f203730cec00d6cffd3472b84cbdb/effekt/shared/src/main/scala/effekt/core/Transformer.scala#L635-L638

I reviewed the Scala source changes and they look mostly good to me. I only have a few remarks:

https://github.com/effekt-lang/effekt/pull/427#discussion_r1572385267
https://github.com/effekt-lang/effekt/pull/427#discussion_r1572605230 (and for other backends)
https://github.com/effekt-lang/effekt/pull/427#discussion_r1572603819

(interpreted that as approval)


Compatibility with Dehydration mod.

When using a flask on a puddle it isn't disappearing like when using a glass bottle.

https://github.com/Globox1997/Dehydration/issues/24#issuecomment-816779531


Small grammar fix

Changes "code of conducts" to "codes of conduct"

We posted an update here: http://todogroup.org/blog/followup-open-code-of-conduct/

@caniszczyk So in other words, TODO is dead. Good.


Connect-Ippssession using Managed Identity

Hello,
We use the Security and Compliance PowerShell module (part of EXO) in Azure Automation to automate retention policies.  We are currently connecting using the Connect-IPPSession using CBA authentication however we would like to start using managed identity if possible.  The connect-exchangeonline cmdlet currently can use the managed identity option.  Any idea when connect-ippssession will be able to use manage identity to connect?
Azure Automation will sunset the use of Run-As accounts in September and this is the only cmdlet we have left that uses the run-as account cert.  Rather than create a new enterprise application in AAD to support CBA, we would like to just use the managed identity.
Thanks,

@jachaohk, you can try asking at exocmdletpreview[at]service[dot]microsoft[dot]com.

@jachaohk Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


[OTHER] < Typo error in iOS development roadmap>

Which field of community (DevOps/Opensource/Web/Web3/Android/Devrel) you want to add, drop the links?
Hey Maintainers!
Opening an issue for fixing the typo error in iOS development roadmap, adding an image for reference, do check.
Happy to contribute, Thank You!

Hey Maintainers! I want to work on this issue; Please assign this to me to complete it!
Happy to contribute to our community!
Thanks!

Since this issue has been solved,


Filtering podla organizatora a podla typu akcie

Allow filtering by the organizer and by the action type (seminary, camp, etc.)
Maybe consider other filterable fields.

organizator tam je, action type zatial netreba.


design-doc: mirror standard

Description
This document presents the SuperchainERC20 Mirror Standard, which enables existing tokens deployed through OptimismMintableERC20 Factory in L2 (also called legacy tokens) to be interoperable without any liquidity migration process.

We will want to describe how to do withdrawals back to L1 using this standard

Closing this in favor of the convert approach


Initial base for AltFP

Define RISC-V version of BF16 format and behaviors

I am not sure the .DS_store file attached to this PR was intended.

Have you considered any synergy effects between this extension and the P (Packed SIMD) proposal? BF16 is definitely a good candidate for that, so this should probably be discussed in the spec somewhere. Especially with the mention of dot product operations

I also noticed the statements:  "Instruction design and definition. (This part has dependency on Zfh & RVV & EDIV.)" and "Additional vector extension/ EDIV extension operations;"

you left out ZHinx (or ZFinx, or both) as well as P-extension (in RV64, at least).
in the interests of not "boiling the ocean" I would think it would be prudent to neither rely on nor consider defining anything that depends on RVV for now - and especially not EDIV which is not official in any sense. That should be a separate TG.
I am guessing that you just want to make sure that this might be extended_to / supportable_by a vector implementation - and that you're not trying to define those here - but that should be clear and explicit.

Typo: in the "Extension rationale" you say:
However, it avoids double rounding can occur
which obviously should be
However, it avoids double rounding that can occur

Also It is up to software to ->elimiante<- such sources of error if this is important to the application.

NaNs
You say you're supporting signaling Nans, but no operation will produce them.
Does that mean if one is loaded into a register, despite not being produced by an fp16 op,
and subsequently used by an fp16 op, it will be treated as a quiet NaN? (i.e. no trap)
I actually don't know what IEEE says about that particular case.
denorms
The charter mentions "Handling flush-to-zero for IEEE types and BF16 type." but the format doc simply states that all denormals are flushed to zero. So are you making flush-to-zero configurable? OR is this strictly how you handle conversions for IEEE denormals to bf16, or something else?
Also: you say "Furthermore, with BFloat16’s relatively large exponent range, subnormals add little value."
except there is only a 5bit exponent field, smaller than any other format listed. How can you call this "large"?
Exceptions:
the statement is confusing in that  the first sentence mentions exceptions, and the second status, with nothing that connects them. Specifically, it doesn't mention that RISC-V never takes an exception for an operation regardless or result or input operand, and so (insert second sentence here)
In the Policies doc, you say:
"higher effective storage bandwidth - Two BFloat16 operands can be transferred at the same rate as one FP32
higher  computational  throughput  -  Two BFloat16 multiplies can be performed with less logic than one FP32"
This implies that you're using packed SIMD. IS that being proposed at all? Otherwise, you highly unlikely to get any better throughput, and you can get better load store bandwidth, but you need to add extra pack/unpack operations, which decreases throughput, at least.

Thanks Allen,
The intention is for this to be the base behavior for BF16 in all of
RISC-V. This allows results to be shared between, for example, scalar
floating-point and vector. I don't think that the P-extension includes
floating-point. In any case, I think BF16 will see more use in the
V-extension as it is commonly used in high-performance matrix operations.
I'll add the missing references. Based on Krste's comments in another
thread, it seems that EDIV is no longer under consideration and there are
newer better approaches that will be proposed for vector-based matrix
operations.
Thanks,
Ken
On Fri, Mar 4, 2022 at 11:39 AM Allen Baum @.***> wrote:

I also noticed the statements: "Instruction design and definition. (This
part has dependency on Zfh & RVV & EDIV.)" and "Additional vector
extension/ EDIV extension operations;"

you left out ZHinx (or ZFinx, or both) as well as P-extension (in
RV64, at least).
in the interests of not "boiling the ocean" I would think it would
be prudent to neither rely on nor consider defining anything that depends
on RVV for now - and especially not EDIV which is not official in any
sense. That should be a separate TG.
I am guessing that you just want to make sure that this might be
extended_to / supportable_by a vector implementation - and that you're not
trying to define those here - but that should be clear and explicit.

—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-alt-fp/pull/2#issuecomment-1059378426,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI6QBRUDKMX6MUFB5KVHN2TU6JDGHANCNFSM5PLM7QJA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

On Fri, Mar 4, 2022 at 12:15 PM Allen Baum @.***> wrote:

NaNs
You say you're supporting signaling Nans, but no operation will produce
them.

[KAD] Yes, IEEE-754 states that no operation will produce an SNaN. They can
be provided by the user, for example as uninitialized data.

Does that mean if one is loaded into a register, despite not being
produced by an fp16 op,
and subsequently used by an fp16 op, it will be treated as a quiet NaN?
(i.e. no trap)
I actually don't know what IEEE says about that particular case.

[KAD]  IEEE Std 754™-2019  says that "any general-computational operation
on a signaling NaN" causes an invalid operation. We will follow this
behavior.

denorms
The charter mentions "Handling flush-to-zero for IEEE types and BF16
type." but the format doc simply states that all denormals are flushed to
zero. So are you making flush-to-zero configurable? OR is this strictly how
you handle conversions for IEEE denormals to bf16, or something else?

[KAD] The proposal is for subnormal BF16 inputs to be treated as properly
signed zeros and for subnormal outputs to be flushed to a properly signed
zero. There is no configuration.

Also: you say "Furthermore, with BFloat16’s relatively large exponent
range, subnormals add little value."
except there is only a 5bit exponent field, smaller than any other format
listed. How can you call this "large"?

[KAD] That was a typo on my part. BFloat16 uses the same 8-bit exponent as
FP32.

Exceptions:
the statement is confusing in that the first sentence mentions exceptions,
and the second status, with nothing that connects them. Specifically, it
doesn't mention that RISC-V never takes an exception for an operation
regardless or result or input operand, and so (insert second sentence here)

[KAD] I'm not sure what text you are talking about. Are you conflating
exceptions with exceptions with traps?  RISC-V reports floating-point
exceptions via the exception flags. It does not take traps due to
floating-point exceptions.

In the Policies doc, you say:
"higher effective storage bandwidth - Two BFloat16 operands can be
transferred at the same rate as one FP32
higher computational throughput - Two BFloat16 multiplies can be performed
with less logic than one FP32"
This implies that you're using packed SIMD. IS that being proposed at all?
Otherwise, you highly unlikely to get any better throughput, and you can
get better load store bandwidth, but you need to add extra pack/unpack
operations, which decreases throughput, at least.

[KAD] Typically, BF16 is used in widening dot product operations - this is
where they earn their keep. However, I was asked to address the base part
first. Once we have consensus on the base we can move to instructions.

Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-alt-fp/pull/2#issuecomment-1059404296,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI6QBRVXYTVEZSVWASPWODDU6JHL3ANCNFSM5PLM7QJA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Flushing subnormals to zero should be a property of an operation, not a property of the format. The format can clearly define what the subnormal values mean, and specific operations can choose to interpret them as zero and flush outputs to zero. This approach better separates concerns.
Some other architectures’ BF16 instructions only flush subnormals in some instructions (e.g. dot product flushes to zero, but conversion to and from FP32 does not, since flushing in the latter case doesn’t buy you anything). We don’t need to wade into that debate today, but we do need to preserve the possibility of having that debate by removing the flush-to-zero mandate from the format definition.

Thanks Andrew,
I agree that it doesn't necessarily make sense to flush to zero on
conversions and that there might be other instructions where flushing
doesn't make sense.
I put the flush-to-zero as part of the format because I was told that we
need to agree on the base before we can move forward on discussing
instructions. I will revise the wording to indicate that such flushing is
the general intention but for a limited set of instructions (which are TBD)
it might not be the rule.
Ken
On Fri, Mar 4, 2022 at 3:46 PM Andrew Waterman @.***>
wrote:

Flushing subnormals to zero should be a property of an operation, not a
property of the format. The format can clearly define what the subnormal
values mean, and specific operations can choose to interpret them as zero
and flush outputs to zero. This approach better separates concerns.
Some other architectures’ BF16 instructions only flush subnormals in some
instructions (e.g. dot product flushes to zero, but conversion to and from
FP32 does not, since flushing in the latter case doesn’t buy you anything).
We don’t need to wade into that debate today, but we do need to preserve
the possibility of having that debate by removing the flush-to-zero mandate
from the format definition.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-alt-fp/pull/2#issuecomment-1059554453,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI6QBRW2COWAV6W2TAJXNXDU6KAB7ANCNFSM5PLM7QJA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Apologies to all - my comments were referencing an old document that I
managed to stumble on, not the charter document.
On Fri, Mar 4, 2022 at 1:46 PM Andrew Waterman @.***>
wrote:

Flushing subnormals to zero should be a property of an operation, not a
property of the format. The format can clearly define what the subnormal
values mean, and specific operations can choose to interpret them as zero
and flush outputs to zero. This approach better separates concerns.
Some other architectures’ BF16 instructions only flush subnormals in some
instructions (e.g. dot product flushes to zero, but conversion to and from
FP32 does not, since flushing in the latter case doesn’t buy you anything).
We don’t need to wade into that debate today, but we do need to preserve
the possibility of having that debate by removing the flush-to-zero mandate
from the format definition.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-alt-fp/pull/2#issuecomment-1059554453,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJTVJA7UQIADFIRKPO3U6KAB7ANCNFSM5PLM7QJA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID:
@.***>

This might not be in the scope for this extension, but have you considered unum/posit?

+...Signalling NaNs are provided as input data since no computational
instruction will ever produce this kind of a NaN.
I would add ony to this:
+...Signalling NaNs are provided as input data only* since no
computational instruction will ever produce this kind of a NaN.
+...Operating on a Quiet NaN usually does not cause an exception.
The word "usually" is uncommonly vague here.
Does that mean it depends on the op, the other bits in the Nan
operand, the value of the other operand, the rounding more, the phase
of the moon, or what?
On Mon, Apr 4, 2022 at 3:22 PM Nicolas Brunie @.***>
wrote:

@.**** commented on this pull request.
In doc/riscv-bfloat16-format.adoc
https://github.com/riscv/riscv-alt-fp/pull/2#discussion_r842183937:

+NaN stands for Not a Number. These are provided as the result of an operation when it cannot be represented
+as a number or infinity. For example, performing the square root of -1 will result in a NaN because
+there is no real number that can represent the result. NaNs can also be used as inputs.
+
+There are two types of NaNs: signalling and quiet. Signalling NaNs are provided as input data since no computational instruction will ever produce this kind of a NaN. Operating on a Signalling NaN will produce an invalid operation exception. Operating on a Quiet NaN usually does not cause an exception.
+
+NaNs include a sign bit, but the bit has no meaning.
+
+NaNs are important for keeping meaningless results from being operated upon. It is best to retain them. As IEEE allows, operations should return the canonical NaN rather than be required to propagate the payload.
+
+===  Rounding Modes:
+In general, the default IEEE rounding mode (round to nearest, ties to even) works for arithmetic cases. There are some special cases where a particular instruction benefits from a different rounding mode (e.g., convert to integer, widening multiply-accumulate) - we can address this on those specific instructions.
+
+=== Handling exceptions
+Default exception handling, as defined by IEEE, is a simple and effective approach to producing results in exceptional cases. For the coder to be able to see what has happened, and take further action if needed, the BFloat16 instructions need to set floating-point exception flags the same way as all other floating-point instructions in RISC-V.
I am concerned that another floating-point extension may be introduced
with a different way of managing FP exception flags, making "as all other
floating-point instructions ..." missleading. So mentioning explicitly that
we intend to managed them as extension F and D (and Q), clarifies things if
such an extension should appear at some point. I agree that the use of such
remark may be limited.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-alt-fp/pull/2#discussion_r842183937, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJU2RMD2GLYSIXI4MALVDNTRNANCNFSM5PLM7QJA
.
You are receiving this because you commented.Message ID:
@.***>

Hi Torbjørn,
You are correct in that this is out of scope for this BFloat16 extension.
However, it is not out of scope for the broader AltFP group. So,
unums/posits could be considered for subsequent extensions under AltFP.
-Ken
On Mon, Apr 4, 2022 at 8:45 PM Torbjørn Viem Ness @.***>
wrote:

This might not be in the scope for this extension, but have you considered
unum/posit?
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-alt-fp/pull/2#issuecomment-1088186717,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI6QBRX2YRODVBS6SBBW4LDVDOLLLANCNFSM5PLM7QJA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Thanks Allen,
I agree, the sentence is missing an "only". I'll add it in.
I'll add some more text to generally explain where an input QNaN could
cause an exception with more details in subsequent text.
Thanks,
Ken
On Mon, Apr 4, 2022 at 11:42 PM Allen Baum @.***> wrote:

+...Signalling NaNs are provided as input data since no computational
instruction will ever produce this kind of a NaN.
I would add ony to this:
+...Signalling NaNs are provided as input data only* since no
computational instruction will ever produce this kind of a NaN.
+...Operating on a Quiet NaN usually does not cause an exception.
The word "usually" is uncommonly vague here.
Does that mean it depends on the op, the other bits in the Nan
operand, the value of the other operand, the rounding more, the phase
of the moon, or what?
On Mon, Apr 4, 2022 at 3:22 PM Nicolas Brunie @.***>
wrote:

@.**** commented on this pull request.
In doc/riscv-bfloat16-format.adoc
https://github.com/riscv/riscv-alt-fp/pull/2#discussion_r842183937:

+NaN stands for Not a Number. These are provided as the result of an
operation when it cannot be represented
+as a number or infinity. For example, performing the square root of -1
will result in a NaN because
+there is no real number that can represent the result. NaNs can also be
used as inputs.
+
+There are two types of NaNs: signalling and quiet. Signalling NaNs are
provided as input data since no computational instruction will ever produce
this kind of a NaN. Operating on a Signalling NaN will produce an invalid
operation exception. Operating on a Quiet NaN usually does not cause an
exception.
+
+NaNs include a sign bit, but the bit has no meaning.
+
+NaNs are important for keeping meaningless results from being operated
upon. It is best to retain them. As IEEE allows, operations should return
the canonical NaN rather than be required to propagate the payload.
+
+=== Rounding Modes:
+In general, the default IEEE rounding mode (round to nearest, ties to
even) works for arithmetic cases. There are some special cases where a
particular instruction benefits from a different rounding mode (e.g.,
convert to integer, widening multiply-accumulate) - we can address this on
those specific instructions.
+
+=== Handling exceptions
+Default exception handling, as defined by IEEE, is a simple and
effective approach to producing results in exceptional cases. For the coder
to be able to see what has happened, and take further action if needed, the
BFloat16 instructions need to set floating-point exception flags the same
way as all other floating-point instructions in RISC-V.
I am concerned that another floating-point extension may be introduced
with a different way of managing FP exception flags, making "as all other
floating-point instructions ..." missleading. So mentioning explicitly
that
we intend to managed them as extension F and D (and Q), clarifies things
if
such an extension should appear at some point. I agree that the use of
such
remark may be limited.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-alt-fp/pull/2#discussion_r842183937, or
unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AHPXVJU2RMD2GLYSIXI4MALVDNTRNANCNFSM5PLM7QJA
.
You are receiving this because you commented.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-alt-fp/pull/2#issuecomment-1088262446,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI6QBRVNFFSFGDLWCLVGAA3VDPADTANCNFSM5PLM7QJA
.
You are receiving this because you authored the thread.Message ID:
@.***>


Missing fix in published 1.0.4

It seems like the fix for infinitly growing of header Last-Event-Id (#3) (commit bf20a1a7e6d8ac9f05b80cec6bdfd1e5fb2cc213) is missing in the published NuGet package version 1.0.4

Uploaded a repackaged 1.0.5.


Allow the user to pass iss and launch_token directly to provider_ehr_launch as keyword arguments

cc: @Vaibhavdixit02 @andreasnoack

https://github.com/JuliaRegistries/General/pull/40467


Mounting issues

On occasion mounts do not persist or they fail between commands

#443 solves mounting issues that have been found but more issues that cause mounts to fail will be posted as new issues (more specific).


Draw a diagram of the pipeline and add to the repo

Maybe using mermaid-js, which is supported in the markdown of GitHub?

Some useful images.

Did this in app.diagram.net

Alternative


[$250]  Android - Split - Keyboard opens and closes when tapping on split input of the last user

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.77-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4585180
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-internal team
Action Performed:
Precondition:

Samsung keyboard is used.

Launch New Expensify app.
Go to FAB > Split expense > Manual.
Enter amount > Next.
Select many participants so that the confirmation page is scrollable.
On confirmation page, tap on the split amount input next to the last user in the list.

Expected Result:
Keyboard will open without issue.
Actual Result:
Keyboard opens and closes when tapping on the split amount input of the last user in the list.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/115492554/1d58adb2-bd3b-467e-8579-d0bc4443886d

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01fd23cc3f2ade28b9
Upwork Job ID:<PHONE_NUMBER>300827136
Last Price Increase: 2024-05-31
Automatic offers:

dukenv0307 | Reviewer | 102596353
tienifr | Contributor | 102596356

Issue OwnerCurrent Issue Owner: @dukenv0307

We think this issue might be related to the #vip-split.

Hello,
I believe the problem described involves the Samsung keyboard on Android devices where it opens and closes when tapping on the split amount input of the last user in a scrollable list in the Expensify app. This issue is reproducible in both staging and production environments.

let me take the job up, if you may

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~017e81b8541352d771

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~017e81b8541352d771

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~017e81b8541352d771

Proposal
The issue is that when using the Samsung keyboard on the Android version of the New Expensify app, the keyboard opens and closes immediately when tapping on the split amount input field next to the last user in the list on the confirmation page.
Root Cause
The root cause is likely due to a conflict between the UI elements and the keyboard behavior when the screen is scrollable. Specifically, tapping on the input field near the bottom of a scrollable view might cause the view to adjust, resulting in the keyboard closing unexpectedly.
Proposed Changes
To solve the problem, the following changes are recommended:

Adjust Viewport and Scroll Behavior
Ensure that the viewport and scroll behavior are properly adjusted when the input field is focused.

// Adjust the viewport and scroll behavior
function handleInputFocus(event) {
    const inputField = event.target;
    // Scroll the view to ensure the input field is fully visible
    scrollView.scrollTo({
        y: inputField.offsetTop - keyboardHeight,
        animated: true,
    });
    // Ensure the keyboard remains open
    inputField.focus();
}

Prevent Keyboard from Closing
Implement logic to prevent the keyboard from closing when the input field is focused.

// Prevent the keyboard from closing
inputField.addEventListener('focus', handleInputFocus);

Update the Confirmation Page Layout
Ensure that the layout of the confirmation page is properly adjusted to accommodate the keyboard when it is opened.

// Adjust the layout of the confirmation page
<ScrollView contentContainerStyle={styles.scrollViewContent}>
    {participants.map((participant, index) => (
        <View key={participant.id} style={styles.participantRow}>
            <TextInput
                style={styles.splitInput}
                onFocus={handleInputFocus}
                placeholder="Enter amount"
                value={participant.amount}
                onChangeText={(text) => updateParticipantAmount(index, text)}
            />
        </View>
    ))}
</ScrollView>

Test with Samsung Keyboard
Ensure that the changes are tested specifically with the Samsung keyboard to verify that the issue is resolved.

// Test with Samsung keyboard
function testWithSamsungKeyboard() {
    // Simulate the conditions of the issue
    simulateKeyboardOpen();
    // Verify that the keyboard remains open
    assert(keyboardIsOpen());
}

Expected Result
When tapping on the split amount input field next to the last user in the list, the keyboard should open without any issues and remain open, allowing the user to input the split amount.
By implementing these changes, the user experience on the Android version of the New Expensify app will be improved, ensuring that the keyboard behavior is consistent and reliable when entering split amounts for the last user in a scrollable list.

@dukenv0307, can you please review the proposal above? Thanks!

@dukenv0307, please review the new proposal above. Thanks!

@dukenv0307, can you please share an update? Thanks!

Payment summary:
@tienifr requires payment automatic offer (Contributor) $250
@dukenv0307 requires payment automatic offer (Reviewer) $250

The payments were processed in Upwork. All set.


Add VS Code settings

Feature
Maybe I missed it, but is there a way to add VS Code user settings like:
{
  "AykutSarac.jsoncrack-vscode": {
    "lightmode": true
  }
}

I'm specifically looking to use "expand": false in VS Code so the nodes all render the same width, like how the editor works. Thanks!
Alternative solutions or implementations
No response
Other context
No response

One other suggestion would be to also add an orientation switch like top-down, bottom-up, left-right, right-left

Hi, lightmode is now supported and changed through user theme. Hoping to bring rotate layout and similar features soon.


Any way to make this work with mutable data structures?

psygnal version: 0.9.5
Python version: 3.11.6
Operating System: Ubuntu 22.04.3

Description
After connecting events to mutable types, I would expect that events are called when they are mutated.
What I Did
from psygnal import EventedModel

class MyModel(EventedModel):
    data: dict = {}
    values: list[int]

model = MyModel(data={'foo': 'bar'}, values=[1, 2, 3])
model.events.data.connect(lambda v: print(f"updated data: {v}"))
model.events.values.connect(lambda v: print(f"updated values: {v}"))

model.data['test'] = 'fail'
model.values.append(4)

This doesn't print anything.

you would need to use an evented container like psygnal.containers.EventedList.  The reason is that when you set the attribute of a field directly model.field = thing, it goes through the __setattr__ of the model.  When you use model.values.append (or any other thing that calls model.values.__setitem__) then there's no way for the evented model to know about it.
You would need to do something like this:
from psygnal import EventedModel
from psygnal.containers import EventedList

class MyModel(EventedModel):
    data: dict = {}
    values: EventedList[int]

however, on a quick try, I'm noticing a couple issues at the moment with using an unmodified EventedList as a hint for a pydantic model (both v1 and v2).  So, let me have a closer look tomorrow.

also related... even once it does work as a field (which it should)... you'll have the issue of nested events.  That is, since an evented list has many events (not just a single change event), it's not immediately clear how one should access them on the model.events field itself.  This was being addressed in https://github.com/pyapp-kit/psygnal/pull/169 ... but it hasn't seen action in a while.  Let me know if you specifically need the nesting for your use case, or if using model.values.events... would be sufficient in this case

After this has seen some work but no answer from OP so far, I thought I'd chime in:
I would love to see #169 coming back to life, because it could enable undo/redo implementations by using the memento or state-diff patterns. Then use EventedModel.update() for in-place updates from the saved states.

thanks for chiming in @ndxmrb, it definitely helps to know what features people would like to see implemented!  I'll look at reviving that PR, as I'm also still interested in using it myself


Update project 2 markdown file

First draft of project 2 description.
Please give advice.
@MengfeiJiang @pttzty

#7

Coverage remained the same at 3.846% when pulling 6ee43d30e44da4ff8fe20d726d15787c4f8e8d74 on changsiyao:dev into e880158544056df4c1b0954ba9983ec2597e0cb4 on berkeley-stat222:master.

Update pull request for CI and travis updates to pass checks.
Now passing checks and coverage remains stable.

If you can arrive a few minutes early to class on Monday, I will help you merge this.  I will want you to rebase it off master first and I can walk you through the process then.

Coverage remained the same at 22.162% when pulling 61ae15257865b16c402cc6d3d4da8e9e0c0d1b32 on changsiyao:dev into aefcb8fe1a255c1e3722451523eccb177f38b5a3 on berkeley-stat222:master.

@jarrodmillman I think I have rebased and force pushed my file. Can you check if I have done the right thing?
Thanks!

Coverage remained the same at 22.162% when pulling 54facedd654f286e00508f0224be20e7b48c27e3 on changsiyao:dev into aefcb8fe1a255c1e3722451523eccb177f38b5a3 on berkeley-stat222:master.

Coverage remained the same at 22.162% when pulling c546a1df3cbf6ca2b7836706876cc105ce318536 on changsiyao:dev into baaa9e566ccc310df6c8d3b2bebfd426cfd12721 on berkeley-stat222:master.


turn statically known erroneous code into a warning and an unconditional panic

To prevent breaking changes, the compiler should turn statically known erroneous code (that previously wasn't a compile-time error) into an unconditional runtime-panic and issue a warning.
Rendered

cc @rust-lang/compiler

I certainly agree with the sentiment of this RFC, but I think I prefer the "constant evaluation does not influence code generation" alternative. That is, I think the fact that we sometimes constant fold expressions is not something which should be observable to an end user (except via a warning) -- it's just a runtime optimization for better performance.

It's probably worth adding to the RFC a definition of "constant evaluation" vs "runtime evaluation" contexts. I think that the language has a pretty clear distinction, though:

the initializer of a constant const foo: ty = EXPR or static foo: ty = EXPR
the size of an array [T; EXPR]

The body of a const fn is sort of interesting. I think my preference is that the body is treated as a constant evaluation context, and hence an error is reported, even if the const fn is never called from a constant initializer -- so long as the overflow can be observed without knowing the values for these arguments. Implementing this, of course, will require a more sophisticated handling of constants (which we need anyhow). Since const fn is feature-gated we have time to play with this. Similar concerns will apply to generic and associated constants of course. I think from the POV of this RFC we can leave this as an "unresolved question", or at least as an open bug that will not be impl'd immediately.

I think the fact that we sometimes constant fold expressions is not something which should be observable to an end user (except via a warning) -- it's just a runtime optimization for better performance.

I mostly agree. Rust has debug_assert and compiler-inserted debug assertions in debug builds or with the -C debug-assertions flags enabled. These are disabled by default in release mode because they have a runtime-penalty. In case it is statically known that such an assertion would be triggered if it were enabled, then it should also be there in release mode, since the code already compiles to implementation defined machine code (As far as I know Rust makes no guarantees about code containing overflow or overbitshift except that it still is memory safe).

@oli-obk
The overflow RFC states that, when overflow checking is not enabled (i.e., in release builds), "erroneous operations will produce a value".  I do not believe there is any provision in the RFC for us to cause a panic to occur unless overflow checks have been enabled. (Earlier drafts did explicitly permit this, however.)
My main concern here is causing code to break that used to work (because it relied on the integer overflow fallback semantics). I realize that such code is "officially" buggy, but it costs us nothing (in terms of maintenance burden, etc) to simply keep producing the same code we would have produced had the expression not been constant, and it will probably prevent some code from randomly panic'ing after a rustup. (Issuing a warning is nice, though.)

Implementations are permitted to check for overflow at any time (statically or dynamically)
any failure to do so can be considered a bug, and hence can be flagged by a static/dynamic analysis tools as an error.

These two statements sound to me as if it were legal to actually cause a compiler-error when such a bug is encountered. While this would be my preferred handling of such situations, I can see (and accept without argument) how such breaking changes should not happen suddenly after a minor compiler-upgrade.
My issue is that a library user needs to opt-in to all of the overflow panics or none when compiling the library, while the default could be "all statically proven overflow panics".

It's probably worth adding to the RFC a definition of "constant evaluation" vs "runtime evaluation" contexts.

done

I think from the POV of this RFC we can leave this as an "unresolved question", or at least as an open bug that will not be impl'd immediately.

added an unresolved question about const fn.

This is also relevant for our erroring on transmute.

Pre-execution constants (array lengths, enum variant discriminants, const, static, and probably some places I've missed) must have a result after compilation is over. Therefore, panics and UB here must occur during compilation (as controlled compiler errors, not rustc panicking/UB-ing, of course). There should not be any question about that.
The more interesting case is panics/UB in ordinary code. If the code isn't actually reached at runtime, this can be completely fine, and may occur as a result of macros or potentially generics, e.g.
fn elts_per_page<T>() -> usize {
    if mem::size_of::<T>() == 0 {
        usize::MAX
    } else {
        4096 / mem::size_of::<T>()
    }
}

or a similar version of using macros. It would be very annoying if overly-eager evaluation makes that a compile-time error. Note that this is what currently happens with transmute: transmuting between types of different sizes is obviously UB, but it currently causes a trans-time error. The attempts to go down this path with SIMD (#1199) weren't particularly well-received. Polymorphic recursion is somewhat similar too, but recursion limit issues are always non-compositional.

It would be very annoying if overly-eager evaluation makes that a compile-time error.

it wouldn't occur, If we enable if/else in the constant evaluator, only the true branch will be evaluated.
if you wrapped the else branch in a const-fn that would be a different issue though, as that function should also be evaluated on its own.

@oli-obk

it wouldn't occur, If we enable if/else in the constant evaluator, only the true branch will be evaluated.

This is of course specific to @arielb1's example. There can easily be conditions which are always false, though we cannot know it statically. But regardless the intent of this RFC is that such code would be accepted, though it would get a warning.

@oli-obk can you adjust the RFC to the alternative of "do not influence codegen"? I still think that is the preferred alternative. (After some discussion with others on the @rust-lang/lang team, I believe they are largely in agreement, though I'm not 100% sure -- if others disagree, please say so.)

But regardless the intent of this RFC is that such code would be accepted, though it would get a warning, right?

The code would get a warning currently (if there were a const fn sizeof), but an improved const evaluator (that can evaluate if) would again remove the warning.

can you adjust the RFC to the alternative of "do not influence codegen"?

sure thing, if the preference ever changes, it'll be as trivial as turning the lint into forbid

updated PR, should I squash?

@oli-obk I think the lang team is more inclined to accept the "constant evaluation does not influence code generation" Alternative.
Would you be willing to revise the RFC text so that that alternative becomes the plan of record?
(If you are not willing, please let us know, so that we can figure out next steps in that scenario.)

updated title and message at the top

Hear ye, hear ye. This RFC is entering final comment period.

These warnings should always be displayed. I don't see a reason to ever allow them. Is there any equivalent to forbid that enforces that a warning can't be changed to allow, but only to deny/forbid?

@oli-obk: I'd be careful going down that road. When I was younger and dumber, my response to a warning I couldn't silence wasn't "Hmm. Why shouldn't this be silenced?" but, instead, a burst of annoyance and, in a burst of semi-spiteful productivity, a wrapper which added 2>&1 | grep -v 'warning text' (or equivalent) and possibly # Silence warning made unsilenceable by incompetent devs.

At the very least, I'd make it very clear that it's some kind of deprecation warning and, thus, it can't be silenced because it's really an error that's just cutting you some slack by giving you some catch-up time.

I'll make sure to add to the warning message that this is in fact an erroneous but well-defined situation (see #1237 for details on the well-defined-ness).

I just tried to implement this RFC... And hit a curious issue. There's actually no const evaluation happening until the lint-passes run: https://github.com/rust-lang/rust/blob/master/src/librustc_lint/builtin.rs#L174-L178 Is it really a breaking change to improve a lint? IIRC #1105 says that if you could have prevented the situation by changing a lint-level or using UFCs, the breaking change is fine.
The more we improve the const evaluator, the more time this lint will end up using, especially in the non-error case. It would be better to actually remove the lint and fold those const evaluable expressions so llvm has to do less work.
A few things could be done here, but the only true way forward is to wait for MIR, port const_eval to MIR, fold all constant expressions in MIR and report errors/warnings during the folding, and finally remove the lint as it is now duplication.

@oli-obk
The thing here is that various places in rustc evaluate const-exprs, and the first place that fails reports the error.
The first place that evaluates const-exprs is typeck in type-level expressions (I am using -Z treat-err-as-bug to pinpoint the errors):
fn main() {
    let x: Option<[u8; 1/0]> = None;
}

Error:
$ RUST_BACKTRACE=1 rustc -Z treat-err-as-bug foo.rs
foo.rs:2:24: 3:27 error: internal compiler error: array length constant evaluation error: attempted to divide by zero
foo.rs:2     let x: Option<[u8; 1/0]> = None;
                                ^~~
<snip>
   7:     0x7fa1094ad367 - session::Session::span_err_with_code::h9bb47c81beb44685kGr
   8:     0x7fa10ae56eff - astconv::ast_ty_to_ty::he0a6db80093cc897Z8v
   9:     0x7fa10aea5eee - astconv::ast_ty_arg_to_ty::h4b63c64f7c8feadc7Zv
  10:     0x7fa10aea5b56 - vec::Vec<T>.FromIterator<T>::from_iter::h7691401690500070843
  11:     0x7fa10aea2af7 - astconv::convert_angle_bracketed_parameters::hd78cf94c1c4a6735K2u
  12:     0x7fa10ae55757 - astconv::ast_path_substs_for_ty::h5630483a91fb604bXLu
  13:     0x7fa10aeaaa3f - astconv::ast_path_to_ty::he16254360eff8a4aJrv
  14:     0x7fa10ae97b5f - astconv::finish_resolving_def_to_ty::h548b2bf1a94ff87fb7v
  15:     0x7fa10ae575b4 - astconv::ast_ty_to_ty::he0a6db80093cc897Z8v
  16:     0x7fa10ae494ea - check::GatherLocalsVisitor<'a, 'tcx>.Visitor<'tcx>::visit_local::h639702fd67237370ESn
  17:     0x7fa10ae2cf45 - check::check_fn::h3fcdd81a07ce16bbrZn
  18:     0x7fa10ae44e98 - check::check_bare_fn::h12de780dac587f1d1On
  19:     0x7fa10ae42dc2 - check::check_item_body::h481313b4e0932aa5Ufo
  20:     0x7fa10ae44ab4 - check::check_item_types::h4ee0d91dc68ee41byMn
  21:     0x7fa10af006f9 - check_crate::hed55c46ad8cec60dw8C
  22:     0x7fa10bbc2c9c - driver::phase_3_run_analysis_passes::he94da8ae9035992aGGa

The second place is const_check, which evaluates divisions:
fn main() {
    let x = (0u8-1u8)/1;
}

Error:
$ RUST_BACKTRACE=1 rustc -Z treat-err-as-bug foo.rs
foo.rs:2:14: 2:21 error: internal compiler error: attempted to sub with overflow in a constant expression
foo.rs:2     let x = (0u8-1u8)/1;
                      ^~~~~~~
<snip>
   7:     0x7f0e14929367 - session::Session::span_err_with_code::h9bb47c81beb44685kGr
   8:     0x7f0e14a6dd4c - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_expr::h6d2359b0311a538foke
   9:     0x7f0e14a6f893 - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_block::h7c5fa31839a19fd6bie
  10:     0x7f0e14a6e8e0 - middle::check_const::CheckCrateVisitor<'a, 'tcx>::fn_like::closure.81125
  11:     0x7f0e14a6e6d1 - middle::check_const::CheckCrateVisitor<'a, 'tcx>::fn_like::he96168b2665b6768B1d
  12:     0x7f0e14a7412f - visit::walk_item::h13051231923695214486
  13:     0x7f0e14a73d5e - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_item::heaafb7200b0245caUbe
  14:     0x7f0e14a77a0a - middle::check_const::check_crate::hd10c1c21df338568sPe
  15:     0x7f0e1703ecdb - driver::phase_3_run_analysis_passes::he94da8ae9035992aGGa

Third in line is the type_limits lint, which only cares about the value of shifts:
fn main() {
    let _x = 1<<(0u8-1u8);
    let _y = 1<<64;
}

Error:
$ RUST_BACKTRACE=1 rustc -Z treat-err-as-bug foo.rs
foo.rs:3:14: 3:19 error: internal compiler error: bitshift exceeds the type's number of bits, #[deny(exceeding_bitshifts)] on by default
foo.rs:3     let _y = 1<<64;
                      ^~~~~
<snip>
  10:     0x7febf9dfc424 - lint::context::Context<'a, 'tcx>::span_lint::h2ffdb047ae2ae95bNht
  11:     0x7febfadfd0cd - builtin::TypeLimits.LintPass::check_expr::h4be59f8968b266922ea
  12:     0x7febf9e01ed6 - lint::context::Context<'a, 'tcx>.Visitor<'v>::visit_expr::h9e77c18ecd8829fd2tt
  13:     0x7febf9e05d9e - lint::context::Context<'a, 'tcx>.Visitor<'v>::visit_block::h0d243a925ef41f59oHt
  14:     0x7febf9e0278a - lint::context::Context<'a, 'tcx>.Visitor<'v>::visit_fn::hd9ec7ea9d9ac70cc8vt
  15:     0x7febf9dfde24 - lint::context::Context<'a, 'tcx>::with_lint_attrs::h2026432032816296521
  16:     0x7febf9e02a2c - lint::context::Context<'a, 'tcx>.Visitor<'v>::visit_mod::hcb8a89207f3e5847aFt
  17:     0x7febf9e10944 - lint::context::check_crate::h206de34c06abf3109Yt
  18:     0x7febfc1427cc - driver::phase_3_run_analysis_passes::he94da8ae9035992aGGa

The last place that does constant evaluation is trans:
fn main() {
    let _ = 127u8+129u8;
}

Error
$ RUST_BACKTRACE=1 rustc -Z treat-err-as-bug foo.rs
foo.rs:2:14: 2:25 error: internal compiler error: attempted to add with overflow
foo.rs:2     let _x = 127u8+129u8;
                      ^~~~~~~~~~~
<snip>
   7:     0x7f547b7800f6 - session::Session::span_err::h7e3fb41450de8302CFr
   8:     0x7f547c623575 - trans::consts::const_expr_unadjusted::hdf9dedc40195dad4O4s
   9:     0x7f547c5cb0dc - trans::consts::const_expr::h0fc914963c16e320tOs
  10:     0x7f547c61fa7a - trans::consts::get_const_expr_as_global::h57188bb77ebc5316zLs
  11:     0x7f547c6365d3 - trans::expr::trans_into::h415bacc50d92798cpwA
  12:     0x7f547c6b74da - trans::_match::mk_binding_alloca::h17286627990888781114
  13:     0x7f547c5ad80e - trans::base::init_local::hfaa046e6df58977cVdh
  14:     0x7f547c5bd816 - trans::controlflow::trans_block::h32c6387759bf9c1aRov
  15:     0x7f547c5bc421 - trans::base::trans_closure::h4f0176769f365e43yUh
  16:     0x7f547c5be12a - trans::base::trans_fn::h3ac38359cc215db9g5h
  17:     0x7f547c5c1018 - trans::base::trans_item::h3fe1d8c9b2f38607Kti
  18:     0x7f547c5ced44 - trans::base::trans_crate::hb837a89597acef06Phj
  19:     0x7f547dd57708 - driver::phase_4_translate_to_llvm::hc295663c813bca94zOa

I think we should consolidate the const_check & type_limits passes. The trans pass will be harder when we get generic constants through.

I just tried to implement this RFC... And hit a curious issue. There's actually no const evaluation happening until the lint-passes run: https://github.com/rust-lang/rust/blob/master/src/librustc_lint/builtin.rs#L174-L178 Is it really a breaking change to improve a lint? IIRC #1105 says that if you could have prevented the situation by changing a lint-level or using UFCs, the breaking change is fine.

Improving a lint is fine; see #1193 etc.  For now, it would probably be good enough to just discard any constant evaluation warnings which would be triggered by a lint.  Don't worry too much about the eventual model; a lot of our constant-handling code is probably going to have to be rewritten to work on MIR anyway.

Huzzah! The language design subteam has decided to accept this RFC. Tracking issue is https://github.com/rust-lang/rust/issues/28238