Not work with css module

After using css module in parent component, Slider throws following exception

Uncaught Invariant Violation: Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.
The above error occurred in the  component:
in InnerSlider (created by Slider)
in Slider (at Slider.js:32)
...

And if I remove cssmodules decorator from parent component, then Slider works well.
Can not figure out why css module causes infinite render loop.
import React, { Component } from 'react'
import CSSModules from 'react-css-modules'
import styles from './index.css'
import Slide from 'react-slick'

// removing this line, then Slider renders well
@CSSModules(styles)
class Container extends Component {
   render() {
     return (
        <div styleName="container">
          <Slider />
        </div>
    )
   }
}

After some investigation, I found that props.children of Slide component changed repeatedly,
which caused endless loop.
As the error stated, I  removed componentDidUpdate method in InnerSlider, but the error still appeared.
Can not figure out why the children always changed.

I'm also having the same issue with react-css-modules

Look into source codes of react-css-modules,
See LinkElement method in LinkClass.js, the children props is transformed by  Children.map(children).
So chilldren prop in react-slick change repeatedly.

This might not be a problem with react-slick.

your docs are shockingly bad

Any updates regarding this issue?

Using "babel-plugin-react-css-modules" instead of "react-css-module"  to get rid of this issue.

@xsq007 I am using "babel-plugin-react-css-modules" and I am still facing the same issue. How were you able to make it work with it?


dragging stops when dragging images

Describe the bug
Trying out useGeasure - seems super-useful, but I ran into what to me feels odd.  I hooked up a drag-geature to an element that has an image as child. When I start draggiing, the drag stops after a few movements. onDragEnd is also triggered.
I the draggable do not have an image as a child, i do not see this behaviour.
Is this expected?
Sandbox or Video
https://codesandbox.io/s/elated-lalande-udmot

If applicable, please provide a minimal reproduction sandbox on code sandbox. Or a video / screenshots that could help.

Information:

React Use Gesture version: v9.0.0
OS: macOs
Browser: Brave

Checklist:

[x] I've read the documentation.
[x] If this is an issue with drag, I've tried setting touch-action: none to the draggable element.

Hi, this has been a recurring question so I've just added a section in the docs FAQ:
https://use-gesture.netlify.app/docs/faq/#why-cant-i-properly-drag-an-image-or-a-link
Hope it helps.

Hi, this has been a recurring question so I've just added a section in the docs FAQ:
https://use-gesture.netlify.app/docs/faq/#why-cant-i-properly-drag-an-image-or-a-link
Hope it helps.


Video Tutorial - Hooks

Summary
What: Video tutorial (acts of visual documentation) for how to use Hooks in Rhum. Though it's open to whoever takes on this issue how they'd like to do the video
Could be useful to include in the description of the video, times of topics, eg:
0:00 - introduction
0:23 - what are hooks
5:10 - creating hooks
Why: Supports visual learners, and thus creates another platform for people to understand Rhum hooks and how to use it - further enforcing "documentation driven"
Information

OBS can be used as the software to screenshare and video recording

Includes the drashland introduction? (speak to @crookse)

Includes the Rhum logo with the greenish background as the thumbnail

Video can be added to a "Rhum" playlist (can also be created if it doesn't exist)

Make it chill :)

All done: https://www.youtube.com/watch?v=jDzX4xlk-JY&ab_channel=drashland


Some game reviewes are missing on the sales page

Games like Commandos 3: Destination Berlin, Commandos: Behind Enemy Lines, Gravity Badgers, Talisman: Digital Edition, Infinity Runner and a lot of others show "-" in their Rating column. However, they do have reviews on Steam.
This is a recent bug, I think. Also, maybe it's not related, but this weird thing started a couple days ago: when I load a Steam page of a game, the review section (the one above the tags) is often missing at all (while there still are reviews down the page). A few page refreshes fixes it.
Is there something globally bugged with Steam reviews?

when I load a Steam page of a game, the review section (the one above the tags) is often missing at all (while there still are reviews down the page). A few page refreshes fixes it.

That would perfectly explain why it's missing from SteamDB.


Change shopify api and adapters for magento implementation

I propose change pod file by replacing gateway version with develop branch. This is a temporary solution.


Rename package to nitrokey

Rename package to nitrokey. Make sure the names do not clash with Solo-python.
Connected: #4

Fixed with https://github.com/Nitrokey/nitro-python/pull/16


Do shellcheck on PR code

find out if https://github.com/redhat-plumbers-in-action/differential-shellcheck is usable for us.
needs further brainstorming

Shellcheck has already been integrated. One can run it by writing [test] or [test-all] to PR's comment.


 Now I want to test out the pre-trained model on a sample image before starting the instruction tuning.
I run this command:
python -m llava.serve.cli \
    --model-base  customMPTmodel \
    --model-path ./checkpoints/llava-v1.5-pretrain/ \
    --image-file ./PXL_20230304_023217466.jpg \
    --temperature 0.1

When I give the prompt as: "Describe the image"
I get this runtime error:
Traceback (most recent call last):
  File "/opt/conda/envs/llava/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/conda/envs/llava/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/sensei-fs/users/achandhok/LLaVA-1.1.3-adobeone/llava/serve/cli.py", line 120, in <module>
    main(args)
  File "/sensei-fs/users/achandhok/LLaVA-1.1.3-adobeone/llava/serve/cli.py", line 97, in main
    output_ids=model.generate(input_ids,images=image_tensor,do_sample=True,temperature=args.temperature,max_new_tokens=args.max_new_tokens,streamer=streamer,use_cache=True,stopping_criteria=[stopping_criteria])
  File "/opt/conda/envs/llava/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/opt/conda/envs/llava/lib/python3.10/site-packages/transformers/generation/utils.py", line 1588, in generate
    return self.sample(
  File "/opt/conda/envs/llava/lib/python3.10/site-packages/transformers/generation/utils.py", line 2679, in sample
    next_tokens = torch.multinomial(probs, num_samples=1).squeeze(1)
RuntimeError: probability tensor contains either `inf`, `nan` or element < 0

I saw a couple other people facing similar issue but there wasn't any clear solution posted for the same. I'd appreciate it a lot if someone can point me in the correct direction.

same problem but after finetuning with my own data. Did you solved it?

I was using the older version of the code (v1.1.3 to be specific). Didn't get this after switching to the latest code base

I switched with latest code base tried it again with cli but I got same error. Did you finetune it again with new code base or just switched the code base and worked for inference ?Thank you so much for your quick answer.

yes, I pre-trained again. I was working with the MPT model. If you get a tokeniser mismatch warning while training, you need to rectify that as it can lead to bad learning during pretraining

yes, I pre-trained again. I was working with the MPT model. If you get a tokeniser mismatch warning while training, you need to rectify that as it can lead to bad learning during pretraining

Hello, I encounter the same error, how did you solve the mismatch problem?


WIP: Avoid a single recording rule creating many large objects

I ran into a problem with a rule like count_over_time( some_series[Many d:Small s]) that would end up with the kernel OOM killer sacrificing prometheus (besides overcommit being turned off). Taking a pprof/heap profile quickly pointed me to the Point slices and looking at the implementation shows me numSamples as a possible contributor. It's a WIP PR as I am not that familiar with Go (and Prometheus)
Most interestingly the --query.max-samples  only partially helps. It does fail the query but still does bad things to the heap (it seems unable to return memory to the OS, even with GODEBUG=madvdontneed=1). The closest thing I have to a working theory is:

Pooled []Point with a large capacity ends up being used by smaller queries. This would keep the slices alive with a lot of memory unused. It seems a best practice for sync.Pool is to have objects of roughly the same memory cost in it. I peeked into Go's fmt implementation and have a patch that discards large slices (larger than the ones used in the benchmark).

Interestingly the above does not apply when --query.max-samples kicks in as many slices are not returned/inserted to the pool but I can still see Prometheus taking up most of the physical RAM and never return it to the OS (and then run at risk to get OOM killed). My hypothesis is that Go's memory allocator will try to directly allocate large slices.. and we fragment the heap because we have many of them.
On a conceptual level I think the capacity requested by getPointSlice calls in a query should not exceed maxSamples but that might be rather difficult to implement. Another observation is that numSteps is the upper bound and in some cases we might get a lower bound (Min(numSteps, len(result)) or even get it precisely?

What is the performance/allocation impact of doing this?

The benchmark in promql didn't seem conclusive (lot's of noise, some more fast and some more slow) but I picked the threshold in a way that the benchmarks in promql/ do not need to grow the slice.

This code comes from before subqueries, when num steps could never be bigger than 11k.

In my case I have a low retention (days) but this recording rule created a large numSamples (let's say 365d at 1s resolution). And let's assume the query has something like 100 rows in the result set and the total query does not run into the ev.maxSamples limit. Then we have 100 slices with millions of entries capacities (all large allocations) and Go's GC is too poor to deal with that properly.
As a minimum I think we could:

Not return large allocations to the pool
We could clamp sz to ev.maxSamples or even ev.maxSamples - ev.currentSamples. In the above case the first results would have large allocations but not all rows.

Better: Allocating the exact number but I don't know enough of the data structures to see how difficult it is. I do see things like biggestLen but also once we started to iterate from startTs to endTs and create the point slice on first occurrence of a metric's hash.. we know how many samples were not consumed..
WDUT?

The benchmark in promql didn't seem conclusive (lot's of noise, some more fast and some more slow) but I picked the threshold in a way that the benchmarks in promql/ do not need to grow the slice.

We'll need some new benchmarks then.

Not return large allocations to the pool
We could clamp sz to ev.maxSamples or even ev.maxSamples - ev.currentSamples.

These would make sense.

Allocating the exact number but I don't know enough of the data structures to see how difficult it is.

We don't know the number until the calculation is performed, and copying around data again would be slow and mean more allocations. #6372 is related.

Allocating the exact number but I don't know enough of the data structures to see how difficult it is.

We don't know the number until the calculation is performed, and copying around data again would be slow and mean more allocations. #6372 is related.

But is the trade off really in favor of quickly blowing up the plant over running it safely? From my point of view such a query will be slow anyway and growing+copying the slice is unlikely to be the slowest part here. I am totally guessing but neither of us has a benchmark for this degenerated case. ;)

This is why benchmarks are needed, extra allocations will affect overall performance due to the additional GC.

We have looked at this pull request during our bug scrub.
Because of the lack of benchmark, we have decided to close this issue. Feel free to reopen if needed.
cc @bboreham for awareness.
Thank you for your contribution.

@roidelapluie I haven't looked at this part of the code in a while but I think it still makes sense to not return slices with a large capacity to the pool.


server_names will be free if temp_pool be destroyed.

First of all, I just know a part nginx source code. the issue occur when I use source code to dump configuration to json.
then,  I find out  then server_names is zero if i call ngx_pcalloc sometimes.
finally, I gdb the Nginx and catch the root cause that the server_names be assign in wrong pool.
I don't know whether the solution is the best. Just throw the issue. thanks.

