Add JWT support as an option for sign in

Since we start to support sign in Via JWT. need to change TSC as well for adopt this feature.
this CL:

changed the TSC for JWT sign in support
update the sample/login as an example
create another example of invoking API using JWT

Hi Jac, if you already have a design for Jwt sign in, I'm up for it as well. Could I review your design as well? If all is good, we can close this CL.

Hi Jac, if you already have a design for Jwt sign in, I'm up for it as well. Could I review your design as well? If all is good, we can close this CL.

It's based on this: https://github.com/tableau/server-client-python/pull/1032


location attachments

Location attachments for migration events

Fyi, @BeckySharp. I don't think this broke anything. The code will still need to be cleaned up, but it seems to be attaching geoloc to loc mentions alright.

nice!
On Tue, Jun 11, 2019 at 9:25 AM Maria (Masha) Alexeeva <
<EMAIL_ADDRESS>wrote:

Fyi, @BeckySharp https://github.com/BeckySharp. I don't think this
broke anything. The code will still need to be cleaned up, but it seems to
be attaching geoloc to loc mentions alright.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/clulab/eidos/pull/600?email_source=notifications&email_token=ABJCPCIBO7NNFKFPPINAWNTPZ7GTZA5CNFSM4HWVQZ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXNWRBA#issuecomment-500918404,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABJCPCJIIKDUYBNTJ2SZSPTPZ7GTZANCNFSM4HWVQZ5Q
.


Draft: ISS 359 - Connect AsyncSelect to OccupationSelect and smart-soc-list endpoint

DRAFT
https://github.com/codeforboston/jobhopper/issues/359
To-do

Main test should probably pull from the fake API instead of the live API for national/state tests (need to debug)
Code cleanup

Changes

Adds awesome-debounce-promise package
Adds debouncing to user input
Takes user's input for occupation select search and routes it to the smart-soc-list endpoint, returning an occupation that's routed to the transitions-extended endpoint (like before)

Example

Current deployment:

After changes:

Thanks for the review & fixes, Alex!!


fixed issue sans ips not returned by x509 extension class

I generated a certificate in hashicorp-vault, along with 2 SAN DNSs and 2 SAN IPs, the subjectAlternativeNames field on the X509Certificate class only returned the 2 DNSs while the 2 IPs were lost. For e.g. when I enter the sample IP "<IP_ADDRESS>", on line 71 of X509ExtensionAltName the variable item.value contains |\0\0\u{2} in Xcode debugger, which is a string represents binary data.
The as? Data cast will only succeed if item.value is already a Data object. If item.value is a String, the cast will fail, even if the string represents binary data.
since item.value is a String that represents binary data, I had to convert it to Data before extracting the IP address, i.e.:
if let ipString = item.value as? String {
let ipData = Data(ipString.utf8)
return ipData.map({ "($0)" }).joined(separator: ".")
}
with that fix, X509Certificate!.subjectAlternativeNames finally returns my SAN IPs as well as the SAN DNSs.

Hi, thanks for the PR. Actually the current check Data on the value is not reliable and with String which also utf8 conversion is involved. It's better to use rawValue instead.
Here a more comprehensive solution:
if let ip = item.rawValue {
    let separator = ip.count == 4 ? "." : ":"
    return ip.map({ "\($0)" }).joined(separator: separator)
}

