Add some demo attacks (CPA2 and CCA2)

Here are some attacks to recover secret information about the key, recover secret messages, and forge encrypted messages.
This doesn't mean the algorithm is dead, it just means the algorithm is not CPA/CCA secure.  This is a stream cipher (kinda-sorta) so it's not a big surprise that message recovery and forgery are possible.  These attacks work against some advanced stream ciphers, too.
The more unsettling attacks are the ones that reveal key information.  In this case, I was able to reveal the key jumps and key length, without looking at the key.  It doesn't reveal the whole key, but it's an important first step.  The next step to key recovery might be coding the algorithm in a constraint solver, to see if it can narrow down the search space for the key body.  You would need to know the jumps and key length (for modulo) to define the constraints in the solver.
Note: these attacks all work with random data.  They don't use any property of the plain text, like it being ascii or compressed.  The attacks are equally effective for all types of data.
Chosen Plaintext Attack (CPA)
Chosen Ciphertext Attack (CCA)
May I also recommend:
Cryptography I - Stanford Online

Sorry,
I don't know anything about Python language.
I  am not sure if I could understand your code properly.
But, I haven't seen a code which reveals any information.
Can you explain me better what that code does?

I never use nor recommend using the algorithm without Hohha Communication packet format.
Hohha Communication packet format has its own integrity check values.
Once a corrupted packet received, the server aborts the communication with the client.
It's not possible to use the server as oracle.
Are those attacks still valid in those circumstances?

Can you explain me better what that code does?

Yes.  I'll go write some nice long comments in the code explaining the theory of the attack, and what exactly the code does.
Python is a useful language to know.  I recommend learning the basics of it.  Lots of example code online is actually valid python code.
This attack code would look pretty much the same in c, with semicolons, and array length instead of array slice notation.  The boilerplate to run the oracle would be different (~10 times longer in c), but that's not important for understanding the attack.

Hohha Communication packet format has its own integrity check values. Once a corrupted packet received, the server aborts the communication with the client. It's not possible to use the server as oracle. Are those attacks still valid in those circumstances?

Yes, the attacks are still possible.  For the two recovery attacks, it will take on average 128 attempts, at worst 256, to determine a valid crc for the target output.  After the target crc is known, the rest of the attack only requires one attempt per step.  If an attempt fails the hohha crc check, the error result is just as useful as a result that doesn't match the target.  When the result matches the target, the crc check will pass.  For the message forgery attack, on average 128 guesses, at worst 256, may be needed for each character.
Actually, all of the attacks would be possible, knowing only if the message is valid.  The attacker wouldn't need to actually observe the result of the encryption, just whether or not the server disconnects.  In the attacks against the packet format, I will just have the oracle (simulating the server) return an error if the message is invalid (simulating disconnect), no error if the message is valid, and nothing about the result of decryption.  Error or no error will be the only signal available to the attack.
I will add hohha packet format support to the harness, and write attacks against the packet format.

It's very bad that I can't undestand Python or you haven't coded in C.
I of course want to learn Python but I really have no time for that at the
moment.
Are you sure about the numbers you're giving?
In packet format, the header is also encrypted.
And CRC value is 32 bits.
I still can't understand how you can guess CRC in 128 or 256 attempts.
I even don't mention about the padding yet.
On Thu, Jan 28, 2016 at 4:06 PM, ed770878<EMAIL_ADDRESS>wrote:

Can you explain me better what that code does?
Yes. I'll go write some nice long comments in the code explaining the
theory of the attack, and what exactly the code does.
Python is a useful language to know. I recommend learning the basics of
it. Lots of example code online is actually valid python code.
This attack code would look pretty much the same in c, with semicolons,
and array length instead of array slice notation. The boilerplate to run
the oracle would be different (~10 times longer in c), but that's not
important for understanding the attack.
Hohha Communication packet format has its own integrity check values. Once
a corrupted packet received, the server aborts the communication with the
client. It's not possible to use the server as oracle. Are those attacks
still valid in those circumstances?
Yes, the attacks are still possible. For the two recovery attacks, it will
take on average 128 attempts, at worst 256, to determine a valid crc for
the target output. After the target crc is known, the rest of the attack
only requires one attempt per step. If an attempt fails the hohha crc
check, the error result is just as useful as a result that doesn't match
the target. When the result matches the target, the crc check will pass.
For the message forgery attack, on average 128 guesses, at worst 256, may
be needed for each character.
Actually, all of the attacks would be possible, knowing only if the
message is valid. The attacker wouldn't need to actually observe the result
of the encryption, just whether or not the server disconnects. In the
attacks against the packet format, I will just have the oracle (simulating
the server) return an error if the message is invalid (simulating
disconnect), no error if the message is valid, and nothing about the result
of decryption. Error or no error will be the only signal available to the
attack.
I will add hohha packet format support to the harness, and write attacks
against the packet format.
—
Reply to this email directly or view it on GitHub
https://github.com/ikizir/HohhaDynamicXOR/pull/13#issuecomment-176199219
.

In packet format, the header is also encrypted.

I think you will find this to be impossible.  In order to decrypt the message, you would need to know the salt.  If the salt is encrypted (because the header is encrypted), how will you know the what salt to use to decrypt the packet?
If the crc is encrypted as well, and the whole packet is integrity checked with crc, how do you know what crc to put in the packet, before computing the crc of the whole packet?

I still can't understand how you can guess CRC in 128 or 256 attempts.

Because I'm not guessing the crc.  I'm guessing the character that gives that crc.  I simply compute the crc of the one character target plaintext, and then try 256 possible ciphertexts that might decode to that plaintext.  If I guess the right ciphertext character, it will decode to the target plaintext, and the crc will be valid.

I even don't mention about the padding yet.

It is actually very simple.  Remember, the attack does not need to know anything about the message.  It is just as effective against text, compressed, random data, and even the padding.    I'll provide the crc value 0xad7d53ae (crc32 of the single byte zero, or other crc32 of the byte of my choice), and try 256 possible ciphertexts that might represent the fake message.  I will repeat this process for each byte of the message (always with a padding align 1, and increasing message length).  When I have recovered all of the encrypted data, I can just change the padding align to match the message.
If messages of length zero are rejected, I'll send a message of length one instead, and try 64K of possible messages to crack the first two bytes at the same time.
I can imagine your next idea might be to reject connections after N attempts.  I will distribute the attack across thousands of machines.  If the server were to reject connections from everyone after N attempts, it would be trivial to implement a denial of service attack against the server.  It is very hard to defend against distributed attacks, and provide service.  The service pretty much has to respond to all the requests, no matter what, because some of the requests might be from valid clients, and you still should serve those clients.  This is what makes distributed attacks so frustratingly effective.

I think you will find this to be impossible. In order to decrypt the message, you would need to know the >salt. If the salt is encrypted (because the header is encrypted), how will you know the what salt to use >to decrypt the packet?

There are 2 salts:

Key has an original salt value in the key.
Every encrypted packet has its own salt value in the header. The key's original salt value is solely used  for encrypting packet headers.

It is actually very simple. Remember, the attack does not need to know anything about the message. It >is just as effective against text, compressed, random data, and even the padding.  I'll provide the crc value >0xad7d53ae (crc32 of the single byte zero, or other crc32 of the byte of my choice), and try 256 >possible ciphertexts that might represent the fake message. I will repeat this process for each byte of >the message (always with a padding align 1, and increasing message length). When I have recovered >all of the encrypted data, I can just change the padding align to match the message.

Padding can only be 8,16,32 or bytes.
There is no packet of 1 byte.
I am talking about this: You minimum length of the text you must guess its CRC is 16 bytes.
With your previous answer, I clearly understood that you still don't know how the algorithm works.
You make false assumptions.

The key's original salt value is solely used for encrypting packet headers.

This is bad.  Oh, how this is bad!  The same key AND salt are used to encrypt multiple packet headers.  Stream ciphers fail so spectacularly this way.  This offers no protection for he header.
Stream Cipher Attack

you still don't know how the algorithm works

And yet, I've rewritten it, refactored it even, in a completely different programming language.  I have offered some demonstrations of how it is vulnerable, even.
Look.  The cryptographic theory always makes assumptions about what the attacker can and can not do.  What those assumptions are is stated in the attack models.  Sure, you can change the assumptions, but then you are asking for a different kind of attack.  I have shown you that some attacks work assuming the attacker can do some things.  If the attacker can not do those things, sure, the attack won't be effective, but if the attacker can do those things, the attack is effective.

This is bad. Oh, how this is bad! The same key AND salt are used to encrypt multiple packet headers. >Stream ciphers fail so spectacularly this way. This offers no protection for he header.

I think, you are still making false assumptions.
You don't take into account the random nature of the data encrypted. CRC and random salt values every time.
And you don't take into account that the key itself dynamically updated according to plaintext.
Try to demonstrate those attacks with you, as you told me. Then, let's continue our discussion.

Look. The cryptographic theory always makes assumptions about what the attacker can and can not >do. What those assumptions are is stated in the attack models. Sure, you can change the >assumptions, but then you are asking for a different kind of attack. I have shown you that some >attacks work assuming the attacker can do some things. If the attacker can not do those things, sure, >the attack won't be effective, but if the attacker can do those things, the attack is effective.

I know. You are right,  And I accepted when you told me the first time.
Every "base" encryption algorithm is vulnarable for some kind of attacks.
That's why, we're using padding schemes.
Without padding, most of encryption algorithms are useless, including RSA.
Even, with padding, RSA with PKCS1 is not used anymore. They recommend using OAEP.
I am also trying to learn from you. I just asked how you can attack to hohha packets.
And, if I cut the connection and force the client to change the key(That's really what I'm actually doing); you can't use the server as an oracle. You will only have 1 (or let's say 100 if you want) chances before the key expiration.
As you told, append packet attack code to harness test.
Then, let's talk again.

And yet, I've rewritten it, refactored it even, in a completely different programming language. I have >offered some demonstrations of how it is vulnerable, even.

That's why I am surprised when you told me that's impossible to encrypt the header when I told you the header is also encrypted. These are you words:

I think you will find this to be impossible. In order to decrypt the message, you would need to know the >salt. If the salt is encrypted (because the header is encrypted), how will you know the what salt to use >to decrypt the packet?

You refactored the code in another language and yet you don't know the header is encrypted! Let me tell you that's interesting!
Again, I will wait for your new harness code.
And, we're not here to demonstrate defense scenarios against distributed attacks. Theoretically, noone is secure against distributed denial of service attacks. Like Archimedis, everyone can move the earth with proper tool.

You refactored the code in another language and yet you don't know the header is encrypted! Let me tell you that's interesting!

I didn't refactor the packet code, so what's your point?  I did rewrite the cipher code, I know how it works, and that's what I've shown is vulnerable.
So, you know what?  Here is my response: I know how your cipher algorithm works, better than you do.  Prove me wrong.  Tell me how and why my attacks against your algorithm work.  If you know how your algorithms works better than I do, this should be no challenge for you at all.  You don't even have to look at the python code, because you know!