the server_names is a element of ngx_http_core_srv_conf_t. I wired that ngx_http_core_srv_conf_t at cf.pool and server_names at temp_pool.   why not be in the same pool.  so wired.


FP16 Batch Matmul still does not run.

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):  Slightly.

OS Platform and Distribution (e.g., Linux Ubuntu 16.04):  Linux Ubuntu 16.04

TensorFlow installed from (source or binary):  Binary

TensorFlow version (use command below):  v1.9.0-0-g25c197e023 1.9.0

Python version:  3.6

CUDA/cuDNN version:  9.1

GPU model and memory:  V100 on GCE

Exact command to reproduce:

with tf.device("/gpu:0"):
    a = tf.random_normal(dtype=tf.float16, shape=[5, 2, 3], name='a')
    b = tf.random_normal(dtype=tf.float16, shape=[5, 3, 2], name='b')
    c = tf.matmul(a, b)
sess = tf.Session(config=tf.ConfigProto(log_device_placement=True, allow_soft_placement=False))
print(sess.run(c).shape)

Describe the problem
The above operation yields a InvalidArgumentError saying the kernel is not registered for DT_HALF. I've copied the full error below.
When the operation is pinned to cpu:0, it runs with no problems.
This issue is referenced in #18123, and was apparently addressed in #18436, then committed to master in commit f08f24cd559b5824a1874a0e76d339875e43f366, which ought to be included in v1.9.0, but the above code still errors for me when I try it.
Source code / logs
InvalidArgumentError (see above for traceback): Cannot assign a device for operation 'MatMul_1': Could not satisfy explicit device specification '/device:GPU:0' because no supported kernel for GPU devices is available.
Registered kernels:
  device='GPU'; T in [DT_DOUBLE]
  device='GPU'; T in [DT_FLOAT]
  device='GPU'; T in [DT_COMPLEX128]
  device='GPU'; T in [DT_COMPLEX64]
  device='CPU'; T in [DT_INT32]
  device='CPU'; T in [DT_HALF]
  device='CPU'; T in [DT_DOUBLE]
  device='CPU'; T in [DT_FLOAT]
  device='CPU'; T in [DT_COMPLEX128]
  device='CPU'; T in [DT_COMPLEX64]

         [[Node: MatMul_1 = BatchMatMul[T=DT_HALF, adj_x=false, adj_y=false, _device="/device:GPU:0"](a_1, b_1)]]

since it's addressed in #18436, adding TF_CALL_half(REGISTER_BATCH_MATMUL_GPU); back in ensorflow/core/kernels/batch_matmul_op_real.cc#L34-L35 should work.

Yes, I built your PR from source and it appears to work. Thanks!

For what it's worth, I took a look at the kernels called in nvvp and when built with cuda 9.1, it calls one kernel, whereas for cuda 9.0, it loops over elements in the batch, as expected.

Nagging Assignee @tatianashp: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

This issue should have been fixed now after the following change.
https://github.com/tensorflow/tensorflow/commit/cfdc46956574de703df2251ac52d30e593d8d417#diff-dacd84efa9d7e0ac640165c911203745
Please reopen if further changes are required. Thanks for reporting this issue.


chore(main): release 0.0.3

:robot: I have created a release beep boop
0.0.3 (2023-12-06)
Features