Thank you so much Filippo! I’ll test out your suggestion and update the PR accordingly.
Thanks,
Yan
From: Filippo Maguolo @.>
Date: Friday, February 9, 2024 at 7:24 AM
To: filom/ASN1Decoder @.>
Cc: Yan Ding @.>, Author @.>
Subject: Re: [filom/ASN1Decoder] fixed issue sans ips not returned by x509 extension class (PR #40)
Hi, thanks for the PR. Actually the current check Data on the value is not reliable and with String which also utf8 conversion is involved. It's better to use rawValue instead.
Here a more comprehensive solution:
if let ip = item.rawValue {
let separator = ip.count == 4 ? "." : ":"

return ip.map({ "\($0)" }).joined(separator: separator)

}
—
Reply to this email directly, view it on GitHubhttps://github.com/filom/ASN1Decoder/pull/40#issuecomment-1935836677, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BETWK7PCDV5PJMJYUQBNX4TYSYIOJAVCNFSM6AAAAABDAWM5YKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZVHAZTMNRXG4.
You are receiving this because you authored the thread.Message ID: @.***>

@filom Tested your suggestion, it's working fine for my data. I've updated PR according to your suggestion. Thank you again!

Thank you @filom for merging it!, I really appreciate it! Please let me know when you get a chance to push it to CocoaPods, so we can reference v1.9.1 in our podscpec file. Thanks a lot!

Pod released as 1.10.0 version (updated with iOS 12 version required)

Thank you so much!


GetIt Package Manager

Can you please add The-Drag-and-Drop-Component-Suite-for-Delphi to GetIt Package Manager ?

i have no experiance with that.

The-Drag-and-Drop-Component-Suite-for-Delphi is available via the Delphinus Package Manager
https://github.com/Memnarch/Delphinus

I will try to register the component.

ok


MudTable - GroupBy - Virtualize to True not taking any effect

Bug type
Component
Component name
MudTable
What happened?
When I have a "GroupDefinition" and if I enable Virtualization by "Virtualize=true", it was NOT applying virtualization here
Expected behavior
Setting  "Virtualize=true" with "GroupDefinition" should apply virtualization
Reproduction link
https://try.mudblazor.com/snippet/cOmQuQwbbbNgiQqH
Reproduction steps

On click the run here in Try Mudblazor - https://try.mudblazor.com/snippet/cOmQuQwbbbNgiQqH
You might see loading the row might freeze the whole screen
It will take more the 15 sec wait time to render
...

Relevant log output
No response
Version (bug)
6.0.5
Version (working)
No response
What browsers are you seeing the problem on?
Chrome
On what operating system are you experiencing the issue?
Windows
Pull Request

[X] I would like to do a Pull Request

Code of Conduct

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

I can see the issue is with the the code code snippet that doesn't has Virtualize.


Fix configmap volume

POC for #280
I tested the code locally (no automated test yet)  and it does work, however the code is a bit strange. The code has almost nothing to do with Kubernetes anymore. The only thing that relates to kubernetes is the way Kubernetes changes data in mounted volumes.
The game.properties file is actually a symbolic link, so you cannot have watch events on this. Every time the files are changed, Kubernetes creates a directory like: ..2021_03_18_17_30_18.531648931 and creates some temp folders and deletes the old ones.
These are the events fired every time a change happens in chronological order:
File at path ..2021_03_18_17_30_18.531648931 changed. Firing change event: ENTRY_CREATE
File at path ..2021_03_18_17_30_18.531648931 changed. Firing change event: ENTRY_MODIFY
File at path ..data_tmp changed. Firing change event: ENTRY_CREATE
File at path ..data_tmp changed. Firing change event: ENTRY_DELETE
File at path ..data changed. Firing change event: ENTRY_CREATE
File at path ..2021_03_18_17_17_29.703573822 changed. Firing change event: ENTRY_DELETE

In the code I just listen to the 1 MODIFY event, remove all propertysources and add them all back again after.
Maybe this code should be in a different repo as another bootstrap/client-config/hot-reload file repo. Instead of using Consul,  Kubernetes,... you just use files to drive you configuration and have the possibility to change them on the fly.
bootstrap.yaml to make this work
micronaut:
  application:
    name: micronaut-service
  config-client:
    enabled: true

kubernetes:
  client:
    enabled: false
    watch: true
    config-maps:
      enabled: true
      paths:
        - /etc/example-service/configmap
    secrets:
      enabled: true
      paths:
        - /etc/example-service/secrets

Looking forward to ideas.

@rdesgroppes are you interested in this pull request/feature? I did manage to get something working. I am still using the normal file watcher, but this time to only look for CREATE of the folder "..data"
I can update this POC with my new code, but I have problems writing tests for this in the micronaut code repo.

@StephanePaulus Unfortunately, I can't devote time to it this year.


Optional automatic re-import of resources

Some engines like Unreal Engine 4 offer an option to automatically re-import any resources that are modified. Currently, Godot will notify you when some of your assets are modified, but won't automatically re-import them.
I guess an option to re-import them automatically would make sense.

Yeah, now that we can probably do away with the 3D import/merge options it
could be easier
On Sat, Dec 26, 2015 at 11:17 AM, Calinou<EMAIL_ADDRESS>wrote:

Some engines like Unreal Engine 4 offer an option to automatically
re-import any resources that are modified. Currently, Godot will notify you
when some of your assets are modified, but won't automatically re-import
them.
I guess an option to re-import them automatically would make sense.
—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3139.

Sounds good to me so long as we can be sure nothing in the scene breaks during the update process (ie. making sure all outstanding import/re-import issues are fixed), it will make iterating that much quicker.

Hm, has the situation changed since 2015? :smile:

This was implemented in 2.1
On Sat, Sep 24, 2016 at 7:34 AM, Bojidar Marinov<EMAIL_ADDRESS>wrote:

Hm, has the situation changed since 2015? 😄
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/3139#issuecomment-249357999,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2wd6Ac4veA__mlrspDOc8G9sU0p4ks5qtPzAgaJpZM4G7dH8
.

AIUI now it's automatic but not optional.

I'd propose to close it as fixed, since the current situation is now different to the one that prompted asking for an optional auto-reimport.
If some users have a need for disabling auto-reimport, they'll open a new issue against 2.1 or 2.2-dev.


Add tuple cons cell syntax

Add syntax for expressing tuples as a head and tail pair, similar to a Lisp cons cell.
Rendered

One possible alternative syntax is (a, b, ...more_elms), like JavaScript, but that would conflict with the inclusive ranges RFC (not stable though).  Ruby and Python use * for this, which would definitely be unsuitable here for obvious reasons.

If you’re proposing syntax changes/additions/removals, please strive to describe the changes in terms of changes to the grammar in the RFC as well.

Yay, variadic generics.
I think tuples shouldn't be considered in isolation, the solution should cover all heterogeneous type/value lists, with function parameters/arguments being, probably, the most important.

I feel like there must be some kind of complications around this but I can't think of them at the moment. Maybe they'll come to me later. If there actually aren't then let's definitely do this.
Is there any use case where you would ever want to use this outside of trait impls?

One possible alternative syntax is

Thanks, I've updated the RFC to mention other syntaxes.

If you’re proposing syntax changes/additions/removals, please strive to describe the changes in terms of changes to the grammar in the RFC as well.

You mean supply a diff for parser-lalr.y with the RFC?

Yay, variadic generics.

Ah, I'd forgotten about that RFC.

I think tuples shouldn't be considered in isolation, the solution should cover all heterogeneous type/value lists, with function parameters/arguments being, probably, the most important.

Good point. The RFC as it is would at least get you some of the way there because it would be possible to impl<H, T: Tuple> Fn<(H; T)> for Foo

Is there any use case where you would ever want to use this outside of trait impls?

Not that I can think of. You do need to be able to pattern-match on generically sized tuples in order to write those trait impls though (eg. let (ref head; ref tail) = arg).

It occurred to me that this could be extended for structs, perhaps with some sort of brace-based syntax (I consider the syntax unimportant because I have a feeling this would be a separate RFC).
basically, in some sense, a struct is itself a tuple, with types equivalent to the types of the fields as declared in the struct.  If the syntax were to be extended to structs, it would provide a method to implement traits that apply if all contained fields of a struct implement a specific trait.  This would be hard to work with for traits that actually do things, but might be useful for marker traits (but then we need a syntax to opt out which I'm not sure we have).
Possibly I'm saying the same thing @petrochenkov  is.
On another note, this gets us to within 6 inches of variadic functions and let me be the first to say that I'll certainly be entering the race to submit that RFC, should this one get accepted.  Speaking as a C++ programmer, I don't use them often.  But they're a godsend when they're needed.

The type (A, B, C) is packed like a struct, and it does not in general contain a subrange of it that has identical representation with the tuple (B, C). Because of that you can not in general take a reference to the tail.
 Is the representation of tuples set in stone?

Also, not sure whether to close this and just turn it into a comment on #376. It's the same basic idea as that RFC just done a little bit differently.

The representation is not set in stone. That the (u8, u8, u64) would use 24 bytes instead of 16 doesn't sound like a workable alternative though.

Would a workable alternative be to be a bit cleverer about how we do padding? We could represent a (u8, u64) as 16 bytes where byte[0..7] are dummy bytes, byte[7] is the u8 and byte[8..16] are the u64. Then we can represent a (u8, u8, u64) the same way except with the first u8 at byte[6].

@canndrew It's an interesting idea and it fixes some cases, but the rule does not handle this example
type T = (u32, u8, u8, u16);
type Tail = (u8, u16);

The tail of T would point to the last four bytes, the front byte being "padding" but also a value byte of the part outside of that (u8, u8, u16), which means that a mutable pointer to Tail could overwrite the value byte "outside" the tuple.
This kind of cons-tail scheme seems to be much easier to work out for value-only destructuring (which may require copying).  Just notice today how much (A, B, C) and (A, (B, C)) can differ in size depending on the types involved, they are definitely not represented the same way.

which means that a mutable pointer to Tail could overwrite the value byte "outside" the tuple.

Not if we ensure that modifications to a tuple never modify any "padding" bytes at the start of the tuple. I imagine this might cause extra overhead some of the time. For example it might be more efficient to modify the u16 of a (u16, u32) by overwriting the first 32 bits.

It's incompatible with all the tools of a low level language like rust, that assumes it can for example memcpy over the whole memory of a value (like std::mem::swap does).

Right, of course. Well that screws this whole plan then as far as I can see. You can't implement &self methods on a (H; T) if you can't take a reference to the T.

This also sounds potentially related to https://github.com/rust-lang/rfcs/issues/1397

It seems like this can not be done in regular rust reference to compound type parts semantics, instead variadic generics needs its own syntax and semantics.

@bluss Actually, if we implemented the suggestion in the link @glaebhoerl posted it seems like we could do this. Just layout tuples the other way around than to what I was proposing.

There is an unused syntax, (head, tail...), because x... doesn't offer much value over x.. (maybe with floating-point it would include Infinity itself, but do we really need that?).
I like the solution for the representation incompatibility, seems easier than my contraptions to turn e.g. &(A, B, C) into (&A, &B, &C) (which work, mind you, but are still non-trivial).
I'm cc-ing @ubsan as them and I have experimented with (working) prototypes of variadic generics, one of mine being https://play.rust-lang.org/?gist=030b0b74b3a72eecd09d567368a592bb&version=nightly.
What's really cool in that one is that CloneFn is for<T> <T as Clone>::clone and we might be able to keep that polymorphism on function item types so that you can do .map(Clone::clone) on a tuple.

Ah, I should've known it was too good to be true.
Do you plan to waste space on unnecessary padding to make this happen?
That is, the (u32, u8, u8, u16) example above would have to be laid out like (u32, (u8, (u8, u16))), which has 2 extra padding bytes.
In that case, I prefer my "take references to all fields" contraptions.

@eddyb It works with #1397. But you have to either layout the tuple fields in reverse order or treat tuples as a prefix+final_element pair rather than a head+tail pair.

@canndrew I see your point about the reverse layout order. Seems interesting to say the least. It makes sense that to add an element (the head) and keep the rest (the tail), you need to add it at the end.
As for (Prefix..., Final) being the default way of working on tuples, it doesn't sound tractable, since most implementations I can think of need left-to-right evaluation.

Yeah I'd prefer reverse layout order.

I'm wondering why do we need extra syntax (";" or "...") for this feature at all.
What we can do is just group extra elements in a tuple:
(head, tail) = (1, 2, 3, "4") // head = 1, tail = (2, 3, "4")

Am I miss some Rust feature that prevents this?

@HaronK You can't do that without knowing you have a type mismatch first, so what if you need to retcon it?
Making the following work is impossible in the current type-checking system:
let x = (1, 2, 3);
let y: &(_, _) = &x;

You also still need a syntax for expanding a tuple value/type in-place and (variadic) function arguments.

I understand that it's not possible right now. That's why we have this RFC. I only suggest instead of extending tuple syntax, update current type-checking system to group tail part of the tuple.
(I have updated an example code in my previous comment)

@HaronK So that (T, U, V) is sugar for (T, (U, V))?
Because then, if you have an impl of the same trait for both (A, B) and (A, B, C) that would then error as overlapping (where it previously wasn't).
And by "type-checking system" I meant the entire type-checker. It's not going to be rewritten from scratch to be more magical for just one feature, especially when we can design that feature better.

Tuples are just semantically ordered sets of values, the actual memory representation is irrelevant. So we could simply swap the order in memory...
#[repr(C)] tuples obviously need to stay in the old format, but those could simply not support subtupling (similar to no internal references for #[repr(Packed)])

Can we think of a tuple like a packed struct, but where references to the head but not the tail are permitted?

@Ericson2314 But then you can't recurse for e.g. a Clone implementation, which was the whole point. I know how to do a Clone implementation by first producing a tuple of references to all the fields, and then recursing on that with a different trait, but it get (much) messier.

I feel like with specialization it might still be possible if (ref x; (ref y; _) is valid.

@canndrew Food for thought: reversing the order of fields allows (ref head, ref tail...) but disallows (ref prefix..., ref last), whereas my "take references to all fields" approach works for both usecases.

"take references to all fields" is pretty good, will might make for inefficient code? all those offsets becoming independent pointers? If we had non-movable types, we could have "tail-tuple-types" which don't have a packed restriction but are indexed with their offset so they can compute padding properly.

@Ericson2314 it gets monomorphized so SROA would just make quick work of it. In the case of Clone on Copy types, it would be equivalent to copying each field in turn, which should get optimized to a single memcpy.

If the (ref prefix..., ref last) destructuring works with current default tuple layout, why not use that? It is just the reversal of the other scheme, so it should have equal power.

@bluss You can't use it directly for evaluating anything that's normally LTR.

Can the Tuple trait of a Tail/Prefix associated type? I think that might help reduce the one-off traits. proposed here.

@Ericson2314 Depends, you might need 2 traits just to distinguish tuples that have at least one element from () (and have the compiler understand that Foo<T>: Tuple doesn't depend on T if Foo is a structure or enum).
The one approach which I really like is https://play.rust-lang.org/?gist=030b0b74b3a72eecd09d567368a592bb&version=nightly (sorry for linking it again, but maybe you haven't seen it yet).

Actually, make that Tail, Prefix, and give constructors and eliminators, then (... ; ...) is just sugar.
impl<T: Tuple> Debug for T where T::End: Debug, T::Prefix: Debug { .. }

almost works

I was keen on this idea for a while pursued it vigorously, but eventually I backed off from it, primarily because of the layout complications. I see there has been plenty of discussion about this in the thread, though the RFC text itself doesn't seem to mention it at all. I would suggest that this isn't quite ready for RFC yet, perhaps we should close the RFC and move the discussion over to the existing tracking issue instead? (https://github.com/rust-lang/rfcs/issues/376)

@eddyb

Food for thought: reversing the order of fields allows (ref head, ref tail...) but disallows (ref prefix..., ref last), whereas my "take references to all fields" approach works for both usecases.

That's true, but you can also append to the end with (H; T) style tuples by writing a trait for it
trait AppendEnd<X>: Tuple {
    type Output: Tuple;

    fn append_end(self, val: X) -> Self::Output;
}

impl<X> AppendEnd<X> for () {
    type Output = (X,);

    fn append_end(self, val: X) -> (X,) {
        (val,)
    }
}

impl<X, H, T: AppendEnd<X>> AppendEnd<X> for (H; T) {
    type Output = (H; T::Output);

    fn append_end(self, val: X) -> (H; T::Output) {
        let (head; tail) = self;
        (head; tail.append_end(val))
    }
}

Of course, that's a hellavu lot more cumbersome than your syntax.
@Ericson2314

Can the Tuple trait of a Tail/Prefix associated type? I think that might help reduce the one-off traits. proposed here.

Not all tuples consist of a Head+Tail/Prefix+End pair. Only tuples of the form (H; T) do, and if you've got one of them then you already know the head is H and the tail is T.
@nikomatsakis

perhaps we should close the RFC and move the discussion over to the existing tracking issue instead? (#376)

Fine by me.

I've decided to reopen this as it's a strict subset of the variadic generics RFC and can be implemented beforehand. The variadic generics RFC still has major unresolved questions, however for the specific case of generic tuples I can't imagine it being done any differently to what's described here.
I've also expanded the RFC to discuss (and tentatively pick a position on) the representation issue as well as specify the grammar for the new syntax.

@eddyb if we wanted to use (prefix..., last) syntax instead, do you think it would be worth advocating for the inclusive ranges syntax to be changed to ..=?

The variadic generics RFC still has major unresolved questions, however for the specific case of generic tuples I can't imagine it being done any differently to the ways described here.

The main possible difference is (A, B, C) vs (&A, &B, &C) and respecting/not respecting tuple layouts.
Respecting tuple layout leads to Draconian restrictions - either you have one layout and can extract only the   last N - 1 elements, or you have another layout and can extract only the first N - 1 elements, and you never able to extract N - 2 elements in the middle. Variadics should be able to extract arbitrary subsequences.

Variadics should be able to extract arbitrary subsequences.

Even with the layout restrictions you can still do &(A, B, C, D) => (&B, &C) to get the middle, it's just that you can also do &(A, B, C, D) => &(A, B, C). And for implementing methods on traits that's both sufficient and necessary.

Hmm... wouldn't the forward-order just-add-padding layout that supports (element, suffix...) splits also support (prefix..., element), and (therefore) (element, mid..., element) splits as well? What's a case where it fails?

@glaebhoerl: I can't see a problem with that. I guess the question is, what's more important? Being able to take arbitrary ranges of a tuple or having tuples packed efficiently? Personally I don't see that much value in being able to take arbitrary ranges. The only time I've ever wanted to split up tuples like this is when I've wanted to be able to handle generically-sized tuples, and in these cases having a single way to do induction over tuples is enough.
On the other hand, people always have structs. So maybe we could give them the freedom to take arbitrary ranges but warn them not to use a tuple where they care about efficient memory usage.

@canndrew It's interesting that you think "Personally I don't see that much value in being able to take arbitrary ranges", while @petrochenkov thinks "Respecting tuple layouts leads to Draconian restrictions - either you [...] can extract only the last N - 1 elements, or you [...] can extract only the first N - 1 elements [...]. Variadics should be able to extract arbitrary subsequences.".
So is being able to take arbitrary subslices not very valuable, or is it Draconian to disallow it? I don't know, and I'm not even sure how to look for the answer. Can anyone provide support for one view or the other?
While trying to write the second half of this comment, I realized I don't completely understand how the "just add padding" layout is specified. As far as I can tell, only a couple of specific examples have been discussed. What's the general case? (u8, u8, u64) takes a hit - does (u64, u8, u8) also? Are there element types where no order is optimal? What about just (u8, u8) - keeping in mind that it might be embedded inside a large tuple? Is this impacted by whether only suffix, or also prefix slices need to be supported? (In my previous comment I had the suspicion that supporting prefix slices is "free" once you take the hit for suffixes - and right now I have the opposite suspicion... best to admit I have no idea.)

I think the (A, B, C) to (&A, &B, &C) can be handled by adding an as_ref() method to tuples (along with as_mut() for the &mut equivalent). This RFC can then be amended to only allow capturing tuple tails by value in patterns. This avoids the need to give ref a special meaning when dealing with tuple tails.
The debug_tail implementation in the RFC can then be changed to pass the tuple by value, since a tuple returned by as_ref() is always going to be Sized. In practice all of the references are going to be optimized away by the compiler.

To me, there's two possibly valuable cases:

Extract the first n elements.  With this and some sort of Pythonesk unpacking syntax (not in this RFC I think), it could be an at least slightly valuable tool for domain specific languages.

Split in half.  This one is more interesting because it allows you to make a bunch of O(n) recursion depths O(n log n).  To be more concrete, a function that sums all arguments passed to it recurses 10 times (and possibly copies 10 tuples onto the stack) without this.  But with it, you can get away with roughly 4.

It's hard for me to come up with good examples, though.  I think that this is more useful with function overloading.  I'm speaking from some small experience with C++ variadic templates, and most of those patterns don't apply to Rust.
Also, I'm assuming that we will eventually use this like a C++ variadic template.  If not, then I don't see even the little bit of value I see in it now.  I'm not saying that there isn't any.

I hope this becomes a reality soon.
I am trying to write a wrapper for a C library that makes thorough use of variadic functions (technically they're trampoline functions). This is the one feature I am really craving to port my entire project over from C++.

@Chaser53
As this RFC stands, I don't think it will give you variadic functions in the way you need.
If your goal is to call a function using va_list, you need some other things that I don't know about.  This Reddit thread has some info.  I think that Rust's C FFI can't do it, but could be much mistaken having never tried.
What this RFC is a step towards is C++ parameter packs and/or a Rust equivalent of C's va_list.  But it's not quite there.  If it goes through, you could wrap the extra arguments in parentheses however.  But the convenient syntax would still need a macro.
What I personally want to see after this one (which I likewise hope gets approved) are the following two RFCs:

One that makes fn foo<T>(extra_args: T...) a shorthand for passing 0 or more extra arguments inside an automatically generated tuple, with the ability to place constraints on the elements.  I.e. fn foo<T: Debug>(extra_args: T...).  Also allow fn foo(extra_args: i32...), etc.

A second one that makes function overloading possible.  You can fake some of it with traits, but faking with traits is ugly.  I by no means think it should be as complicated as C++, but we should be able to do exact match on numbers and types of arguments.  My viewpoint on it is that match is pattern matching on values and overloaded functions is more convenient pattern matching on types.

@camlorn
Maybe it will, maybe it won't. I do know that the variadic functions that I am calling aren't technically variadic (they don't use va_list), they are trampoline functions with indefinite arity. I currently have to implement a function for every tuple between 0 and 16 elements in order to give me almost what I need, but the syntax is odd to use.
extern {
    fn a_trampoline(); // my c trampoline function
}

trait CVariadic {
    fn call();
}

impl CVariadic for () {
    fn call() {
        let call0Args: unsafe extern fn() = unsafe { mem::transmute(a_trampoline) } ;
        call0Args()
    }
}

impl<A> CVariadic for (A) {
    fn call() {
        let call1Args: unsafe extern fn(A) = unsafe { mem::transmute(a_trampoline) } ;
        let (a : A) = self;
        call1Args(a)
    }
}

impl<A, B> CVariadic for (A, B) {
    fn call() {
        let call2Args: unsafe extern fn(A, B) = unsafe { mem::transmute(a_trampoline) } ;
        let (a : A, b : B) = self;
        call2Args(a, b)
    }
}

// etc.

// ... later

(1, 2.34, "five", var6).call();

It's not perfect: It get's the job done but there is a lot of code, a lot more than there would be if this was a feature of the language. I have cleaned this up with macros to make it a bit easier to implement all of them. (This is off the top of my head, I don't know if this is actually 100% correct).
I think that this will be a useful feature nonetheless, even if this doesn't pave the way for support with va_list.

@Chaser53
I'm now really curious what you mean by trampoline function with indefinite arity.  Is this embedded or something?  I thought the only way to even get what you're talking about is va_list.  I'm imagining assembly at this point.
Also, I'm not seeing how you generalize that trait with this RFC.  You could do it but for the body of call.  I don't think this RFC will let you get them into the argument positions how you want.  Do you have a way to do it?
Those traits are very interesting.  I wonder what the calling convention for va_list is, as that could work there potentially.
As for this RFC.  I'm not saying I don't think it's valuable, just that I don't see it as very useful by itself.  I think we need some further RFCs to see the real benefit, but this certainly enables stuff and opens possibilities.

@camlorn
Apologies, the jargon isn't necessarily my strong suit. I believe the more correct term is thunking.
I am trying to write a wrapper for a language similar to Smalltalk that already has the runtime library in C. It uses a few calls similar to objc_msgsend(id obj, sel s, ...) in the Objective-C runtime, and it actually acts in a very similar way. It is defined in a C header file but the implementation had to be done at assembly level.
From what I understand, since this will allow tuple expansion, we can expand the tuple_type to do the transmutation and expand the tuple values to pass them in as args.
Then again, I may be completely wrong about how this would interoperate with C if it is added.

@Chaser53
As I read this RFC, you can destructure a tuple and you can build tuples using something akin to lisp.  But given some tuple p, you can't get it to transparently disappear.  I.e, given:
let p = (1i32, 2i32, 3i32);

fn foo(a: i32, b: i32, c: i32) {
//stuff
}

there's no way to get p to go into the arguments of foo conveniently.  The issue with your traits is that you can't do this easily.
I was going to say this is impossible.  But while I was typing this comment, a solution occurred to me.  You could probably implement a recursive trait that bound the parameters one by one and then uses the empty tuple to mean make the final call.  This seems like it would be horribly inefficient; given that we're talking about a language that decided to implement itself using assembly, performance is obviously a concern.  That said, I feel like this solution wouldn't even require specialization.
I don't want to go too far off topic, but can you provide a link to whatever this language is?  Saying that it has to be implemented in assembly has me kind of curious now.

@camlorn
Its my own hobby project. I never released it because it is extremely sloppy and buggy.
If you're curious about the assembly bit, there is a good article on roughly how it is done in Objective-C, and it is very similar to how I am doing it as well. It is only the thunking (trampoline) code that is done in assembly.
https://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-build-objc_msgsend.html
In response to what you have said, I think I have seen my error. I thought this RFC included tuple expansion like what is discussed in #376 (that's what I get for commenting at 4am). Nonetheless, I know that this feature will be an extremely helpful addition to the language.

@glaebhoerl

So is being able to take arbitrary subslices not very valuable, or is it Draconian to disallow it? I don't know, and I'm not even sure how to look for the answer. Can anyone provide support for one view or the other?

As far as I'm concerned the entire use-case for this feature is to be able to iterate over a tuple type at compile time to generate an impl. For this, just being able to iterate left-to-right (or right-to-left) is sufficient. I'm not saying other use-cases don't exist, I just haven't thought of them myself. Can someone provide an example of where you'd actually want to take arbitrary ranges?
@camlorn

Extract the first n elements. With this and some sort of Pythonesk unpacking syntax (not in this RFC I think), it could be an at least slightly valuable tool for domain specific languages.

This would be simple to implement by just repeatedly taking the head n - 1 elements until you're down to the length you want.

Split in half. This one is more interesting because it allows you to make a bunch of O(n) recursion depths O(n log n). To be more concrete, a function that sums all arguments passed to it recurses 10 times (and possibly copies 10 tuples onto the stack) without this. But with it, you can get away with roughly 4.

Remember, tuples aren't arrays, if you're passing around values of type (u32, u32, u32, u32, u32, u32, u32, u32, u32, u32) you'd probably just be better off using [u32; 10]. The whole point of tuples is that they're heterogeneously typed in which case why would you ever want to split one in two?

@canndrew
My example of splitting is contrived, but I'm assuming that someone is going to do a variadic functions RFC with this one.  In that case, split in half can be used to keep the stack depth down in some cases in the future.
Whether or not these cases will be valuable, I don't know.  It's not the future yet.  There is also at least one other solution we could add later.  Something like C++17 fold expressions comes to mind.
@Chaser53
thanks for the article.

Map and fold operations on tuples can be handled by adding the ability to define generic closures:
(1i32, 2u8, 3.5f64).map(<T: Display>|x: T| println!("{}", x));
let sum = (1i32, 2u8, 3.5f64).fold(0, <T: Into<f64>>|v: f64, x: T| v + x.into());
assert_eq!(sum, 6.5);

Regarding splitting, I've used this in C++ before to spawn a bunch of tasks in parallel. Basically, I have a tuple of T: FnOnce() where each T can be a different type, so I can't use an array. I then split the tuple in 2, send one half to another thread and then recurse.

@Amanieu I think one could do the splitting using recursion, stopping when LHS has the same number of items as RHS, or one more. This might be possible to define in traits even without specialization.

@eddyb
That would lower the recursion depth, but probably comes with a runtime overhead. At least, I can't see how to do it strictly at compile time.
I think what this comes down to is the question "Do we want to use tuples as C++ variadic parameter packs in future?"  Given that they're already about 6 inches away from it, I think yes.  Also, the C++ people end up putting them in std::tuple so that they can get tuple features from it, so we might as well just let it have that machinery to start with.
But if we decide that tuples are not a good fit, then I reserve the right to change sides.  Without that, a lot of the advanced manipulation stuff becomes kind of pointless.
I don't like using closures for map and fold unless the compiler is going to be smart enough to always inline them.  As I understand it, there is cost to building the closure object.  Maybe MIR will let us optimize it. Maybe it can be optimized now.  I'd like this question answered before I jump on that bandwagon.  But if it is, then I'm all for it.
I feel like maybe I should link this page on C++17 fold expressions.  There's been a couple occasions that I've daydreamed about using them to make functions that can act as unrolled convolution loops and DSLs that let you build up larger filters from smaller classes, but unfortunately we don't have them yet.

As I understand it, there is cost to building the closure object.

Not since before Rust 1.0, closures are structures containing their captures and built-in implementations of the Fn traits, they get statically dispatched even without inlining.
Neither of @Amanieu's examples uses captures, so they're just zero-sized types with generic Fn impls.
In what I'm suggesting, there is no runtime operation other than packing/unpacking and function calls that can be trivially inlined.
Generally speaking, LLVM's SROA would make quick work of repeated packing/unpacking operations.
We can also do it in a deterministic manner on MIR, although it would have to be monomorphic MIR,
which is not the best use of MIR optimizations (gains from polymorphic optimizations scale better).

@eddyb
The reason I'm concerned about the optimization is because of the discussion on the RFC about adding &move.  that discussion as well as a linked previous discussion both talked about how it's valuable because LLVM doesn't always do inlining.  I can find references if needed, but don't have them in front of me now.
Provided that this is true there, why isn't it true here?  What makes LLVM inline in this case?  if this is a standard library function, then presumably the compiler doesn't have special knowledge of it.
Unless those functions can be rewritten to trigger TCO, we still have a less than optimal recursion depth.  These functions can be done "flat" by the compiler, provided a C++17-ish fold expression or magic macro.  If you don't make guarantees on the order that map and fold do stuff, then you can use it there for better depths.
Without the discussion on &move, I'd just let it be.  But it was pretty clear there that people are having actual problems with the size of the stack and LLVM not inlining and eliding copies as much as it could.
I think that this discussion is now at the point of "ideas for further RFCs", so maybe we should drop it for this one.  The only concern is that maybe the representation might prevent efficient splitting, but others would know about that better than I.

this PR has been silent for 3 months, I guess it's time for FCP?

You know, we could avoid some of the representation issues if we add a compile-time way to iterate over tuples, but not arbitrarily destructure them. Since like 90% of our use cases are just "we need the compiler to look at a tuple of arbitrary length and do something to each of its elements", having some kind of generic "static foreach", generic map (as proposed above), or even generic flatMap/monad operator, would all likely be good enough for our purposes. After all, we don't iterate through a vector by pattern-matching it into increasingly smaller subsections--why should we do it for tuples?
The only problem with that is working at the type level, because the only way that makes sense for iterating over types that doesn't involve "destructuring" them is with higher-kinded types...

add a compile-time way to iterate over tuples
having some kind of generic "static foreach"

Yes! Having imperative "static if" and "static for" instead of declarative recursion and specialization through pattern matching is a long time dream of mine (it first was applied to C++ though). And C++ already start going this way by introducing if constexpr (motivation, wording).
Constructions that mirror usual control flow are much more user friendly and boilerplate-free, than specialization based ones.

static for poses a problem in that the type of the value being produced changes for each iteration.
You also can't produce a new tuple of the same length and with related types, this way.
Generic closures OTOH are much more feasible and on't require HKT, not even type HRTB.
As proof, this demo contains the desugaring of for<T: Clone> |x: &T| -> T { x.clone() }.

There is a lot more one could do at compile time obviously.  As a first, it's quite obnoxious that mem::size_of<T>() cannot be used when declaring types.  It'd be nice if one could write :
struct BytesOf<T>([u8; mem::size_of::<T>()])

In general, there are way too many libraries using [u8] instead of [u8; n] when they actually know the size n at compile time.  I think every endianness library falls into this.  And too many with lists of impls for different n.  I'd think addressing those issues with [;] should be a higher priority than anything with tuples, but some RFC for that exists if I recall.
About tuples though : I doubt one can impose alignment requirements on tuples.
Instead, one might do tuple cons backwards, so if t : (A,B,C,D) then let (..foo, bar, baz) = t gives foo:(A,B) and bar: C and baz: D, so no alignment issues for foo.  There are alignment issues with bar and baz too, but presumably those could be handled as with total destructuring today.  If that were not sufficient, maybe bar and baz could be given some special invisible Unaligned<T> type from which a properly aligned T gets moved, copied, etc. whenever anything happens.
As for looping over tuples at compile time, @Amanieu's generic closures sound way nicer than static while, etc.  You'll frequently need temporary trait and impls, which gets slightly C++ish.

There's an RFC for type-level integers which I can never find quickly, and thus I don't have the link.
My work on layout which is maybe 2/3rds finished if I'm lucky will make changing the representation of a tuple a trivial operation.  It will also probably make a tuple not necessarily ordered in memory to match the field indexes.
Miri could allow for compile-time maps and (with generic closures) folds of constant tuples.  I can't quite envision how you write the types though; it seems like the constraints on the closure that the mapping function takes would have to somehow match those on the closure as written at the call site.

@burdges Yeah, we really need constexpr. I myself also like the idea of <const Param: T> for statically known parameters.

There's an RFC for type-level integers which I can never find quickly, and thus I don't have the link.

@camlorn Do you mean the const-dependent type system RFC?

@mglagla
Yeah, but GitHub does everything by numbers and Google is bad at finding things by half-remembered title.
Someone needs to work out how to make a system like this come up with memorable identifiers.

@rfcbot fcp postpone
As of this writing we have 34 open lang RFCs. People who follow many RFCs may have noticed that there's been an effort recently to move many of the open RFCs to a resolution, especially if they haven't seen recent activity.
This RFC has had basically no activity since June, and isn't likely to be prioritized as a result of the 2017 roadmap. However, this RFC is a big proposal, taking steps to solve a big problem (variadic generics), and so I want to be emphatic that I'm proposing postponement only because it seems likely to sit quietly open for a good long while before we take further action on it. Once solving this problem is a more immediate term priority, I'd be glad to see it re-opened.

My own opinion is that it seems like the solution proposes by this RFC is improperly generalized.
The problem this RFC is trying to solve is "implementing a trait for all tuples." This RFC solves that problem, but the connection between the problem and the proposed syntax is not obvious. The syntax is general purpose, but as far as I can tell it would be dubious to use the syntax for anything other than implementing traits for all tuples.
Basically, I wonder if there is a solution to this problem that is more targeted on implementing traits for tuples. Unless we have other motivations for this syntax, I don't want to add overly general features because that has its own complexity cost.
I do think this RFC takes the right approach to solving variadic generics though - start with solving the most common problem (implementing a trait for all tuples), before moving to the wider problem.

Status update on "static for" mentioned above:
It turns out this is already possible to do in C++ with recently introduced fold expressions!
This program goes through a heterogeneous list and prints all its elements:
#include <iostream>

template<typename... T>
void print(T... items) {
  ([&](auto&& item) {
      std::cout << item << std::endl;
  }(items),...);
}

int main() {
    print(10, 11.1, "abc");
}

The lambda's operator() is monomorphized several times for each item's type and all its versions are called in order. And everything is imperative, no recursion or specialization in user code, yay.

@petrochenkov I've mentioned generic closures for this before, I also think it has a lot of potential.

I see a lot of discussion in the abstract with A and B and such, but more concrete examples would make the motivation more clear. Are there examples of projects that suffer for the lackof this?

Tuples are product types where cons cell lists are sum types. My intuition says mixing them together is asking for trouble.
The construct proposed here reminds me of HList, which, IIRC, requires HKT.

HList doesn't require HKT AFAIK, there are implementations in Rust, and tuples are just that, but they're missing composition and decomposition tools.
The "cons cell" analogy is unfortunate, I agree. I prefer spread/capture operators myself.
As for usecases: variadic generics and variadic functions. Implementing traits for any tuple.
In particular, Fn* traits currently use a very hacky version of this to be variadic.

I find the "change the layout of tuples" solution very, very surprising.
It feels totally reasonable to me to expect that simd::i32x4, (i32, i32, i32, i32), and [i32;4] are all layout-compatible in the .0-is-[0] way.
I would be very confused to find my code breaking or its performance changing because I went from a (A,B,C) to a TupleStruct(A,B,C) or MyStruct{a:A,b:B,c:C}.
For consistency and simplicity, I hope that it always remains true that "a tuple is the same as the equivalent struct with 0, 1, ... for the field names".

@scottmcm I don't believe the layout of homogenous tuples would be impacted?
I think there is a completely principled reason for tuples and structs to have different representation: one is ordered, the other is not. Just like you presumably don't find it surprising that HashMap and BTreeMap are represented differently and perform differently. Copying my comment on this from earlier in the thread...

... while the alternative of laying out tuples less efficiently is shaky on "don't sacrifice potential performance ever ever" grounds, I do think it could pass the "don't pay for what you don't use" test. Heretofore, tuples and structs have been semantically equivalent, so it makes perfect sense that they would use the same representation. With this change, tuples would now be more powerful than structs: they would not merely be "anonymous structs", as they had been before, but heterogenously-typed lists which can be iterated over. Furthermore, struct fields are unordered, while tuple fields would have a strict ordering not just syntactically but now semantically as well. Just as unordered collections often get to use more efficient representations than ordered ones, it also makes sense that unordered structs would get to use more efficient representations than ordered tuples. But we should collect statistics and benchmarks about the impact on existing real-world Rust code if we choose to pursue this option. My suspicion is that the impact would be negligible - tuples with more than two elements and of different types are already an uncommon case, I think.

Tuples wouldn't have to be strictly ordered under this proposal. The fundamental unit here is pairs, and pairs can be ordered either which way the compiler chooses. For an n-tuple that still gives the compiler 2^(n-1) different layout options (rather than n! in the case of structs).
ie. for a tuple (a, b, c), any layout that keeps b and c adjacent is admissable.

Something else I noticed: RFC 1506 uses and extends the "a tuple struct is equivalent to a braced struct with integer literal field names" idea: https://github.com/rust-lang/rfcs/blob/master/text/1506-adt-kinds.md.
@glaebhoerl The RFC says "Secondly, we layout tuples in reverse order".  I don't see any note about homogeneous sections being different.
Also, it's not completely true that "one is ordered, the other is not".  The last field in a braced struct is already special: only the last field of a struct may have a dynamically sized type.

I'm going to close this RFC as postponed. While there's desire to eventually support this kind of tuple-generic programming, there are many thorny issues and in terms of the roadmap the feature doesn't rank high enough to devote the necessary bandwidth at this time.

@eddyb Looking back on this, it seems like most of the disagreements were focused around the tuple representation and the new syntax. Is there any reason not to reopen a more minimal proposal based on your playground example? It seems like this approach avoids the representation issue, and any special syntax for pattern matching out the head of a tuple could be implemented as sugar for Split::unpack.
P.S. If such a proposal were to move forward, I'd also highly suggest implementing Cons<T> and Split for arrays of type [T; n] to allow for generic array impls without needing to wait for type-level numerics.

to allow for generic array impls without needing to wait for type-level numerics

I thought so too, a long time ago, but we're actually closer to the latter at this point.

@eddyb Even if so, I think there are many cases where it's useful to be generic over both tuples and arrays, and getting both with one trait impl seems like a great advantage to this approach.
That aside, is there a reason not to have these traits in the language? The only downside I can think to avoiding them is that it wouldn't be immediately obvious to library consumers that a Split trait impl means they can use tuples.


Attempt to provide a better error for undef sret

I was thinking if we can find which values weren't initalized by Enzyme for the shadow
sret we could fix them up with fictious values instead of Julia throwing an error, but
I haven't found a solution yet since for some values we can't take a pointer Symbol...
x-ref: #347

Codecov Report

Merging #422 (88b4ce2) into main (0f3233d) will decrease coverage by 3.97%.
The diff coverage is 23.52%.

@@            Coverage Diff             @@
##             main     #422      +/-   ##
==========================================
- Coverage   76.33%   72.36%   -3.98%
==========================================
  Files          17       17
  Lines        4226     4038     -188
==========================================
- Hits         3226     2922     -304
- Misses       1000     1116     +116

Impacted Files
Coverage Δ

src/compiler.jl
74.15% <23.52%> (-0.64%)
:arrow_down:

src/compiler/orcv2.jl
0.00% <0.00%> (-72.39%)
:arrow_down:

src/compiler/interpreter.jl
30.95% <0.00%> (-69.05%)
:arrow_down:

src/compiler/utils.jl
55.71% <0.00%> (-37.44%)
:arrow_down:

src/logic.jl
75.00% <0.00%> (-5.00%)
:arrow_down:

src/compiler/validation.jl
62.05% <0.00%> (-2.30%)
:arrow_down:

src/api.jl
55.62% <0.00%> (-2.27%)
:arrow_down:

src/compiler/pmap.jl
79.45% <0.00%> (-1.80%)
:arrow_down:

src/pmap.jl
83.33% <0.00%> (-1.29%)
:arrow_down:

src/typeanalysis.jl
90.00% <0.00%> (-0.91%)
:arrow_down:

... and 5 more

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

I think the better soution would be to zero-initialize the sret (instead of undef as it is currently) and then define something like.
zeroof(::Symbol) = :Zero

So I thought about this a bit more, and I think there's a reasonably nice solution here. Namely, this error can only occur if an active input value contains an allocatedinline value for whom bits of 0's are not legal.
Since we know the proper julia type, and this only is an issue on the outermost level where there's an ABI interface from Enzyme to Julia (already wrapped), prior to returning from the llvmcall we create, we can initialize any allocatedinline types with placeholders of choice.

My comment/proprosal above wouldn't just be a better error, but in fact a fix.

Zero init'ing the sret wouldn't be sufficient, you'd need to post copying the result from the Enzyme struct, or alternatively only copy the relevant parts of the LLVM struct.

we can initialize any allocatedinline types with placeholders of choice.

Can you implement that?


Gemm only support 2D tensor

The third optional operand must be 2D tensor.
Maybe we should remove gemm scalar bias  , gemm single vector bias  test case, and remove 0.0 for both gemm aTranspose and gemm bTranspose.

@BruceDai , please help on this issue. Thanks!

@huningxin Please review pr #69, thanks.

Opened webmachinelearning/webnn#171 for spec discussion.

gemm now supports scalar and broadcasting.


Wallet Presentation Issues in Release 0.6

Hi team,
I have pulled the latest release of the waltid identity to test it out. The release has been improved significantly overrall.
There are however some problems with the wallets especially related to the presentation protocol when Wallet submits an sd-jwt-vc. More specifically, I try to test with a Sd-jwt credential issued by the Portal and try to authenticate with it. Here is an error returned:
 Verifier API : Error: Verification failed: String does not have JWS part amount of 3 (= 2 dots): eyJraWQiOiJkaWQ6andrOmV5SnJkSGtpT2lKRlF5SXNJbU55ZGlJNklsQXRNalUySWl3aWEybGtJam9pTTFsT1pEbEdibmc1U214NVVGWlpkMmRYUmtVek4wVXpSM2RKTUdWSGJFTkxPSGRHYkZkNFIyWndUU0lzSW5naU9pSkdiM1paTWpGTVFVRlBWR3huTFcwdFRtVkxWMmhhUlV3MVlVWnlibEl3ZFdOS2FrUTFWRXR3UjNWbklpd2llU0k2SWtOeVJrcG1SMVJrVURJNVNrcGpZM0JSV0hWNVRVOHpiMmgwZW5KVWNWQjZRbEJDU1ZSWmFqQnZaMEVpZlEiLCJjdHkiOiJjcmVkZW50aWFsLWNsYWltcy1zZXQranNvbiIsInR5cCI6InZjK3NkLWp3dCIsImFsZyI6IkVTMjU2In0.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiQmFua0lkIl0sImNyZWRlbnRpYWxTdWJqZWN0Ijp7Il9zZCI6WyIweFRLNTJyYzU3RVdzbDFwSkJHUFZtSk9TLU5EUkZBU2dDTkxaZWVQYVdNIiwiT0JrSzd5bmhBZV9pczJ5Y09HZ3gwcGFrOHFsa1c2bkFOZm1SUDY0cjl2WSIsIkJBczhrZWlEQXhWRGZyVVk4MGxTcGZTSGNEbFd4MDBIYkFzRVdzelF6S0UiLCI5cTk2N1F2ZUtvTjhkWjFRX3ZEaXBXTG5HYnBzdVpKUFZKMWYzdmNfRkg0IiwiOFpmdVJzV2U3N2xrbFVEcmhYaXhsT1pUUjZheTlnMEVwLVhLaHI3V2syWSIsIlF6LWRETFhaV3RCN1NmOHBWdC1GdVhhVXVmRWVqOEdHUUlpajRQajJVNTQiLCIySDRRSmZlSHNWakNSbHNrYUhmQ0VZclc4SjQyTkYwS21UQUlEZVRaa1cwIl19LCJpZCI6InVybjp1dWlkOjY3NzZjMDMyLWE1NDgtNDM0Mi1hNzdhLWJjNzkyMjk4YTA5ZiIsImlzc3VlZCI6IjIwMjEtMDgtMzFUMDA6MDA6MDBaIiwiaXNzdWVyIjp7ImlkIjoiZGlkOmp3azpleUpyZEhraU9pSkZReUlzSW1OeWRpSTZJbEF0TWpVMklpd2lhMmxrSWpvaU0xbE9aRGxHYm5nNVNteDVVRlpaZDJkWFJrVXpOMFV6UjNkSk1HVkhiRU5MT0hkR2JGZDRSMlp3VFNJc0luZ2lPaUpHYjNaWk1qRk1RVUZQVkd4bkxXMHRUbVZMVjJoYVJVdzFZVVp5YmxJd2RXTktha1ExVkV0d1IzVm5JaXdpZVNJNklrTnlSa3BtUjFSa1VESTVTa3BqWTNCUldIVjVUVTh6YjJoMGVuSlVjVkI2UWxCQ1NWUlphakJ2WjBFaWZRIiwiaW1hZ2UiOnsiaWQiOiJodHRwczovL2ltYWdlcy5zcXVhcmVzcGFjZS1jZG4uY29tL2NvbnRlbnQvdjEvNjA5YzBkZGY5NGJjYzAyNzhhN2NiZGI0LzE2NjAyOTYxNjkzMTMtSzE1OUs5V1g4SjhQUEpFMDA1SFYvV2FsdCtCb3RfTG9nby5wbmc_Zm9ybWF0PTEwMHciLCJ0eXBlIjoiSW1hZ2UifSwibmFtZSI6IkNIIEF1dGhvcml0eSIsInR5cGUiOiJQcm9maWxlIiwidXJsIjoiaHR0cHM6Ly9pbWFnZXMuc3F1YXJlc3BhY2UtY2RuLmNvbS9jb250ZW50L3YxLzYwOWMwZGRmOTRiY2MwMjc4YTdjYmRiNC8xNjYwMjk2MTY5MzEzLUsxNTlLOVdYOEo4UFBKRTAwNUhWL1dhbHQrQm90X0xvZ28ucG5nP2Zvcm1hdD0xMDB3In0sInZhbGlkRnJvbSI6IjIwMjEtMDgtMzFUMDA6MDA6MDBaIiwiaXNzdWFuY2VEYXRlIjoiMjAyNC0wOC0xM1QxMzowMTowNS43NDE5MjI4MzRaIiwiaXNzIjoiZGlkOmp3azpleUpyZEhraU9pSkZReUlzSW1OeWRpSTZJbEF0TWpVMklpd2lhMmxrSWpvaU0xbE9aRGxHYm5nNVNteDVVRlpaZDJkWFJrVXpOMFV6UjNkSk1HVkhiRU5MT0hkR2JGZDRSMlp3VFNJc0luZ2lPaUpHYjNaWk1qRk1RVUZQVkd4bkxXMHRUbVZMVjJoYVJVdzFZVVp5YmxJd2RXTktha1ExVkV0d1IzVm5JaXdpZVNJNklrTnlSa3BtUjFSa1VESTVTa3BqWTNCUldIVjVUVTh6YjJoMGVuSlVjVkI2UWxCQ1NWUlphakJ2WjBFaWZRIiwiY25mIjp7ImtpZCI6ImRpZDpqd2s6ZXlKcmRIa2lPaUpQUzFBaUxDSmpjbllpT2lKRlpESTFOVEU1SWl3aWEybGtJam9pU1c4dFRIbFBOVVl6WkZKM2FUVlBUbTVaVWpNMGJtUllRa2hJYTBWT1ZIZDRaQzE0U3pGM05WQjJSU0lzSW5naU9pSnBjRGRaTFZGM2VIbEhjSEEyYTBWYWVYcDZabE5ZZFROVVozRldZVUozYVRKMFNDMWFhRXRVVEZoUkluMCJ9LCJ2Y3QiOiJCYW5rSWRfdmMrc2Qtand0IiwianRpIjoidXJuOnV1aWQ6Njc3NmMwMzItYTU0OC00MzQyLWE3N2EtYmM3OTIyOThhMDlmIiwiaWF0IjoxNzIzNTU0MDY1LCJuYmYiOjE3MjM1NTQwNjV9.ewojjDkUYGXuNClczUAY2ySZH6Q0cffNKK5Qy9_dkzXNteffTGkMDh9o_GXXqeaYkS8ZFknNH8TA9meyKaM4ag~eyJraWQiOiJJby1MeU81RjNkUndpNU9ObllSMzRuZFhCSEhrRU5Ud3hkLXhLMXc1UHZFIiwidHlwIjoia2Irand0IiwiYWxnIjoiRWREU0EifQ.eyJpYXQiOjE3MjM1NjUzNzMsImF1ZCI6Imh0dHA6Ly9ob3N0LmRvY2tlci5pbnRlcm5hbDo3MDAzL29wZW5pZDR2Yy92ZXJpZnkiLCJub25jZSI6ImQyMTFlZGRjLTE2YjAtNGY1Yy1hZDZhLWU1ZjMzYzZjMjVkZCIsInNkX2hhc2giOiJzOEt1YzNWVldha2RlaWQ5WWJQMHF3RnduRld2NTFMS3g3THlmeXdjeTdFIn0.x_2dIW03plZzN3ND5OUwVXKg2JxD0Vro8_gOSe5PdWM-7dnUly4a19WR7a1j2fJ2AA4Wo3kBYl71rr-I-pDSBQ
Actually there are no disclosures sent by the Wallet to Verifier. And The Verifier could not verify the signature because the wallet concatenates another jwt for key binding. and the Verifier takes both Jwts as one single input to verify.
Could you please have a look ?
Cheers,
Hoan

Sure! Let's check it out.

Hi @vanhoanHoang .
We are working on it at #701 and it will be merged soon.

Thank you @alegomes  for your response
However I spot another problem with both sd_jwt_vc and mso_mdoc.
Currently, for authorization response sent to Verifier,  Wallet is only wrapping  jwt_vc_json credential into the vp_token.
For sd_jwt_vc and mso_mdoc, they are sent directly to Verifier as you can see here
I'm not sure if this was intentional or a mistake. I look up the OID4VP spec again but apparently nothing has been changed with regards to the Authorization Response. And for any format, Wallet should wrap credentials into vp_token.
Thank you for your help :)
Cheer,
Hoan

Thank you @alegomes for your help.
As indicated in the example above, there was no disclosures sent by Wallet to Verifier even though I chose to reveal them on the Wallet UI.
I looked at the code here, apparently it is not added if I'm not wrong ?
Cheers
Hoan

Hey, @vanhoanHoang
If it's related to another problem, just to keep things organized and easier to track, do you mind opening new issues for them? ;-)
All the best,
Ale

Dear @alegomes,
I'm creating a new issue :)
Thank you


Saving event on save translation

Hi guys,
i found that saving events of model is not fired as well on updating model.
I found bug on Translatable.php on row 211 when before saving translation it need to fire that event.
So on row 211 i put $this->fireModelEvent('saving', false); just before the if statement.
So the bug is fixed.
i'm working on v5.5.1 of Translatable.

Thanks for the contribution! 👍
Can you add a test asserting that the saving event is fired when saving a model that is not dirty?

Hi dimsav,
this is the boot function i have on my model and that fire correctly saving event after changes.
This function need me to change slug url of a page when user change title of that page.
public static function boot() { 	parent::boot(); 	Pagina::saving(function ($data) { 		$data->slug = str_slug($data->title,'-'); 	}); }

I mean an automated test like the ones here


CASMINST-5427 Remove confusing step for normal Ceph upgrade in stage_1

Description
Remove confusing step for normal Ceph upgrade in stage_1
Checklist Before Merging

[x] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[x] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[x] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

/backport release/1.3


Tween#generateData with no arguments causes infinite loop, memory issues.

Hi. I think you did a little oversight there.
In the Phaser' API manual, the Tween#generateData method is documented as having two optional arguments, whose default parameter values are, respectively, a default frame rate of 60 FPS and an empty Array to store the generated data.
Looking through the class source code, though, I noticed that only the last parameter is assigned the default value, possibly leaving the frameRate parameter undefined.
When that parameter is omitted and not assigned the appropriated value, its value gets coerced by JavaScript to NaN, due to the calculations done by the TweenData#generateData, which doesn't handle the value in any way either, an makes the program run in an infinite loop.
When I tried that method without a frame rate argument, misled by the documentation, my web browser became unresponsive, causing high CPU and memory usage. It took me a while to figure out why. So much for a missing line of code, I guess :)
The issue could be reproduced as in the following code snippet but, really, I don't recommend that.
var t = this.make.tween({ foo: 0 });
t.to({ foo: 10 })
t.generateData(/* no arguments */); // Actually, don't try this :)

This issue is present in both release (v2.3.0 and earlier builds) and development code bases.

2015-05-08: Edited.

Merged to dev, thanks.


[BIOMAGE-1506] Fix 2 small things in continuous embedding plot

Background
Link to issue
https://biomage.atlassian.net/browse/BIOMAGE-1506
Link to staging deployment URL
https://ui-martinfosco-ui583.scp-staging.biomage.net/
Links to any Pull Requests related to this
Anything else the reviewers should know about the changes here
Changes
Code changes
Definition of DONE
Your changes will be ready for merging after each of the steps below have been completed:
Code updates
Have best practices and ongoing refactors being observed in this PR

[ ] Migrated any selector / reducer used to the new format
[ ] Validated that current unit tests work as expected and are enough

Testing

[ ] Unit tests written
[ ] Tested locally with Inframock (with latest production data downloaded with biomage experiment pull)
[ ] Deployed to staging
[ ] Passed integration tests

To set up easy local testing with inframock, follow the instructions here: https://github.com/biomage-ltd/inframock
To deploy to the staging environment, follow the instructions here: https://github.com/biomage-ltd/biomage-utils
Documentation updates
Is all relevant documentation updated to reflect the proposed changes in this PR?

[ ] Relevant Github READMEs updated
[ ] Relevant wiki pages created/updated

Approvers

[ ] Approved by a member of the core engineering team
[ ] (UX changes) Approved by vickymorrison (this is her username, tag her if you need approval)

Just before merging:

[ ] After the PR is approved, the unstage script in here: https://github.com/biomage-ltd/biomage-utils is executed. This script cleans up your deployment to staging

Optional

[ ] Photo of a cute animal attached to this PR

In staging, the first time I go to the continuous embedding plot I get "it's not you, it's us". Then if I go back to Plots & Tables home page and then click the continuous embedding plot again, it loads fine. I tried with 3 different experiments - the same thing happened every time. Video below (the plot did load I just didn't record it).
https://user-images.githubusercontent.com/74908153/146605416-5d91b376-2ad3-4483-af4a-b75d541a3384.mov
The 2 issues are fixed though!

In staging, the first time I go to the continuous embedding plot I get "it's not you, it's us". Then if I go back to Plots & Tables home page and then click the continuous embedding plot again, it loads fine. I tried with 3 different experiments - the same thing happened every time. Video below (the plot did load I just didn't record it). https://user-images.githubusercontent.com/74908153/146605416-5d91b376-2ad3-4483-af4a-b75d541a3384.mov
The 2 issues are fixed though!

Thanks! I'll take a look


DPO Submission Script

Adding a version of submit_finetune for DPO. Since we are more likely to be doing DPO from internal checkpoints, I added some stuff for mounting beaker datasets.
Appears to work: https://beaker.org/ex/01J4WJK6MHPNARSN14QBJV17HY/tasks/01J4WJK6MQ0DQGH0ASQF5H0TJG/job/01J4WJKB9X1Q9MF8KK012CRWBD
I haven't tested multinode stuff, though.

LGTM! I used the DPO script in a multinode setting to run DPO on OLMoE, and it seemed to work fine? We probably just need to create a multinode config and everything else should Just Work:tm:. It seems very quick to run though, so I'll approve this and we can add it later if you want

Cool! Yeah, lets handle multinode later (when we need to).

Nice!


docs: add a short description about the project roadmap views

/cc @davidffrench @emmanuelbernard  I thought I could capture the discussion on Zulip about the project roadmap views.
So I am opening this draft PR in view of getting some feedback.
Fix https://github.com/bf2fc6cc711aee1a0c2a/ffm-project/issues/11

As suggested in https://github.com/bf2fc6cc711aee1a0c2a/ffm-project/pull/12#discussion_r811937409, I am planning to setup some time tomorrow and clean up the projects views leaving us with only the two suggested views.
Let me know if anyone has opposing ideas.
/cc @davidffrench @emmanuelbernard

As suggested in #12 (comment), I am planning to setup some time tomorrow and clean up the projects views leaving us with only the two suggested views. Let me know if anyone has opposing ideas.
/cc @davidffrench @emmanuelbernard

That sounds good, thank you Manyanda

Promoted the PR as ready for review.

Thank you for the review.

@davidffrench I am not able to merge this, do you have the access to the merge button?


removed unnecessary call

remove third condition from is.boolean which was not necessary.

Hey @zaheer-ahmed
Thanks for the PR. My first implementation of this method was like yours actually.
@zekiunal pointed out to this addition. As he said:
true === new Boolean(true)
=> false


Warning about 'IPHONEOS_DEPLOYMENT_TARGET' is set to 7.0 when building iOS

Expected Behaviour
deployment target to be determined by config.xml
Actual Behaviour
warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 7.0, but the range of supported deployment target versions is 8.0 to 13.2.99. (in target 'FirebaseInstanceID' from project 'Pods')
warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 7.0, but the range of supported deployment target versions is 8.0 to 13.2.99. (in target 'FirebaseCore' from project 'Pods')
warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 7.0, but the range of supported deployment target versions is 8.0 to 13.2.99. (in target 'FirebaseAnalytics' from project 'Pods')
warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 7.0, but the range of supported deployment target versions is 8.0 to 13.2.99. (in target 'FirebaseMessaging' from project 'Pods')

Steps to Reproduce
cordova platform add<EMAIL_ADDRESS>cordova plugin add<EMAIL_ADDRESS>Platform and Version
cordova ios 5.1.1
phonegap-plugin-push 2.3.0

add below line of code at the end of your podfile. it will delete IPHONEOS_DEPLOYMENT_TARGET and set the project's deployment target.
post_install do |lib|
lib.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'
end
end
end

Podfile? Where is this file please? I can't find it anywhere...


[et] Startup time is about 10s

details
os: macos
network: google wifi
seen results
There is about 10 seconds between invoking ./flutter/bin/et build -c host_debug_unopt_arm64 //flutter/impeller:impeller_unittests and seeing [2024-05-08T09:16:10.317][macos/host_debug_unopt_arm64: GN]: OK printed out.
expected results
I'd expect to have faster startup time (sub 1s).  Or better transparency about what it is doing for 10s.

I think this is a duplicate of https://github.com/flutter/flutter/issues/147666.


Implement a basic "confidence" system for fingerprinting

I've found a situation where the current method is causing issues, however it's not my instance so I can't provide easy testing.
This draft PR is up so I can send the changes required to the user & get feedback while I await to see if it improves the situation at all.
If you want an in-depth description of the new behavior, please check the comments I added to the code which explains as they are in-depth and fully cover everything.
The TLDR of it is that this changes the failure threshold from a fixed 50% to being 50% when we can be confident, but the it scales up as we have less available data-points, which makes it harder for the check to fail when there's not enough info.

The fix has been confirmed to be working

Some reverse proxy configurations will always add HTTP_UPGRADE_INSECURE_REQUESTS to the request headers, so that won't ever change and HTTP_CF_IPCOUNTRY isn't useful if the system isn't behind cloudflare, so we're effectively down to 11 markers.
https://github.com/FOSSBilling/FOSSBilling/blob/9ce61b2aed7064df36dc24f78509c661a5072edc/src/library/FOSSBilling/Fingerprint.php#L67C56-L67C56

Some reverse proxy configurations will always add HTTP_UPGRADE_INSECURE_REQUESTS to the request headers, so that won't ever change and HTTP_CF_IPCOUNTRY isn't useful if the system isn't behind cloudflare, so we're effectively down to 11 markers.

It would be great if you actually stated what your point is with this.
But besides that, the actual properties of the fingerprint are outside of what this PR changes.
The purpose of the PR is to change the behavior of it so that it's more lenient when we have less properties available to work with so that it won't cause issues under situations that are less-than-ideal.

It would be great if you actually stated what your point is with this.

The point is that from 13 Markers, 1 is only present if the instance is protected by cloudflare, and 1 is likely not to change in setups with reverse proxies.
The result is, that only 12 markers are available to being compared, and 1 marker would always be "good" if it's behind a reverse proxy that configures HTTP_UPGRADE_INSECURE_REQUESTS.


weights of bins outside ROI

May be I do not understand something, but, it seems, that in the current version of the script when weights of bins outside ROI are estimated, mult_factor is not taken into account. That is why, I guess, pixels outside ROI are always under-coloured after balancing (even if mult_factor is set to 100). Is it supposed to work this way?

As far as I remember, multiplication was taken into account separately here, but I will check next week if you see under-colouring... Actually, multiplication would be easiest to do by setting weights of bins outside to mult_factor, I think now!


Signature Format Feedback

I've had some more time to look over the signature format here: https://github.com/notaryproject/nv2/blob/prototype-1/docs/signature/README.md
Here's some initial feedback:

The self-signed x509 usage (at least as documented) seems superfluous. A simple public key or JWK would suffice, without the x509 complexity.

x509 could make it easier to attach into a large PKI, but I'm not sure which one or if that's in-scope here.

I don't understand the typ and alg fields.

x509 certs already contain their algorithm inside them, so that field seems redundant at best. I think that's a general criticism with the JOSE standards though.
The specification declares that typ can either be x509 or tuf - I don't understand what tuf would do here.

The claims are fine, they look kind of like an OCI descriptor though.
What if we just went all in and made it an OCI descriptor by nesting all the other fields under "annotations"?
{
    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
    "digest": "sha256:c4516b8a311e85f1f2a60573abf4c6b740ca3ade4127e29b05616848de487d34",
    "size": 528,
    "annotations": {
      "references": [
          "registry.example.com/example:latest",
          "registry.example.com/example:v1.0"
      ],
      "exp":<PHONE_NUMBER>,
      "iat":<PHONE_NUMBER>,
      "nbf":<PHONE_NUMBER>
    }
}

For the x509 key usage - would code signing make sense instead of digital signature? https://www.globalsign.com/en/code-signing-certificate
The iat claim seems weak: https://github.com/notaryproject/nv2/blob/prototype-1/docs/signature/README.md#claims, which is noted. Without a way to attest to the time of the signature (a trusted timestamp), the cert expiry date isn't really useful. Compromised keys could be used to sign artifacts at any time, even after the cert has expired.
I'm not sure I understand hte use-case for the nbf claim.
Some other things I think I would prefer:

take x509 out of the spec completely and just use a JWS in all it's glory. The x509 stuff is still compatible and can be used with the x5u/x5c/x5t stuff, but we'd also allow the other methods like kid or jwk or jku. It makes this spec smaller and more flexible. Implementations can be opinionated.
With that, I'm not sure this spec even needs to exist. The signature spec just becomes jws. The payload spec is what matters, and the OCI descriptor already exists and is flexible enough.

The type x509 generally refers to public keys of a digital signature scheme in the X.509 format. As you have mentioned, it could be as simple as just a public key in PKCS formats.
The cert does not contain the algorithm for an image signature. Technically, the private key associated with the public key in the cert can be used in whatever signature scheme, which supports the key type. For instances, a RSA key can be used in RSA + SHA256 or RSA + SHA512, and a EC key can be used in DSA or ElGamal or other advanced signature schemes. Having an alg-like section can let the clients know whether they have the crypto suite available for verification.
For the annotations section, I don't have a preference since they are all claims. BTW, I think extensions may sound better than annotations.
For the x509 key usage, it is a nice-to-have feature. Just as the section Standard vs. EV Code Signing Certificates states, it is more legit and is more friendly to those strict verifiers.
For the timestamp issue, it is related to the key management. Currently, we assume that the private key is kept secret and will be revoked if the key is lost. Also, you are welcome to contribute to how we should do key management.
The nbf stands for not before and it is optional. It usually used for future signatures and dealing with clock skew.
For the last one, I agree that we could drop the outer spec and keep the payload spec. In fact, the first prototype of nv2 is not in JWT, and later we put the payload into the JWT form. As mentioned in the first sentence in the README, the signature spec is a JWT variant.

The cert does not contain the algorithm for an image signature. Technically, the private key associated with the public key in the cert can be used in whatever signature scheme, which supports the key type. For instances, a RSA key can be used in RSA + SHA256 or RSA + SHA512, and a EC key can be used in DSA or ElGamal or other advanced signature schemes. Having an alg-like section can let the clients know whether they have the crypto suite available for verification.

Ah thanks for clarifying! - I think it still introduces some potential for mismatch here like the HMAC attacks here: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
Again, this is a criticism of the JWS/JWT specs though that and not really anything specific to nv2.

For the x509 key usage, it is a nice-to-have feature. Just as the section Standard vs. EV Code Signing Certificates states, it is more legit and is more friendly to those strict verifiers.

If we go with x509, I think we would need to settle on a specific key usage to prevent protocol attacks (people getting a cert TLS Web Server Authentication for a domain and then using it to codesign). I'm not sure what the best would be, Code Signing vs. Digital Signature.

For the timestamp issue, it is related to the key management. Currently, we assume that the private key is kept secret and will be revoked if the key is lost. Also, you are welcome to contribute to how we should do key management.

I'm not sure this is related to key management, but I also disagree with that being a safe assumption. Timestamping protocols are critical to using x509 in code signing. Some more info is here: https://en.wikipedia.org/wiki/Code_signing#Time-stamping
In short, there are two main flows for code signing:

Certificates expire (in your example the lifetime is 365 days). Without timestamping, signature lifetime must be limited to the lifetime of the cert. When the cert expires, the signatures are no longer valid. This is fine and might be desirable for airgapped situations, but introduces a failure mode (all binaries are no longer valid and might fail to deploy) if someone forgets to rotate a cert.
Timestamping protocols (RFC3161). More info is here: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode. With a third-party timestamp attestation, you can trust signatures beyond the lifetime of the certificate. This is more robust to key rotation, and can also remove much of the need for revocation by allowing users to rely on shorter-lived certs. They introduce a dependency on another protocol, though.

But if the trust model assumes private keys are never leaked, then allowing certs to expire after 365 days doesn't really add value and only adds a potential failure point (if someone forgets to rotate).
I'd prefer to embrace short-lived certs with timestamps, which reduces the need for revocation (I've never seen or heard of revocation working well in practice anyway). For one recent point of reference, the Solarwinds Codesigning certs have still not been revoked: https://www.solarwinds.com/sa-overview/new-digital-certificate

Also, you are welcome to contribute to how we should do key management.

Thanks! I guess the fundamental disagreement here though is whether or not we should do key management at all as part of this specification. I would prefer not to and allow implementations to handle that as they see fit, rather than baking it into a specification.

For the last one, I agree that we could drop the outer spec and keep the payload spec. In fact, the first prototype of nv2 is not in JWT, and later we put the payload into the JWT form. As mentioned in the first sentence in the README, the signature spec is a JWT variant.

This makes the most sense to me. Drop the outer spec, call it a JWT/JWS rather than a variant, and settle on the payload spec.

If there is a specific threat around misuse of a Web PKI / TLS certificate to generate one of these signatures then you'll probably want to enforce a code signing key use in certs. The digital signature key use often appears in TLS client/server certs. I've looked in the past and I've never been able to find any standard mapping between x509 key usage / extended key usage and JWS operations.
+1 on switching to a plain old JWS. Are you planning on supporting signatures using JWKs as well as x509 certs? You'll need to enforce key use there as well. There, the only standard key uses are enc and sig. There's no equivalent to x509 "code signing".
Regarding the alg parameter: yea, it's different than the algorithm identifier in the x509 cert, which is specifying the algorithm the CA used to sign the cert. In this case we're specifying the aglorithm the cert holder is using to sign the JWS payload. That said, that alg header is a big ole bag of worms...
The idea behind the alg header is to provide "cryptographic agility". You can change / upgrade your signing algorithms and clients will continue working. This is a gigantic footgun, however, because it also allows an attacker to maliciously downgrade your algorithm to something unsafe / insecure. JWS/JWT went the extra mile by building in the degenerate worst-case scenario here with the "none" algorithm type. So if you write a naive JWS validator that simply looks at the header to find the alg it's trivially easy to forge a "valid JWS" with someone else's pubkey/identity/cert.
Long story short, it's critical that the verifier not accept any ole algorithm. There are a few ways I've seen this addressed in practice:

Profile JWS and standardize a fixed set of algorithms that you intend to support
Distribute the algorithms along with the key material (e.g., signed over in your cert or publish in the alg property of your JWKs at a trusted source)
Distribute the algorithm in a protocol discovery document (e.g., see id_token_signing_alg_values_supported in OIDC's discovery doc)

Either way, if you're gonna use JWS I think a solution to this problem needs to be baked in and there should be well documented implementation guidance for anyone writing a verifier.
Regarding secure timestamp: it probably is necessary. The threat is that a compromised key can be used to sign an artifact with a "fake" timestamp that claims it was signed before compromise. You either need to stop trusting anything signed with a key after a compromise (which means signatures over old artifacts will no longer validate) or you need some authentic evidence that an artifact was signed before a compromise occurred. Secure timestamps are one way to do that. This is not strictly a key management issue since it involves the signed artifacts, not the keys themselves. I think it does require some thought as part of the protocol: it should either be solved or explicitly identified as out of scope / not a threat that the protocol intends to protect againts.

Hey,
Any interest in discussing any of this stuff further? Is there any kind of timeline or process for deciding on what the actual "notary v2 signature" format will be?
It's kind of hard to tell how firm these specs are while the descriptions are in prototype branches.

An attractive feature of x509 is it could allow signing with a CA signed certificate (not self-signed like the current examples). A private self signed CA could be used to sign leaf certificates, which make Notary signatures. If clients allowed pinning this CA, you could use it to bootstrap trust.
I also agree in with the other comments here though. You need to decide if you're actually doing x509 or not. What fields is the verifier responsible for checking (CN, usage, etc.)? What happens when the certificate is expired? Trusted timestamping is a solution, but I don't think there's a standardized way to integrate it with JWTs. A transparency log could be a solution instead of trusted timestamping, but that's probably out of scope.
Ephemeral certs could enable some safe key management workflows for automated signing in CI.
If the spec becomes just "use JWS", it may make sense to name what types of algorithms to support. x509 does enable some use cases that other algorithms do not.

+1 to all of that @bburky - you basically described the exact design we're trying for over at github.com/sigstore, for all artifact types.
I'm still really hoping we can settle on a standard signature format to work across tools, is there anything I can do to help move this stuff forward? Or any timeline to when we can start iterating on/firming up these things?

@dlorenc Yep, I'm loosely aware of sigstore. It seems like an interesting solution. Something along the lines of "sigstore without fulcio" might make sense for enterprise or CI environments. Enterprises likely have existing PKI infrastructure, and signing in CI would be a non-person entity doing the signing which maps poorly to OIDC.
Notary's half of that would be standardizing the  signature format and ensuring x509 is a supported mode (possibly among other signature algorithms). Requiring trusted time-stamping (or something else). Defining what fields of a cert are checked (can I restrict a cert to some registry paths like example.com/foo/*:*?). Defining what happens on cert expiration. Etc.

Exactly! The certificate semantics, timestamp stuff, payload format and signature format are what I'm hoping we can agree on here and reuse in multiple places.

@mmalone I don't believe there is a misuse issue around PKI certs vs signing certs (ie the security issues are largely around enc vs sign only, and the encryption keys for TLS are ephemeral only). This is why JWS only separates these. As a policy matter you should have keys for different functions for revocation etc reasons, but its not a critical misuse issue.

I took a stab at more formally documenting the signature, payload and OCI formats we're using in sigstore here: https://github.com/sigstore/cosign/pull/214
I'm still hoping we can converge on something. I think the biggest disconnect right now is that we're storing the signature/payload separately rather than encoding into a JWS/JWT.


Listen to two sensors separately

Hello there,
This is a part of the manual control code. I added those two lines and i can display them using tab button. What i am trying to do is to display them on two separate windows using numpy and opencv. So can i listen to those two lines separately?
I am using:
carla 0.9.8
python 3.7
os: windows

Hi @AmirHarvey so what did u do ? I sm trying the same .. please share


tendermint-proto: Add a feature flag and generate gRPC server definitions

proto-compiler uses tonic-build
tendermint-proto can be compiled with std for the grpc feature
(as required by the generated tonic code)
the primary motivation is the new gRPC-based PrivVal interface
in Tendermint 0.35
(see https://github.com/informalsystems/tendermint-rs/issues/1134)

[x] Referenced an issue explaining the need for the change
[ ] Updated all relevant documentation in docs
[ ] Updated all code comments where relevant
[ ] Wrote tests
[x] Added entry in .changelog/

Codecov Report

Merging #1137 (1fdd02d) into master (cd3e391) will increase coverage by 0.0%.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #1137   +/-   ##
======================================
  Coverage    64.7%   64.7%
======================================
  Files         231     231
  Lines       15637   15637
======================================
+ Hits        10121   10122    +1
+ Misses       5516    5515    -1

Impacted Files
Coverage Δ

proto/src/lib.rs
100.0% <ø> (ø)

testgen/src/commit.rs
91.3% <0.0%> (+0.6%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cd3e391...1fdd02d. Read the comment docs.

@thanethomson +1 on this. It would unblock gRPC work on TMKMS

thanks @thanethomson , this unblocks some of the Tendermint 0.35 support work.
I also posted a proposal for follow up PRs: https://github.com/informalsystems/tendermint-rs/pull/1142 (rendered).
Could you take a look at it? I'm happy to either upstream the work for it or if it doesn't fit the goals of tendermint-rs, close the issue and do it outside of tendermint-rs.


Add many error handling

Also, a new AsyncChatGPT

Ah sorry, wait for me to debug please... So many bugs currently :(

Please have a look! :pray: :pray:  This might seem a lot of changes (indeed) but I think they largely improve this thing!
Summary:

Added a AsyncChatGPT
Added many error handling
Improved the refresh_session function: Navigate the browser to /api/session/auth rather than making a plain XHR request, so that we can pass the browser check.
Use a single browser and page across different instances of ChatGPT (but still different conversations), for less risk of getting Access denied or something like that.

This results in a much more stable behavior and more up time, according to my feelings when I use this library to build a qq bot. I believe this can help many people who also wants to build a bot.

Hey @SuperKen,
Firstly, thank you for submitting the PR. After reading your comment, it seems that you have resolved many of the issues we have been experiencing lately. We have been struggling with refreshing sessions for the past few weeks, and introducing async is a much-needed feature that we still don't have.
However, I don't think we can merge the PR in its current form. The reason being, firstly, it introduces many changes at the same time, and secondly, it adds unnecessary redundancies and complexities.
My proposal is that you create a PR that only includes the session refresh feature, and then we can go from there. What do you think?

I think it would be too troubling and error-prone to seperate async changes and error handling changes, because error handling codes are everywhere.
I think it might be better if we first merge the error handling part, then I PR the async part and we merge that.
What do you think?

Yes, breaking it down into those two steps would certainly make it easier to review and approve the PRs, let's do that.

Quick note that https://github.com/mmabrouk/chatgpt-wrapper/pull/169 ended up migrating Playwright to async, so that work is done for you!

Ohh that’s great! But… is it good to remove all the sync interfaces? Should we make a wrapper? 在 2023年2月28日，12:25，thehunmonkgroup @.***> 写道：
Quick note that #169 ended up migrating Playwright to async, so that work is done for you!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

You know, that might be a good idea, I didn't do that yet, and ended up having to convert some of the GPTShell methods as well. I don't have a lot of experience with async programming in Python, and only did this work because it seemed necessary as part of the Prompt Toolkit migration.

After a night of sleep, it's now clear that my initial async implementation has some, well, flaws ;)
I'm now convinced that we need the sync wrapper you suggested, and I'll work on cleaning that up in a bit.

I think I might not spend time on this anymore... if nobody else is working on this or you want please just close this pr...
Really had a great time cooperating with you!

Thanks for all your help on this project so far!


Remove the Steel tests and the Steel part of krmllib

Steel is being moved to its own repository: https://github.com/FStarLang/steel
Thus, this PR removes:

the Steel tests, now going to https://github.com/FStarLang/steel/tree/main/share/steel/tests/krml
the Steel part of krmllib, now going to https://github.com/FStarLang/steel/tree/main/include/steel and https://github.com/FStarLang/steel/tree/main/src/c . Thus, I believe that the krmllib parts of #341 should move there too.

This PR is a companion to FStarLang/FStar#2889.

do you have provisions in the new steel repo for regenerating Steel_Spinlock.h?

Yes, I documented it at https://github.com/FStarLang/steel/blob/main/CONTRIBUTING.md#modifying-the-steel-interfaces-of-the-libsteel-c-library
Moreover, the CI for the Steel repository regenerates it every time and checks that it has not changed.

are the tests running as before, including extraction and wasm execution?

Yes: https://github.com/FStarLang/steel/tree/main/share/steel/tests/krml are all part of the CI for the Steel repository.

what is the expected workflow, notably the new PR for spinlocks? I can merge it right now, before this PR, if it helps?

Yes, thank you for having merged #341. I just replicated it in the Steel repository. So, here is the expected workflow:

Have an Everest green on project-everest/everest#97
Revert 27347d0ac581fb1535db7fd4ae2293964b733bb7
Merge this PR
Merge the F* PR

Thanks again!


BDD: Features and scenarios to test dependent APIs

Description
Create a set of BDD features and scenarios to test dependent APIs. Use the example component from  reference-example-components issue 18 to build the scenarios.

Hi @LesterThomas,
Is this issue same as https://github.com/tmforum-oda/oda-canvas/issues/365

Fixed in #383


Nonlinear behavior

Hi! Maybe you can help or give some advice with applying non linear I-V curve characteristics in inference mode to yours crossbar simulator. I need to compute voltage drop (same as in badcrossbar) and take into account non linear I-V dependence.

Hi @anddudkin 👋
Taking into account only nonlinear IV characteristics or only line resistance effects is doable. Combining those two things may be unfeasible for large crossbar arrays.
badcrossbar just applies Ohm's law and Kirchhoff's current law to compute voltages and currents; due to the linearity of these circuit laws, this just happens to be a linear algebra problem. But even in this ideal, linear case, computations can be quite expensive for large crossbar arrays. Once you introduce nonlinearities, this becomes an exponentially more difficult problem.
If you are going to introduce nonlinearities, I'd recommend coming up with an approximation for line resistance effects. Computing these effects precisely when nonlinear IV behavior is present is likely to fail.
🔗 Our paper on badcrossbar
🔗 Our paper on nonideality-aware training, whose section 2.4.1 discusses nonlinear IV modelling.


Feature Request: Extend drop-overload to include overload category

Traffic drop request is provided to envoy as part of eds.ClusterLoadAssignment.policy.drop_overload
This along with lrs.ClusterStats.total_dropped_requests can be used as feedback loop to rate-limit traffic from envoy and check if it is having desired effect by a Central control system.
In v2 proto the expectation is that there is one Central control system which will generate this drop request and will use the feedback.
The Central control system could potentially generate drop_overload for various reasons

Load balancing feedback to prevent a client from overloading servers.
Centralized Quota/Rate management, requesting client to dial-back based on policies.

Fine grain control over specifying the type of 'drop_overload' and its feedback 'dropped_requests' can help provide better management and control.
More details + proposal for change.
https://docs.google.com/document/d/1gZENz8GZOo1-uvA299_Kxbo3D1XYg0fPbR0Ac_x9I_w/edit?usp=sharing

@mattklein123 @amb67 @alyssawilk for review.

I added one comment but sounds fine to me. My main comment is that given drop_overload is not implemented yet, let's just replace it entirely with the more flexible scheme with some notion of default category or something like that.

LGTM


new collector error on startup

got this error on startup of the collector
 screen = grab_screen(region=(0,40,800,640))
TypeError: grab_screen() got an unexpected keyword argument 'region'

changed the error to be more complete

can be closed


Can't get current logs from running container and return immediately

Is this a BUG REPORT or FEATURE REQUEST?:
BUG REPORT
Description
I want to get logs from running containers, so call "attachContainer()" to get a LogStream,  and use it to return a log-String.
However,  LogStream.readFully() will hang until the container stop.
How to reproduce
       dockerClient.startContainer(container.id());
        final String logs;
        try (LogStream stream = dockerClient.attachContainer(container.id(),
                DockerClient.AttachParameter.LOGS, DockerClient.AttachParameter.STDOUT,
                DockerClient.AttachParameter.STDERR, DockerClient.AttachParameter.STREAM)) {

                System.out.println("ready to get logs......");
                logs = stream.readFully();
                System.out.println("over...");
                System.out.println(logs);
        }

What do you expect
I want to get the current logs from running container.
What happened instead
The logs will return only when container stopped.
Software:

docker version:
Version:           19.03.2
API version:       1.40
Go version:        go1.12.8
Git commit:        6a30dfc
Built:             Thu Aug 29 05:26:49 2019
OS/Arch:           darwin/amd64
Experimental:      false

Server: Docker Engine - Community
Engine:
Version:          19.03.2
API version:      1.40 (minimum version 1.12)
Go version:       go1.12.8
Git commit:       6a30dfc
Built:            Thu Aug 29 05:32:21 2019
OS/Arch:          linux/amd64
Experimental:     false
containerd:
Version:          v1.2.6
GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
runc:
Version:          1.0.0-rc8
GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
docker-init:
Version:          0.18.0
GitCommit:        fec3683

Spotify's docker-client version:
8.16.0

Full backtrace

I think you should only pass DockerClient.AttachParameter.STREAM if you intend to stream logs from the container until it exits:

stream: Stream attached streams from the time the request was made onwards.

https://docs.docker.com/engine/api/v1.40/#operation/ContainerAttach