Explain the attacks against message forgery and message recovery.

This is the easy one.  You can just copy-paste the answer from wikipedia.

Explain the attack that reveals the number of key jumps.
Explain the attack that reveals the key length.

I think, you are still making false assumptions.  You don't take into account the random nature of the data encrypted in header.

Again, it does not matter that the header has random data, because random data is just as vulnerable as anything else.  The header is encrypted with the same key and the same salt every time.  This raises a big red flag that the scheme is very likely to be vulnerable.  It's up to you to prove otherwise.
You need to prove that COA, or better yet KPA are impossible when the same key and salt are used to encrypt the header.  I already know that KPA with only one known plaintext will reveal the first byte of any other header.  I haven't ruled out that KPA might reveal the entire header, or that COA might reveal anything.
If you know your algorithm better than me, prove it.  Explain the KPA attack that reveals one byte.  This should be easy, just like (1.) above.
My proofs that the algorithm is vulnerable are easy.  I can prove vulnerability by example, by demonstrating an attack.  A demonstrated attack is impossible to refute.  Your proofs of invulnerability have to be much more rigorous.  You have to prove that an attack is impossible, not just that it hasn't been broken yet.

Thank you for your contributions.
If you have other attack samples, I will add them with pleasure.
If you or someone else proves or demonstrates with working code, a  serious attack against packet format, I will either try to develop the algorithm or cancel it.
Until that day, I will keep using this algorithm.

@ikizir I was really interested in this project, but your unwillingness to even consider any problem or concern with your algorithm makes me wonder why you even put it on GitHub.

Without padding, most of encryption algorithms are useless, including RSA. Even, with padding, RSA with PKCS1 is not used anymore. They recommend using OAEP.

RSA is a public key cryptosystem.  It can't really be compared to a symmetric cipher like Hohha.  One thing RSA on its own doesn't do very well: large payloads.  RSA is generally only used in combination with other algorithms like symmetric ciphers or cryptographic hash functions.  Data can be encrypted by some symmetric cipher, and then the secret key encrypted by RSA.  Data can be hashed, and the hash value signed by RSA.
PKCS1/OEAP are recommendations about how to use RSA.  They don't change the RSA algorithm.  They describe operations on plaintext, prior to encryption with RSA (or with other PK cryptosystems like RSA).  They are used, for example, to prevent an observer from seeing that two messages are the same.  Furthermore, OEAP makes it impossible to recover any of the plaintext without recovering all of it.  PKCS1/OEAP, like RSA, operate on small payloads.  They aren't applicable to stream ciphers, so they really have nothing to do with Hohha.
For stream ciphers, the Initialization Vector (IV, or salt, as we have been calling it for Hohha), is supposed to make two of the same message indistinguishable, and protect against a stream cipher attack.  IV doesn't provide an all-or-nothing guarantee like OEAP.  The all-or-nothing guarantee would not practical for a large payload.  It could be used for denial of service, because an attacker could send a very large invalid ciphertext, and the server will have no choice but to process all of it, consuming gobs of memory and cpu resources, because it won't know if the message is valid until the very end.
All of this about padding, encrypting the header, verifying the crc, etc, has to do with the packet, not the cipher.  The packet format is like what PKCS1/OEAP are for RSA, it is a "recommendation for how to use" the Hohha cipher.  The packet format is used with the Hohha cipher, but it is not the Hohha cipher.  The recommendation should be, use it this way, otherwise the cipher is vulnerable.  Not the cipher is invulnerable because of the packet format, duh!
The cipher is vulnerable to at least CCA/CPA.
The packet format might mitigate CCA/CPA (no guarantee), but it is vulnerable to at least KPA.
I am eagerly waiting to read your explanation of my attacks.

(attack the cipher) message forgery and message recovery
(attack the cipher) recover the number of jumps
(attack the cipher) recover the key length
(attack the packet format) knowing the plain text of one header, recover one byte of every other encrypted header.

Again:
And again,
And again:
At first, I thought that you are a "typical crypto wannabee" who looks at the "jargon" and apply ready remedies!
You think:
"Oh! This is a stream cipher! What are the attack types against stream cipher?"
"Yess! They told me on Crypto 101 there is a typical attack:
https://en.wikipedia.org/wiki/Stream_cipher_attack
I'll write it to that ignorant!
He doesn't know our jargon!
And other people here, who doesn't understand about what happens, will think I'm cool!"
But I clearly understand that you're not!
And you willingly do this to mislead the people! And this is the 3rd time you're doing it:
https://en.wikipedia.org/wiki/Stream_cipher_attack
will not work on Hohha headers because:
Hohha algorithm is not a "simple xor" algorithm. It dynamically changes the key during encryption and make jumps according the input and output. Which means, unless "the same salt" and "the same plaintext" is used for encryption(which is nearly impossible); no header will produce the same encrypted header. And you can't use those values to obtain any meaningful attack information.
Read carefully(from Wikipedia):

In other words, if anyone intercepts two messages encrypted with the same key, they can recover A >xor B, which is a form of running key cipher. Even if neither message is known, as long as both >messages are in a natural language, such a cipher can often be broken by paper-and-pencil >methods. During World War II, British cryptanalyst John Tiltman accomplished this with the Lorenz >cipher (dubbed "Tunny"). With an average personal computer, such ciphers can usually be broken in >a matter of minutes. If one message is known, the solution is trivial.

What will you obtain from the "differences" of random numbers?
And again, those numbers are not simply "xor"able; they are results of a much more complex operations with more variables involved.
You ARE TRYING TO MISLEAD THE PEOPLE!
AND THIS IS NOT THE FIRST TIME!

And about the question: Why did I put the algorithm to public domain?
I've tried to explain it on Wiki. But, I think, I must explain you again what I'm trying to do here.
As I explained in Wiki, I am not a cypto expert, nor, I want to become a crypto expert.
I created this algorithm, because, until today, nearly all standardized algorithms has been broken.
There wasn't "any" secure algorithm,  in SSL 3.0!
There were too slow in TLS 1.2.
Google thinks the same: That's why they had to choose to use ChaCha20 for encryption.
Shortly after, TLS included ChaCha20 in their drafts.
In my application, user's private chat data is encrypted twice: Optionally, it may encrypted with 4096 RSA and then encrypted with Hohha encyrption. Or, after hohha key exchange with RSA encryption, their prv. messages can be encrypted with Hohha + Hohha.  So, user has a choice.
Trying to use a new algorithm doesn't put my users privacy in danger, even if it's proven as broken. I give my users a choice.
I am enjoying this. In my projects, I like to use at least 1 "non standart" encryption. This is my choice.
I put what I could to in public domain and I left the rest to other developers imaginations.
Anyone can fork, develop, can prove what is wrong, can give new ideas.
It is a toy for developers.
Everybody is responsible of himself or herself.
I will use Hohha as my default encryption.
If someone proves a serious vulnarability, I will try to fix it or use another encryption.

I must repeat that, you're making a very dangerous thing: You are misleading people with some false information but you also feed them with also some true information.
I must clarify the minds of readers who can't follow the conversations:
So far, I detected 2 true assumptions amongst what @ed770878  wrote:

The algorithm is vulnerable when used wihout Hohha Packet header. I already knew it. That's why I've developed Hohha Comm pack format. In fact, the packet format is by design of the algorithm. I designed everything from scratch for that packet format. That's why, the key contains, "one original salt" which is solely used to encrypt the packet headers. I know, this is not "on the book". But, I don't care about the jargon. I must produce working solutions and I must produce them as quick as possible. I don't care how it will be called.

It is not very serious. I don't know what the attacker can obtain but, this vulnerability is theoretically possible against packet format:

(attack the packet format) knowing the plain text of one header, recover one byte of every other >encrypted header.

I will put one byte extra random padding byte at the first byte of the header against this attack.
Again, thank you for your contributions.
Your critics are always welcome unless you mislead the other developers.

Communcation packet format update committed.

And about the question: Why did I put the algorithm to public domain?

Is this public domain or MIT?  Your LICENSE is MIT.

What will you obtain from the "differences" of random numbers?

It is a stream cipher attack.  It doesn't reveal the whole header.  It reveals the first byte of the header, but it is still the classic stream cipher attack.

I will simply put one extra random padding byte as the first byte of the header against this attack which will eliminate that possibility.

And here you go again with more recommendations on how to use the algorithm securely.  I point out a vulnerability, and you say, *oh nonononono because I can put a padding byte there so it's secure, duh! *  That extra padding is something you can prepend to the plain text, before encrypting it with the vulnerable cipher, to mitigate that vulnerability.

Google thinks the same: That's why they had to choose to use a non standart algorithm, ChaCha20, for encryption.

Hmm... I wonder what google thinks of hohha.  Maybe that should use that instead of ChaCha20!  I don't know where you're going with this... RC4 wasn't good enough for google, therefore hohha is secure, QED?

He doesn't know our jargon! And other people here, who doesn't understand about what happens, will think I'm cool!" But I clearly understand that you're not!

What are you, a troll?  Am I being trolled?  On the internet?  It all makes sense now.  You trolled the linux mailing list to see who would bite, and I'm that sucker.
If you're serious, not trolling me, man, I feel sorry for you.  Have fun developing your algorithm, I guess.  I can't imagine how you'll ever convince anyone that they're secure, or how you'll get any help, with that attitude.  If anything is impenetrable here, it's not your algorithm, man, it's you.
I am -- still -- waiting to read your explanation of these attacks.  You really don't know how they work, do you?

(attack the cipher) message forgery and message recovery - of the whole message
(attack the cipher) recover the number of jumps
(attack the cipher) recover the key length
(attack the packet format) knowing the plain text of one header, recover one byte of every other encrypted header.


Adding a message queue

Added a system to queue TTS messages to prevent newer messages from cutting of previous ones. I tested this on a few streams and it seemed to work fine.
I also ran my linter over the code.

Thank you for the queue system!


[sidecar] setup pod with simple sidecar for development and demonstration

加一个docs目录，专门放md文档吧

加一个docs目录，专门放md文档吧

OK


Feature request: support calling static functions in separate files

I'd like to be able to do this:
File1.cs
using static CommonHelperFunctions;

[VertexShader]
Vector4 VS(Vector4 input)
{
    return FunctionInAnotherClass(input);
}

File2.cs
public static class CommonHelperFunctions
{
    public static Vector4 FunctionInAnotherClass(Vector4 value)
    {
        return value;
    }
}

I imagine this could be a common pattern for helper functions.
But currently, it crashes in the language backend. For example, in HlslBackend it crashes here. This Single call doesn't match anything, because setContext.Functions only contains functions defined in the local file:
ShaderFunctionAndBlockSyntax f = setContext.Functions.Single(
    sfabs => sfabs.Function.DeclaringType == name.TypeName && sfabs.Function.Name == name.MethodName);

