Improve install_cni_chaining to support updates to CNI conf file

The script is in charge of overwriting the cloud-specific CNI conf file
(e.g., 10-aws.conf for EKS).
However, the script is currently run as an initContainer, and does not
account for the possibility that the CNI conf file may be modified again
by the cloud provider at a later time, hence discarding the changes
made by the script.
For example, restarting aws-node on EKS will cause the 10-aws.conf file
to be overwritten with the default configuration, and Antrea will no
longer be involved in Pod networking configuration. For the user,
everything may appear to work from a connectivity standpoint, but
NetworkPolicies will not be enforced!
To avoid this issue, we run install_cni_chaining in a "normal"
container, and leverage inotify to monitor the CNI conf file. Every time
another process writes to the file, we process it one more time and
update it again if necessary.
This solution is not perfect. I think that there is a small possibility
of race conditions, but they remain very unlikely. One example is this
sequence of events:

aws-node overwrites the CNI conf file (because of a restart?)
a new Pod is created on the Node, the Antrea CNI is not used
install_cni_chaining updates the CNI conf file and adds Antrea to the
chain

Avoiding this race would require some major changes (e.g., to
antrea-eks-node-init). Because changes to the CNI conf file are very
infrequent, I think this is acceptable.
This solution is loosely based on the linkerd CNI installation script:
https://github.com/linkerd/linkerd2/blob/main/cni-plugin/deployment/scripts/install-cni.sh
Fixes ##3974
Signed-off-by: Antonin Bas<EMAIL_ADDRESS>

I tested this manually on EKS (aws-node restart):
$ kubectl -n kube-system logs antrea-agent-xbxms -c install-cni
[2022-07-15T00:42:07Z INFO install_cni_chaining]: updating CNI conf file 10-aws.conflist
uid=0(root) gid=0(root) groups=0(root)
[2022-07-15T00:42:07Z INFO install_cni_chaining]: Starting inotify monitor for 10-aws.conflist
Setting up watches.
Watches established.
[2022-07-15T00:42:56Z INFO install_cni_chaining]: inotify event in /host/etc/cni/net.d/: CREATE 10-aws.conflist
[2022-07-15T00:42:56Z INFO install_cni_chaining]: updating CNI conf file 10-aws.conflist
[2022-07-15T00:42:56Z INFO install_cni_chaining]: inotify event in /host/etc/cni/net.d/: CLOSE_WRITE,CLOSE 10-aws.conflist
[2022-07-15T00:42:56Z INFO install_cni_chaining]: sha matches existing one, ignoring event
[2022-07-15T00:42:56Z INFO install_cni_chaining]: inotify event in /host/etc/cni/net.d/: CLOSE_WRITE,CLOSE 10-aws.conflist
[2022-07-15T00:42:56Z INFO install_cni_chaining]: sha matches existing one, ignoring event

I will run CI jobs for EKS & AKS.