add implicit auth support to Helm chart (#31) (7f0a707)
RBAC rules (#21) (d532c56)

Bug Fixes

deps: update module github.com/azure/azure-sdk-for-go/sdk/resourcemanager/authorization/armauthorization/v2 to v2.2.0 (#24) (1b737ca)
deps: update module github.com/onsi/ginkgo/v2 to v2.13.2 (#26) (abb4784)
deps: update module github.com/spectrocloud-labs/validator to v0.0.26 (#25) (fd6fc77)
deps: update module github.com/spectrocloud-labs/validator to v0.0.27 (#28) (03575e7)
deps: update module github.com/spectrocloud-labs/validator to v0.0.28 (#32) (bca0a38)

Other

deps: update actions/setup-go action to v5 (#34) (293a890)
deps: update actions/setup-python action to v5 (#33) (169bdb5)
deps: update anchore/sbom-action action to v0.15.1 (#30) (47b0704)
deps: update google-github-actions/release-please-action action to v4 (#29) (35f91aa)
release 0.0.3 (5e0f069)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/spectrocloud-labs/validator-plugin-azure/releases/tag/v0.0.3 :sunflower:


Binding Unmodified Rust

Moving the discussion from #1116 as @fzyzcjy suggested. Here's a copy of the proposal:
Dart users don't expect to deal with ownership, lifetimes, and indirection. On the other hand, Rust exposes all of these for function arguments and returns. It's also nonsensical for Dart to borrow (& and &mut) a non-'static Rust object because the borrow checker doesn't work across language boundaries. (It is sensible for Rust to borrow a Rust value owned by Dart.) The Dart representation of a Rust object should encapsulate as much of the Rust memory model as possible to simulate the Dart memory model. For aspects that can't or shouldn't be encapsulated, we can leverage Dart constructs like implements to abstract them.
Arguments to Rust Functions
In Rust, we can't call a function with an argument that will take ownership if the caller does not have ownership. This is one example of the Rust memory model that can't be hidden from Dart. Here's the complete list:

No derivation of ownership from indirection
No derivation of mut indirection from const indirection
No derivation of exclusive ownership from shared ownership, or vice-a-versa
No derivation of Rc from Arc, or vice-a-versa

It's also worth pointing out some of the derivations that can and should be hidden from Dart:

Derivation of indirection from ownership
Derivation of const indirection from mut indirection
Derivation of mut double indirection upon mut or const indirection
Derivation of const double indirection upon const indirection

To abuse Worth Syntax Notation, I define five equivalence classes:
OWNED   = Box<OWNED>
        | T

MUT_IND = *mut T
        | &mut T
        | *mut MUT_IND
        | &mut MUT_IND

IND     = *const T
        | &T
        | *const IND
        | &IND
        | *mut IND
        | &mut IND

RC      = Rc<T>

ARC     = Arc<T>

T is any valid Rust type name. Any type constructor that can be derived from the same production is in the same equivalence class. For example, &mut *const T and &T can be derived from IND and are in the same equivalence class. Type constructors in the same equivalence class are interchangeable to pass an argument to a function. If we have a &T, we can invoke a function that wants a &mut *const T and vice versa. Generally, it's not possible to move across equivalence classes, except in the following scenarios, which I've dubbed substitutions:
OWNED   = IND
        | MUT_IND

RC      = IND
        | MUT_IND

ARC     = IND
        | MUT_IND

MUT_IND = IND

To explain by way of example, Box<T> is in the OWNED class, and we can compute &T in the IND class from it. Therefore, OWNED can be substituted for IND. (By the way, I spent some time investigating OWNED = RC and OWNED = ARC, but there's no way to make fake reference counters without causing memory leaks.)
If T implements Clone, then these additional substitutions are possible:
IND     = OWNED
MUT_IND = OWNED
RC      = OWNED
ARC     = OWNED

These can probably be piled into the "unexpected behavior" that @Desdaemon mentioned. Dart users expect pass by reference, not pass by value. These types should instead expose a clone method in Dart. I must point out that for values that can be serialized, the semantics of flutter_rust_bridge today is to pass them by value. We'll have to think about whether that should change.
Here's a more concrete example of the equivalence classes:
dump_file version 1
/// dump a File, taking ownership and destroying the File when done
pub fn dump_file(file: std::fs::File) {
    println!("{}", file.read_to_string());
}

dump_file version 2
/// dump a Box<File>, taking ownership and destroying the File when done
pub fn dump_file(file: Box<std::fs::File>) {
    println!("{}", file.read_to_string());
}

Dart needn't care about whether the argument is Boxed. All it needs to know is it owns a File, it will lose ownership when it calls dump_file, and the interop layer will take care of the rest. (Maybe !Sized: T needs to be its own class too) One final wrinkle: what if the Dart user wants to interact directly with pointers or reference counters? I said that T above is a type name. The good news is that we could tuck a pointer or ref counter into that T, and the rules still work, so long as the "no derivation of mut indirection from const indirection" rule isn't violated. If this capability is added, it would be follow-up work.
Equivalence Class Abstraction
In the same way FrbOpaque is inherited to make Rust-type-specific instantiations, five new Dart classes will be introduced that will be inherited to make Rust-type-specific instantiations. (Possible ten if we want "NoSend" variants for T: !Send. (12 for !Sized, maybe.))

Dart Base Type
Dart Derived Type Generated for Rust Type MyType
Notes

FrbInd
FrbIndMyType
fn f(&self, ...) method bindings

FrbMutInd
FrbMutIndMyType
implements FrbIndMyType, fn f(&mut self, ...) method bindings

FrbOwned
FrbOwnedMyType
implements FrbMutIndMyType, fn f(self, ...) method bindings

FrbRc
FrbRcMyType
implements FrbMutIndMyType

FrbArc
FrbArcMyType
implements FrbMutIndMyType

As in the RustOpaque example, the var keyword keeps the type name from the user. (I am concerned that the different collections of method bindings (see Notes above) could confuse the user if the type name is hidden. "Why can't I use this method?" Maybe we can abuse Darts @Deprecated annotation to notify the user?) The implements relations are modeled after the aforementioned substitution rules. They enable Dart bindings of Rust functions to parameterize with the least derived type but be called with the more derived type due to Liskov Substitution Principle (LSP). For example:
void do_a_thing(FrbIndirectionMyType value) { /* send to Rust */ }
FrbOwnedMyType make_a_value() { /* get from Rust */ }

var value = make_a_value();
do_a_thing(value); // OK, because FrbOwnedMyType implements FrbIndMyType

It's also theoretically possible for a binding to return, for example, a FrbOwnedMyType, despite having a declared return type of FrbIndirectionMyType due to the LSP, but that's probably not useful in practice and diverges from the Rust memory model anyway.
Return Values from Rust Functions
The equivalence classes are helpful here as well, with a tweak. Dart cannot generally borrow, except for &'static and &'static mut, so replace all occurrences of & with &'static . To send a return value to Dart, in order:

Convert to the first variant of the equivalence class. E.g., &'static mut T becomes *mut T, and T becomes Box<T>.
Serialize and transfer to Dart, including ownership, based on the type constructor:

*const T - serialize into FrbInd
*mut T - serialize into FrbMutInd
Box - Box::into_raw and serialize into FrbOwned
Arc - If Arc::try_unwrap works then change to Box, otherwise mem::forget, serialize *const Arc into FrbArc (like FrbOpaque)
Rc - If Rc::try_unwrap works then change to Box, otherwise mem::forget, serialize *const Rc + thread::ThreadID into FrbRc

Again, if T implements Clone, it's feasible to work with borrowed return values, but the same pass-by-value concerns apply.
Rust-Function Valued Returns from Rust Functions
The feasibility of this was shown in https://github.com/fzyzcjy/flutter_rust_bridge/discussions/986. On the Dart side, it'll be an object that implements invocation, forwarding arguments to the Rust function.
Dart-Function Valued Arguments to Rust Functions
Similar conceptually to Rust callback functions but requires a bit more.
pub fn callback_caller(callback: Fn(String) -> i64) {
    assert(callback("1337") == 1337);
}

int dartCallback(String str) {
  return int.tryParse(str);
}

This can work similarly to StreamSink with the addition of multiplexing. On the Rust side, the Fn is made from a closure. If this is done right, we can even let the user hang themselves with callback hell. xD
Marshaling
Marshaling exposes the members of an unserializable Rust object to Dart. For example, a Rust std::fs::File object cannot be serialized. Nonetheless, a Dart class like the following is possible:
class StdFsFile {
  final Platform _platform;
  final RustIndirection _native;

  int write(UInt8List buf) {
    _platform.inner.std_fs_file_write(_native, buf);
  }
  ...
}

It's Getting Late
This is pretty long already, so at the very least, it's time for a first round of discussion, especially since I'm still new to Rust and flutter_rust_bridge (how many months can I keep saying that?). Please let me know what you think, if I need to add some details, if something is wrong, etc. Cheers!

@fzyzcjy said

The proposal is exciting - especially, I love how we can call Dart callbacks from Rust and vise versa! IMHO this is quite useful, because closure (or "function as first-class citizen") is a commonly used language feature for modern languages.
To be honest, I am a little bit confused why we need FrbInd/FrbMutInd/..., etc. We know frb currently passes (copy or move) everything by value (except for Opaque) between Dart and Rust. Therefore, for example, no matter what Rust semantics say (e.g. owned, indirection, ...), we still create a brand new object (or move - if you are using ZeroCopyBuffer) in the Dart side. Thus, I am not very sure the use of FrbInd/FrbMutInd/...

They're for unserializable objects - like what's done with RustOpaque. The motivation is that we don't want:
pub fn my_function(foo: RustOpaque<Bar>)

because that's a Rust function written for flutter_rust_bridge. We want
pub fn my_function(foo: Bar)

a generalized Rust function that can be called from Dart. We need different varieties because of the (at least) 5 equivalence classes. Also take a look where I said, "Dart users expect pass by reference, not pass by value."

I see. So if I understand correctly, those FrbInd/FrbMutInd/etc are there, because we want to avoid writing RustOpaque in api.rs? Then still a bit confused: seems that we do not need FrbInd/... to avoid RustOpaque. Instead, just do some more code generation at bridge_generated.rs seems enough.

Say we have this Rust
struct Unserializable { ... }
pub fn put_owned(x: Unserializable) { ... }
pub fn get_owned() -> Unserializable { ... }
pub fn put_arc(x: Arc<Unserializable>) { ... }
pub fn get_arc() -> Arc<Unserializable> { ... }

These functions aren't interchangeable.
set_owned(get_owned()); // OK
set_arc(get_arc());     // OK
put_owned(get_arc());   // Error, can't pass Arc as owned
put_arc(get_owned());   // Error, can't pass owned as Arc

Because we want to hide Arc from Dart, we can imagine our Dart bindings like this:
class Unserializable { ... }
void put_owned(Unserializable x) { ... }
Unserializable get_owned() { ... }
void put_arc(Unserializable x) { ... }
Unserializable get_arc() { ... }

Here's the problem:
set_owned(get_owned()); // OK
set_arc(get_arc());     // OK
put_owned(get_arc());   // Invalid, but no Dart compiler error
put_arc(get_owned());   // Invalid, but no Dart compiler error

We can get Dart to produce compile errors for the invalid invocations if the binding looks like this instead:
class FrbOwnedUnserializable { ... }
class FrbArcUnserializable { ... }
void put_owned(FrbOwnedUnserializable x) { ... }
FrbOwnedUnserializable get_owned() { ... }
void put_arc(FrbArcUnserializable x) { ... }
FrbArcUnserializable get_arc() { ... }

And then the same Dart test code:
put_owned(get_owned()); // OK
put_arc(get_arc());     // OK
put_owned(get_arc());   // Dart compilation fails successfully
put_arc(get_owned());   // Dart compilation fails successfully

The Dart type system simulates the Rust memory model. To explain the use of the Liskov Substitution Principle, let's start with some new Rust code:
struct Unserializable { ... }
pub fn put_owned(x: Unserializable) { ... }
pub fn get_owned() -> Unserializable { ... }
pub fn put_ref(x: &'static Unserializable) { ... }
pub fn get_ref() -> &'static Unserializable { ... }

put_owned(get_owned()); // OK
put_ref(get_ref());     // OK
put_owned(get_ref());   // Error, can't pass ref as owned
put_ref(&get_owned());  // OK, we can get a ref from an owned

So in Dart we write
class FrbIndUnserializable { ... }
class FrbOwnedUnserializable implements FrbIndUnserializable { ... }
void put_owned(FrbOwnedUnserializable x) { ... }
FrbOwnedUnserializable get_owned() { ... }
void put_ref(FrbIndUnserializable x) { ... }
FrbIndUnserializable get_ref() { ... }

and calling in Dart
put_owned(get_owned()); // OK
put_ref(get_ref());     // OK
put_owned(get_ref());   // Dart compilation fails successfully
put_ref(get_owned());   // OK, because FrbOwnedUnserializable `implements` FrbIndUnserializable

I see - these types can generate compiler errors in Dart for bad types.
However, I am not sure, how can we pass (move) a owned non-serializable object? Currently, we only support Arc (via Opaque).

These types are similar to but distinct from Opaque. For Onwed on the Rust side, some pseudocode:
fn make_frb_owned(value: Box<T>, channel: etc) {
    // Unbox value, keeping it on the heap and manually managing lifetime
    let ptr: *const T = Box::into_raw(value);
    // Send the pointer to Dart
    channel.serialize_and_transmit(ptr);
}

I see - the owned value can be created by leaking a raw pointer.
Then, I wonder how we should use the owned value? My guess is like (pseudocode):
void useOwnedValue(FrbOwnedUnserializable x) {
  if (x.movedAway) throw Exception;
  x.movedAway = true;
  call_rust_code_via_ffi(x.ptr);
}

class FrbOwnedUnserializable {
  final int ptr;
  bool movedAway = false;
}

Note that my naive method above has a problem: If the call via ffi somehow fails, there is memory leak. But it is at least better than use-after-free. IIRC, I have seen such dilemma in Opaque's implementation (not remember exactly though).

Also cc @Desdaemon @ShaunPettiN who discussed in the previous discussions (in case this new issue does not appear on your inbox)

Yeah, I had suspected that RustOpaque could leak too, because it owns an Arc. There's are ways to clean up such objects, but that might be a separate feature.
Anyway to answer your question, your example code is how it works, yes.

I see. So this proposal is quite interesting! If I understand correctly, it can be broken into a few (mutually related) parts:

Allow Dart/Rust closures to be used in Rust/Dart respectively
Implement owned (i.e. non-Arc) Rust values
Create class hierarchy in Dart to simulate Rust's type system, which is like a generalization and enhancement of the FrbOpaque

It would be great to separate the implementation into at least a few PRs (e.g. the ones above), because the larger the PR is, the harder to implement and review ;)

As a side remark: For owned values, we should be extra careful, e.g. need to be Send if we cannot guarantee it is on the same thread

IMHO the proposal looks great to me (except that the Dart type system looks a bit complicated - would be even greater to have a simpler type system or other ways). But before getting started, maybe we should hear more voices: @Desdaemon what do you think about it?

Send is a concern, which is why I mention possibly needing even more Dart types in the proposal, but thinking about it now I don't think that's the solution. Rc isn't send either, and the way I suggested dealing with that was serializing the thread ID alongside the pointer. The thread ID can hopefully help with Send and Sync, but I haven't hashed out the details.

IIRC the existing Opaque already has some things about Send and thread-id like that.
Also cc @rogurotus who implemented the great opaque type, and @Desdaemon who implemented the initial parts of the great opaque system :)

Another part in addition to the three you mentioned is generating method and field accessors for the Dart types. See the Notes column in the original table

Edited :)

I just have one question: how should we accommodate for the aliasing rules? Since if I understand this correctly FrbMutInd types implement FrbInd, meaning Dart users are allowed to pass a &mut T everywhere a &T is expected, without the borrow checker to guide them. This wouldn't be an issue if our design is similar to how RefCell does it, i.e. panic on aliases, but it is imperative we do not introduce possibilities for UB on the FFI border.
On a separate note, Dart consumers of these functions will be forced to pay attention to limitations introduced by the borrow checker and that creates some friction, as did my attempt to enable methods taking self. But that's a trade-off the library authors will have to make, not us.
Lastly, I think *const T and *mut T are still pretty half-baked in Rust and I wouldn't count them in the same indirection classes you have mentioned. I feel that they have a closer relationship to ffi.Pointer than a reference, and that's how we should interpret them.

I agree. Making raw T/&T/&mut T will introduce a lot of difficulties and edge cases - that's partially why our current Opaque uses a naive Arc. The performance is definitely a bit worse, but given that our generated code + Dart's indirection code already have performance penalty, I guess Arc vs raw pointers will not be a big difference.  So, maybe we can firstly implement the parts unrelated to these T/&T/&mutT.?

I agree. Making raw T/&T/&mut T will introduce a lot of difficulties and edge cases - that's partially why our current Opaque uses a naive Arc. The performance is definitely a bit worse, but given that our generated code + Dart's indirection code already have performance penalty, I guess Arc vs raw pointers will not be a big difference.  So, maybe we can firstly implement the parts unrelated to these T/&T/&mutT.?

No, I don't have any issues with the proposal itself, it's just that we're moving into fundamental Rust types that are unrepresentable in the Dart/C world, all that means is that some extra scrutiny is required. Yes, the promise is to write straightforward Rust code, but it does mean it won't be as straightforward in other languages that don't share Rust's vocabulary.

To be more specific, I am not against the proposal; instead, I am just pointing out some possible challenges of the T/&T/&mutT part, while it is still quite good!
Btw some random thoughts: Even if Arc vs raw pointer does not make a performance difference, the T/&T/&mutT may be still quite useful, because it may enable future optimization when the other overhead has been eliminated. In addition, without benchmarks we do not know yet whether Arc vs raw T/&T/&mutT is much slower or non-visibily slower.

@Desdaemon, Rust type conversions handle the type aliasing rules, which I've neglected in the proposal so far. The best way to explain and verify feasibility was to... well, just write it - the below is self-contained, working code for ease of evaluation. There's still some work to be done, but I think it's getting there.
pub trait DartSafe: std::panic::UnwindSafe + std::panic::RefUnwindSafe {}
impl<T: std::panic::UnwindSafe + std::panic::RefUnwindSafe> DartSafe for T {}

/// Sometimes needed to prevent error[E0117}:only traits defined in the current
/// crate can be implemented for arbitrary types
trait Alias<T>: Sized {
    fn alias(self) -> T;
}

type RustInd<T> = *const T;
type RustOwned<T> = *mut T;
type RustMutIndOrOwned<T> = *mut T;
type RustRc<T> = RustOwned<(std::rc::Rc<T>, std::thread::ThreadId)>;
// type RustMutRc<T: ?Sized + DartSafe> = RustRc<std::cell::RefCell<T>>;
type RustArc<T> = RustOwned<std::sync::Arc<T>>;
// type RustMutArc<T: ?Sized + DartSafe> = RustArc<std::cell::RefCell<T>>;

// FrbInd -> &'static T
impl<T: ?Sized + DartSafe> Alias<&'static T> for RustInd<T> {
    fn alias(self) -> &'static T {
        unsafe { &*self as &T }
    }
}

// FrbInd -> *const T
impl<T: ?Sized + DartSafe> Alias<*const T> for RustInd<T> {
    fn alias(self) -> *const T {
        self
    }
}

/// FrbMutInd -> &'static T
/// FrbOwned -> &'static T
impl<T: ?Sized + DartSafe> Alias<&'static T> for RustMutIndOrOwned<T> {
    fn alias(self) -> &'static T {
        unsafe { &*self as &T }
    }
}

/// FrbMutInd -> *const T
/// FrbOwned -> *const T
impl<T: ?Sized + DartSafe> Alias<*const T> for RustMutIndOrOwned<T> {
    fn alias(self) -> *const T {
        self as *const T
    }
}

/// FrbMutInd -> &'static mut T
/// FrbOwned -> &'static mut T
impl<T: ?Sized + DartSafe> Alias<&'static mut T> for RustMutIndOrOwned<T> {
    fn alias(self) -> &'static mut T {
        unsafe { &mut *self as &mut T }
    }
}

/// FrbMutInd -> *mut T
/// FrbOwned -> *mut T
impl<T: ?Sized + DartSafe> Alias<*mut T> for RustMutIndOrOwned<T> {
    fn alias(self) -> *mut T {
        self
    }
}

/// FrbOwned -> Box<T>  (ownership transferred)
impl<T: ?Sized + DartSafe> Alias<Box<T>> for RustOwned<T> {
    fn alias(self) -> Box<T> {
        unsafe { Box::from_raw(self) }
    }
}

/// FrbOwned -> T  (ownership transferred)
impl<T: Sized + DartSafe> Alias<T> for RustOwned<T> {
    fn alias(self) -> T {
        *unsafe { Box::from_raw(self) }
    }
}

trait ThreadCheck {
    fn thread_affinity(&self) -> std::thread::ThreadId;

    fn check(&self) {
        let this_thread_id = std::thread::current().id();
        if self.thread_affinity() != this_thread_id {
            panic!("wrong thread!");
        }
    }
}

impl<T: ?Sized + DartSafe> ThreadCheck for RustRc<T> {
    fn thread_affinity(&self) -> std::thread::ThreadId {
        unsafe { (*(*self)).1 }
    }
}

/// FrbOwned::into_rc, the Rc takes ownership
impl<T: ?Sized + DartSafe> Alias<RustRc<T>> for RustOwned<T> {
    fn alias(self) -> RustRc<T> {
        Box::into_raw(Box::new((
            std::rc::Rc::<T>::from(unsafe { Box::from_raw(self) }),
            std::thread::current().id(),
        )))
    }
}

/// FrbRc<T> -> &T
impl<'a, T: ?Sized + DartSafe> Alias<&'a T> for RustRc<T> {
    fn alias(self) -> &'a T {
        // assert!(std::thread::current()::thread_id() == self.1)
        unsafe { (*self).0.as_ref() }
    }
}

/// FrbRc<T> -> *const T
impl<T: ?Sized + DartSafe> Alias<*const T> for RustRc<T> {
    fn alias(self) -> *const T {
        // assert!(std::thread::current()::thread_id() == self.1)
        unsafe { (*self).0.as_ref() as *const T }
    }
}

// /// FrbRc<RefCell<T>> -> &mut T
// impl<'a, T: ?Sized + DartSafe> Alias<&'a mut T> for &'a RustMutRc<T> {
//     fn alias(self) -> &'a mut T {
//         Alias::<&'a std::cell::RefCell<T>>::alias(self).get_mut()
//     }
// }

// /// FrbRc<RefCell<T>> -> *mut T
// impl<T: ?Sized + DartSafe> Alias<*mut T> for &RustMutRc<T> {
//     fn alias(self) -> *mut T {
//         Alias::<&std::cell::RefCell<T>>::alias(&self).get_mut() as *mut T
//     }
// }

// FrbOwned::into_arc, the Arc takes ownership
impl<T: ?Sized + DartSafe> Alias<RustArc<T>> for RustOwned<T> {
    fn alias(self) -> RustArc<T> {
        Box::into_raw(Box::new(std::sync::Arc::<T>::from(unsafe { Box::from_raw(self) })))
    }
}

/// FrbRc<T> -> &T
impl<'a, T: ?Sized + DartSafe> Alias<&'a T> for RustArc<T> {
    fn alias(self) -> &'a T {
        // assert!(std::thread::current()::thread_id() == self.1)
        unsafe { (*self).as_ref() }
    }
}

/// FrbRc<T> -> *const T
impl<T: ?Sized + DartSafe> Alias<*const T> for RustArc<T> {
    fn alias(self) -> *const T {
        // assert!(std::thread::current()::thread_id() == self.1)
        unsafe { (*self).as_ref() as *const T }
    }
}

// /// FrbRc<RefCell<T>> -> &mut T
// impl<'a, T: ?Sized + DartSafe> Alias<&'a mut T> for &'a RustMutRc<T> {
//     fn alias(self) -> &'a mut T {
//         Alias::<&'a std::cell::RefCell<T>>::alias(self).get_mut()
//     }
// }

// /// FrbRc<RefCell<T>> -> *mut T
// impl<T: ?Sized + DartSafe> Alias<*mut T> for &RustMutRc<T> {
//     fn alias(self) -> *mut T {
//         Alias::<&std::cell::RefCell<T>>::alias(&self).get_mut() as *mut T
//     }
// }

fn add_and_print(a: &i32, b: &i32) {
    println!("{}", a + b);
}

fn main() {
    let mut owned = 1 as i32;
    let mutable = &mut owned;
    let immutable = mutable as &i32;

    let frb_owned = Box::into_raw(Box::new(2 as i32));
    let mut mutable2 = 4 as i32;
    let frb_mut_ind = &mut mutable2 as *mut i32;
    let frb_ind = immutable as *const i32;
    let rc: std::rc::Rc<i32> = std::rc::Rc::<i32>::new(8);
    let frb_rc = Box::into_raw(Box::new((rc, std::thread::current().id())));
    let arc = std::sync::Arc::<i32>::new(16);
    let frb_arc = Box::into_raw(Box::new(arc));

    // f takes two &i32 args, but lets call it with a *bunch* of things
    add_and_print(frb_owned.alias(), frb_mut_ind.alias());
    add_and_print(frb_ind.alias(), frb_rc.alias());
    add_and_print(frb_arc.alias(), frb_owned.alias());
}

Suppose we have this Rust function:
pub fn inc_and_print(left: &mut i32, right: &i32) {
    left += 1;
    println!("{left} != {right}");
}

Which this proposal would translate into Dart as:
void incAndPrint(FrbMutIndI32 left, FrbInd32 right);

Then a Dart consumer of this library may use it as such:
FrbMutIndI32 mutableValue; // obtained elsewhere
// aliasing rules violated:
// mutableValue is borrowed at the same time mutably and immutably
// Dart doesn't complain since FrbMutInd is covariant with FrbInd
incAndPrint(mutableValue, mutableValue);

If our Rust-side FrbInd were instead type aliases to e.g. RefCell, then attempts to .borrow or .borrow_mut would panic on the FFI border, which is totally fine since we should have mechanisms to catch panics as early as then. This is not the only approach, but the easiest one to demonstrate for now.
My point is, without any of Rust's guardrails in Dart, interior mutability is an acceptable compromise to prevent rustc miscompiling due to aggressive optimizations.

Thank you for bringing that up. We're looking at where the rubber meets pavement now, and there are difficult but essential philosophical questions about the interactions between memory models.
When first writing the proposal, my instinct was that any function returning a & or &mut could not be bound to Dart because there's no way to rule out access after free. For that reason, I also thought &'static and &'static mut were acceptable - I hadn't considered the aliasing and mutability rule yet. Also, without thinking about it enough, I assumed that *mut and *const let us throw all the considerations about lifetime, aliasing, and mutability out the window, and a pointer was a "get out of jail for a price" card. Honestly, I still don't know the right way to think about Rust pointers, though from @Desdaemon's comment about them being half-baked, maybe nobody does. The reality is that if we are to ensure that no Rust invariants are broken by Dart, including erring on the side of caution for pointers, then Dart can interact with a Rust value in only one way: ownership. That's what RefCell requires. It simplifies things a lot because RustOpaque already does this. We can go forward with the call-back functions and the generation of method and field accessors for RustOpaque, and that would be of great benefit. But IMHO, that would be underwhelming. This may be putting the cart (pointers) before the horse (refs), but examing the invariants behind pointers seems like the easiest way to broach the subject of undefined behavior (UB) between languages and the implications of how we map invariants from one language onto another.
I'm going to write several programs below, combining Rust and C. Each will have the same intended behavior, setting a byte with the dereference of two simultaneous mutable indirections. I'll change just one aspect at a time, and each subsequent program will be more offensive to Rust sensibilities.
Pure C
This program's behavior is well-defined.
#include <stdio.h>

int main() {
    char value = 0;
    char* ptr_a = &value;
    char* ptr_b = &value;
    *ptr_a = 'a';
    *ptr_b = 'b';
    printf("%c\n", *ptr_a); // prints b
}

Two uint8_t* to a u8
This time the byte is a Rust value, not a C value. We make two mutable indirections to a Rust value, but only in C and not escaping to Rust.
#include <stdio.h>

void algorithm(char* ptr_a) {
    char* ptr_b = ptr_a; // double mutable indirection to Rust value
    *ptr_a = 'a';
    *ptr_b = 'b';
    printf("%c\n", *ptr_a); // prints b
}

extern "C" {
    fn algorithm(ptr_a: *mut u8);
}

pub fn main() {
    let mut value = 0 as u8;
    unsafe { algorithm(&mut value as *mut u8) };
}

Two uint8_t* to a u8, Dereferenced in Rust
Now Rust will do the dereferencing.
#include <stdio.h>

extern void put(char* ptr, char);

void algorithm(char* ptr_a) {
    char* ptr_b = ptr_a; // double mutable indirection
    put(ptr_a, 'a');
    put(ptr_b, 'b');
    printf("%c\n", *ptr_a); // prints b
}

extern "C" { fn algorithm(ptr_a: *mut u8); }

#[no_mangle]
unsafe extern "C" fn put(ptr: *mut u8, value: u8) {
    *ptr = value;
}

pub fn main() {
    let mut value = 0 as u8;
    unsafe { algorithm(&mut value as *mut u8) };
}

Two uint8_t* to a u8, Dereferenced Simultaneously in Rust
This version makes Rust simultaneously hold two mutable references to a single location. This places us in the vicinity of the incAndPrint example.
#include <stdio.h>

extern void put(char* ptr_a, char value_a, char* ptr_b, char value_b);

void algorithm(char* ptr_a) {
    char* ptr_b = ptr_a; // double mutable indirection
    put(ptr_a, 'a', ptr_b, 'b');
    printf("%c\n", *ptr_a); // prints b
}

extern "C" { fn algorithm(ptr_a: *mut u8); }

#[no_mangle]
unsafe extern "C" fn put(ptr_a: *mut u8, value_a: u8, ptr_b: *mut u8, value_b: u8) {
    let ref_a = &mut *ptr_a;
    let ref_b = &mut *ptr_b;
    *ref_a = value_a;
    *ref_b = value_b;
}

pub fn main() {
    let mut value = 0 as u8;
    unsafe { algorithm(&mut value as *mut u8) };
}

Pure Rust
And just for the sake of completion, however unsettling.
pub fn main() {
    unsafe {
        let mut value = 0 as u8;
        let ref_a = &mut *(&mut value as *mut u8);
        let ref_b = &mut *(&mut value as *mut u8);
        *ref_a = 5;
        *ref_b = 6;
        println!("{}", ref_a);
    }
}

We started out with well-defined behavior and ended with undefined behavior. Somewhere along the way we crossed over to the dark side. The first question is, which one? I can see a case being made for any one of them. The second question is, how does this impact us in practice? I tested all these programs, and they work, if incidentally.
In the second example, we create two mutable indirections. If the borrow checker is an algebra that applies to the whole program, then this example escapes that algebra. Yet, the second example will be a working program for any correct compiler. (I suspect three as well, but four could reorder.) Corollary: The borrow checker helps us avoid logical errors, but there are programs that are valid despite eluding the borrow checker. In such a case, it's undefined behavior only because the borrow checker can't prove that it's not.
Where does that leave us? Obviously, the borrow checker is a cornerstone of Rust and a big part of why Rust is so amazing. The borrow checker is responsible for keeping us from shooting ourselves in the foot. However, I would argue that, in the interest of interop, maybe the user can take on some of that responsibility. Maybe lifetimes too. That said, C is a different language from Dart, and we should consider that in deciding how much responsibility is the right amount.

After sleeping on it, we could make the default behavior ownership-based interaction only, and provide an escape hatch for users who are willing to take more responsibility. It would enable the generation of the other equivalence classes. Documentation needs to detail the risks of using the escape hatch. What would an escape hatch look like? It could be a toggle, but maybe that's too blunt an instrument. The CLI today accepts file-by-file source and destination information. Perhaps that can be extended with a "--unsafe-file". An even more granular option would be "--unsafe-type" or "--unsafe-function". I'm just spitballing, so please share your ideas.

I think the way looks good - then we are keeping a simple and intuitive developer interface to the users (by default). Then it is easy to learn and use the library without the need to learn a lot. On the other hand, if we or they want the more complex but flexible behavior, the flag can come to help.
As for the escape hatch: Or we can utilize #[frb(...)] annotations? Or wrapper types just like how we did for ZeroCopyBuffer<...> and Opaque<...>.

For code that we own and write for dart consumption, I agree that annotations make sense. For third party libraries, command line options are unintrusive. But why choose? Let's do both.

Thank you @fzyzcjy. And thank you @Desdaemon. You guys have done great work for the community in putting this project together and getting it to where it is today. I appreciate you giving me the opportunity to work with you and contribute to enhancing it.

You are welcome. Also thank you @coder0xff - you have proposed interesting new features, happy to discuss with you, and looking forward to the PRs!

Here's some Dart code. Let me know what you think.
FrbDescriptor will be passed back and forth between Dart and Rust. When passed to Rust, Rust code will look at the usage field to deserialize to the correct type constructor, *const, Arc, etc. Type safety of the (implied) T works the same way as FrbOpaque, with derived classes and Rust functions specific to each T. After deserialization, the aliasing rules in https://github.com/fzyzcjy/flutter_rust_bridge/issues/1132#issuecomment-1474822609 perform argument forwarding to the target function.
/// Generalizes pointers to Rust objects. Treat it as a black box in Dart.
@ffi.Packed(1)
class FrbDescriptor extends ffi.Struct {
  // Rust fat pointer serialized as pointer and metadata. Implementation
  // details may change; treat as unstable black boxes.
  external PlatformPointer pointer;
  external PlatformPointer metadata;

  /// The pointers originating Rust thread, for asserting Send and Sync usage.
  @ffi.Uint64()
  external int threadId;

  /// 1 - pointer to borrowed
  /// 2 - pointer to mutably borrowed
  /// 3 - pointer to owned
  /// 4 - pointer to owned Rc
  /// 5 - pointer to owned Arc
  @ffi.Uint8()
  external int usage;

  /// The Rust type of the pointee implements Sync
  @ffi.Bool()
  external bool sync;

  /// The Rust type of the pointee implements Send
  @ffi.Bool()
  external bool send;
}

typedef DropOwnedFnType = void Function(FrbDescriptor);

abstract class FrbInd {
  FrbDescriptor? _accessor;

  FrbInd(this._accessor);
}

abstract class FrbMutInd extends FrbInd {
  FrbMutInd(FrbDescriptor _accessor) : super(_accessor);
}

abstract class FrbOwned extends FrbMutInd {
  FrbOwned(FrbDescriptor _accessor) : super(_accessor);

  /// A native finalizer rust opaque type.
  /// Is static for each frb api class instance.
  OpaqueTypeFinalizer get staticFinalizer;

  /// Rust type specific drop function.
  ///
  /// This function should never be called manually.
  DropOwnedFnType get dropOwnedFn;

  /// Call Rust destructors on the backing memory of this pointer.
  ///
  /// This function should be run at least once during the lifetime of the
  /// program, and can be run many times.
  ///
  /// When passed into a Rust function, Rust enacts *shared ownership*,
  /// if this pointer is shared with Rust when [dispose] is called,
  /// ownership is fully transferred to Rust else this pointer is cleared.
  void dispose() {
    if (_accessor != null) {
      var accessor = _accessor;
      _accessor = null;

      staticFinalizer.detach(this);
      dropOwnedFn(accessor!);
    }
  }

  FrbDescriptor consume() {
    if (_accessor == null) {
      throw FlutterRustBridgeValueMovedException();
    }
    var accessor = _accessor;
    _accessor = null;

    staticFinalizer.detach(this);
    return accessor!;
  }
}

typedef DropRcFnType = void Function(FrbDescriptor);

/// Like FrbOwned, except the Rust object is an Rc
abstract class FrbRc extends FrbMutInd {
  FrbRc(FrbDescriptor accessor) : super(accessor);

  /// A native finalizer rust opaque type.
  /// Is static for each frb api class instance.
  OpaqueTypeFinalizer get staticFinalizer;

  /// Rust type specific drop function.
  ///
  /// This function should never be called manually.
  DropRcFnType get dropRcFn;

  /// Call Rust destructors on the backing memory of this pointer.
  ///
  /// This function should be run at least once during the lifetime of the
  /// program, and can be run many times.
  ///
  /// When passed into a Rust function, Rust enacts *shared ownership*,
  /// if this pointer is shared with Rust when [dispose] is called,
  /// ownership is fully transferred to Rust else this pointer is cleared.
  void dispose() {
    if (_accessor != null) {
      var accessor = _accessor;
      _accessor = null;

      staticFinalizer.detach(this);
      dropRcFn(accessor!);
    }
  }
}

typedef DropArcFnType = void Function(FrbDescriptor);

/// Like FrbOwned, except the Rust object is an Arc
abstract class FrbArc extends FrbMutInd {
  FrbArc(FrbDescriptor accessor) : super(accessor);

  /// A native finalizer rust opaque type.
  /// Is static for each frb api class instance.
  OpaqueTypeFinalizer get staticFinalizer;

  /// Rust type specific drop function.
  ///
  /// This function should never be called manually.
  DropArcFnType get dropArcFn;

  /// Call Rust destructors on the backing memory of this pointer.
  ///
  /// This function should be run at least once during the lifetime of the
  /// program, and can be run many times.
  ///
  /// When passed into a Rust function, Rust enacts *shared ownership*,
  /// if this pointer is shared with Rust when [dispose] is called,
  /// ownership is fully transferred to Rust else this pointer is cleared.
  void dispose() {
    if (_accessor != null) {
      var accessor = _accessor;
      _accessor = null;

      staticFinalizer.detach(this);
      dropArcFn(accessor!);
    }
  }
}

That's interesting!
Firstly, some uber-nits: things like external bool sync; can be known at compile time, so no need to be a real field.
As for the design, to be honest, I am quite busy recently so cannot fully load this interesting but huge proposal into my mind and process it ;) So, it may be helpful to clearly state what the proposal is going to solve, probably with examples. For example, imagine "what are we going to tell the future users in the future releases?"

How about something simpler? This proposal does give us the ability to determine shared references vs. owned values (partly, because the existence of Cow and similar types complicate things.) So it is still fine to represent them as *const T or Option<NonNull<T>> where T: DartSafe and allocated on the heap, and since it's raw pointers Rust is more conservative and will not optimize out reads.
However, mutable references and owned types cannot afford concurrent modifications, and will be wrapped in a RwLock<&mut T> or some manner of Cell, and implicitly unwrapped by us, bubbling any runtime errors up as Dart exceptions. One can think of it as an invariant to be upheld by the Dart caller, like how Java has ConcurrentModificationException so everyone understands the limitations of iterating.
// left is understood to never point to right, and vice versa
pub fn do_stuff(left: &mut i32, right: &i32);

FrbMutInd value;
api.doStuff(left: value, right: value); // throws e.g. ConcurrentModificationException
FrbInd another;
api.doStuff(left: value, right: another); // no problem

@Desdaemon, good point, we can do borrow checking amongst arguments when invoking a Rust function from Dart. It would be helpful to identify the requirements of the encapsulation, which I named "descriptor", which is not very creative but also doesn't need to be. Rust values and indirections to values are encapsulated by a descriptor to

maintain state across language boundaries
provide an abstraction of Rust semantics while in Dart
and safely transform type constructors in Rust to facilitate function invocation

To that end, we require that a descriptor,

must be plain old data that can cross language boundaries (ffi.Struct)
must be able to reproduce exactly one of the following:

an owned value
an immutable indirection
a mutable indirection
an owned Rc
an owned Arc

may not be directly instantiated, and is sub-typed for each T, providing all capabilities for the sub-types. (The subtypes may not extend the descriptor.)
when sub-typed, checks for violations of !Send and !Sync using a saved originating-thread ID.
has a value-equality operator (not of the value, but of the descriptor itself)
if representing an owned value, or a uniquely owned Rc or Arc, may pass the value to a callee that will consume the value, invalidating the descriptor.
if representing an (shared) owned value or mutable indirection, may either

produce many const references with lifetimes not exceeding the invocation, or
produce one mutable reference with a lifetime not exceeding the invocation

if representing an immutable indirection, may produce many const references with a lifetime not exceeding the invocation.

Looking first at the following requirements:

must be plain old data that can cross language boundaries (ffi.Struct)
must be able to reproduce exactly one of the following:

an owned value
an immutable indirection
a mutable indirection
an owned Rc
an owned Arc

I feel a tagged union is best suited, which is where the usage field comes into play.
Looking next at these three requirements:

must be plain old data that can cross language boundaries (ffi.Struct)
has a reference equality operator
if representing an owned value or mutable indirection, can either

produce many const references with lifetimes not exceeding the invocation, or
produce one mutable reference with a lifetime not exceeding the invocation

We can do something like this:
pub fn my_function(a: &mut i32, b: &mut i32) { ... }

// generated
pub fn my_function_wrapper(a: RustDescriptor, b: RustDescriptor) {
    my_function(a.into(), b.into());
}

// Eliding the FrbOwned, for explanatory purposes
FrbDescriptor my_rust_int_descriptor = ...;

// Call the Dart binding of the Rust function
my_function_binding(my_rust_int_descriptor, my_rust_int_descriptor);

// generated
void my_function_binding(FrbDescriptor a, FrbDescriptor b) {
    assert a != b; // do borrow checking
    my_function_wrapper(a, b);
}

That is, we can statically generate borrow checking code as part of the bridge. That would have the benefit of raising in Dart before even reaching Rust. I don't know if this is simpler like you had hoped. But I also don't see how any of the requirements could be removed.  Let me know if I'm overlooking something.

Personal update: Just moved house, bought new PC, have to RMA parts. I haven't forgotten and will resume work in the coming weeks. I'll leave this comment for a short time and then delete so as to not pollute the thread. ✌🏻

@coder0xff Take your time! It's OK to leave this comment and not delete it. Sorry to hear the chore housework (if I understand correctly) and hope you get a new good house and PC!

(I should have unlocked it in addition to reopening it)

I won't be able to continue working on this, at least until my circumstances change. Thanks for your upkeep.

@coder0xff It's totally OK, no worries - Ideas, even though not become mature code, are themselves quite valuable, because it is interesting, can inspire future people for more ideas, real code, etc!


Postgres tests failed by ContextualVersionConflict.

I tried running test for deis/postgres (just forked. no modification) and got an error by Wal-e
pkg_resources.ContextualVersionConflict: (google-gax 0.12.3 (/usr/local/lib/python2.7/dist-packages), Requirement.parse('google-gax==0.12.2'), set(['gax-google-logging-v2', 'gax-google-pubsub-v1']))

Complete log is at https://travis-ci.org/monami-ya/postgres/builds/145157860

This issue can be fixed by patching Dockerfile in deis/postgres.
Which is bettter, here or there?

patches are better here. Thanks!

@bacongobbler I sent PR #15. It works on my environment.

I close this issue as the PR #15 is merged.

Thanks again for tracking this down and fixing it @monaka.


Type error on compilation with react loosely lazy late import

Hi, any ideas about this

It might have been a problem with babel transform not understanding function declaration. We usually go for arrow functions. Have you tried with lazyForPaint(() => ... ) ?


npm WARN deprecated<EMAIL_ADDRESS>

We are getting the following warning when installing the CLI:
npm WARN deprecated<EMAIL_ADDRESS>

Expected behaviour - the CLI should install with zero warnings or errors

guess you are suppose to report it to https://github.com/sasjs/adapter that have a dependency on url that looks like it is not being used?

Quite right @jimmywarting, thanks for the spot!  We have an adapter PR underway, @saadjutt01 is investigating.
https://github.com/sasjs/adapter/pull/467

For reference, here is the PR that deprecated querystring: https://github.com/Gozala/querystring/pull/52
As per the homepage:

The querystring API is considered Legacy. new code should use the URLSearchParams API instead.


Add to maven repos

Please help me get this into the maven et al repositories

Done by @ucbjrl, thanks


Add a @Cookie annotation and CookieParameterProcessor

Simplify Feign client which needs multiple cookies in the request.

This function is very useful. we hope we can use it in the latest version.

@OlgaMaciaszek Can you help to check with this?

This function is very useful. we hope we can use it in the latest version.

Please tell me if need any more change.

@topikachu, thanks for the PR. @topikachu @MarkDcc will review this week.

Why introduce a custom annotation when Spring MVC already has one https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/bind/annotation/CookieValue.html

Why introduce a custom annotation when Spring MVC already has one https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/bind/annotation/CookieValue.html

Well, thanks for your information. Change code to use @CookieValue from Spring MVC

@MarkDcc and @spencergibb,
I use the spring mvc @CookieValue instead of the custom one. Please check the new code.
Thanks.


Add English Localization

改善詳細 / Improve details

xxxx(できるだけ簡潔に/as concise as possible)

Have a button to change everything to English on the website.
スクリーンショット / Screenshot

None.
期待する見せ方・挙動 / Expected behavior

xxxx(できるだけ簡潔に/as concise as possible)

All Japanese text becomes English.
動作環境・ブラウザ / Environment

All

As far as I know, we've completed translation into English, but some texts need to be checked by the authorities or other related organizations. Once the translation is approved, we're probably going to commit these changes.
Our core members may also add some details here; I'm just a contributor.

HI. thanks your issue
same reaming issue has been opened #60

@mikkame #60 はfaviconの話のようなので #62 かも...

sorry my bad. updated my comment


Cannot import adatest in python 3.10

got the following error with "import adatest"
partially initialized module 'adatest' has no attribute 'generators' (most likely due to a circular import)

Hello there,
It did work for me but I had to try one of these solutions! I will provide them to you :
Examine your codebase: Look for any circular dependencies between modules or any import statements that may be causing the issue. Circular dependencies can occur when module A imports module B, and module B also imports module A.
Refactor your code: Once you have identified the circular dependencies, you'll need to refactor your code to break the loop. Consider rearranging your imports or reorganizing your code structure to eliminate the circular dependency.
Use local imports: If possible, use local imports instead of importing modules at the global level. Local imports are placed inside functions or specific blocks of code, which can help avoid circular import issues.
Import at the time of use: Instead of importing the entire module, you can import specific functions or classes when you need them. This approach can help avoid importing modules at the global level and reduce the likelihood of circular imports.
Separate functionality: If your code relies heavily on interdependent modules, consider separating the functionality into different modules with clear responsibilities. This can help eliminate circular dependencies and make your codebase more maintainable.
Use importlib.reload(): As a last resort, if you're working with a complex codebase and refactoring is not immediately feasible, you can use the importlib.reload() function to reload the modules. This function allows you to reimport a module, potentially resolving the circular import issue. However, note that this is not a recommended long-term solution and should be used with caution.
Let me know if it works for you finally!


Run CIFuzz continuous integration on PRs.

oss-fuzz provides a GitHub CI integration that would run the fuzzer on a
given pull request for a period of time. The minimum recommended time is
600 seconds, which is the value included in this commit.
See the following link for details:
https://google.github.io/oss-fuzz/getting-started/continuous-integration/

Would be cool if somehow the fuzzer could be configured to focus on code paths that involve code touched by the PR, but I guess that's not an easy thing to do.

It might be worthwhile to only do this (and also the build/test CI) when changes are made to the code (**.cc, **.h), as described here: https://google.github.io/oss-fuzz/getting-started/continuous-integration/#branches-and-paths
Currently this also gets run when only making changes to documentation or fixing a typo in the README.md, which is a bit unnecessary...


Dependencies

It still shows it is open.
On Fri, Sep 10, 2021, 3:09 AM Brendan Rottmund @.***>
wrote:

@.**** approved this pull request.
Did I do it right? Will they merge now?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/az84/Project-2/pull/3#pullrequestreview-750874757,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUCZP4KERNE2ES3EOENNI4DUBEWCTANCNFSM5DVIHVOA
.
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.

Can I merge them now?


Guard remote branch exists in pull-request:create

Q
A

Fixed Tickets
#407

License
MIT

Guard the remote branch exists in pull-request:create

check if the remote branch exists
ask to push when the remote branch doesn't exists but does local
error when the remote branch doesn't exist and not local or not pushed

TODO:

[x] Update test
[x] Fix with partial-matching branch name "407-pull-" matches in "407-pull-create-warn-when-remote-branch-doesn-t-exist-and-ask-to-push" but does not exist itself.

I was not sure about this one because it bloats the command and the method private probably should go to the githelper? maybe not, but just saying. In any case because this is used a lot i am good for usability so merging...

great job @sstok


One-line installation for Pathogen

Faster and more convenient this way (for lazy people 😉)

Thanks :smile:


Ensure Channel.isWritable() works with SslHandlerCoalescingBufferQueue

Motivation:
A regression is introduced by commit 86e653e04fb452c92154e39cd7189615dc0ec323.
The new SslHandlerCoalescingBufferQueue does not update the pending outbound bytes.
Thus the Channel.isWritable() does not work anymore. External implementations that
rely on the ChannelInboundHandlerAdapter.channelWritabilityChanged do not receive
this event anymore if SslHandler in the pipeline.
This is related to issues #2752 and #7264
Modifications:

Introduce PendingWritesTrackerFactory extracted from PendingWriteQueue
increment/decrement the pending outbound bytes when adding/removing
content via AbstractCoalescingBufferQueue methods

Result:
Channel.isWritable() works as expected. External implementations receive
the event ChannelInboundHandlerAdapter.channelWritabilityChanged

Closing this... Please check https://github.com/netty/netty/pull/7322 for a fix which will allow us to keep stuff package-private. @violetagg thanks again!


(Unreverting) Improve specificity of the Reads API documentation.

Add missing docs, increase specificity in several cases, and make some minor style tweaks.
Trying this again after merging too-soon on the original attempt, and subsequently reverting that PR. Reverts ga4gh/schemas#474

+1 -- only affects comments, and all the edits are improvements over where we started.
(Full disclosure -- CH and I worked on these files together during the docathon, so I'm not impartial.)

This is certainly an improvement. I'm +1 modulo the niggle about ordering above.

+1

Any more comments? Is this good to merge?

+1 Reads well. I believe it's good to merge too.

We have the requisite +1-age and elapsed time, so I'm merging. Thanks @calbach, this is a good clarification.


How to use juice in Angular?

Use Juice in angular Project

This issue is a vague usage question, so I'm closing it


Fix issues

Description:

BZ#2042609 policy was still copied and never deleted if all clusters were already compliant

Fix: skip policies that are already compliant with all the clusters in the upgrade. Include 2 new fields in the UOCR status:
managedPoliciesCompliantBeforeUpgrade (to list the policies that are compliant when the upgrade starts) and   managedPoliciesForUpgrade (policies that will be copied and enforced as part of the upgrade)
Fix: if the upgrade starts with all the policies compliant then it moves directly to UpgradeCompleted

BZ#2042502 Canaries are ignored if they are not included in clusters in UOCR

Fix: include check in validateCR and error if a canary cluster is not included in the list of clusters

BZ#2042517 upgrade pods crashed after applying UOCR without remediationStrategy spec

Fix: Make remediationStrategy and maxConcurrency requested fields. Leave the timeout default to 240 for now

BZ#2042601 upgrade started when blockingCR failed silently

Fix: Check conditions of UOCR and consider CR as not completed  if the conditions are nil

BZ#2040833 UOCR validation should not fail due to maxConcurrency larger than cluster count

Fix: maxConcurrency is automatically adjusted to min(#clusters, 100, Spec.RemediationStrategy.maxConcurrency) if the
initially requested maxConcurrency is larger than that minimum

add KUTTL tests for: skipping compliant policies, blocking mechanisms, upgrade that starts with all the policies compliant, adjusting the maximum concurrency

/retest

/retest

/retest-required

/retest-required


Updated docs with latest AWS pics. 🖼

Also hopefully fixed the logo resizing bug...

Coverage remained the same at 63.617% when pulling 1f6b7d1ad1d56d174de69e564f936be3f74656e5 on mikegrima:docFixes into ee673a8e1a1ee82657359d6b8f13fe7dfeaf3075 on Netflix:develop.


NFC interface for library with samples

Added

PCSCDevice for generic reader
ACR1252UPCSCDevice for ACR1252U and compatible readers (mostly from acs)
library almost not changed
pyscard - optional dependency (in pcsc.py there is a flag UseNFC that can turn NFC off)

Examples:

get_info_nfc - general NFC demo
acr122u.py - work with acr122u reader and compatible via direct apdu channel
acr1252u.py - work with acr1252u reader and compatible via control channel
u2f_nfc.py - demo of u2f operations via NFC
modified credential.py - work with fido2 via NFC

issue here: #47

it seems all is ok.

Thanks for your work on this. While I haven't yet had a chance to look at a deeper level into the code, I've had a cursory glance and have tested to see that it works on my machine (It does!). A few notes from my end:

The dummy PCSCDevice implementation seems unnecessary, I'm perfectly happy with import fido2.nfc and import fido2.pcsc failing if pyscard isn't installed. As long as CtapHidDevice can still be used without pyscard that is sufficient. The examples can use something like:

from fido2.hid import CtapHidDevice
dev = next(CtapHidDevice.list_devices(), None)
if dev is None:
    try:
        from fido2.nfc import CtapNfcDevice
        dev = next(CtapNfcDevice.list_devices(), None)
    except ImportError:
        pass  # No NFC support

if not dev:
    print('No device found')
...

I'm reluctant to include features which are not strictly related to FIDO2, like LED control, and so on. I also don't want to have reader-specific classes. I'd prefer get rid of the abstract _PCSCDevice class and just have a single PCSCDevice implementation. Or, alternatively, to move the remaining code from pcsc.py into nfc.py and just use the smartcard module from the CtapNfcDevice class directly.

Please change function names and variables to use snake_case rather than CamelCase for consistency with the rest of the library.

CtapNFCDevice should be renamed to CtapNfcDevice for consistency with CtapHidDevice.

camels and so on fixed.
readers stuff moved to another classes.
Why I think readers must be there:

Some readers dont work with contactless cards by default. They need to transfer command via special commands or control sequences (like acr122u-sam or touchatag) and people needs to make them work. (ill add this ACR reader later). This readers are very common because of their's low price.
Some readers needs to be configured to on|off field and anti-collision card. sometimes they just dont do anything with card without configuration
Too complex code to make pos 1 and 2. needs to have too much experience to make some of readers to work
as a sample for developers. they will know how to add their specific reader. and know some "magic" constants. I see only 1 comment with this constant in the internet(

but... i can remove this code or move it to samples if you want

Thank for the changes!
Getting the reader version, and the LED control code, is still not needed for FIDO functionality, correct? I would like to drop that from the library. I'd be ok with an example showing how to use this extra functionality, as acr1252u.py does, but keeping the reader specific code in that example file (invoking PCSCDevice.control_exchange manually, etc.), with comments describing what is done and why.
I would like to save the user from having to perform a bunch of magic ceremony for each reader, but the way I see people using this mainly is the developer wanting support as many readers as possible, and not necessarily knowing what type the end user has. Do you have any links to documentation about the specific configuration needed for these readers?
I'd prefer if the CtapNfcDevices returned by list_devices connected to the card in the constructor to avoid introducing the internal state. CtapHidDevice currently does this. This likely would mean adding some additional mechanism to list readers, as the user may need to be prompted to present the Authenticator if there is an NFC reader available. I think a reasonable approach would be that PCSCDevice connects to the card, and that CtapNfcDevice selects the applet (in their respective __init__ methods), and no internal state variable would be needed.

Do you have any links to documentation about the specific configuration needed for these readers?
it from reader's SDK. like https://www.acs.com.hk/download-manual/1083/API-ACR122USAM-2.01.pdf
but sometimes it not have all needed information( then libs decompile or forums or etc..

looks like all is ok

Hi, cool stuff!
Here's some notes (that apply to the library code, not the examples):

The logging module should be used instead of print, and in general I would reduce the number of logged messages.

For consistency with the rest of the codebase ifs with multiple conditions should not have parentheses around each condition.

There are multiple instances of except Exception; it would be better to catch the actual excpetion or at least the most specific one.

When raising excpetions it would be better to create and raise specific ones, Exception is too generic.

I did not have the time to test this yet, but my impression is that some code would work only with Python 3. The library must also work with Python 2, at least as long as it is supported.

except Exception - looks like SmartcardException is maximum. I can disassemble it, but there may be many exceptions and sometimes they not predictable.
About python2 - ill try it on holidays. some time ago it worked.

looks like it cant import nfc module from python 2.7.

now it works in python 2.7
but...
travis tests returns AttributeError: 'module' object has no attribute 'test_nfc'
local tests works OK
dont know....

ok
i have checked - it works on python 2.7 and python3
so all is ok

done

Sorry for this dragging on a big. I'm mostly happy with things now, though there are a few things I'll likely want to change. I think we need to do some more thinking around some parts though, so I'm leaning more towards merging this now into a development branch (see the next branch) and probably making some changes to it later (hope you don't mind!).
Would you mind rebasing off of the next branch and squashing your commits into a single one?
Also, as this is a substantial contribution, please state that you contribute this code under the license of the repository (2 clause BSD).

I dont mind to merge it to next branch.  Maybe needs to update the next branch.
Its OK as for license. I know.

@dainnilsson may you help me to squashing my commits into a single one?

I can certainly do that, but I'm not sure if you'll still be listed as the author on the commit if I do, would you be ok with that?

its ok

Thanks for your contribution, these changes have now been merged into the next branch, which will contain active development until it is merged into master!


Add full support for typing, Ruff and Pyright, and do some touchups

Tagging a release after pull would be much appreciated

Fully type the module, drop the need for os module, drop deprecated typing conventions
Mark project as supporting typing
Bump devel to 2.5.0
Update supported Python versions to currently supported upstream versions
pyproject.toml: Add basic Ruff and Pyright rules
Touch up Readme a little, update listed function to match reality
Update CI

Squash when merging please.

Hey!
Thanks for the contribution. I looked briefly at the PR so far. I like that you added full typing to the project.
I have some questions:

Why is it necessary to drop support for Python 3.7 and 3.8?
What are the advantages of ruff and pyright over mypy and flake8? How do you use them, if they are not included in code-quality-check workflow?

Why is it necessary to drop support for Python 3.7 and 3.8?

Python already dropped them upstream.
Users wishing to use insecure EOL Python versions can simply keep using an old version of the library that last still supported it.

What are the advantages of ruff and pyright over mypy and flake8?

Ruff directly replaces flake8 and a couple other tools, and is much faster.
https://github.com/astral-sh/ruff?tab=readme-ov-file#ruff
I'd suggest you check it out on your dev env when you have the time - https://github.com/astral-sh/ruff

How do you use them, if they are not included in code-quality-check workflow?

For development, as plugins in VSC.

I don't mind replacing flake8 and even mypy with newer, equivalent tools. But I think the proper way to do this is to fully remove the old tools and replace them with the new tools in code-quality-check workflow. What do you think?

I don't mind replacing flake8 and even mypy with newer, equivalent tools.

Note that I have not replaced them, I simply added support for Ruff(and Pyright) too, for those that use them in their envs.
The diff may look a bit odd about removals at a glance, since the tools are now sorted alphabetically.

I think the proper way to do this is to fully remove the old tools and replace them with the new tools in code-quality-check workflow. What do you think?

That'd be the best, but I didn't want to dive into that in this PR, I just needed my env to work correctly

Okay, I am ready to merge this PR after you remove sys.platform != "win32" checks.


[Issue]: Test Prerequisites - Points to Rajy's JPEG Turbo Branch

Problem Description
https://github.com/ROCm/rpp/blob/develop/utilities/test_suite/README.md --
sudo apt-get install nasm
sudo apt-get install wget
git clone -b <IP_ADDRESS> https://github.com/rrawther/libjpeg-turbo.git
cd libjpeg-turbo
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr \
      -DCMAKE_BUILD_TYPE=RELEASE  \
      -DENABLE_STATIC=FALSE       \
      -DCMAKE_INSTALL_DOCDIR=/usr/share/doc/libjpeg-turbo-2.0.3 \
      -DCMAKE_INSTALL_DEFAULT_LIBDIR=lib  \
      ..
make -j$nproc
sudo make install

Solution
Use same JPEG Turbo version as in rocAL
Operating System
ALL
CPU
ALL
GPU
AMD Instinct MI300
Other
No response
ROCm Version
ROCm 6.0.0
ROCm Component
rpp
Steps to Reproduce
No response
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response

@r-abishek -- needs upgrade to the documentation

@kiritigowda PR #419 should address this


Fixed #160 - Crash when using labelFor attribute

Having a labelFor attribute was causing crashes in the CalligraphyFactory due to an uncaught ResourceNotFound exception. We should be catching this exception and treating it the same as if the view had NO_ID.

does does lableFor do to cause the crash. It seems odd that having id not set and labelFor set causes a crash? I would like to get to the underlying cause instead of just headlessly patching it.


refactor CI using provision-with-micromamba

This PR updates the environment setup in unittests.yml to take advantage of provision-with-micromamba. It is based on the current CI schema in spaghetti where runtime is reduced by approx. half.

@knaaptime Any thoughts on getting this passing?

i think we could probably skip the notebook tests here. The line that's failing is trying to use ltdb data, which we have to download privately. For the main tests, that happens in this script, but i dont know why the data dont seem to be available to the next process. As an alternative, we can keep the notebook examples in a separate repo and have that test separately

i think we could probably skip the notebook tests here. The line that's failing is trying to use ltdb data, which we have to download privately. For the main tests, that happens in this script, but i dont know why the data dont seem to be available to the next process. As an alternative, we can keep the notebook examples in a separate repo and have that test separately

OK. Well then I think this PR is good to go if you like it.


Protocol Status Implementation

What's the problem? (required)
Protocol status is not shown in the explorer.
What's the current behavior? (required)
No protocol status
Describe a possible solution you've considered (optional)
Create a modal for protocol status.
The information displayed in the modal are:

# blocks until next round (already in Round.js in graphql.  Look at graphql-sdk for example.  For UI example, look at explorer/src/components/BasicNavbar.js -> connectCurrentRoundQuery for example)
Max active transoders (add bondingManager -> getTranscoderPoolMaxSize to sdk first)
inflation per round (waiting for https://github.com/livepeer/livepeerjs/issues/116)
target bonding rate (need to be added to the sdk first)
# LPT bonded (need to be added to the sdk first, and then graphql)
unbonding period (already in sdk, need to be added to graphql)

Implementation Instruction

Add a "Status" callout next to the green round indicator on the top left.  This should trigger the modal.
Create the modal, set up the proper layout for displaying the information (# blocks until next round, max active transcoders, inflation per round, target bonding rate, # LPT bonded, unbonding period).
For this gitcoin issue, you only have to add # blocks until next round.

Additional context (optional)

This seems related to #12 (requirement for adding "protocol status" metrics).
Unfortunately, this layout would break the nav (too tall). And currently, the explorer doesn't keep track of what the current block is. So first, we nee 1) a different UI and 2) to do the groundwork to add block tracking into the sdk, and subsequently, model it in graphql-sdk package.
The sdk/graphql-sdk part can be addressed immediately. However, before settling on a UI, my recommendation here is to ask a question -- what other metrics are similar to this one and might want to be seen in tandem? Then, come up with a cohesive visions of where they should all live -- a page, a modal. If it is the case that there are related metrics but they do not need to be seen together, then it would still be good to analyze specific contexts in which are most relevant.
My first instinct is that the "network/round badge" should open a modal with more detailed information when clicked. But it would be good to understand what content that modal would contain and to also brainstorm other options.

Related to the block.number not being available in the sdk, and asking what other metrics we may want to see that are similar...
Is it worth considering exposing a web3 wrapper in graphql itself? I ran into this during the hackday that I wanted to use web3 getters, and I couldn't access it directly. If the idea is that everything runs through graphql queries, then maybe just exposing a separate module that makes web3 data accessible generally would be more helpful than adding specific values one by one as needed. See https://www.reddit.com/r/ethdev/comments/8dbqnh/creating_a_graphql_wrapper_for_web3js_looking_for/

@dob That's exactly how it works currently. The sdk is our web3 wrapper, and it is used to resolve data in the graphql-sdk. See getting an account's ETH balance, for example.

I agree with @jozanza's instinct of opening up a modal for protocol parameters.  But I think there should be a callout along the line of "protocol params".
I think we can expose 6-8 parameters that an average user would care about in the modal.  My proposal:

currentBlock vs. nextRoundStartBlock
unbondingPeriod
numActiveTranscoders
inflation
targetBondingRate
currentBondingRate (Total LPT vs. Bonded LPT)

@iamonuwa thanks for applying! Gonna give this one to @palevoo because he has been talking to me offline about it. I'm making a few other bounties, and let you know :)

@ericxtang, have released it. Thank you

@ericxtang This new description and mockup look really good!


[airflow] Updates README.md with better instructions for installing extra dependencies

What this PR does / why we need it:
Instructions on how to install extra Python dependencies were not very clear. Additionally, the option to install them by placing a requirements.txt to the root of the DAGs folder seemed to be only possible for an init-container strategy. That is not the case, since this method also works for a shared persistent volume strategy.

/assign @gsemet

/lgtm


i want to  setup selected day/today/other unselected day's  text color and backroundcolor

[x] I have verified there are no duplicate active or recent bugs, questions, or requests
[x] I have verified that I am using the latest version of CVCalendar.
[x] I have given my issue a non-generic title.

Expected Behavior

i want to this
today always is :textColor:white  backgroundColor:blue
selected day always is :  textColor : red  backgroundColor : white

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

i don't Understand this attribute：－－－－－ CVStatus  point  Which states
@objc public enum CVStatus: Int {
case in, out, disabled, selected, highlighted
}
i use these methods
func dayLabelPresentWeekdayTextColor() -> UIColor {
    return UIColor.red
}

func dayLabelPresentWeekdaySelectedBackgroundColor() -> UIColor {
    return UIColo.red
}

func dayLabelWeekdaySelectedTextColor() -> UIColor {
    return UIColor.white
}
func dayLabelWeekdaySelectedBackgroundColor() -> UIColor {
    return UIColor.blue
}

Result is ：
selected other day :textcolor->white  /backgroundColor:blue
current day:textcolor->red  /backgroundColor:red
unseleted day : textcolor->black  /backgroundColor : white

selected current day:
selected current day :textColor:white /backgroundColor:red
other day : textColor:black /backgroundColor : white

Context

Your Environment

Version used (Cocoapods spec):
Device used i.e. iPhone 6S:
Physical device (y/n):
Link to your project (if available):

How to add dot under day number if had task?

Same issue


5pm 2 favicon

As of right now, needs a PR description (the description is entirely blank).   Anyone on the team can fix this; just get the information from the linked issue and do a copy/paste.;


Clarification?

On this line, I'm thinking it shouldn't say to run the command-line but rather copy and paste it (without the ccmsetup.msi) into the Intune app that is being created?
5. After the app is updated, configure the app information by running the following command-line argument:

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7294682b-1bfb-54e4-0bdb-178e6fe2cc9a
Version Independent ID: 6c5f1cfb-ae12-1fd2-80ef-1f67e419f4c5
Content: Prepare Windows 10 for co-management - Configuration Manager
Content Source: sccm/core/clients/manage/co-management-prepare.md
Product: configuration-manager
GitHub Login: @aczechowski
Microsoft Alias: aaroncz

Yes, thanks @russrimm for the feedback. I hope to rework this entire article in the near future.


[FR] Metaparts

Is your feature request the result of a bug?
No
Problem
Alternative concept to PartKeepr Metaparts
Suggested solution
Having used PartKeepr for a number of years the lack of development and bugfixes is getting a bit problematic.
InvenTree seems to be a much more mature and modern platform but I think lacks one major concept for Electronics which PartKeepr actually does rather well, Metaparts
https://readthedocs.web.cern.ch/display/PARTK/03+-+Meta-Parts
It works really well, because you can use generic parts in projects but real parts which are filtered based on parameters.
InvenTree supports parameters but I don't think the concept of Metaparts, or any similar method?
Describe alternatives you've considered
NA
Examples of other systems
Show how other software handles your FR if you have examples.

Do you want to develop this?
Yes, but I have limited web development experience.

I believe that the existing concept of "template" parts would fit here. You can have a generic master part that you put in your BOM, and fulfil the requirement with a specific variant part
https://inventree.readthedocs.io/en/latest/part/template/
Does this fit your requirement?

That may be similar, though would require manually setting up each time a new part is bought? the nice thing about Metaparts is that it's purely based on parameter filters.
For example a 10K 0402 1%

0402 100nF 16V X7R 10%

@SchrodingersGat from the examples this seems to be a use case for variants?

@chrissnow ah I see what you mean about specifying parts simply based on parameters. Currently we don't have the framework to support that. There are some roadmap items to improve our parameter functionality (which is currently pretty meagre) but nothing like the full "meta part" concept.

@chrissnow closing this issue out as stale. Please let us know if you would like to discuss it any further.


Parameter maxDaysToShow not consiered correctly anmyore

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Since version v7.7.1 or v7.7.2 the parameter maxDaysToShow is not considered correctly anymore.
I have one card for birthdays, maxDaysToShow is equal to 1 to show only todays birthdays (all-day events)
but the card is showing also the (2) birthdays of the next day.

Expected behaviour
Parameter maxDaysToShow is consiered correctly
Steps To Reproduce
No response
Mode
Event (default)
Card Version
v8.0.0
Home Assistant Version
2023.9.2
Configuration
type: custom:atomic-calendar-revive
enableModeChange: true
entities:
  - entity: calendar.geburtstage
    name: Geburtstage (Bastian)
    icon: mdi:cake-variant
    showMultiDay: true
  - entity: calendar.geburtstage_2
    name: Geburtstage (Mareike)
    icon: mdi:cake-variant
    showMultiDay: true
firstDayOfWeek: 1
maxDaysToShow: 1
refreshInterval: 300
hideDuplicates: true
showProgressBar: true
showCurrentEventLine: false
showMonth: false
showDescription: false
showWeekDay: false
disableEventLink: false
disableLocationLink: false
showNoEventsForToday: true
showFullDayProgress: false
showEventIcon: true
showHiddenText: false
showCalendarName: false
showWeekNumber: false
calShowDescription: false
showLastCalendarWeek: false
disableCalEventLink: true
disableCalLocationLink: true
disableCalLink: true
dimFinishedEvents: true
hideFinishedEvents: false
showRelativeTime: false
showMultiDay: false
showDeclined: false
showMultiDayEventParts: false
showDate: false
showLoader: false
showLocation: true
showDatePerEvent: false
showEventDate: false
language: de
fullDayEventText: ganztags
noEventText: keine Geburtstage heute
noEventsForNextDaysText: keine Geburtstage in den kommenden Tagen
dateFormat: L
allDayBottom: false
sortBy: start

Relevant log output
No response
Code of Conduct

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

Thanks for checking!
Actually I've upgraded already to 8.0.0.
I also did a reboot of HA and the dashboard (not only the preview of the card editor) is showing the event of the next day.
I created 3 birthdays in a row: today, tomorrow and the day after.
   I noticed it because I was trying to create 5 separate cards,  one per day of the week.   Each card should be limited to 1 day and be 1-5 days ahead.   Any help would be greatly appreciated.

Thanks for the info, I think this is a bug introduced with the latest changes they have been quite substantial to the way events are handled it's likely this messed something up.
I'll take a look as soon as I get chance.

Please could you install v9.0.0-beta.1 issues around  this should be resolved as part of that.
Let me know if you have any issues.


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/104865

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/111132

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/111325

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/113340


XCode: "custom destination platform" option is always used if set regardless which item is selected from the dropdown

Issue Description

Create a build with an 'Xcode build' phase
Enter a string in the "Custom destination platform" box
Switch to a different item on the Destination platform drop down
Save and queue the build

The previous entered "custom desitination platform" still ends up being sent to the xcodebuild agent. It should not as it is fairly confusing to track down why that's still happening.
It seems this is the bug.  We always honor what's set in "custom destination platform" field.

Closing since this is being tracked on https://developercommunity.visualstudio.com/content/problem/193958/xcode-entering-a-custom-destination-and-then-chang.html


dev-cmd/cat: improve error message.

Fixes #14815.
CC @gromgit @EricFromCanada @apainintheneck for messaging thoughts.

Review period skipped due to critical label.

@reitermarkus @gromgit thanks both!

FYI, I added a suggestion to use brew info --github formula|cask in #14902