I had a quick go at trying to fix the code but it got a bit complicated. I can keep going, but I wanted to check first: is this something you'd like to support? If so, any implementation suggestions would be appreciated :)

Yes, this is something I would like to support.
The way that functions are enumerated, ordered, and processed is quite a mess at the moment. It's grown over time from the beginning when I had no clue how the Roslyn API worked or how ShaderGen should use it...
I've looked it over again and this is how it currently works:

ShaderGen does a full syntax walk (ShaderSyntaxWalker), and whenever it discovers ANY method declaration, it adds it to the context's function list.
When some backends are outputting code for the functions, they generate an "ordered graph" of the function calls. This does ANOTHER syntax walk (FunctionCallGraphDiscoverer and MethodWalker) which puts the functions that are actually used into an ordered graph. This is because HLSL and GLSL need functions to be declared before they are called (unlike C#).
The HLSL/GLSL backend spit out the functions in reverse order from the call order. Actually, the Metal backend does this too, but I don't think it's actually necessary. I never tested, but it's not a big deal either way.

Unless I'm missing something obvious, we should be able to more-or-less remove the first step. The only thing that step needs to discover is the entry point functions for the shader set (vertex/fragment). It doesn't need to track all of the other functions in the type, because they don't actually matter unless they are called by the entry function. If they are, they will be caught by the FunctionCallGraphDiscoverer later on. We can augment the FunctionCallGraphDiscoverer to output the full ShaderFunctionAndBlockSyntax information that is needed to generate the code in each backend.
Note that this definitely won't work for externally-defined functions (e.g. there's no implementation IL available for them). To allow that, we'd need to process an entirely different object model (Cecil's, probably), and only if you have the implementation handly (not a reference assembly).


Updated to biicode version 3.3

I just closed this one and opened a new pull request with shasum updated #11985


Android Google Sign-in: When Google account popup is set to the maximum font size and the screen is rotated, scrollbar not visible

Step 1: Are you in the right place?

For issues or feature requests related to the code in this repository file a Github issue.
For general technical questions, post a question on StackOverflow tagged appropriately.

Step 2: Describe your environment

Device: Samsung Galaxy S9
OS version: Android 9
[Android] Google Play Services version: 19.6.29

Step 3: Describe the problem:
When font size is set to maximum on device, no scrollbar visible on google sign-in pop-up dialog.
(See below screenshot)

Steps to reproduce:

Set font-size to maximum on device.
Make sure device has logged in google accounts.
Open app supporting google sign-in.
Attempt sign-in with google.
Rotate the device to landscape.
Observe no indication of scrollbar. (as shown in image above)

Observed Results:

No scrollbar visible even though we have more content.

Expected Results:

Scrollbar should be visible indicating there is more content to be seen in the pop-up.

@navshri thanks!  I'll report this bug to the right team.

Has been issue fixed?
I have the same result. The google sign in view isn't scrollable if font is large as settings


Unable to create the new team in MS Teams

Steps to reproduce

Open MS Teams.
Navigate to the Teams tab.
Click on "+" Icon and then select Create Team option.
Enter the team name and description.
Click on the Create button

Expected behavior
The team should be created successfully.
Actual behavior
Getting the error like "We ran into a problem creating your team"

Error details
I am getting the error while creating the teams in the MS team web application login.
Error Details:- "We ran into a problem creating your team"
Data :- used MS teams service account credentials

@rakshith1428 We are mainly responsible for Microsoft Teams app development related issues.
For Microsoft Teams product issues/failures your tenant Admin can reach out to Microsoft 365 Product Support.
For general questions about Microsoft Teams please post your question on Microsoft Teams Community.
For question related to Microsoft PowerShell Microsoft PowerShell
For question related to Microsoft Booking Microsoft Bookings


Page Filter

Hate to do this, I'm super noob when it comes to Grav, but am loving what I am testing out here.
I was wondering if when using the page.find function, if there's a way to filter by a custom option set in the blueprint.yaml.
For instance, I'm making a blog and listing options as to whom is the author. I want when you go to the author page to list the blogs that the author has posted on the site, so to do so I wanted to do something like-
{% for post in page.find('/blog').children.filter(author.name, header.author.name) %}
posts
{% endfor %}
Am I just missing some tiny detail here?

Solved in Gitter


Instructions for setting up bcbio via conda