@antoninbas
I've been thinking about this:
`` `
This solution is not perfect. I think that there is a small possibility
of race conditions, but they remain very unlikely. One example is this
sequence of events:
aws-node overwrites the CNI conf file (because of a restart?)
a new Pod is created on the Node, the Antrea CNI is not used
install_cni_chaining updates the CNI conf file and adds Antrea to the
chain

Currently when a node is killed, EKS starts a new one. When that  new node joins the cluster antrea-agent , antrea-init-eks and all other daemon-sets ( or even deployments ) can be scheduled to the node BEFORE the antrea agent/antra-init-eks. Will those other pods not have netpol enforced ?

Currently when a node is killed, EKS starts a new one. When that new node joins the cluster antrea-agent and antrea-init-eks will be scheduled. But all other daemon-sets ( or even deployments ) can be scheduled to the node BEFORE the antrea agent/antra-init-eks. Will those other pods not have netpol enforced ?

For new Nodes, this is not an issue. This is what antrea-eks-node-init is for. However, there is an issue in case of a Node restart. This is partly my bad because I changed antrea-eks-node-init a while back to prevent it from running again in case of a restart. I'm thinking of reverting my change to that the antrea-eks-node-init script runs again in this case. I will do it in a follow-up PR thought.

Will this be backported to 1.7.2 ? Or only on 1.8 now ?

@jsalatiel I plan to backport this to v1.7

/test-all


Transposition Cipher

Related Issue

Info about the related issue

[x] DevIncept Participant

[ ] Contributor

Closes: #42
Describe the changes you've made
Added code for encryption and decryption of text using transposition cipher.
Type of change
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Manually run and tested
Checklist:

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly whereever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added test cases that prove my fix is effective or that my feature works.

I have done the changes requested.

Thank you!


fix(bytetrack): no need to throw exception when idx is out of range

Description
Since ColorMapper just returns a unique color to the caller, we simply use modulo to get a valid color index.
In such a way there is no need to check the index validity and throw a runtime exception.
Related links
Parent Issue:

Link

How was this PR tested?
Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

@chihungtzeng
I don't think you meant to edit so many files based on the title if your PR. Could you rebase and solve conflicts?

It is a mistake while I merge the files from the main branch. I will resolve it.

Please rebase your branch to the latest main and only keep your own commit (I think only this one is needed: https://github.com/autowarefoundation/autoware.universe/pull/8100/commits/089dbb3e29c1a2bb1d6c6e6c71224af13cc7fa44).

Github thinks that the src branch adds files belonging to other commits. I should create another PR.


Adds Testcontainers with SSL config for SSL-specific testing

Some features of the ElasticsearchIO connector[1] can only be verified by testing against a cluster with SSL and user/password authentication enabled.  We should provide a way to test that kind of environment specifically, ideally using Testcontainers (possibly along with docker-compose?).

[1] https://github.com/apache/beam/pull/17297#discussion_r857612803
Imported from Jira BEAM-14531. Original Jira may contain additional context.
Reported by: egalpin.

@egalpin @nishantjain91 are either of you planning to work on these test cases?

@johnjcasey loved to work on this but can only start in next month

Np, that timeline is fine. I'll assign this to you, and we can remove awaiting triage from this


chore: snap stable channel

License: MIT
Signed-off-by: Henrique Dias<EMAIL_ADDRESS>

Note:  this stopped attaching .snap to github release and instead uploads it to the snap store instead.
@hacdias do you know how snapStore backend tells if this is official build or not?


Update logo of enterprise applications using the CLI

Is your feature request related to a problem? Please describe.
Update logo of enterprise application.
Describe the solution you'd like
Being able to update the enterprise application logo using Azure CLI
Additional context
Using az ad sp update, it looks like you can update settings on the "Properties" tab of an Enterprise application ("Enabled for users to sign-in?", "User assignment required?", "Visible to users?"...) except logo. Could it be possible to also update logo using the CLI? E.g. as path to logo .png or input base64-encoded image.

Graph


Imported: Thank post feature?

Imported issue
Wed Nov 17, 2010 04:00 AM Thank post feature? by Glukom:

Forum32x has this and for the most part it's worked out extremely well. I
don't really think a dislike/disagree feature is really necessary, but the
ability to thank a post is always a fun one. I like being able to show
recognition for posts that are really awesome without having to flood the
topic with quotes and @!$%.

Wed Nov 17, 2010 04:01 AM Re: Thank post feature? by BlasterMaster:

Glukom:
Forum32x has this and for the most part it's worked out extremely well. I
don't really think a dislike/disagree feature is really necessary, but the
ability to thank a post is always a fun one. I like being able to show
recognition for posts that are really awesome without having to flood the
topic with quotes and @!$%.
thank you for suggesting this

Wed Nov 17, 2010 04:20 AM Re: Thank post feature? by Draku:

no, i don't want a "thank" feature
a "like" feature would be nice though!

Wed Nov 17, 2010 04:38 AM Re: Thank post feature? by Glukom:

same thing
or, at least, people use them for the same thing

Wed Nov 17, 2010 04:53 AM Re: Thank post feature? by Draku:

Glukom:
same thing
or, at least, people use them for the same thing
i know they're the same thing
just "thank post" sounds retarded imo

Wed Nov 17, 2010 05:36 AM Re: Thank post feature? by Glukom:

yeah i just went with that because i haven't seen a like post feature, it's
usually thank
like makes more sense though

Wed Nov 17, 2010 05:42 AM Re: Thank post feature? by JoshJDubya:

empty

Wed Nov 17, 2010 08:23 AM Re: Thank post feature? by Roo:

Pedigree:
Dislike
No.
I can live with liking but dislikes? @!$% no.

Wed Nov 17, 2010 08:29 AM Re: Thank post feature? by rtsmarty:

i like the idea of having a like button but not a dislike button

Wed Nov 17, 2010 08:40 AM Re: Thank post feature? by World'sTallestLadder:

hate the "positive input only" attitude spreading across the internet. no.

Wed Nov 17, 2010 08:45 AM Re: Thank post feature? by Oracular:

Quote:
hate the "positive input only" attitude spreading across the internet. no.
disliking a post is basically a flame (at least, it has the potential to be
used as a flame)
if you dislike a post you should have to quote them and say whatever you want.
liking on the other hand is different, as you're essentially agreeing with or
praising the comment; no explanation is needed.

Wed Nov 17, 2010 08:48 AM Re: Thank post feature? by World'sTallestLadder:

Oracular Orion:
Quote:
hate the "positive input only" attitude spreading across the internet. no.
disliking a post is basically a flame (at least, it has the potential to be
used as a flame)
if you dislike a post you should have to quote them and say whatever you want.
liking on the other hand is different, as you're essentially agreeing with or
praising the comment; no explanation is needed.
Why is no explanation needed for liking something? Both "I don't like this"
and "I like this" have reasons behind them, don't be silly.

Wed Nov 17, 2010 08:51 AM Re: Thank post feature? by Retriever II:

Kesha:
hate the "positive input only" attitude spreading across the internet. no.
Feedback is open to abuse and negative feedback just seems to attract more of
it.

Wed Nov 17, 2010 09:16 AM Re: Thank post feature? by Kyori:

I would be more for liking only than I would for both like/dislike.
I'm still not a great fan but it'd definitely be less bad.

Wed Nov 17, 2010 09:16 AM Re: Thank post feature? by World'sTallestLadder:

Retriever II:
Kesha:
hate the "positive input only" attitude spreading across the internet. no.
Feedback is open to abuse and negative feedback just seems to attract more of
it.
Not really!
While I could agree that abusive positive feedback most often comes from
attacking negative feedback, that's not a good reason to throw negative
feedback out the window.
Abusive or disruptive feedback is the problem, so go after that. Dumb to
attack negative feedback.

Wed Nov 17, 2010 09:20 AM Re: Thank post feature? by Retriever II:

Kesha:
Retriever II:
Kesha:
hate the "positive input only" attitude spreading across the internet. no.
Feedback is open to abuse and negative feedback just seems to attract more of
it.
Not really!
While I could agree that abusive positive feedback most often comes from
attacking negative feedback, that's not a good reason to throw negative
feedback out the window.
Abusive or disruptive feedback is the problem, so go after that. Dumb to
attack negative feedback.
It is a good reason to throw negative feedback out the window. It's also a
good reason to throw positive feedback out the window.

Wed Nov 17, 2010 09:22 AM Re: Thank post feature? by Kyori:

Kesha:
Retriever II:
Kesha:
hate the "positive input only" attitude spreading across the internet. no.
Feedback is open to abuse and negative feedback just seems to attract more of
it.
Not really!
While I could agree that abusive positive feedback most often comes from
attacking negative feedback, that's not a good reason to throw negative
feedback out the window.
Abusive or disruptive feedback is the problem, so go after that. Dumb to
attack negative feedback.
imo people learn better from positive reinforcement than they do from negative
criticism.
Obviously that doesn't apply to when you can provide constructive criticism,
but you quite obviously can't be constructive in any way by just clicking a
"dislike" button.
But yeah, positivity teaches people way better than negativity. That said,
it's still open to abuse so I'm not sure if we should have either.

Wed Nov 17, 2010 09:27 AM Re: Thank post feature? by World'sTallestLadder:

Retriever II:
Kesha:
Retriever II:
Feedback is open to abuse and negative feedback just seems to attract more of
it.
Not really!
While I could agree that abusive positive feedback most often comes from
attacking negative feedback, that's not a good reason to throw negative
feedback out the window.
Abusive or disruptive feedback is the problem, so go after that. Dumb to
attack negative feedback.
It is a good reason to throw negative feedback out the window. It's also a
good reason to throw positive feedback out the window.
no feedback poses the question of why are you even on a forum

Wed Nov 17, 2010 09:45 AM Re: Thank post feature? by Retriever II:

I didn't know forums were exclusively composed of anonymous like/dislike
votes.

Wed Nov 17, 2010 10:38 AM Re: Thank post feature? by Captain Flame Guy:

With features like that you wouldn't be able to get something out of it,
except for a bit more e-peen
you wouldn't get any criticism at all that way

Wed Nov 17, 2010 10:53 AM Re: Thank post feature? by Chipper:

Captain Flame Guy:
With features like that you wouldn't be able to get something out of it,
except for a bit more e-peen
you wouldn't get any criticism at all that way
You would get criticism in the form of a constructive post, rather than a
simple "I dislike this," whereas if someone likes your post they could just
say they liked your post.
I'm for saying I like the post, then responding to it as well, but I'm not for
a dislike feature as it's prone to abuse more than a like feature is (which
can also be prone to abuse in very certain circumstances, but not near as
easily as a dislike feature).
To actually clarify my stance (EDIT): I'm not actually for this at all. It's
not fair to have it only be one side of the coin, but at the same time I'm not
a fan of the possibility of abuse if both sides of the coin are available.

Wed Nov 17, 2010 11:08 AM Re: Thank post feature? by Kyori:

goddamn what is wrong with these permissions

Wed Nov 17, 2010 11:21 AM Re: Thank post feature? by World'sTallestLadder:

Teddy:
I dislike the whole thanking system because it promotes laziness and reduces
activity.  Welp, that's a day. close window"
all people ever post is "i like this" and "I don't like this" right?!??!
come on that's ridiculous

Wed Nov 17, 2010 12:48 PM Re: Thank post feature? by rtsmarty:

would it be possible to exclude a feature like this from the creativity
boards? i mean i think teddy has somewhat of a valid complaint there
in other boards, all it would do (in theory at least) is stop posts like
"this" "user was thanked for this post", or "where is the thank post button"
etc. i can't see much worthwhile discussion actually being lost because of it.

Wed Nov 17, 2010 07:08 PM Re: Thank post feature? by VinnyVideo:

I don't see any real need for a "Like" post feature; if you say something
brilliant or funny on the forums, people are going to make it clear in other
ways that they liked your post. And a "Dislike" button is a terrible idea that
would probably end up discouraging new members from sticking around.

Wed Nov 17, 2010 08:57 PM Re: Thank post feature? by RetroX:

Oracular Orion:
disliking a post is basically a flame (at least, it has the potential to be
used as a flame)
and liking also has the potential to be trolling
rating posts in general is a bad idea imo
f32x doesn't do it well; it's basically
"smok 420 peas"
"thanked by 20 members"

Wed Nov 17, 2010 10:09 PM Re: Thank post feature? by Glukom:

RetroX:
Oracular Orion:
disliking a post is basically a flame (at least, it has the potential to be
used as a flame)
and liking also has the potential to be trolling
rating posts in general is a bad idea imo
f32x doesn't do it well; it's basically
"smok 420 peas"
"thanked by 20 members"
someones mad they never make posts that get thanked by 20 members
also its not rating posts, its people expressing whether or not they thought a
post was cool or not
it has less to do with the number of likes than it has to do with the person
liking it
i dunno, i just think its kind of a nice feature sometimes
i can sort of understand the arguments against it though

Wed Nov 17, 2010 10:17 PM Re: Thank post feature? by Oracular:

RetroX:
Oracular Orion:
disliking a post is basically a flame (at least, it has the potential to be
used as a flame)
and liking also has the potential to be trolling
rating posts in general is a bad idea imo
f32x doesn't do it well; it's basically
"smok 420 peas"
"thanked by 20 members"
that example isn't really 'trolling', per se.
it's just being incredibly cool and edgy. which can't really be construed as
negative for the forum
although yeah, there are instances in which it can be used sarcastically and
may be seen as flaming, but these are more obvious to spot out...
eh, I can see both PoV. as long as there is no dislike button, I'm cool.

Wed Nov 17, 2010 10:20 PM Re: Thank post feature? by Oracular:

again, I wouldn't class it as flaming, but I can see why it would be
discouraged.

Wed Nov 17, 2010 10:55 PM Re: Thank post feature? by RetroX:

Glukom:
someones mad they never make posts that get thanked by 20 members
not really; just annoyed that people are thanking depending on who says
something rather than what a post actually says (usually)
I can imagine the same thing happening
thanking posts is good in theory, but are almost never used well

Thu Nov 18, 2010 11:06 AM Re: Thank post feature? by Chipper:

RetroX:
Glukom:
someones mad they never make posts that get thanked by 20 members
not really; just annoyed that people are thanking depending on who says
something rather than what a post actually says (usually)
Oh cool I'm not the only one that noticed that over there (it's why I only
made like two posts).

Thu Nov 18, 2010 11:43 AM Re: Thank post feature? by Oracular:

actually yeah
@!$% liking/disliking
I forgot it was one of the reasons f32x sucked

Thu Nov 18, 2010 05:37 PM Re: Thank post feature? by Glukom:

RetroX:
Glukom:
someones mad they never make posts that get thanked by 20 members
not really; just annoyed that people are thanking depending on who says
something rather than what a post actually says (usually)
this happens to an extent but tbh pretty much any good post gets thanked a
lot, regardless of who posts it
there definitely is some of that though, you're right, and while i'd hope that
wouldn't be a problem here i guess we couldn't really count on it

Thu Nov 18, 2010 05:42 PM Re: Thank post feature? by JoshJDubya:

empty

Thu Nov 18, 2010 06:48 PM Re: Thank post feature? by Chipper:

Pedigree:
Perhaps rather than Like, an Agree option.
To reduce posts just to say "this" or "^".
Possibly a good alternative, but in the end that would be rather pointless as
it would spark people who disagreed calling people out and asking why they
agreed.
That and I'm sure that most people would appreciate an explanation of why
someone agrees.
Also it'd be rather silly for someone to tell a joke and people to "agree"
with the joke. :P

Thu Nov 18, 2010 07:35 PM Re: Thank post feature? by VinnyVideo:

"Agree" and "Like" are, in practice, the same thing.

Thu Nov 18, 2010 08:05 PM Re: Thank post feature? by Chipper:

VinnyVideo:
"Agree" and "Like" are, in practice, the same thing.
No.
I can agree with a decision made by a higher up, but I can also hate that very
same decision.
Before you argue and are like, "But in this case--" don't. I have a fair grasp
of why he offered an "agree," rather than a "like," option.

Thu Nov 18, 2010 09:26 PM Re: Thank post feature? by JoshJDubya:

empty

Thu Nov 18, 2010 09:31 PM Re: Thank post feature? by Chipper:

Pedigree:
In any case on SFGHQ they had some type of like dislike feature where you had
to state why you liked or disliked the post, and if we were to use that it
could be useful.
That I would get behind, definitely.

Thu Nov 18, 2010 06:48 PM Re: Thank post feature? by Chipper:

Pedigree:
Perhaps rather than Like, an Agree option.
To reduce posts just to say "this" or "^".
Possibly a good alternative, but in the end that would be rather pointless as
it would spark people who disagreed calling people out and asking why they
agreed.
That and I'm sure that most people would appreciate an explanation of why
someone agrees.
Also it'd be rather silly for someone to tell a joke and people to "agree"
with the joke. :P

Thu Nov 18, 2010 07:35 PM Re: Thank post feature? by VinnyVideo:

"Agree" and "Like" are, in practice, the same thing.

Thu Nov 18, 2010 08:05 PM Re: Thank post feature? by Chipper:

VinnyVideo:
"Agree" and "Like" are, in practice, the same thing.
No.
I can agree with a decision made by a higher up, but I can also hate that very
same decision.
Before you argue and are like, "But in this case--" don't. I have a fair grasp
of why he offered an "agree," rather than a "like," option.

Thu Nov 18, 2010 09:26 PM Re: Thank post feature? by JoshJDubya:

empty

Thu Nov 18, 2010 09:31 PM Re: Thank post feature? by Chipper:

Pedigree:
In any case on SFGHQ they had some type of like dislike feature where you had
to state why you liked or disliked the post, and if we were to use that it
could be useful.
That I would get behind, definitely.

Fri Nov 19, 2010 08:02 PM Re: Thank post feature? by Draku:

Teddy:
imo there's nothing wrong with blankquoting or posts that say "this"
it was looked down upon and regarded as spam at points on mfgg though
damn conflicting moderator views

See #28


Network status not returning True if mobile data is active.

I just checked it out and confirmed. I'll fix it asap. Thanks for feedback.

I already fixed it bro. I have created a Pull Request and merged it but I
can't see the changes I made on the main code.
I'm new to GitHub and this is first time creating a PR.
On Sun, Jan 16, 2022, 1:20 PM Yunus Ceyhan @.***> wrote:

I just checked it out and confirmed. I'll fix it asap. Thanks for feedback.
—
Reply to this email directly, view it on GitHub
https://github.com/kvdroid/Kvdroid/issues/26#issuecomment-1013865765,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQRWA66E5GGP2QM42YCKHITUWKZYZANCNFSM5MCWP6RQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Am I supposed to merge the changes I made myself?
On Sun, Jan 16, 2022, 1:23 PM Agboola Odunayo @.***>
wrote:

I already fixed it bro. I have created a Pull Request and merged it but I
can't see the changes I made on the main code.
I'm new to GitHub and this is first time creating a PR.
On Sun, Jan 16, 2022, 1:20 PM Yunus Ceyhan @.***>
wrote:

I just checked it out and confirmed. I'll fix it asap. Thanks for
feedback.
—
Reply to this email directly, view it on GitHub
https://github.com/kvdroid/Kvdroid/issues/26#issuecomment-1013865765,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQRWA66E5GGP2QM42YCKHITUWKZYZANCNFSM5MCWP6RQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Ok i checked your solution and fixed it by it. Thanks for your contribution.
https://github.com/kvdroid/Kvdroid/commit/cc9241f7f43fb3bc3d72ee8201dc1bb3627fe1fb

Alright, thanks.
I wanted to ask...Did I do the Pull Request the right way? I was hoping to
see my changes or link on the pull request tab but I didn't and I was
thinking no one too will.
On Sun, Jan 16, 2022, 2:11 PM Yunus Ceyhan @.***> wrote:

Ok i checked your solution and fixed it by it. Thanks for your
contribution.
cc9241f
https://github.com/kvdroid/Kvdroid/commit/cc9241f7f43fb3bc3d72ee8201dc1bb3627fe1fb
—
Reply to this email directly, view it on GitHub
https://github.com/kvdroid/Kvdroid/issues/26#issuecomment-1013873547,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQRWA66IX4CJ3H2DFQ74MOLUWK7W3ANCNFSM5MCWP6RQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

After commiting changes on your fork just create a pull request then wait for the repo owner to merge it.

Thank you
On Sun, Jan 16, 2022, 2:58 PM Yunus Ceyhan @.***> wrote:

After commiting changes on your fork just create a pull request then wait
for the repo owner to merge it.
—
Reply to this email directly, view it on GitHub
https://github.com/kvdroid/Kvdroid/issues/26#issuecomment-1013881208,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQRWA656ZWUVCGYO7YPFCHLUWLFIBANCNFSM5MCWP6RQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>


Show multiple accounts in the the timeline

I love the design of this app. But two things that are keeping me from switching is.

Show multiple accounts in Timeline. If I'm logged into two or more accounts, I would love to only have to refresh one timeline and that shows me all the news. (See Twidere on F-droid for an example)
Swipe between different things rather than open the menu. Between messages, interactions, etc.

Thanks!

That's a functionality, I would appreciate too.
Nice design, clean and straight. Thanks.

Or, have a "unified" timeline like mail clients do

This would be very cool!

Would be great, yes. This would simplify using mastodon and twitter in parallel.


test reaper / socialreaper

https://github.com/ScriptSmith/socialreaper
https://reaper.social

add to the tested platform sections as discussed (Twitter and misc)

somehow reaper ended up on the tool list for instagram instead of twitter/facebook. was that on purpose or does this needs to be fixed, @FlxVctr ?


Feedback magnify - Input

Purpose
Adding and using Cunningham in magnify, I have some thoughts and remarks on the input component
Proposal

If the input is of type password, add the possibility to show or hide it. (Don't forget the case if there is an icon on the left.)

Be able to add a placeholder in addition to a label (or finally choose to put the placeholder in the text props. And why not use the placeholder props and use it in the text props)

Have the same default height as the default button height

I created an issue for the retained proposals, thank you 🙏
https://github.com/openfun/cunningham/issues/301


Is CSS transform skew (x,Y) Equivalent exist for Velocity.js ?

Hello Julian,
I notice that i can't have the same result from css transform skew(x,y) with Velocity.
http://jsfiddle.net/xqhqwyL3/
I think it's not an issue so sorry if my post isn't in the right place.
My idea is that I want to create a personal web site with a " star menu". So i need to use skew transformation with animation. I know I have to define transform in js otherwise the animation will overwrite the transform property.
Also, I know a part of the problem is that Velocity respect "SVG transformation", so we can't use skew with 2 arguments.
I tried to find something in Velocityt's source file but I only found that there is no merge for skew property.
My problem is very particular and i might be the only one who want to do that but still, if you have a solution for me it would be great =).
Velocity is a stunning work men thanks a lot !
Cordialy Romain.
PS : Sorry for my english I have tried my best but ... I know it's bad.

Indeed, I think what you are saying is that skew(35,35) != skewX(35) skewY(35) ? Which is correct, so they aren't interchangeable like that. In the absence of any other solutions, you could roll your own with progress. I'm not sure if this method loses any efficiency brought about with Velocity, but it should be ok if necessary as a workaround.
$(".loxange").velocity(
    { tween: 35 },
    { progress: skewFunc },
    1000);

function skewFunc(elements, complete, remaining, start, tweenValue) {
  var t = 'skew(' + tweenValue + 'deg,' + tweenValue + 'deg)'
  elements[0].style.transform = t ;
}

http://jsfiddle.net/ian_b/xqhqwyL3/4/

Hello julian,
Thanks for your answer, I didn't know this tips. It's quite interesting and
I will try as soon as I can. Thanks again !
Cordialy Romain
Le 20 nov. 2015 17:11, "Ian"<EMAIL_ADDRESS>a écrit :

Indeed, I think what you are saying is that skew(35,35) != skewX(35)
skewY(35) ? Which is correct, so they aren't interchangeable like that. In
the absence of any other solutions, you could roll your own with progress.
I'm not sure if this method loses any efficiency brought about with
Velocity, but it should be ok if necessary as a workaround.
$(".loxange").velocity(
{ tween: 35 },
{ progress: skewFunc },
1000);
function skewFunc(elements, complete, remaining, start, tweenValue) {
var t = 'skew(' + tweenValue + 'deg,' + tweenValue + 'deg)'
elements[0].style.transform = t ;
}
http://jsfiddle.net/ian_b/xqhqwyL3/4/
—
Reply to this email directly or view it on GitHub
https://github.com/julianshapiro/velocity/issues/605#issuecomment-158445862
.


modules: OCI clients should set helpful User-Agent HTTP headers in requests

As we get ready for the v0.8.0 release with the modules experiment via OCI registries implemented in both cmd/cue and cue/load, I think it's really important that we do the final release with configured user-agents in all HTTP requests done to registries.
By default, Go's net/http user agent is rather basic (https://cs.opensource.google/go/go/+/refs/tags/go1.22.0:src/net/http/request.go;l=538) and is shared by all net/http clients that don't configure one, so it's almost useless to OCI registries wanting to see who the client is.
The user agent should include at least these parts:

What kind of client it is - cmd/cue or cue/load
What version of the client - i.e. the same semver reported by cue version
What platform the client is running on - i.e. GOOS/GOARCH
What version of Go built the client - i.e. https://pkg.go.dev/runtime#Version

The format (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent) appears to be a ${product}/${version} followed by a list of either (${comment}) or more product versions, like PostmanRuntime/7.26.5 or Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41. Following that example, a user agent string might be like:

CmdCue/v0.8.0 (linux/amd64) Go/go1.22.0 on a cmd/cue release binary
CueLoad/v0.8.0-alpha.3.0.20240229113828-93acaa356a70 (linux/amd64) Go/devel_go1.23-0784fd1b2f_2024-02-29_01:07:18_+0000 on a cue/load API user using master of both CUE and Go (note how Go devel version strings contain spaces, which we replace to make a single Product/Version user agent component)

The first one is helpful because cmd/cue and cue/load will be used in different kinds of scenarios and behave differently. And in particular, the CUE and Go versions will be helpful for the server to be able to implement fixes and workarounds that only affect particular versions, e.g. if we ship CUE v0.8 and it turns out to have a bug that spams repeated requests to the server, and that is fixed in v0.9, the server can be patched to reject or rate limit requests from v0.8.
The platform information is also useful as both CUE and Go may behave quite differently depending on the OS, for example when making network requests, so some bugs may only happen on a particular platform. Knowing that some errors or failures only happen on certain platforms would greatly help with debugging on the server side.
Finally, setting a real and somewhat unique user agent will be helpful so that third party HTTP servers or proxies are less likely to treat our client requests as abuse or spam.
Note that none of this information would be unique to a user, nor would it leak any information about what CUE or Go code they are developing. For all the reasons above, and because there shouldn't be any privacy concerns over such a user agent string, we don't intend the user-agent string to be configurable in any way.

@rustamabd2 points out that since cmd/cue and cue/load share the majority of the code to talk to the OCI registry, and that in the end they are both clients coming from the same project/software, they should share the same "top-level" product kind, and add another component to specify which API entrypoint was used.
Revising the two examples from earlier:

Cue/v0.8.0 (cmd/cue) (linux/amd64) Go/go1.22.0
Cue/v0.8.0-alpha.3.0.20240229113828-93acaa356a70 (cue/load) (linux/amd64) Go/devel_go1.23-0784fd1b2f_2024-02-29_01:07:18_+0000

The package path comment goes first, because it feels like the most important piece of information.

Great point, thanks for raising the issue.
Per our chat, the only one point I would like to clarify is how uses of the Go API would go about setting the user agent for their CUE-based tool. Please can we clarify what that would look like?

Moreover, cue/load having a configurable HTTP client is also important for other reasons - configuring the timeouts, transport, TLS settings, etc. Otherwise it's all the default per http.DefaultClient.

Now seeing https://github.com/cue-labs/oci/issues/28, I think using ociclient.Options.HTTPClient to set the user-agent might not be the right choice if that disables the use of the authorizer. I'll let @rogpeppe chime in once he's back next week.

For the sake of context and reference, note that @rogpeppe decided to change the order of the Go version and goos/goarch, so now in master we have Go/go1.22.0 (linux/amd64) rather than (linux/amd64) Go/go1.22.0 as described above. Quoting him:

The reason I changed the order is that all the examples in https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent seemed to have the parenthesized attributes after a non-parenthesized attribute, as if they're qualifying the term before. That's how I read the user agent strings, anyway, and that seems to make sense to me.
So it seems to me that the goos/arch is qualifying the Go attribute that goes before it (and the "Go/" prefix makes it clear how to parse the qualifier that follows it).


Styled tables are very slow vscode console

Here is a minimal script that reproduces the issue:
import time

from rich.console import Console
from rich.table import Table

table = Table(title="Test")

columns = range(20)
for i in columns:
    table.add_column(str(i), style="green")

for row in range(20):
    table.add_row(*[f"{row}-{i}" for i in columns])

console = Console()

start = time.time()
console.print(table)
total = time.time() - start
console.print(f"[red]This took {total:.2f} seconds")

Inside the vscode console (Windows 10): This took 1.29 seconds
In regular shell (Windows 10 / Ubuntu): This took 0.10 seconds
It seems that the issue comes from using colors. Without style, the table renders much faster under vscode (0.2 seconds).
I realize this probably isn't a high-priority issue, but I thought you might like to know!
P.S. Great library, I just discovered it and it's a lot of fun! I wish I could use it to replace everything prompt-toolkit does

What you are timing there is mostly the terminal. Dedicated terminals tend to be faster than HTML terminals.
Try the following change, which separates generating the table from the time it takes to render on the terminal:
import time

from rich.console import Console
from rich.table import Table

table = Table(title="Test")

columns = range(20)
for i in columns:
    table.add_column(str(i), style="green")

for row in range(20):
    table.add_row(*[f"{row}-{i}" for i in columns])

import io
console = Console(file=io.StringIO(), force_terminal=True)

start = time.time()
console.print(table)
result = console.file.getvalue()
total = time.time() - start
print(result)
print(f"This took {total:.2f} seconds")

I see, so it seems that the problem is with the way the vscode terminal handles color escaping.
Thanks for the quick reply!

Old thread, but adding some context in case anyone finds it useful. VS Code's terminal has 3 different renderers which are now driven by the terminal.integrated.gpuAcceleration setting. The best experience by far is if you have that as "on" (or "auto", but that will fallback if a problem is detected) which will use WebGL2 to render the buffer and should generally be on par with native terminals.
Unfortunately WebGL2 doesn't work on all environments though and rarely there are strange issues that come with it typically related to GPU drivers/Chromium.


Upgrade to Gradle 2.11

Upgrade from Gradle 2.10 to 2.11
Also removes some unnecessary code from security configuration.

Current coverage is 79.98%

Merging #184 into develop will increase coverage by +0.04% as of 68a529c

@@            develop    #184   diff @@
=======================================
  Files            90      90
  Stmts          2767    2763     -4
  Branches        266     266
  Methods           0       0
=======================================
- Hit            2212    2210     -2
  Partial          64      64
+ Missed          491     489     -2

Review entire Coverage Diff as of 68a529c

Powered by Codecov. Updated on successful CI builds.


Separate fail_under option for branch and statement coverage

Is your feature request related to a problem? Please describe.
In our team, we want to assert that at least 80% branch coverage are reached. Meanwhile, statement coverage should also always be at 100%. However, fail_under = 80.0 only applies to the branch coverage if you enable the collection of it via branch = True.
Describe the solution you'd like
Some option to set a threshold per coverage type wold be great. For example, by specifying branch = True, fail_under_statements = 100.0, fail_under_branch = 80.0. Also, fail_under could default to the current behavior (i.e. become an alias to branch coverage if it is enabled and else specify statement coverage).
Describe alternatives you've considered

Writing a script that parses the output of coveragepy and realizes the same behavior. This is annoying since many different teams would have to do this on their own. Although one could also publish the (admittedly rather small) snippet in the docs of this library.
Have a human check the output (e.g. in reviews).

Additional context
Distantly related to #666.

I'm wondering if using the json report to drive some conditionals outside of coverage.py would be a simple way to get what you need.

Well, yeah. If you have the the above setup (collect coverage with branch=True, fail_under=80.0), the tool will correctly report coverage being under 80%. The additional constraint on 100% statement coverage can be achieved like this (using Python 3):
coverage json
cat coverage.json | python -c "import json,sys;miss=json.load(sys.stdin)['totals']['missing_lines'];exit(1 if miss == 0 else 1);"

That works, yes. Thank you for the hint. You may still consider whether this is worth adding to the tool or its documentation.

While it works, it does a poor job at showing which lines are not statement-covered.

See https://nedbatchelder.com/blog/202111/coverage_goals.html for progress on improved target measurement.


'sharedApplication' is unavailable - xcode compilation error with Firebase 4.11.0 & FirebaseAuth 4.5.0

Xcode version: 9.2
Firebase SDK version: 4.11.0
Firebase Component: Auth
Component version: 4.5.0

[REQUIRED] Step 3: Describe the problem
I'm running a Swift 4.0, iOS 11 app attempting to upgrade to the new Firebase 4.11.0 & FirebaseAuth 4.5.0.
My end purpose is to use Auth.auth().sendSignInLink capability, which is only available with these versions.
I'm getting the following compilation error inside the FirebaseAuth library:

This is the relevant part of my Podfile

:
Thank you for your speedy handling of github issues! You're doing a great job!

@jyaunches,
Thanks for raising this issue. I have a quick question; are you building an App Extension?
cheers,
-Z

By 'App Extension', do you mean framework? If so, nope! This is just a standard iOS client app!

From your screen shot, it looks like OneSignalNotificationServiceExtension is an extension.
It's not valid to use UIApplication in an app extension and Firebase doesn't officially support app extensions.

You know.. your earlier question made me go back and look at the Podfile again. With the earlier version of the Cocoapod, I had moved it outside this target to make it available for the unit test suite. This may not be a good practice. Either way, I got things working by putting the pod specifications back inside the project target.
So, I'm good! Thanks for you time.

Revisiting FirebaseAuth, Firebase 5.x and extensions in #1357


Bevy 0.15 migration

Made changes necessary for bevy 0.15 migration. Main change was adding the repeat flag to keyboard events, due to this PR.
I didn't dig too far into making sure the flag is correct in every case, as currently the key repeat double-buffering code has some bugs and is subject to change. I simply set it to false except for when sending the "reciprocal" repeat events.

Codecov Report
Attention: Patch coverage is 0% with 7 lines in your changes missing coverage. Please review.

Project coverage is 0.00%. Comparing base (221d7bd) to head (3294fd4).

Files with missing lines
Patch %
Lines

src/input_forwarding/keyboard.rs
0.00%
7 Missing :warning:

Additional details and impacted files
@@          Coverage Diff          @@
##            main     #27   +/-   ##
=====================================
  Coverage   0.00%   0.00%
=====================================
  Files          7       7
  Lines        805     815   +10
=====================================
- Misses       805     815   +10

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

LGTM


RELATED: RAIL-3955 Fix dashboard styles when not used inside of Page

Better scope the header style so that they are not applied
when the user removes the Page component.
JIRA: RAIL-3955

The code coverage is the same after your change 🤟
This is a good thing if you are not sure ;)
Report (compared to build #307)
Covered lines: 22.73%, change: 0%
Covered branches: 33.33%, change: 0%
Coverage report
https://checklist.intgdc.com/job/client-libs/job/gooddata-create-gooddata-react-app-unit-tests-zuul-docker-el7/308/artifact/ci/results/coverage/lcov-report/index.html

Build succeeded (check pipeline).

https://checklist.intgdc.com/job/client-libs/job/gooddata-create-gooddata-react-app-unit-tests-zuul-docker-el7/308/ : SUCCESS in 1m 08s
https://checklist.intgdc.com/job/compliance/job/gooddata-create-gooddata-react-app-oss-check/250/ : SUCCESS in 7s

The code coverage is the same after your change 🤟
This is a good thing if you are not sure ;)
Report (compared to build #307)
Covered lines: 22.73%, change: 0%
Covered branches: 33.33%, change: 0%
Coverage report
https://checklist.intgdc.com/job/client-libs/job/gooddata-create-gooddata-react-app-unit-tests-zuul-docker-el7/309/artifact/ci/results/coverage/lcov-report/index.html

Build succeeded (gate pipeline).

https://checklist.intgdc.com/job/compliance/job/gooddata-create-gooddata-react-app-merge-compliance-check/123/ : SUCCESS in 18s
https://checklist.intgdc.com/job/client-libs/job/gooddata-create-gooddata-react-app-unit-tests-zuul-docker-el7/309/ : SUCCESS in 1m 03s
https://checklist.intgdc.com/job/compliance/job/gooddata-create-gooddata-react-app-fossa-scanning-zuul-el7/88/ : SUCCESS in 1m 12s (non-voting)


Remove trailing comma from the last tsconfig setting

TypeScript Version:  2.4.1 / nightly (2.5.0-dev.20170621)
The default generated tsconfig.json has a trailing comma for the emitDecoratorMetadata setting that's not required and often causes silent bugs.
Current settings file
{
  {
    ...
    // "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */
  }
}

Expected
{
  {
    ...
    // "emitDecoratorMetadata": true          /* Enables experimental support for emitting type metadata for decorators. */
  }
}

It's convenient to have this so you can move it to another location in the file without adding the comma yourself. How exactly is this causing problems?

OK, I can't speak for others but at least I tend to not move around these options at all — I only go out and enable or change them in-place, in which case this last option will always break the json. Still, I'll go ahead and make the (somehow weak) argument that not many are likely to place them before the 3 options already enabled by default because those 3 seem far more significant by virtue of being explicitly enabled.
There's already the slight constant friction of needing to add the comma after "strict": true whenever an option below it needs to be set, I thought this small change might help make things a bit smoother. :)

@RyanCavanaugh, does your same rationale apply to this enum example, and, more importantly, is this done deliberately by the TypeScript compiler? It gives us a bit of trouble with TSLint's no-trailing-comma rule.
enum Colors {
    Blue = "BLUE",
    Green = "GREEN",
    Red = "RED"
}

results in TypeScript definition with trailing comma:
declare enum Colors {
    Blue,
    Green,
    Red,
}

@simonua I would consider that a bug - we should write out the same commas you did

@RyanCavanaugh, glad to hear that. Thank you! Would you like me to create a new issue (and reference this) or is this current issue sufficient?

Please create a new issue. Thanks!

@prashaantt, can you elaborate on your comment that "the last option will always break the json"? As of TypeScript 2.4 we are a little bit more relaxed when parsing JSON files used by the compiler to improve the experience when using an editor to modify configuration.
I can see how it could make the tsconfig.json file unreadable in earlier versions of the compiler (which do not allow the trailing comma), though that can be remedied by manually removing the comma.

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.


'commit amend' fails and resets to wrong location

In the command-line I amended a commit (successfully) while on a detached head.  I realized I needed another change added, so I made the change and used Git-Plus to add the file. Then I used Git-Plus to amend the previous commit.
Git-Plus opened the commit message in a new buffer but it immediately reported an error:
Git-Plus
: Commit amend aborted!

It then reset my head to the wrong previous location (ORIG_HEAD, but it was wrong because of the series of resets Git-Plus performed; see below).
When I eventually cancelled the amend by closing the left-open commit message tab, Git-Plus reset my head again to a new (wrong) location.  Then it again reported the "amend aborted!" error.
Git-Plus
: Commit amend aborted!

Here's the output from 'git reflog --relative-date' showing the commit I successfully amended from the commandline and then the subsequent resets performed by Git-Plus.  The most recent reset occurred after I closed the (already aborted) commit message tab.  The previous 5 resets occurred immediately when I tried the "Git Plus: Commit amend".
37ac942 HEAD@{12 seconds ago}: reset: moving to ORIG_HEAD
59f6d6d HEAD@{41 seconds ago}: reset: moving to ORIG_HEAD
37ac942 HEAD@{41 seconds ago}: reset: moving to ORIG_HEAD
59f6d6d HEAD@{42 seconds ago}: reset: moving to HEAD^
37ac942 HEAD@{42 seconds ago}: reset: moving to HEAD^
5be67c5 HEAD@{42 seconds ago}: reset: moving to HEAD^
4376c78 HEAD@{3 minutes ago}: commit (amend): OemConfig: Expand "keys" to 16-bits

I do not have any idea why the 'commit amend' failed, nor why Git-Plus tried to reset to HEAD^ three times (effectively resetting to HEAD^^^).
Maybe this is related to #213.  If so, maybe Git-Plus is running the amend command three times; this would explain why two of them are failing with the reported error, though I don't know what happens to the third.  I do not see three reported "aborted!" error messages.
Also when I close the commit message tab, one of my open file tabs is also closed.  I had about 10 files opened when I ran into this.  After trying to reproduce it several times, I noticed all my files had been closed.  It seems they were closed one at a time as I ran each test.  This is likely a separate issue already reported in #209.  But I mention it here in case it is important.
Some notes on my conditions:
Here's my current log when I tried this (for correlation with my reflog above):
4376c78 - (HEAD)
5be67c5 - (HEAD^^)
37ac942 - (HEAD^^^)
59f6d6d - (HEAD^^^^)
75496f0 - (HEAD^^^^^)

I am on a detached head (no branch label checked out).
I initially had three project folders open (Ctrl+Alt+O).  I thought this might be related to the three resets performed, but I removed two of the project folders and tried it again and the same (three) resets pattern occurred.

Right now the implementation resets to head in order to get the previously staged files to recreate the commit file. A quick fix is to not reset but that means the new commit file won't have those details. I'm going to work on backing up those details and then you can give it a test and tell me how you feel about it

I've pushed a new branch, amend with the hopeful fix. Clone that and replace the git-plus directory in .atom/packages and let me know what you think.


 Think of it as generalization of @lemire's fastrange reduction.
:memo: Checklist

[x] Add and test Bloom filter implementation
[x] Figure out where to placed check for 128-bit support (@dominiklohmann)
[x] Provide frozen implementation
[x] Consider moving adjustment of m into evaluate
[x] Evaluate performance
[ ] Consider switching to byte addressing (raised by @pdillinger)
[ ] Replace with existing Bloom filter in meta index

:dart: Review Instructions
Not yet.

Thanks for chiming in over here, @pdillinger. The overall strategy is as follows:

Replace the current textbook Bloom filter (double hashing) with the basic worm hashing variant. We can re-use our parameter calculation and don't have to change much on the user side. Use this as an example to test-drive the builder pattern for filters, i.e., first mutate until done, then pack into a frozen filter (inside a flatbuffer) so that later memory mapping is trivial.
Add the split block Bloom filter where time/throughput matters.
Use Ribbon filters where space or FP rates matter. Buffer the master digests (builder phase) and then construct the (frozen) ribbon filter in one shot.
Use Taffy filters for mutable data sets with unknown a-priori cardinality.

We plan on using (4) for threat data that the user manages. I'm not 100% sure if we have a use case for (2) where (1) would be too slow or (3) more important. We want to use (3) as sketches for our data partitions that represents the persistent data. We'll probably look at  on the sooner side, because FPs result costly in disk access and Ribbon outperforms all other filters in that regard. (Time is not too critical here because the filters are built and written asynchronously.)

By the way we use byte addressing for Bloom filters in RocksDB so that they are endian-neutral through add, lookup, and (trivial) serialization/de-serialization. At least on Intel hardware, I have not really seen a performance difference between byte addressing vs. word addressing.

By the way we use byte addressing for Bloom filters in RocksDB so that they are endian-neutral through add, lookup, and (trivial) serialization/de-serialization. At least on Intel hardware, I have not really seen a performance difference between byte addressing vs. word addressing.

That's a good idea, @pdillinger.
How have you implemented this? Do you perform conditional byte-swapping on read/write of  bits[upper >> 6]? Or do you unroll the 8-byte read/write?

How have you implemented this? Do you perform conditional byte-swapping on read/write of  bits[upper >> 6]? Or do you unroll the 8-byte read/write?

Use array of char, uint8_t or similar.

@dominiklohmann and I had a chat on how to handle the flatbuffer. We agreed we'll wrap the Bloom filter into a top-level ProbabilisticFilter that supports our usual versioning with the union dispatch. That's why this flatbuffer doesn't support explicit versioning.

@dominiklohmann and I had a chat on how to handle the flatbuffer. We agreed we'll wrap the Bloom filter into a top-level ProbabilisticFilter that supports our usual versioning with the union dispatch. That's why this flatbuffer doesn't support explicit versioning.

Note that it'll still be a breaking change if you change the root_type later, so just be careful not to use this for persisting any data before you made that change.

[sc-29595]


Check in dlrm_trace_of_aggregated_samples.txt

Check in dlrm_trace_of_aggregated_samples.txt generated by running reference DLRM code. This helps the submitters who don't want to set up the environment for reference DLRM but still want to get the trace file for their submissions.
@mnaumovfb Could you check if this makes sense? The first lines match your dist_trace_verification.txt. Thanks!

@DilipSequeira FYI

That's a good point.
@DilipSequeira Where would be a good place to store this? Zenodo?

Zenodo is the right place, assuming the trace is permanent (I'm contrasting that with some things which depend on a seed that is only released a few weeks before submission, e.g. the loadgen query sequence randomizer.)

Please let me know when you store this file in Zenodo, so that I can add a link to it in the README.

@mnaumovfb @DilipSequeira Instead of checking in the trace file in the repo, I have uploaded it to Zenodo and add instructions about how to verify the trace file. Could you review this PR again? Thanks

Looks good to me.


:bug: Fix labels validation print

Fixing fmt.Fprintln to correctly recognize first argument as a writer buffer. Bug was introduced in my PR https://github.com/konveyor/kantra/pull/243
This should fix kantra CI.

I believe the CI uses "previous" kantra image, that was reason it didn't fail on original PR and looks red on this PR.

@aufi I don't think CI uses previous image, we build one in one of the steps unless I am missing something.

I think we need to update the parsing logic to accomodate for weirdness in different shells (thinking about windows too). Can we just match a regex for label value format on every line of output https://github.com/konveyor/analyzer-lsp/blob/82b3f8b673cbfc178259faf6e35846bc0534d409/engine/labels/labels.go#L21

@aufi I don't think CI uses previous image, we build one in one of the steps unless I am missing something.

From what I can see locally, the RUNNER_IMG is not propagated to containers kantra executes
$ RUNNER_IMG=kantra-labels go run main.go  analyze --list-targets --log-level 99 # containers still use quay.io/...kantra

Will look on that to be sure I'm not wrong.

I think we need to update the parsing logic to accomodate for weirdness in different shells (thinking about windows too). Can we just match a regex for label value format on every line of output https://github.com/konveyor/analyzer-lsp/blob/82b3f8b673cbfc178259faf6e35846bc0534d409/engine/labels/labels.go#L21

Sounds good, just question what if a line would have more than one match of the regex? (fail I'd suggest)

@pranavgaikwad I noticed the same issue as @aufi while I was debugging https://github.com/konveyor/kantra/pull/247  where the listLabels command uses the current image at quay.io/konveyor/kantra:latest and not a fresh build of runnerImage. Although I built and set a new runnerImage, I had to override these values locally https://github.com/konveyor/kantra/blob/main/cmd/version.go#L11-L12 for it to finally work.

@eemcmullan looks like this is always setting the default value? https://github.com/konveyor/kantra/blob/52f87d7497ec6ba9fa0a3f105687054a79254bc0/cmd/settings.go#L89-L96

There was a conflict with package-level variables from https://github.com/konveyor/kantra/blob/main/cmd/version.go#L12-L16 partially overlapping Settings fields names. Updated Settings to load env with tags (default) as the first step and adjusting it in custom methods as the second one (and use variables within the Settings struct, not outsite).


Support for using Azure OpenAI as the llm for Agents

We have an instance of Azure OpenAI but when using that as the llm, I see generation assert error. But,
llm([message]) works
Is there any sort of workaround to get  Azure OpenAI to work ?
Attaching the screenshot of my crew.py

Here is my AzureOpenAI.py

In Docs I could see that
from langchain.chat_models.openai import ChatOpenAI

is used.
Relevant Class for my case is
from langchain_openai import AzureChatOpenAI

Any suggestions on this @joaomdmoura  ?

Referred https://joaomdmoura.github.io/crewAI/how-to/LLM-Connections/#azure-open-ai
Got the the llm object that responds to the humanMessage but when I use with agents, I am getting this error.
/lib/python3.10/site-packages/langchain_core/language_models/chat_models.py", line 242, in stream
    assert generation is not None
AssertionError

I am also dealing with the Azure Chat OpenAI issue for a company project.
Let me see if I can help.
Please simplify your code to the bare minimum and make sure that calling OpenAI directly works properly with the entire CrewAI crew.

hi, according to https://api.python.langchain.com/en/latest/agents/langchain.agents.agent.RunnableAgent.html, runnableAgent has a stream_runnable option.
it is possible to not use stream modifying crewai/agent.py on line 280
from
        self.agent_executor = CrewAgentExecutor(
            agent=RunnableAgent(runnable=inner_agent, stream_runnable=False), **executor_args
        )

to
        self.agent_executor = CrewAgentExecutor(
            agent=RunnableAgent(runnable=inner_agent, stream_runnable=False), **executor_args
        )

allows to run crewAi with a custom LLM without " assert generation is not None" error

I have also come across this issue when trying to use an Azure LLM instance that cannot stream as it sits behind an application gateway, looking forward to a resolution. @ppk5 I assume from your message above the fix will rely on an upstream langchain fix to be in place first, thank you for being proactive and raising the issue with them. If anyone has figured out a workaround meanwhile to get CrewAi working in this situation please let us know :)

Still hitting this issue as of the end of May 2024.


@Ingerdev thank you for the pr, but tests are failing, can you please fix them? Keep in mind that we are on .netstandard2.0

Weird. As far as i see .netstandart 2.0 havent span-based overloads for Encoding.UTF8.GetBytes
so this is problem similar to https://stackoverflow.com/questions/54255888/can-i-get-a-pointer-to-a-span
If you allow working with unsafe code, may be we can implement something like this.

I'm ok with unsafe code here. Also as I know there's a nuget package for span support, it might help

Method
Length
Mean
Error
StdDev

Mummur3Heap
1
180.4 ms
3.39 ms
3.63 ms

Mummur3Stack
1
168.3 ms
3.36 ms
3.73 ms

Mummur3StackFixed
1
173.2 ms
3.35 ms
3.72 ms

Mummur3Heap
10
196.3 ms
3.82 ms
4.09 ms

Mummur3Stack
10
183.4 ms
1.69 ms
1.41 ms

Mummur3StackFixed
10
185.0 ms
2.97 ms
2.63 ms

Mummur3Heap
100
309.5 ms
6.07 ms
10.30 ms

Mummur3Stack
100
266.3 ms
5.27 ms
10.03 ms

Mummur3StackFixed
100
262.6 ms
4.91 ms
4.82 ms

Mummur3Heap
500
711.2 ms
13.80 ms
13.55 ms

Mummur3Stack
500
570.3 ms
11.27 ms
10.54 ms

Mummur3StackFixed
500
578.8 ms
8.86 ms
8.28 ms

Mummur3Heap
1000
1,221.1 ms
20.52 ms
19.19 ms

Mummur3Stack
1000
975.1 ms
5.94 ms
5.27 ms

Mummur3StackFixed
1000
987.4 ms
12.00 ms
11.22 ms

Span nuget cannot help as it contain only span classes. We need span-based method calls (methods with spans as parameters.)

Thank you, last request - can you please remove Stream version, since it's unused now, and squash all commits into one?

Are you sure input string wont be longer than MaximumStackAllocSize = 32 * 1024 = 32kb?
If so, ill remove stream-based version.

Sorry, forgot about it, then just squash

@Ingerdev do you need a help with squash? You need to make 1 commit out our 5, to accomplish it you need to either use another branch our you can delete your remote develop branch, and push all changes with one commit.

Erm... I did squash on my existing remote repo and pushed it as last commit.  If it is not what you expected i will do as you say :)

Could you please do what I suggested? The desired outcome is 1 commit shown in Commits tab of this PR

I completelly messed up (never did it before). Yet another squash cannot be done, rebase doesnt help as changes already on the remote.. Seems i need your help.

Ok, so

Delete your develop branch in github (not locally)
Follow those comments https://stackoverflow.com/questions/14534397/squash-all-my-commits-into-one-for-github-pull-request
Push your develop branch again
Otherwise I can squash during merge myself, but this will loose your authority of the PR

Develop branch on github cannot be deleted :
git push origin --delete develop
! [remote rejected] develop (refusing to delete the current branch: refs/heads/develop)
error: failed to push some refs to 'git@github.com:Ingerdev/pulsar-client-dotnet.git'

Ok, another option to try is to perform the 2nd step (without branch deleting) and then force push to develop, this will overwrite previous commits


Question: Is the API required to return items in the same order as requested?

Since the v3 update, we've had an intermittent problem with reporting true vulnerabilities against the wrong library. The problem seems to manifest itself in the loop here where the array of pkgs sent to the server is assumed to be in the same order as the data returned. I've run it with some debug and it looks like the arrays aren't always in sync. For example, this is what's sent to the server:
[ index | DATA ]
[ 0 |<EMAIL_ADDRESS>]
[ 1 |<EMAIL_ADDRESS>]
[ 2 |<EMAIL_ADDRESS>]
[ 3 |<EMAIL_ADDRESS>]
...
[ 115 |<EMAIL_ADDRESS>]
[ 116 |<EMAIL_ADDRESS>]
[ 117 |<EMAIL_ADDRESS>]
[ 118 |<EMAIL_ADDRESS>]
[ 119 |<EMAIL_ADDRESS>]

And this is what we have when we run through the aforementioned loop after data is returned:
[ index | pkgs | data ]
[ 0 | node.flow |<EMAIL_ADDRESS>]
[ 1 | node.extend |<EMAIL_ADDRESS>]
[ 2 | is |<EMAIL_ADDRESS>]
[ 3 | object-keys |<EMAIL_ADDRESS>]
...
[ 115 | lodash |<EMAIL_ADDRESS>]
[ 116 | types |<EMAIL_ADDRESS>]
[ 117 | helper-function-name |<EMAIL_ADDRESS>]
[ 118 | helper-get-function-arity |<EMAIL_ADDRESS>]
[ 119 | template |<EMAIL_ADDRESS>]

To me it looks like some of the data is in order, but other items are returned out of order, which breaks the assumption of paired arrays. We can do a map on the receiving end rather than paired arrays, which should get rid of the mismatch -- but is the remote end supposed to be returning in order?

Thanks @ken-duck !

Thanks so much for the quick turnaround!


Dependent useQueries creates too many updates (exceeds maximum update depth)

Describe the bug
When using react-query together with React and the useQueries hook in a dependent manner like described in the docs I get constant rerenders when setting a state with an object inside useEffect with the useQueries result as dependency.
const [onboardingData, setOnboardingData] = useState<Onboarding | null>(null);
const [testState, setTestState] = useState<{ test: string } | null>(null);
const [testState2, setTestState2] = useState(false);

const { data } = useQuery({
  queryKey: ["gitlab", "123456/nonprod-tenant", "data"],
  queryFn: (): Promise<{ files: string[] }> => {
    return new Promise(resolve => {
      resolve({
        files: ["data.pdf"],
      });
    });
  },
});

const uploadedFilesQueries = useQueries({
  queries:
    data?.files.map(file => {
      return {
        queryKey: ["gitlab", "tmp", "files", file],
        queryFn: () => {
          return new Promise(resolve => {
            resolve({ test: true, data: Math.random() });
          });
        },
      };
    }) ?? [],
});

useEffect(() => {
  console.log("SET", uploadedFilesQueries);
  // Creates constantly retrigger of this very hook the the corresponding useEffect to display
  setOnboardingData({} as any);

  // This works
  setTestState(s => {
    return s;
  });

  // This works
  setTestState2(true);
}, [uploadedFilesQueries]);

useEffect(() => {
  console.log("data", onboardingData);
}, [onboardingData]);

useEffect(() => {
  console.log("testState", testState);
}, [testState]);

useEffect(() => {
  console.log("testState2", testState2);
  setTestState({} as any);
}, [testState2]);

Your minimal, reproducible example
https://codesandbox.io/p/sandbox/react-query-issue-v7k28v
Steps to reproduce
Open the console in the code sandbox and watch how the console is spammed & errors pop up
Expected behavior
I expected not to create so much renaders but to set the state and the only rerender when the useQueries is refetched
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform

Browser: Chrome, Safari
Platform: MacOS, CodeSandbox

Tanstack Query adapter
react-query
TanStack Query version
5.29.0
TypeScript version
4.9.5
Additional context
No response

the result returned from useQueries is not referentially stable, but data inside it is.
This is documented here: https://tanstack.com/query/v5/docs/framework/react/guides/render-optimizations#referential-identity
you don't need a useEffect to set state depending on a result of a query, you can derive that state. You can also use the combine function on useQueries in v5.

Alright. Thank you didn't found it in the docs. But maybe also was not reading deep enough. Makes sense now.


Fix issue 17157 ctRegex.matchAll doesn't set last item in Captures

Backtracking engine reused stale data in matches from the previous run.

Auto-merge toggled on

@DmitryOlshansky Try git force pushing to restart the doc builder

@DmitryOlshansky Try git force pushing to restart the doc builder

Tried that to no avail. I think it's broken on stable so what's next? cc @MartinNowak

Auto-merge toggled off

@DmitryOlshansky this is the same problem with all PRs on stable.
@CyberShadow added a dlang.org workaround for a DMD bug in master, but stable is still broken. The only people who can merge this are @MartinNowak @andralex and Walter.

Fix for stable: https://github.com/dlang/dlang.org/pull/1604

Failing CircleCI tests were fixed on master by https://github.com/dlang/phobos/commit/48a17920952d0c8d80744c41898c9ad5fe451be3


package.json module field points to uncompiled source

v2.3.1 introduced the env-preset for babel breaking our builds because we do not include it. I found the issue https://github.com/andreypopp/autobind-decorator/issues/75 but was unable to comment so I'm creating a new one. I have read over https://babeljs.io/blog/2018/06/26/on-consuming-and-publishing-es2015+-packages which you are giving as the reason for why it points to uncompiled source. However, in the article it states
"We should continue to publish ES5/CJS under main for backwards compatibility with current tooling but also publish a version compiled down to latest syntax (no experimental proposals) under a new key we can standardize on like main-es. (I don't believe module should be that key since it was intended only for JS Modules)"
Which indicates that module is not the correct place to do this due to backwards compatibility. We use modules before main in our webpack to get the benefits of import statement treeshaking but still require the rest to be es15 compatible.
Is it possible to have the module point to an es5 compatible version with imports instead of requires as is intended for the module field?

We kept main in package.json. The main entry still points to the original build.
Sent from my iPhone

On 20 Nov 2018, at 3:11 am, lroling8350<EMAIL_ADDRESS>wrote:
v2.3.1 introduced the env-preset for babel breaking our builds because we do not include it. I found the issue #75 but was unable to comment so I'm creating a new one. I have read over https://babeljs.io/blog/2018/06/26/on-consuming-and-publishing-es2015+-packages which you are giving as the reason for why it points to uncompiled source. However, in the article it states
"We should continue to publish ES5/CJS under main for backwards compatibility with current tooling but also publish a version compiled down to latest syntax (no experimental proposals) under a new key we can standardize on like main-es. (I don't believe module should be that key since it was intended only for JS Modules)"
Which indicates that module is not the correct place to do this due to backwards compatibility. We use modules before main in our webpack to get the benefits of import statement treeshaking but still require the rest to be es15 compatible.
Is it possible to have the module point to an es5 compatible version with imports instead of requires as is intended for the module field?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Which field should be used for standard modern JavaScript?
Sent from my iPhone

On 20 Nov 2018, at 3:11 am, lroling8350<EMAIL_ADDRESS>wrote:
v2.3.1 introduced the env-preset for babel breaking our builds because we do not include it. I found the issue #75 but was unable to comment so I'm creating a new one. I have read over https://babeljs.io/blog/2018/06/26/on-consuming-and-publishing-es2015+-packages which you are giving as the reason for why it points to uncompiled source. However, in the article it states
"We should continue to publish ES5/CJS under main for backwards compatibility with current tooling but also publish a version compiled down to latest syntax (no experimental proposals) under a new key we can standardize on like main-es. (I don't believe module should be that key since it was intended only for JS Modules)"
Which indicates that module is not the correct place to do this due to backwards compatibility. We use modules before main in our webpack to get the benefits of import statement treeshaking but still require the rest to be es15 compatible.
Is it possible to have the module point to an es5 compatible version with imports instead of requires as is intended for the module field?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hey,
I'm +1ing this issue.
We encountered almost the same problem. The solution of using "main" is working, but it creates others issues with others dependencies.
So, I don't really know if this is possible, but I'm asking the same question as the author of this issue : "module" pointing to the actual "main" would solve my problem.

I'm unsure what should be used for modern java script as i don't think there has been a convention created yet. The article provided by babel alludes to this. It does state that module was chosen by both webpack and rollup as a convention to provide javascript with es6 imports but still compiled to es5 syntax and to maintain backwards compatibility should likely not be used. We got this dependency intrinsically from react-dnd-html-backend but discovered moving a major version removed the dependency. We were able to upgrade react-dnd and this is no longer an issue for me personally but it seems others are running into it as well.
To give some context. I help manage some core libraries, one of which was including this dependency via react-dnd so all our projects started breaking. Many teams who leverage our libraries are not very strong in babel and webpack (use some precanned templates) so this became a quick blocker. Since it was an intrinsic dependency it was going to be hard to explain to the all the teams why it was broken. We also use the module property ahead of main in our webpack builds to get the benefits of better treeshaking. So when you say we should just use main it means we would need to give up using module all together or for us to disseminate to all the teams how and why to add excludes for this library.
For a while we were providing non-compiled source as a solution, We solved the problem by having people just access source directly like so
import { myFunc } from 'my-library/src'

It is a bit ugly but did the trick and it was clear we were grabbing source directly. Ideally a better convention will come about at some point.

Faced with the same problem, because one of my solution's dependency use this package.
Possible solution: such significant changes (as broken es5 support) should be done under major version of package. This prevents issues after running "npm install" without package-lock.json file.

@vladivanovrf https://github.com/andreypopp/autobind-decorator#es5-and-uglify-users

I don't think anyone is arguing with you about compiling node_modules. I just don't think the module field was the right field to do it. The babel post you refer to suggests NOT using the module field so it doesn't break people.

I have changed the module field to ES5 + es modules and added es field for modern JS. We really need some convention for modern JS 😞


Mod is broken

So the Tardis doesn't work. You can add rooms, enter it, put stuff in the engines, but nothing on the console works, I can't dematerialize, I can't warp to other biomes or coordinates with it, nothing travel wise, am I missing something?

I am just guessing, but did you activate the fueling before trying to take of?
Best regards


"composer install --dev barryvdh/laravel-ide-helper" not pulling current version.

I'm trying to get the recent fix related to #774. I can see the changes in Github:
https://github.com/barryvdh/laravel-ide-helper/blob/881f77156c37deea425caef6482783717c466e4f/src/Console/ModelsCommand.php#L483
But they are not in my local package. I deleted my vendor folder and purged the composer cache to re-install, but that did not solve the problem.
On my end the line still reads:
if (stripos($code, $search) || stripos($impl, $type) !== false) {

And I'm still getting the following error:
Exception: stripos(): Non-string needles will be interpreted as strings in the future. Use an explicit chr() call to preserve the current behavior
Could not analyze class App\Models\User.

Any thoughts on why this is happening?

@RalphMRivera: @barryvdh needs to tag a new release. In the meanwhile, you can use the dev-master to get the new version. Change your composer.json file to this:
"barryvdh/laravel-ide-helper": "dev-master"
And composer update to fix the issue

it's tagged.

Thanks so much!


[Feature Request] Publish details on ZAP tests

Hi,
Came across your repo looking for OWASP ZAP testing as part of a CI pipeline,
it looks like you have integrated ZAP in your CI, is there any chance you can publish orchestration scripts and/or any other information/config you can on this?
Thanks

Hi,
We have written java based tests (currently private) which use the org.zaproxy.clientapi.core java libraries to run some zap based tests.
The tests exclude urls to not scan and also a list of alerts to ignore.  These are then run by CI.
Hope that helps a bit.
Will

Hi,
We have discontinued our use of Jenkins and are archiving the repository.
Regards,
Jonathan


[Mac OS] UnicodeEncodeError

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like that [x])
Use Preview tab to see how your issue will actually look like

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2017.06.23. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.

[x] I've verified and I assure that I'm running youtube-dl 2017.06.23

Before submitting an issue make sure you have:

[x] At least skimmed through README and most notably FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue

If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:
Add -v flag to your command line you run youtube-dl with, copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):
$ youtube-dl
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/usr/local/bin/youtube-dl/__main__.py", line 19, in <module>
  File "/usr/local/bin/youtube-dl/youtube_dl/__init__.py", line 465, in main
  File "/usr/local/bin/youtube-dl/youtube_dl/__init__.py", line 58, in _real_main
  File "/usr/local/bin/youtube-dl/youtube_dl/options.py", line 899, in parseOpts
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1402, in parse_args
    self.error(str(err))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2014' in position 17: ordinal not in range(128)
...
<end of log>

So I get this error no matter what command I give to youtube-dl. Even just typing 'youtube-dl' into terminal gives back the same error. Really not sure what to do at this point. Any help or redirection would be appreciated.
Thanks :)

Do not use em dash (—) in option switches.


Data type for Images

Hi,
Data reduction becomes a daily routine for me from to time to time and I wanted to explore julia a bit. Since this is a new project, I thought I would contribute.
So, I started developing a CCDImage data type here:
https://github.com/pssncp142/CCDReduction.jl/tree/devel_CCDImage
Note that I learnt Julia last week so my code is not very clean. It will require many revisions.
This, in a basic level, describes what it can/should do:
https://gist.github.com/pssncp142/a60e97872ac761d3a4456c0aeb9b73f6
The question is, would you be interested in such a data type? It would allow propagation and storage of uncertainties and bad pixels, and can be stored in your image "Collection". I will work on this regardless since it helps me explore arrays and types functionality in julia. But, if you are interested, I am happy to discuss your opinions and revise the design to integrate into your project.

Based on the notebook it seems relatively close to my vision for the "CCDData" type! Although I do not plan on making a custom type for pixels, since I think we can do fine using existing numeric types with Unitful.jl and Measurements.jl.
Currently I'm working with @siddharthlal25 through Google Summer of Code (GSoC) on this package, so we have plans for implementing this later! Your implementation is a good show of using the abstract array interface and is definitely inspirational for our usage.
If you're interested in contributing, I would recommend looking around JuliaAstro for help wanted issues, I (we) have plenty of issues that we'd love a hand with that will also sharpen your Julia skills!


[23.05] mutt: 2.2.10 -> 2.2.12

Description of changes
Flagged as security related, mutt 2.2.12 includes a fix for a crash on header parsing.
http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20230814/000055.html
http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20230904/000056.html
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Thank you!


change main in package.json (a compromise?)

https://github.com/bendrucker/creditcards
This works fine in JSPM because here you have "main": "index.js",
and in your /index.js you export
'use strict'

exports.card = require('./src/card')
exports.cvc = require('./src/cvc')
exports.expiration = require('./src/expiration')

If you do the same for this repo. I won't need to use a fork, your 2 projects will be consistent (after all isn't that your argument?).
If you do this JSPM will be happy, browserify will be happy, and your 2 projects will be similar in that respect.

your 2 projects will be consistent

It's not about 2, it's about a workflow that works everywhere: https://www.npmjs.com/~bendrucker
Per #54, I'll take a PR. I can't promise permanent compatibility because I write code that's compatible with Node/Browserify. That said, I'm not active working on angular-cc so it should be fine.

@bendrucker  see
https://github.com/robertbaker/angular-credit-cards/tree/jspm_fix