Hi,
Sorry to keep bothering you on bcbio issues.
I am attempting to install bcbio on a server hosted by an external organization, but ran into an issue where the SHA checksum did not match for files downloaded by the bcbio_nextgen_install.py installer.
The engineer at the organization discovered the bcbio in conda
https://anaconda.org/bioconda/bcbio-nextgen
which I was able to install.
However, I don't know how to install the genomes, as well as bwa & star aligner because on attempting to run the upgrade command, the error states that it "cannot update data for bcbio-nextgen not installed by installer".
May I have the steps to set up bcbio properly via this conda installation? As it stands, I don't think I'll be able to install bcbio via the "normal" way. Thank you.
(bcbio128) [simngl@hpc-login01 ~]$ bcbio_nextgen.py upgrade -u skip --genomes GRCh37 --genomes hg38 --aligners bwa --aligners star
Upgrading bcbio
Upgrading bcbio-nextgen data files
Traceback (most recent call last):
File "/home/users/astar/gis/simngl/.conda/envs/bcbio128/bin/bcbio_nextgen.py", line 228, in
install.upgrade_bcbio(kwargs["args"])
File "/home/users/astar/gis/simngl/.conda/envs/bcbio128/lib/python3.6/site-packages/bcbio/install.py", line 107, in upgrade_bcbio
upgrade_bcbio_data(args, REMOTES)
File "/home/users/astar/gis/simngl/.conda/envs/bcbio128/lib/python3.6/site-packages/bcbio/install.py", line 350, in upgrade_bcbio_data
data_dir = _get_data_dir()
File "/home/users/astar/gis/simngl/.conda/envs/bcbio128/lib/python3.6/site-packages/bcbio/install.py", line 327, in _get_data_dir
raise ValueError("Cannot update data for bcbio-nextgen not installed by installer.\n"
ValueError: Cannot update data for bcbio-nextgen not installed by installer.
bcbio-nextgen needs to be installed inside an anaconda environment
located in the same directory as the genomes directory.

Hi @gis-nlsim !
bcbio is much more than just one python package, the full nodata deployment has

bcbio's own conda
bcbio-nextgen python package
many packages in several environments specified here:
https://github.com/chapmanb/cloudbiolinux/blob/master/contrib/flavor/ngs_pipeline_minimal/packages-conda.yaml
tools/bin dir with symlinks to various tools in the environments

So, unfortunately, you can't install bcbio python package and then install data from it - you'd need to run the installer.
The checksums issue was likely due to conda or proxy caches.
SN


CoarseOrientation has only one namespace_component; which causes test_namespace.py to crash. no parsing takes place.

From dsdl_definition.py lines 44-55
        relative_directory, basename = [str(x) for x in os.path.split(relative_path)]   # type: str, str
        print (basename)
        # Parsing the basename, e.g., 434.GetTransportStatistics.0.1.uavcan
        basename_components = basename.split('.')[:-1]
        print (len(basename_components))
        str_regulated_port_id = None    # type: typing.Optional[str]
        if len(basename_components) == 4:
            str_regulated_port_id, short_name, str_major_version, str_minor_version = basename_components
        elif len(basename_components) == 3:
            short_name, str_major_version, str_minor_version = basename_components
        else:
            raise FileNameFormatError('Invalid file name', path=self._file_path)

Are you getting a FileNameFormatError with Invalid file name? You seem to be attempting to parse v0 definitions using the new parser. The format has been changed in v1 in a non-backward-compatible way, so you can't use the new parser with older definitions. Please re-open if I misunderstood your situation.


Point of Departure is changing locations after user zooms or pans after edit script is applied

After a user creates and edits the mil-std graphics via the test scripts, point of departure changes geographic location when the user zooms or pans the map.
script_create_overlay_milstdfeatures.zip
script_edit_overlay_milstdfeatures.zip

Update was not being applied to the stored feature.
test branch bugfix/emp3-web#138-ww-feature-update-position

Reintegrate


[BUG] Unable to open blank issues

Describe the bug
Blank issue cannot be created. On the "New Issue" page there is an option for "(maintainers only) - Blank issue". It links to https://github.com/nebari-dev/nebari/issues/new/. However this redirects to https://github.com/nebari-dev/nebari/issues/new/choose, i.e. our starting point. Thus, it is currently impossible to open an issue without using a template.
Expected behavior
Being able to open blank issues
OS and architecture in which you are running Nebari
GH
How to Reproduce the problem?
Click the links I provided above
Command output
No response
Versions and dependencies used.
No response
Compute environment
None
Integrations
No response
Anything else?
No response

@pmeier Thanks for opening this issue.

On the "New Issue" page there is an option for "(maintainers only) - Blank issue". It links to nebari-dev/nebari/issues/new. However this redirects to nebari-dev/nebari/issues/new/choose, i.e. our starting point. Thus, it is currently impossible to open an issue without using a template.

As someone in the maintainer group, I'm able to create a blank issue with that link.
Not allowing everyone to open blank issues is a deliberate choice, to encourage folks to add necessary details and context while creating new issues. Ref: https://github.com/nebari-dev/.github/blob/8e0ae707b0fa09a292e66e7f439db0d42e2e2878/.github/ISSUE_TEMPLATE/config.yml#L1
Does this help?

If its deliberate, than we can close this one.
I personally feel the issue templates create more noise than they remove. For example nebari-dev/nebari#1716. The unfilled sections are as long as the whole report and stuff like

Expected behavior
If we provide such an option it should work.

does not add anything.


feat(Tab): extend underline to icon

FX-2172
Description
Extend underline in Tab with icon.
How to test
Visit the Tabs page in storybook
Screenshots

Before.
After.

Review

[ ] Read CONTRIBUTING.md and Component API principles
[ ] Annotate all props in component with documentation
[ ] Create examples for component
[ ] Ensure that deployed demo has expected results and good examples
[ ] Ensure that tests pass by running yarn test
[ ] Ensure that visuals tests pass by running yarn test:visual. If not - check the documentation how to fix visual tests
[ ] Ensure the changed/created components have not caused accessibility issues. How to use accessibility plugin in storybook.

PR commands

List of available commands:

@toptal-bot run all - Run whole pipeline
@toptal-bot run build - Check build
@toptal-bot run visual - Run visual tests
@toptal-bot run deploy:documentation - Deploy documentation
@toptal-bot run package:alpha-release - Release alpha version

PR Review Guidelines

When to approve? ✅
You are OK with merging this PR and

You have no extra requests.
You have optional requests.

Add nit: to your comment. (ex. nit: I'd rename this variable from makeCircle to getCircle)

When to request changes? ❌
You are not OK with merging this PR because

Something is broken after the changes.
Acceptance criteria is not reached.
Code is dirty.

When to comment (neither ✅ nor ❌)
You want your comments to be addressed before merging this PR in cases like:

There are leftovers like unnecessary logs, comments, etc.
You have an opinionated comment regarding the code that requires a discussion.
You have questions.

How to handle the comments?

An owner of a comment is the only one who can resolve it.
An owner of a comment must resolve it when it's addressed.
A PR owner must reply with ✅ when a comment is addressed.

I would add visual test, because it looks like no tests failed when we did this change

I would add visual test, because it looks like no tests failed when we did this change

We have a visual test for icons, but its not selected Tab with icon. I will add it 👍

@toptal-bot run all


[py2py3] Migrate WMCore/Credential

Fixes #10007
Status

src: ready
test: ready

Description
Run futurize and then apply manual changes to WMCore/Credential
Summary

Division: keep an eye on old_div, it may be dropped in favor of //

src/python/WMCore/Credential/Proxy.py
test/python/WMCore_t/Credential_t/Proxy_t.py
test/python/WMCore_t/Credential_t/MyProxy_t.py

str : form builtins import str is used extensivvely in this PR

src/python/WMCore/Credential/Proxy.py
src/python/WMCore/Credential/SimpleMyProxy.py

list and iterators: using backported version of filter and range, as described in the python future docs

src/python/WMCore/Credential/Proxy.py

Missing

grouping import from builtins

Is it backward compatible (if not, which system it affects?)
It should be. However, as obtained from the direct dependency graph, any bug would affect directly
 'WMCore_Credential': ['WMCore_BossAir',
                       'WMCore_Credential',
                       'WMComponent_AgentStatusWatcher'],

External dependencies / deployment changes
This PR requires python-future

@mapellidario
I tend to disagree with the following statement:

Division: keep an eye on old_div, it may be dropped in favor of //

What I mean is, blindly substituting an operator may lead to an unexpected surprises. We all know the only difference between those two operators in Python2 and Python3, but let me just for clarity I paste the following table bellow:
   1 │|------------------------------------------------------------------------+------------------------------------------------------------------------|
   2 │| (python2.venv) tivanov@tot-t590:tmp$ python                            | (python2.venv) tivanov@tot-t590:tmp$ python                            |
   3 │| Python 2.7.16 (default, Oct 10 2019, 22:02:15)                         | Python 2.7.16 (default, Oct 10 2019, 22:02:15)                         |
   4 │| [GCC 8.3.0] on linux2                                                  | [GCC 8.3.0] on linux2                                                  |
   5 │| Type "help", "copyright", "credits" or "license" for more information. | Type "help", "copyright", "credits" or "license" for more information. |
   6 │|                                                                        |                                                                        |
   7 │| >>> from past.utils import old_div                                     | >>> from __future__ import division                                    |
   8 │| >>> 5/2                                                                | >>> 5/2                                                                |
   9 │| 2                                                                      | 2.5                                                                    |
  10 │| >>> 5/2.0                                                              | >>> 5/2.0                                                              |
  11 │| 2.5                                                                    | 2.5                                                                    |
  12 │| >>> 5//2                                                               | >>> 5//2                                                               |
  13 │| 2                                                                      | 2                                                                      |
  14 │| >>> 5//2.0                                                             | >>> 5//2.0                                                             |
  15 │| 2.0                                                                    | 2.0                                                                    |
  16 │|------------------------------------------------------------------------+------------------------------------------------------------------------|

Notice the (expected, but still subtle) difference between lines 9 and 15 in the two cases with and without the __future__ module division. I mean if we just change the division with the one from future (old_div -> __future__) is one thing and could be considered  safe enough, but if we couple the change also with a an operator substitution (/ -> //), then we suddenly complicate the 'transition matrix' and we can run into troubles due to over complication (and we may miss a place or two where we forget to take this into account).

Dear Alan and Todor, thanks for your review.
In this PR we face the subtleties of division for the first time in WMCore and in some cases your experience can make the difference.
why i chose old_div
I take src/python/WMCore/Credential/Proxy.py as an example. Right now in this file we do not from __future__ import division, so we have to assume that every division behaves like the old python2 division. (I think that the new kind of division has not been imported here because there may be a couple of places in this file where just importing a new kind of division may break things, as todor pointed out in his comment)
An example of simple change is at L232
- daystoexp = int(timeleft / (60. * 60 * 24))
+ daystoexp = int(timeleft // (60. * 60 * 24))

Here it is obvious that daystoexp should be an integer, and despite int(3.9) == 3 in both python2 and python3 (meaning that the lossy conversion from float to int keeps only the integer part, without any rounding up), using the  // operator makes this more explicit.
A different example is L685
-  vomsValid = "%d:%02d" % (vomsTime / 3600, (vomsTime - (vomsTime / 3600) * 3600) / 60)
+ vomsValid = "%d:%02d" % (old_div(vomsTime, 3600), old_div((vomsTime - (old_div(vomsTime, 3600)) * 3600), 60))

vomsValid is later used as an argument to call the voms-proxy-init, so getting this string wrong can break the voms-proxy-init command. I have been as much conservativeand lazy  as possible by using from past.utils import old_div (this is provided by python future), which is a function that behaves like python2 division both in python2 and in python3.
I am sorry for the comment "Division: keep an eye on old_div, it may be dropped in favor of //", my intentions are not clear at all. I will try to be more clear in my PR messages next time. What I meant is that we may want to have a look at the usages of the division in this PR, understand where the result is intended to be a float (and use / after importing from __future__ import division) and where it is intended to be an integer (and use int(a // b)). This refactoring is not necessary, we can always be dependent on python-future. Since it is not necessary, I have just opted for the lazy options and kept the current situation by importing old_div so that the behaviour is consistent in python3 also.
example of refactoring
With this is mind, we may want to have a second look at L685, I guess that vomsTime is in seconds, but the argument of voms-proxy-init is ${hours}:${minutes, two digits}".
This would mean that vomsTime / 3600 is in hours (and this abuses the python2 division by loosing the fraction part and keeping only the decimal part when two integers are involved). If this is true, this means that in order to have consistent python2 and python3 behavior we have two options:
- vomsTime / 3600
+ old_div(vomsTime, 3600)
# OR
- vomsTime / 3600
+ int(vomsTime // 3600)

With the same assumption as before, this (vomsTime - (vomsTime / 3600) * 3600) / 60 seems like a way of computing the remaining minutes. vomsTime / 3600 is what is already in the hours, (vomsTime / 3600) * 3600 converts the what has already been put in the hours into seconds, (vomsTime - (vomsTime / 3600) * 3600) this keeps only the seconds that did not end up in the hours count, then we divide this by 60 to convert the remaining seconds in minutes (again, this is an abuse of the python2 lossy division between integers, that discards the fractional part). With this in mind, and in order to have consistent behaviour in python2 and in python3, we have some options
- (vomsTime - (vomsTime / 3600) * 3600) / 60
+ int((vomsTime - int(vomsTime // 3600) * 3600) // 60)
# or
- (vomsTime - (vomsTime / 3600) * 3600) / 60
* int((vomsTime % 3600) // 60)

conclusions
I can go through the PR again and try get rid of old_div and use / // % to get consistent behavior in python2 aand pythhon3 instead. I am sorry for having been  bit lazy and conservative at the first round

Hi @mapellidario I understand  what you mean and in general I would be quite supportive in your suggestion, like making an implicit floor operation hidden behind the behavior of the division function itself to become more obvious and rely on everybody's knowledge about the operator behavior. But in  this case as you can see now we suggest a shortcut - like just substituting the operator, and later we forget that this change affected this particular piece of code and then we decide to have a full switch to the __ future__ division .... Not telling this is going to create a problem, but I'd rather not try to remember a past change until the actual transition happens and would directly move to the new division behavior and avoid the operator substitution at all. This is not a strong disagreement with your suggestion... more like ... expressing myself something like : "I would do it the other way around". :)

Ok, so I will add from __future__ import division, but this is going to break lines like
 vomsValid = "%d:%02d" % (vomsTime / 3600, (vomsTime - (vomsTime / 3600) * 3600) / 60)

So, if you want me to add from __future__ import division, then I will have to make all the necessary adjustments/refactoring. I agree that this is the cleanest solution, so new commits will come in the afternoon.
Thanks again!

Thank you very much Dario.
FYI @belforte Stefano, something to keep in mind analysis services start using WMCore >= 1.4.2.pre7 (py2/py3 compatible code).

FYI @belforte Stefano, something to keep in mind analysis services start using WMCore >= 1.4.2.pre7 (py2/py3 compatible code).

I am not sure I understand. Sorry my being thick. Do you simply mean "beware when you will try to get rid of separate CRAB branch that there will be changes in Credential as well" ?
BTW, since we are on topic, I think we'll spend November on K8s, Rucio and NewPublisherForCrab and I'll start looking at py2topy3 for Crab lin a month or so. If @amaltaro  or @mapellidario have time to think about the matter in the meanwhile, the critical part IMHO is this: https://github.com/dmwm/CRABClient/issues/4940  Especially in light of the thing that CRAB Client should keep working also in Py2 environmenr for those CMSSW releases which will stay there. See also this comment from KevinL

I am not sure I understand. Sorry my being thick. Do you simply mean "beware when you will try to get rid of separate CRAB branch that there will be changes in Credential as well" ?

Yes, just something to keep in mind when you upgrade imported WMCore to the latest production release/HEAD in the future.


Specifying .env path

Is it possible to specify .env filename and path?
I am using config/${ENVIRONMENT}.env as a filename.
Cool feature!

not currently.


ES Modules build

Can you provide a pure ES modules build? This library doesn't seem to be easily usable in the browser without webpack or browserify, especially because of the reliance on node crypto

See #259


Upload component drag sort file list, and large file segment upload support.

期望添加上传文件分片，和文件列表拖拽排序功能。
This function solves the problem (这个功能解决的问题)
When we upload a big file, like video, iso files, segment upload can be more stable.
And drag sort file list is also a useful feature.
Expected API (期望的 API)
Add some options like plupload:
chunk-size: 0 means no chunk upload, and great thant 0 mean chunk size, eg: 200 mean 200kb.
file-list-drag-sort: true means allow drag sort file list.

We don't plan to add segment upload & sort file list currently.

This issue does not have any recent activity. If you are still experiencing similar problems, open a new error, including a minimal copy of the problem


Improve Style of Contact Us section

Feature Request
Describe your problem
The Contact Us form on the home page could use some work. Currently it's not very appealing and there seem to be some redundant features.

As you can see, the form is neither left-aligned, nor right-aligned nor justified. It sits in this weird position on the left side of the screen. Moreover, the font color has poor visibility and the check marks seem to serve no function.
Describe the solution you'd like
Align the form in either of the aforementioned manners (left-, right- or justified), improve the color of the headings and try to align all three text areas by giving them the same width. You only need to fiddle around with styles.css for this issue.
Additional context

@uglyprincess  can i work on this?

@uglyprincess can i work on this?

sure @geeks5551, go ahead! 🎉

@deepakDOTexe  assign me with  this issue?

@uglyprincess similar kind of issue has already been opened pls check #150 ....

Due to potential merge conflicts, I'm closing this issue for now.


Fix tabbing issues

Fix #685, #411, #515

Hey @sigerello I tested your fix-tabbing branch for vue-multiselect, and I don't see much difference between it and the latest master from @shentao. Tab behavior seems to work well with both. I'm testing with Chrome. Is there anything I'm missing?

This PR consists of two commits: this one is actually a fix, and second one is not directly related to mentioned issues - it's just code style fixes.
Lets compare in detail 4 versions on JSFiddle:

shentao/vue-multiselect/tree/v2.0.3
shentao/vue-multiselect/tree/v2.1.0
shentao/vue-multiselect/master
sigerello/vue-multiselect/fix-tabbing

Each of them has the same markup and scripts, the only difference is loaded version of vue-multiselect in "resources" section.
We have 3 multiselect instances here:

single select, searchable=true
multiple select, searchable=true
multiple select, searchable=false

Test scenario is the same for each version:

Click on top link and then click tab to move focus to multiselect instance.
When vue-multiselect instance gets focus, click down key (one or several times - just to change highlighted item in list to another one item).
Click tab again to move focus to next multiselect instance.
Repeat steps 2,3 until bottom link gets focus.
Now go in reverse order by clicking shift+tab and repeating step 2.

Results for each version:
shentao/vue-multiselect/tree/v2.0.3:

We successfully went down to bottom link.
Clicking Tab and Shift+Tab doesn't select item on searchable instances, but does select one if instance is "no searchable". This is a bug.
When we go in reverse order, we can reach searchable instance, but clicking Shift+Tab on it - doesn't work, so we can't go upper and stuck here. This is a bug.

shentao/vue-multiselect/tree/v2.1.0:

We can't focus searchable instances at all by tabbing, but can focus "no searchable" instance. This is a bug.
Clicking Tab and Shift+Tab doesn't select item on searchable instances, but does select one if instance is "no searchable". This is the same bug as in v2.0.3.

shentao/vue-multiselect/master:

We can move down and up by tabbing on all instances (yay!)
Clicking Tab and Shift+Tab doesn't select item on searchable instances, but does select one if instance is "no searchable". The same bug as in v2.0.3 and v2.1.0.

sigerello/vue-multiselect/fix-tabbing:

We can move down and up by tabbing on all instances (already fixed in shentao/master)
Tabbing doesn't select items on any instances but just moving focus between them as it intended to be (finally!)

Hey @sigerello, thanks for the detailed explanation.
I'm not sure if everyone considers select on tab to be a bug. I say this because in #612 and #654, several people say they want select on tab for searchable multiselects. In one comment, @shentao implies this was his intention as well. I don't know how any of them would feel about select on tab in non-searchable multiselects.

IMO, tabbing has nothing to do with selections. This leads to unexpected selections and poor user experience. Tabbing should only change focus between elements. We have Enter and Space buttons to make selections. All standard form elements behave this way.
But anyway, if it was intended to behave like that, I think it should be:

Configurable, so we can explicitly enable this feature if needed.
Consistent, so it should behave the same way for all instances - searchable ones and not searchable ones.

In this case I agree with @sigerello – I’m all for sticking to how a native select behaves. This means tabs should not trigger a select. This is also how it used to work. But then there were issues that we should make the tab key trigger the selection if the pointer is dirty. This also makes sense in some cases.
We should probably lean towards making it explicit by setting a prop flag. Another improvement that should make this issue less pressing will be to not open the dropdown on focus. Instead the user will need to click space/arrow/enter to open the dropdown. This behaviour is already present in the current v3.

IMO, tabbing has nothing to do with selections. This leads to unexpected selections and poor user experience. Tabbing should only change focus between elements. We have Enter and Space buttons to make selections. All standard form elements behave this way.
But anyway, if it was intended to behave like that, I think it should be:

Configurable, so we can explicitly enable this feature if needed.
Consistent, so it should behave the same way for all instances - for searchable ones and not searchable ones.

I feel like this should be configurable in some way (I haven't found anything in the docs, if there is a way?). @shentao - I definitely don't agree that we should have to press enter - a normal  menu allows you to move through the options with the keyboard and tabbing keeps your suggestion. Vue-Multiselect requires you to press enter to select, instead. This is not good User Experience, because it functions differently from the standard HTML functionality...


RuntimeError: Expected to have finished reduction in the prior iteration before starting a new one.

Adding my own modification part to the official code found that it can run in single card mode, but it cannot run in multi-card case, what should I do?

@notfacezhi You can add find_unused_parameters=True in the configuration.

Thank you! I tried it and found it works fine. Wish you a happy life!
@hhaAndroid

@notfacezhi You can add find_unused_parameters=True in the configuration.

Hi @hhaAndroid , I met the same error . I added my own modification part to the official code and it can run in single card mode, but it cannot run in multi-card case. And I added  find_unused_parameters=True in the configuration.
However, a new error showed:
RuntimeError: Expected to mark a variable ready only once. This error is caused by one of the following reasons: 1) Use of a module parameter outside the forward function. Please make sure model parameters are not shared across multiple concurrent forward-backward passes. or try to use _set_static_graph() as a workaround if this module graph does not change during training loop.2) Reused parameters in multiple reentrant backward passes. For example, if you use multiple checkpoint functions to wrap the same part of your model, it would result in the same set of parameters been used by different reentrant backward passes multiple times, and hence marking a variable ready multiple times. DDP does not support such use cases in default. You can try to use _set_static_graph() as a workaround if your module graph does not change over iterations.
Why is this and how can I solve this?  Thank you!

@notfacezhi You can add find_unused_parameters=True in the configuration.

Hi @hhaAndroid , I met the same error . I added my own modification part to the official code and it can run in single card mode, but it cannot run in multi-card case. And I added find_unused_parameters=True in the configuration. However, a new error showed: RuntimeError: Expected to mark a variable ready only once. This error is caused by one of the following reasons: 1) Use of a module parameter outside the forward function. Please make sure model parameters are not shared across multiple concurrent forward-backward passes. or try to use _set_static_graph() as a workaround if this module graph does not change during training loop.2) Reused parameters in multiple reentrant backward passes. For example, if you use multiple checkpoint functions to wrap the same part of your model, it would result in the same set of parameters been used by different reentrant backward passes multiple times, and hence marking a variable ready multiple times. DDP does not support such use cases in default. You can try to use _set_static_graph() as a workaround if your module graph does not change over iterations.
Why is this and how can I solve this? Thank you!

Have you solve the problem? I met the same problem now.


The changes made include refactoring of the code, addition of Java Doc, and implementation of Exception Handling.

The changes made include refactoring of the code, the addition of Java Doc, and implementation of Exception Handling.

Thanks @raowaqasakram We usually prefer to avoid adding libraries like lombok if they're not the focus of a certain tutorial because this may make the code more complex for readers to understand.
We'll go over the other suggested improvements and decide whether they'll be included in a new PR.


Sync with master

⚠ Do not merge until comparison test is run

Apologies, created a wrong PR., Closing 🙏


[Storage] Added ResumeTransferAsync to TransferManager

Added TransferManager.ResumeTransferAsync which will allow to resume transfers that are in a resumable state
Added tests

Follow up

Do we need to remove the TransferOptions.ResumeFromCheckpointId so customers would use this API over the one in the options bag?

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Storage.DataMovement


[WFCORE-842] Rename CapabilityContext to CapabilityScope

Windows Build 2047 is now running using a merge of 5d55e18b0c69e98ffb9aea0a9711c3a43402325b

Core - Full Integration - Windows Build 84 is now running using a merge of 5d55e18b0c69e98ffb9aea0a9711c3a43402325b

Core - Full Integration Build 1663 is now running using a merge of 5d55e18b0c69e98ffb9aea0a9711c3a43402325b

Linux Build 2538 is now running using a merge of 5d55e18b0c69e98ffb9aea0a9711c3a43402325b

Windows Build 2047 outcome was SUCCESS using a merge of 5d55e18b0c69e98ffb9aea0a9711c3a43402325b
Summary: Tests passed: 3409, ignored: 64 Build time: 00:37:28

Linux Build 2538 outcome was SUCCESS using a merge of 5d55e18b0c69e98ffb9aea0a9711c3a43402325b
Summary: Tests passed: 3409, ignored: 64 Build time: 00:39:00

Core - Full Integration Build 1663 outcome was SUCCESS using a merge of 5d55e18b0c69e98ffb9aea0a9711c3a43402325b
Summary: Tests passed: 3060, ignored: 358 Build time: 00:51:35

Core - Full Integration - Windows Build 84 outcome was SUCCESS using a merge of 5d55e18b0c69e98ffb9aea0a9711c3a43402325b
Summary: Tests passed: 3060, ignored: 358 Build time: 00:52:34


Do you have any open source plans for the Stage II in your latest paper?

I have read your great work in SELF-SUPERVISED SPEAKER RECOGNITION WITH LOSS-GATED LEARNING（ICASSP 2022).
I attempt to follow Stage II in your paper, which shows great gains in your experiments.
If these parts of codes are available, it will benefit a lot.
Thanks a lot.

Thanks for your interest, I plan to release the code later (maybe on May or June) since I am doing other works recently.

Thx


Migrate critical constants and acentric factors batch 6

Review old PR first. Otherwise, It will be difficult to review.

@saikat-samanta  Resolve merge conflicts


add Open Source license to Weatherize symbols

In the README, Weatherize's license is set to "No license or website found.", so it is proprietary. If so, shouldn't it be removed from inkscape-open-symbols?

@jlar0che: You are the author listed in inkscape-open-symbols's README.md. Would you consider publishing Weatherize with an open source license?

You are right @legrostdg if they are not open it should be removed. Sorry and thanks for pointing thi out.
Hopefully, @jlar0che will license this amazing symbol set as Open Source.
What do you say @jlar0che ?

That seems to be a mistake. Everything I've done for Inkscape Open Symbols is Open Source.

Feel free to change the license on all my contributions to Open Source

@jlar0che: There are quite a lot of different F(L)OSS licences, and nobody but you can add one to your works :) ('Open Source' only means that people are allowed to read the source code, this doesn't say anything about sharing, making derivations, attribution,...).
I'd suggest you use CC0, CC-By, or CC-By-SA, as the licenced contents is basically art, not so much code.
If you use CC-By-SA or CC-By, I think it would be a nice extra to allow people to use the icons without linking to your site, the licence and mentioning your name, and to only have the licence apply if they want to publish derivations of the set. This would have to be mentioned separately.
For a licence choosing aid, see also https://creativecommons.org/choose/?lang=en

I was trying to speed up this process because I won't be able to get to it
since I'm out of town. I'll get to it, but not for a few days at least - I
won't get back home till the end of the first week of January.
On Sun, Dec 25, 2016 at 2:19 PM, Moini<EMAIL_ADDRESS>wrote:

@jlar0che https://github.com/jlar0che: There are quite a lot of
different F(L)OSS licences, and nobody but you can add one to your works :)
('Open Source' only means that people are allowed to read the source code,
this doesn't say anything about sharing, making derivations,
attribution,...).
I'd suggest you use CC0, CC-By, or CC-By-SA, as the licenced contents is
basically art, not so much code.
If you use CC-By-SA or CC-By, I think it would be a nice extra to allow
people to use the icons without linking to your site, the licence and
mentioning your name, and to only have the licence apply if they want to
publish derivations of the set. This would have to be mentioned separately.
For a licence choosing aid, see also https://creativecommons.org/
choose/?lang=en
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Xaviju/inkscape-open-symbols/issues/44#issuecomment-269134345,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB3mR7HMjHr6M1TnSyYPUgcSfBq_v9Iyks5rLsHagaJpZM4LVNZv
.

No problem @jlar0che thanks for your interest in adding an Open Source license! Please let us know which license have you chosen once you did it so we can reference it from the repo so everyone knows that it can be used safely.
It would be even better if you publish you set in your github profile and add an OS License there.
Let me know if I can help

@jlar0che just to be sure: you are the author of weather icons (and did not only convert these to svg from another source), right?

Yes, he did it according to this PR: https://github.com/Xaviju/inkscape-open-symbols/pull/28

OK!

@jlar0che any update? We're waiting for this before making a release (#45) and packaging it for Debian.
Thanks!

All my contributions can fall under the CC-By-SA. Thanks.

I think you need to be more precise... There are multiple version of CC-By-SA. What would really help would be a repo with your symbols, the name of copyright owner and the complete text of the license chosen.

See for example https://github.com/GNOME/gnome-icon-theme-symbolic and https://github.com/GNOME/gnome-icon-theme-symbolic/blob/master/COPYING

@legrostdg I think would be enough for the release if @jlar0che could answer this two questions and give us the result: https://creativecommons.org/choose/?lang=en
I could add the info it to the icon license and finally publish it.
Publishing the icons in a repo and adding the LICENSE file would be perfect but depends on the available time.

The answer is yes, and yes. See below:
Allow adaptations of your work to be shared?

Yes
No
Yes, as long as others share alike

Allow commercial uses of your work?

Yes
No

On Sun, Jan 8, 2017 at 2:46 PM, Xaviju<EMAIL_ADDRESS>wrote:

@legrostdg https://github.com/legrostdg I think would be enough for the
release if @jlar0che https://github.com/jlar0che could answer this two
questions and give us the result: https://creativecommons.org/
choose/?lang=en
I could add the info it to the icon license and finally publish it.
Publishing the icons in a repo and adding the LICENSE file would be
perfect but depends on the available time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Xaviju/inkscape-open-symbols/issues/44#issuecomment-271174102,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB3mRxI_XdGnZuDg_RQOXzjjI2HIr_Zuks5rQTz-gaJpZM4LVNZv
.

Thanks @jlar0che! The license will be Creative Commons Attribution 4.0 International License. I'll update the symbol set with your license.

https://github.com/Xaviju/inkscape-open-symbols/commit/8583275aaf44c021c96890230f9a74077918eabe


'NoneType' object has no attribute 'tokenize'

I'm using Cohere and unstructured, and I'm receiving that error when trying to load a pdf. It works ok with the simple reader, but not with the options for PDF.
this is the log:
ℹ Received Data to Import: READER(PDFReader, Documents 1, Type
Documentation) CHUNKER (TokenChunker, UNITS 250, OVERLAP 50), EMBEDDER
(MiniLMEmbedder)
✔ Loaded ai-03-00057.pdf
✔ Loaded 1 documents
Chunking documents: 100%|████████████████████████████████████████████| 1/1 [00:00<00:00, 37.20it/s]
✔ Chunking completed
Vectorizing document chunks:   0%|                                           | 0/1 [00:00<?, ?it/s]
✘ Loading data failed 'NoneType' object has no attribute 'tokenize'
Regards.

Thanks for the issue! It looks like you're using the SentenceTransformer MiniLM model to embed the chunks, is that intended? It might be that there are some missing dependencies, are you running Verba on a new python environment?

I tried all the possibilities, using the MiniLM was just a try.

Thanks for the insights! I'll look into fixing this 👍

We merged some fixes, are you still getting these errors?

I was getting the same error and found out that it was due to:
⚠ Using `low_cpu_mem_usage=True` or a `device_map` requires Accelerate:
`pip install accelerate`

Perhaps adding accelerate as a direct dependency to Verba is desirable?

https://github.com/weaviate/Verba/blob/1c9d4b49385315883ba0027ac1772a8b448f6204/goldenverba/components/embedding/MiniLMEmbedder.py#L26-L42
device_map should be type str or dict not torch.device type
https://github.com/huggingface/transformers/blob/edb170238febf7fc3e3278ed5b9ca0b2c40c70e3/src/transformers/tools/base.py#L460-L461

I was getting the same error when using MiniLMEmbedder on my mac that doesn't have a cuda gpu. So I tried @f0rmiga solution and I updated my code like this:
from accelerate import Accelerator   accelerator = Accelerator()
After self.device = get_device() I added self.device = accelerator.device
Now MiniLMEmbedder works fine and the document's chunks are being vectorized.

This should be fixed with the newest v1.0.0 version!

with AdaEmbedder in Azure Openai issue still persists
✘ {'errors': {'error': [{'message': "update vector: unmarshal response
body: invalid character '<' looking for beginning of value"}]}, 'status':
'FAILED'}
I am using goldenverba Version: 1.0.1
Also inside schema_generation.py
"text2vec-openai":
{"deploymentId": ,
"resourceName": },
"baseURL"} are defined and correct.

What openai version have you installed?

I have installed version: 0.27.9 however I tried with 1.30.1 also same error

Make sure to use the 0.27.9 version, I'll take a closer look at the Azure Implementation


patches: Drop android-mainline

The one patch has been merged.
Resolves https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/1594688617.

thanks for the patch removing the patch! 🪨 🙄
The output of https://github.com/ClangBuiltLinux/continuous-integration2/runs/4566921218?check_suite_focus=true is pretty confusing that patches failed to apply; is this a side effect of a27c0fe ?

No, that is technically due to https://github.com/ClangBuiltLinux/continuous-integration2/commit/3a7707ebb9915d0c1ca9641736a9d1f79ecd00cb. I could add a check to just bail out early if status_message = Unable to apply kernel patch if that would make it easier for you to see what's going on.

filed #261 to follow up


Find bar locates correct text, but highlights incorrect text

I have discovered a situation where PDF.js is finding the correct phrase in a PDF, but is highlighting letters that are not part of the phrase. To reproduce:

Open https://www.sec.gov/investor/seniors/seniorsguide.pdf with the default PDF.js viewer (or Firefox)
Open the find bar and search for the following: www.sec.gov/investor
Notice that the first match correctly highlights the phrase

Click the button to go to the next match
Note that although it did find another instance of the phrase, the viewer is  instead is highlighting the letters "ens: www.sec.gov/inv", and part of the following letter "e"

This is reproducible in both Chrome and Firefox. It does not occur in Adobe Reader.

I can no longer reproduce this issue, using the latest version of PDF.js (1.2.68).
It was most likely fixed by PR #6588, hence I'm closing this issue.


cephfs: do not run modprobe if support is compiled into the kernel

By reading the contents of /proc/filesystems, and checking if "ceph" is
included there, running "modprobe ceph" can be skipped.
Fixes: #4376
Signed-off-by: Niels de Vos<EMAIL_ADDRESS>

@mergifyio rebase

@mergifyio queue


Update Gradle Wrapper from 7.3.1 to 7.3.2

Update Gradle Wrapper from 7.3.1 to 7.3.2.
Read the release notes: https://docs.gradle.org/7.3.2/release-notes.html

The checksums of the Wrapper JAR and the distribution binary have been successfully verified.

Gradle release: 7.3.2
Distribution (-all) zip checksum: dd54e87b4d7aa8ff3c6afb0f7805aa121d4b70bca55b8c9b1b896eb103184582
Wrapper JAR Checksum: 33ad4583fd7ee156f533778736fa1b4940bd83b433934d1cc4e9f608e99a6a89

You can find the reference checksum values at https://gradle.org/release-checksums/

🤖 This PR has been created by the Update Gradle Wrapper action.

Need help? 🤔

If something doesn't look right with this PR please file an issue here.

Unable to set all the PR reviewers, check the following usernames are correct:

@bigmichi1

Please refer to the documentation for the reviewers and team-reviewers input parameters.

🤖 This is an automatic comment by the Update Gradle Wrapper action.


Add HiFi AMP HAT TAS5713 DAC

I just purchased RPI HiFi AMP HAT TAS5713 Amplifier off of Amazon (link below) I don't believe it is compatible with balena. Can I get the support added?
Amazon link: https://www.amazon.com/gp/product/B07CZZ95B9/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
Thanks,
Kendall

@kcstauffer21 we have only been able to test DACs where the team already had them available or where the manufacturer have sent us them for testing. The list we have isn't a list of all DACs that work with balenaSound - it's a list of tested DACs that we know work.
In any case, looking at the documentation for your Amp board it appears that we already support it.
You just need to add the dtoverlay hifiberry-amp in the "Define DT overlays" section under the device configuration menu section.
Please let us know if this works and we can get the board added to the list for future users :-)

It works thanks!

@kcstauffer21 great will add to the supported DACs list shortly.
Just for future reference the official name is the Innomaker HiFi Amp HAT

i am new to Balena, i have same board  "HiFi AMP HAT TAS5713 DAC" as above, i try add dtoverlays as below, but there is no sound, please help me on this issue. thank you.


TProxy mode in 1.6 cause infinite loop

Bug description
when running with interception mode TPROXY, requests initiated from outside the Pod will cause Envoy to request itself indefinitely.
workload been tested:
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      annotations:
        sidecar.istio.io/interceptionMode: TPROXY
      labels:
        app: nginx
    spec:
      containers:
      - command:
        - nginx
        image: docker.gmem.cc/nginx:1.16-alpine
        imagePullPolicy: Always
        name: nginx
        securityContext:
          privileged: true
      dnsPolicy: ClusterFirst
      restartPolicy: Always

curl from another pod will be blocked, after ctrl + c envoy will keep dumping logs until all ports are used:
[2020-04-29T07:15:44.974Z] "GET / HTTP/1.1" 0 DC "-" "-" 0 0 24101 - "-" "curl/7.67.0" "d203d38c-4e34-4765-8943-aad1ee9f3654" "nginx" "<IP_ADDRESS>:80" outbound|80||nginx.default.svc.k8s.gmem.cc <IP_ADDRESS>:49584 <IP_ADDRESS>:80 <IP_ADDRESS>:49582 - default
[2020-04-29T07:15:44.975Z] "GET / HTTP/1.1" 0 DC "-" "-" 0 0 24101 - "-" "curl/7.67.0" "d203d38c-4e34-4765-8943-aad1ee9f3654" "nginx" "<IP_ADDRESS>:80" outbound|80||nginx.default.svc.k8s.gmem.cc <IP_ADDRESS>:49586 <IP_ADDRESS>:80 <IP_ADDRESS>:49584 - default
[2020-04-29T07:15:44.975Z] "GET / HTTP/1.1" 0 DC "-" "-" 0 0 24101 - "-" "curl/7.67.0" "d203d38c-4e34-4765-8943-aad1ee9f3654" "nginx" "<IP_ADDRESS>:80" outbound|80||nginx.default.svc.k8s.gmem.cc <IP_ADDRESS>:49588 <IP_ADDRESS>:80 <IP_ADDRESS>:49586 - default
[2020-04-29T07:15:44.976Z] "GET / HTTP/1.1" 0 DC "-" "-" 0 0 24105 - "-" "curl/7.67.0" "d203d38c-4e34-4765-8943-aad1ee9f3654" "nginx" "<IP_ADDRESS>:80" outbound|80||nginx.default.svc.k8s.gmem.cc <IP_ADDRESS>:49590 <IP_ADDRESS>:80 <IP_ADDRESS>:49588 - default
[2020-04-29T07:15:44.976Z] "GET / HTTP/1.1" 0 DC "-" "-" 0 0 24105 - "-" "curl/7.67.0" "d203d38c-4e34-4765-8943-aad1ee9f3654" "nginx" "<IP_ADDRESS>:80" outbound|80||nginx.default.svc.k8s.gmem.cc <IP_ADDRESS>:49592 <IP_ADDRESS>:80 <IP_ADDRESS>:49590 - default
[2020-04-29T07:15:44.976Z] "GET / HTTP/1.1" 0 DC "-" "-" 0 0 24104 - "-" "curl/7.67.0" "d203d38c-4e34-4765-8943-aad1ee9f3654" "nginx" "<IP_ADDRESS>:80" outbound|80||nginx.default.svc.k8s.gmem.cc <IP_ADDRESS>:49594 <IP_ADDRESS>:80 <IP_ADDRESS>:49592 - default
[2020-04-29T07:15:44.977Z] "GET / HTTP/1.1" 0 DC "-" "-" 0 0 24104 - "-" "curl/7.67.0" "d203d38c-4e34-4765-8943-aad1ee9f3654" "nginx" "<IP_ADDRESS>:80" outbound|80||nginx.default.svc.k8s.gmem.cc <IP_ADDRESS>:49596 <IP_ADDRESS>:80 <IP_ADDRESS>:49594 - default
[2020-04-29T07:15:44.977Z] "GET / HTTP/1.1" 0 DC "-" "-" 0 0 24104 - "-" "curl/7.67.0" "d203d38c-4e34-4765-8943-aad1ee9f3654" "nginx" "<IP_ADDRESS>:80" outbound|80||nginx.default.svc.k8s.gmem.cc <IP_ADDRESS>:49598 <IP_ADDRESS>:80 <IP_ADDRESS>:49596 - default
[2020-04-29T07:15:44.977Z] "GET / HTTP/1.1" 0 DC "-" "-" 0 0 24109 - "-" "curl/7.67.0" "d203d38c-4e34-4765-8943-aad1ee9f3654" "nginx" "<IP_ADDRESS>:80" outbound|80||nginx.default.svc.k8s.gmem.cc <IP_ADDRESS>:49600 <IP_ADDRESS>:80 <IP_ADDRESS>:49598 - default

Expected behavior
TPROXY mode should work normally.
Steps to reproduce the bug
** Version **
istioctl version --remote

client version: 1.5.1
control plane version: 5f1c6c46fd40655dfe4249a5d288867907fbd704-dirty
data plane version: 1.5-dev (3 proxies), 1.6-dev (1 proxies), 1.7-dev (1 proxies)

kubectl version

Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.12", GitCommit:"a8b52209ee172232b6db7a6e0ce2adc77458829f", GitTreeState:"clean", BuildDate:"2019-10-15T12:12:15Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.10", GitCommit:"575467a0eaf3ca1f20eb86215b3bde40a5ae617a", GitTreeState:"clean", BuildDate:"2019-12-11T12:32:32Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
built from branch release-1.6, installed via istioctl

I'm confused why we trpoxy inbound traffic to listener 15001,  from its name 'virtualOutbound' it should be used for outbound.
in istio 1.5 it worked fine but is broken now.
change port to 15006 (virtualInbound) working:
iptables -t mangle -I OUTPUT 1 -s <IP_ADDRESS>/32 ! -d <IP_ADDRESS>/32     -j MARK --set-xmark 0x539/0xffffffff

Is there any temporary workaround that can be applied for this issue?

@kozelok In our environment we use solving this problem by changing iptable rule generated by istio

@gmemcc I am testing with 1.7.3, and found it is still causing infinite loop. All the traffic is intercepted to 15001 and then envoy sends it out and it is intercepted again to 15001.

@hzxuzhonghu changing target port to 15006 will break the loop, but tproxy mode still not working.  in older versions istio forwards inbound traffic to <IP_ADDRESS>, but now it will send to original dest ip. i thank we should update the iptables rules for tproxy

Yes, i tested it by changing this 15001 to 15006 and also by updating the virtualInbound listener filters with a mark 1337.
-A ISTIO_TPROXY ! -d <IP_ADDRESS>/32 -p tcp -j TPROXY --on-port 15001 --on-ip <IP_ADDRESS> --tproxy-mark 0x539/0xffffffff

And i found that envoy send the traffic to app with original src address, but the connection could not be established. What i see is that envoy has sent out the sync packet, but can not receive the ack.
I am not very familiar with iptables tproxy mode, appreciate if you can help

@hzxuzhonghu  replying packet from workload has been sent out of the network namespace through eth0.
To ensure correct routing, we can use CONNMARK:
iptables  -t mangle -I PREROUTING -m mark     --mark 1337  -j CONNMARK --save-mark
iptables  -t mangle -I OUTPUT     -m connmark --mark 1337 -j CONNMARK --restore-mark

and, to prevent infinite redirecting, additional rule is required:
iptables -t mangle -I ISTIO_INBOUND 5 -p tcp -m mark --mark 0x539   -j RETURN

I will submit a PR later

Thanks very much.

This is fixed in https://github.com/istio/istio/pull/28457. Since this is tracked in a few places, lets consolidate on https://github.com/istio/istio/issues/5679. Thanks!


32bit build test

temporary

Codecov Report

Merging #96 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #96   +/-   ##
=======================================
  Coverage   77.05%   77.05%
=======================================
  Files          43       43
  Lines        2711     2711
=======================================
  Hits         2089     2089
  Misses        495      495
  Partials      127      127

Flag
Coverage Δ

#go
77.05% <ø> (?)

#wasm
69.78% <ø> (?)

Impacted Files
Coverage Δ

association.go
82.52% <0%> (ø)
: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 83dda44...85a2687. Read the comment docs.


Db sizing

Can you confirm that MS is still recommend such small db sizes for each level of Client numbers? ~3mb a client is tiny, these days. What does the telemetry data say the real numbers are?

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

ID: e67ddd45-90df-32cd-3cbe-9e1443b2540f
Version Independent ID: dee7fcb8-a7b7-e5a1-9c04-c113805be0da
Content: Recommended hardware - Configuration Manager
Content Source: sccm/core/plan-design/configs/recommended-hardware.md
Product: configuration-manager
GitHub Login: @aczechowski
Microsoft Alias: aaroncz

Thanks @Garthmj for filing this issue. I'll check with engineering what current data we have on this size.

The long answer is that it depends upon the hierarchy type, the configuration, and the number of clients. (Interesting note, it's generally less for larger environments. In other words, smaller sites have more database usage per client.)
But in short, based on the data, a safe estimate is 10 MB per client
@Garthmj do you want to make this edit?

I made this change, it will publish live tomorrow


execute proposal with sig substrate

LGTM, but we should identify how to fill in that commented out block of code (for parsing the method names from calls directly). Otherwise, we should add a TODO, create a task, and remove the commented block. Also thorough documentation on the execute_proposal method would be appreciated here @saiakilesh. Great work on this PR so far!

Thanks @drewstone!
For now I removed the comments and added a TODO to the function.I also created a task https://github.com/webb-tools/protocol-substrate/issues/150 for it.
I also added another TODO for dealing properly with the nonces since we are not doing any proper checking or incrementation. There is already a task for this on the board https://github.com/webb-tools/protocol-substrate/issues/145


RxBool value change does not trigger UI re-build

Hi, not sure it's a bug or not, does Rx type have different behaviour?
To Reproduce
Steps to reproduce the behavior:
N/A
Expected behavior
RxBool type does not trigger UI changes when modifying its value. RxString does trigger UI re-build (testing purposes )
Screenshots
If applicable, add screenshots to help explain your problem.

Flutter Version:
Flutter 1.24.0-7.0.pre.41 • channel master • https://github.com/flutter/flutter.git
Framework • revision 72267a6cd0 (3 days ago) • 2020-10-31 13:23:02 +0900
Engine • revision<PHONE_NUMBER>
Tools • Dart 2.12.0 (build 2.12.0-3.0.dev)
Getx Version:
^3.15.0
Describe on which device you found the bug:
ex: Pixel 2 - Android. / Iphone 12 PRO Max
Minimal reproduce code
import 'package:get/get.dart';

class BuilderController extends GetxController {

  RxString rxString = ''.obs;
  RxBool rxBool = false.obs;

  void onReady() {
    Future.delayed(Duration(seconds: 5), () {
      rxBool = true.obs;
      rxString.value = 'This does change';
    });
    super.onReady();
  }
}

class BuilderView extends GetView<BuilderController> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Obx(() => Text(controller.isBuilderDone.value.toString())),
      ),
      body: Obx(() => Text(controller.asd.value)),
    );
  }
}

  void onReady() {
    Future.delayed(Duration(seconds: 5), () {
      rxBool.value = true; // <== try this ===========
      rxString.value = 'This does change';
    });
    super.onReady();
  }

You can use:
rxBool.value = true;

Or:
rxBool.toggle();  // A shortcut for flag.value = !flag.value;

Hi guys, thanks for the reply, removing the .obs when changing the value did the trick. I did not even see it.
Thanks again, closing the issue, sorry for the noob mistake!


[dv/common] Move testplan from tools directory to data

I think it makes more sense to have testplan hjson files in dv/data
directory. LMK if you have different thoughts
Signed-off-by: Weicai Yang<EMAIL_ADDRESS>

Prefer to have either dv/data or dv/tools, not both. Going forward we should consolidate all.

Prefer to have either dv/data or dv/tools, not both. Going forward we should consolidate all.

sure, we can discuss this in meeting. Currently in dv/tools there are tool cfg and script. in dv/data mostly are hjson files. maybe we can move dv/data/sim.mk to dv/tools

as discussed in DV meeting, consolidate the dv/data and dv/tools directories as below
dv/tools/dvsim
|- sim.mk
|- tests/
|- testplans/
|- vcs.hjson
|- xcelium.hjson
|- fusesoc.hjson
|- common_sim_cfg.hjson, modes, etc
dv/tools/vcs
|- Cov, tcl, excl files
dv/tools/xcelium
dv/tools/riveira
I also changed formal, lint and syn to have similar directories. @msfschaffner @cindychip PTAL
formal/tools/dvsim <- formal/data/*
lint/tools/dvsim <- lint/data/*
syn/tools/dvsim <- syn/data/*

@rswarbrick just to confirm: this does not help https://github.com/lowRISC/ibex/issues/985, but also doesn't make it worse?

Yep, that's right. Actually we can probably make some progress with those Ibex bugs now, and I don't think this will break anything (doing so is somewhere on the N'th page of my TODO list...)

@imphil, @rswarbrick
If there are no more concerns, is this PR good to go?

Yes, lgtm from my side!

Thanks @imphil @sriyerg
@msfschaffner can you take a look at this PR?

LGTM, thanks @weicaiyang.

Yep, all good from me too. The CI failures are from Verible: it looks like a config file has been renamed but its path hasn't been updated in the Verible configuration?

Yep, all good from me too. The CI failures are from Verible: it looks like a config file has been renamed but its path hasn't been updated in the Verible configuration?

Thanks @rswarbrick. Some recent commits used the old directory structure. Rebased and fixed.


Implement gh bbs2gh inventory-report command for generating Bitbucket Server repo inventory

When customers are planning and preparing their migration, it's really valuable to create a "migration inventory" with key data about all of the repos to be migrated. We recommend doing this in our public docs.
At this time, for Bitbucket Server, we don't have a tool we can recommend for generating this kind of report.
We should build a gh bbs2gh inventory-report command which can generate a report on a customer's Bitbucket Server repos.
It should output a CSV with the following data:

name
project_key
is_archived
pull_requsts_count
last_commit_at

Its interface should:

Require a --bbs-server-url to be specified as an argument
Require a --bbs-pat with the "project read" and "repository read" permissions to be specified as an argument or environment variable
Require a --output-path to be specified as an argument to define where the CSV should be stored
Optionally allow a --bbs-project to be specified to limit the output to repos in one specific Bitbucket Server project

Under the hood, it will need to use the following Bitbucket Server APIs with auto-pagination:

"Get projects" to find all projects, if the command is not limited to a specific project using --bbs-project
"Get repositories for project" to list repos in each project
"Get pull requests for repository" to get the count of pull requests for a repo
"Get commits to get the last commit timestamp for a repo

Example repository API response
{"size":1,"limit":25,"isLastPage":true,"values":[{"slug":"litra","id":1,"name":"litra","description":"A JavaScript library for programatically controlling your Logitech Litra Glow or Logitech Litra Beam light - including CLI tools for quick usage without writing code","hierarchyId":"e9b26cb584a595f3cfa0","scmId":"git","state":"AVAILABLE","statusMessage":"Available","forkable":true,"project":{"key":"OS","id":1,"name":"Open Source","public":false,"type":"NORMAL","links":{"self":[{"href":"https://timrogers-bitbucket.expert-services.io/projects/OS"}]}},"public":false,"archived":false,"links":{"clone":[{"href":"ssh://git@timrogers-bitbucket.expert-services.io/os/litra.git","name":"ssh"},{"href":"https://timrogers-bitbucket.expert-services.io/scm/os/litra.git","name":"http"}],"self":[{"href":"https://timrogers-bitbucket.expert-services.io/projects/OS/repos/litra/browse"}]}}],"start":0}

Tasks

[ ] ...

Dependencies

...

+1 for this functionality 👍
💡 Suggestion: the csv will potentially contain a large number of repos, and in most cases this list will need to be split into batches unless all repos are migrated in one go. With that in mind it would be great to include some more metadata that will make the csv more "reader-friendly", e.g.

repo_description
project_description

If possible, it would also be beneficial to include the (approximate) repo size, as an early indicator of repos that might need to be cleaned up before the migration. At first glance it does not look like this is supported in the BBS API but I might be wrong.
cc @dylan-smith

@samueljmello has built something similar for Manulife https://github.com/mona-actions/gh-bbs-analyzer


[📖] "Edit this page" not found for https://qwik.builder.io/docs/getting-started/

Suggestion
Go to https://qwik.builder.io/docs/getting-started/, click "Edit this page", it will show:
"The 'BuilderIO/qwik' repository doesn't contain the 'packages/docs/src/routes/docs/getting-started/index.mdx' path in 'main'. "

Duplicate of #3546


feat: [FC-7] message encryption

Video demo:
https://github.com/saigontechnology/rn-firebase-chat/assets/105196859/95dc464e-cefc-48a9-972c-f52b64dfd0e8

Algorithms AES-256-CBS

AES-256-CBC:
•	Performance: Similar to AES-256 (slowest).
•	Typical Throughput: Lower (140-160 cycles/byte).
•	Chaining Mechanism: Uses CBC mode, enhancing security by ensuring that identical plaintext blocks produce different ciphertext blocks.
•	IV Requirement: Requires a unique and random IV for each encryption operation.
•	Use Case: Suitable for highly sensitive data requiring maximum security with added protection against pattern analysis.
Throughput will calculate base on:

More example: AES_performance


potplayer symlinked persisting extension folder spelled wrong

the names of both the symlink and the folder it points to in persist are spelled wrong, so the folder that is used is getting overwritten every update

#3056

added relevant folders to persist (note that "Extention" is indeed not my typo)

The folder name is correct. Or last it was on manifest addition.

I just checked and PotPlayer is definitely only looking in the folder with "Extension" spelled correctly

i edited my reply to include more info, not sure if github notifies of edits to issues


Feature Request - Automatically update groups after edit

Hi,
been using the dashboard for a while. Something that's been bothering me for a while is, when I add/edit/delete entries in a (system) group, I have to manually dis- and enable them in the dashboard settings for the changes to take effect.
Just checked, and even a forced reload of the dashboard inside my browser does not update the groups, so it seems to be on Fenrus' side.
Thanks!

what version?  0.5.0 and below (ie the node version) or 0.9.x (the dotnet version)

Hi,
sorry for the delay in answering.
It's the old version, in the meantime I switched to the rewrite & there it works.
Closing the issue then. :)


How do you get the XML feed?

Hi I got a similar stack and would like to build myself a feed, could you share your magic?

Hi, thanks for checking out the site.
I'm using gatsby-plugin-feed to generate the feed. You can find my configuration in my gatsby-config.js file.


Update example Image

This image includes all of the current icons in the examples directory.

I realize you may not want to have a huge long image like this in the readme, but it might be worth putting into a separate readme in the examples folder.  I'm happy to change that if you'd like.  Or just close this, it won't hurt my feelings.

That is a huge image! But it is up to date with the current supported ones so there is value here. Might get some other opinions on how we might want to handle it in the future. Either way thanks for the pr.
//cc @DanBrooker

A updated image is great, it's a little too large for the main readme, maybe shorten it a little

I can take out some of the duplicates (for example, 3ds.mcr, and 3ds.ms), but I think the result will still be very large.  Perhaps a better solution is to create a new README.md inside the examples/ directory and put this image in that document?

how bad does it look if we compress the image?
I do like the idea of having an examples.md that we just reference.

Compress in what way?  I ran it through tinyPNG already.  Or do you mean shrink its size?

shrink its size

@ckross01 : Personally, I think it'd be better to only show a selection of icons in the main readme, and have a separate document for displaying each file icon (ordered alphabetically).
I don't believe it's pertinent to have every icon visible to the casual reader when they first open the package, particularly not when there're now so many icons available.

:shipit: :+1:

@IanVS I'm closing this for now... there're simply too many icons in this package to show them all in one image (and several more have been added since this PR was filed, and many more will continue being added in future...) Sorry. :(

Yeah no problem, I totally get it.  The current one is enough to give the idea.


feat: support release report

Codecov Report

Merging #786 (b327a31) into release-next (15c6641) will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff              @@
##           release-next     #786   +/-   ##
=============================================
  Coverage         52.12%   52.12%
=============================================
  Files                46       46
  Lines              1224     1224
  Branches            257      257
=============================================
  Hits                638      638
  Misses              586      586


conformance: blob deletion tests do not take in to account deletes disabled

Blob deletion can return 405 Method Not Allowed: https://github.com/opencontainers/distribution-spec/blob/master/spec.md#on-failure-method-not-allowed
This does not seem to be represented in the blob deletion conformance tests: https://github.com/opencontainers/distribution-spec/blob/master/conformance/09_blob_delete_test.go as they are looking for 202 and then 404 respectively
Expected Results

First request returns a 405 because deletes are disabled: https://github.com/opencontainers/distribution-spec/blob/38956df5d3957ab35785c608f8cf715584f08a8d/conformance/09_blob_delete_test.go#L13
Second request allows for a 200 since the blob was never deleted: https://github.com/opencontainers/distribution-spec/blob/38956df5d3957ab35785c608f8cf715584f08a8d/conformance/09_blob_delete_test.go#L20

Current Results

@pmengelbert @jdolitsky thoughts?

@vbatts @markphelps This is addressed in our PR #123  which is currently open--registries will be able to disable tests that involve deletion.

Sounds good to me! Feel free to close


Windows executable?

Describe the bug
Trying Hanami 2.0 - when it is installing files with bundler.install!  from cli/commands/gem/new.rb line 57
cli/bundler.rb line 149-157 when searching for bundle command
`
def which(cmd)
# Adapted from https://stackoverflow.com/a/5471032/498386
ENV["PATH"].split(File::PATH_SEPARATOR).each do |path|
exe = fs.join(path, cmd)
return exe if fs.executable?(exe) && !fs.directory?(exe)
end
end
`
on windows fs.executable? returns false even if the bundle command exists
in dry/files/file_system.rb 340-345
`
def executable?(path)
file.executable?(path)
end
This causes the system_call in hanami/cli/bundler to be
"install --jobs=12 --quiet --no-color"
and not
`
"bundle install --jobs=12 --quiet --no-color"
Resulting in the following error
"ERROR: Access to the registry path is denied.\nERROR: Access to the registry path is denied.\n\Microsoft was unexpected at this time."
My environment

Affects my production application: YES/NO
Ruby version: ...ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x64-mingw-ucrt]
OS: Windows

@dsisnero by https://github.com/hanami/cli/pull/72 should have fixed the problem.
The bugfix will be released with the next version of Hanami: 2.0.3.