Multiple Arbitrary File Write vulnerabilities

A specially crafted malicious .unitypackage can save or overwrite arbitrary files on the system when extracted with unitypackage_extractor due to several vulnerabilities. This could be used to install malware or overwrite important files.
tarfile.extractAll
https://github.com/Cobertos/unitypackage_extractor/blob/a05765abcd23884df619f370d471c17314ec6445/unitypackage_extractor/extractor.py#L16-L17
Please note the warning in TarFile.extractall's docs: It doesn't ensure that files aren't created outside of the specified path. Here's a proof of concept:
touch /tmp/badfile
# Make a tarfile with an absolute path
tar -cf bad.tar -PC / /tmp/badfile
rm /tmp/badfile
python -c "import tarfile; tarfile.open('bad.tar').extractall('.')"
ls /tmp/badfile # It exists again!

When fixing this please keep in mind that tarfiles can also contain symlinks and other weird things. So maybe this approach might help to mitigate this issue.
No validation of "pathname" in .unitypackage
https://github.com/Cobertos/unitypackage_extractor/blob/a05765abcd23884df619f370d471c17314ec6445/unitypackage_extractor/extractor.py#L28-L36
This very similar to the above. If a specially crafted .unitypackage has a modified pathname file in it that contains an absolute path, then the asset file will be moved to that location. This issue exists regardless of whether the user specifies an extraction output path or not, as os.path.join() will ignore its first argument when the second argument is an absolute path (tested on Windows and Linux).
As above the path should be validated. I don't think any valid .unitypackage will have absolute paths in it (in the tar itself, or in the pathfiles) so it would make sense to abort extraction if this is the case and inform the user.

Thank you for the link to tarsafe, I will give that a look.
For the second vulnerability, you think it would just be enough to skip w/ notify versus abort? I like the idea of it at least being able to continue if one pathname is malformed.
Thank you for the submit

At the end of the day, I don't think it really matters whether it'll skip or abort. I just have a personal preference for abort here (of course notifying the user why it aborted) and not extracting anything, because I don't see any reason why Unity (or seemingly rarely used external stuff) would generate them. If for some reason there'd be a lot of .unitypackage files out there that had invalid entries in them (e.g. if, say, Unity 1.0 stored some metadata files under absolute paths or something) I'd choose skipping, but since this is entirely unexpected (and a potential security issue) I'm going for aborting.

Aight, should be fixed, added 2 tests for the pathname writing outside the extract path as well as using tarsafe now.
Let me know if https://github.com/Cobertos/unitypackage_extractor/pull/15 looks good


proto: Merge typed nil source panic after v1.5.0

What version of protobuf and what language are you using?
github.com/golang/protobuf v1.5.0
google.golang.org/protobuf v1.26.0

What did you do?
Simple reproducer:
// pb files served on etcd repo
func TestProtoMerge(t *testing.T) {
	dst := &etcdserverpb.AuthDisableRequest{}

	proto.Merge(dst, nilAuth())
}

func nilAuth() *etcdserverpb.AuthDisableRequest {
	return nil
}

What did you expect to see?
I'm not very sure whether this is an intended behavior. Current situation is:
proto.Merge(dst, nil) // this one will always panic

proto.Merge(dst, (*T)(nil)) // this one will panic after v1.5.0 or by google.golang.org/protobuf v1.26.0

I think the reason is this CL: https://go-review.googlesource.com/c/protobuf/+/300869
Background of this CL is trying to support the aberrant message and the proto.Merge turns to use marshal and unmarshal to accomplish to work (for performance reason?).
But this happens the case when there's a "typed nil pointer" fall into interface and then the proto.Merge behavior is different.
Understand there's no guarantees on third party code generators but what's the expected behavior here?
We shouldn't allow nil as a source? Either a typed nil as a source? Especially the later case is probably useful:
proto.Merge(dst, req.Content)

that we don't need to do extra nil check for Content.
What did you see instead?
As illustrated.
Anything else we should know about your project / environment?
Nope.

🤔 I think the case of having a typed proto.Message nil could be reasonably useful, considering that sub-messages that do not appear on the wire are typed nils.
I suppose, we’re handling that case more directly at the point where it is considered as a field, in that case not expecting one to use proto.Merge on a submessage itself, but that seems like something potentially useful to do at times. Though, if the caller has the typed nil directly, rather than through an interface, then a question can arise of where to efficiently test that nil value. Where that would be is before putting it into the interface and losing the ease of just if m != nil { … }.

Though, if the caller has the typed nil directly, rather than through an interface, then a question can arise of where to efficiently test that nil value. Where that would be is before putting it into the interface and losing the ease of just if m != nil { … }.

Thanks for the quick input! I think the at least for legacyMerge case, what about using in.Source.IsValid check first?
Seems won't introduce significant extra overhead.

Understood, thanks for your help!


Unclear how to configure Python environment for Quarto template

Hi all, I started using the Quarto DIME template and had some trouble getting the reticulate and Python packages to work on my machine. I ended up deleting the sections out from my template and once I did, the Quarto template finally compiled.
I think this should be excluded from the default template or commented out. Python package management is notoriously tricky to work with.
I'm opening up an opinionated PR to propose deleting the sections, but I imagine you all may have better ideas
Edit: Here is is https://github.com/dime-worldbank/quarto-dime-theme/pull/11

I like option (2). I think giving instructions to setup Python in R is just too difficult and bespoke.

Keep the lines of code in the template file but have them all be commented out. That will make the file render for pure R users, but some pointers are there for someone needing Python code.

Option (4), keeping a separate Python template in the _alt folder, is certainly ideal! But that might be more work than you all can do right now.

Ok, lets go with (2).
@geoffreyyip , do you want to update the PR with this so that you get the contribution credits?
If you do not have time, then I can do it.

Thanks for testing things @geoffreyyip and reporting back and to @kbjarkefur for laying out the options.
I agree with option 2 for now. I have a bit of capacity today to look at a better way to integrate Python chunks for users who may be unfamiliar with the use of Python environments. Will report back :)


QASM and its implementation seem to have bugs.

I have two simple QASM files:
//test1.qasm
OPENQASM 2.0;
include "qelib1.inc";

qreg q[1];
h q;

//test2.qasm
OPENQASM 2.0;
include "qelib1.inc";

qreg q[1];
u2(0,pi) q;

Let's pass test1.qasm to this program to run first, then test2.qasm.
#include <iostream>
#include <cassert>
#include "qpp.h"

int main(int argc, char** argv)
{
    assert (argc == 2);
    using namespace qpp;

    QCircuit qc = qasm::read_from_file(argv[1]);
    QEngine q_engine{qc};
    q_engine.execute();

    std::cout << disp(q_engine.get_psi()) << '\n';
}

Running test1.qasm produces this result:
0.707107
0.707107

and test2.qasm this result:
-0.707107i
-0.707107i

Logically, however, we should expect the same results because both the QASM specification and the Quantum++ implementation, which has faithfully followed the spec, define this:
// Clifford gate: Hadamard
gate h a { u2(0,pi) a; }

I did some analysis on the issue. Using Hadamard gate directly like the one in the test1.qasm is always correct because the H gate is hard-coded correctly in the Quantum++, bypassing the definition in the qelib1.inc.
So, the problem seems to be twofold. The QASM spec is wrong. Then, the implementation leads the API users to an illusion that the H gate is equivalent to gate h a { u2(0,pi) a; }. But, in fact, it does not use that definition at all.
By the way, I use this QASM paper as my reference.

This is an excellent point which I was not at all aware of, thanks! I frankly don't know what to do here. Most of the time the minus sign in front of the "true" Hadamard doesn't make a difference, but it may, e.g. in a case of a CTRL-Hadamard. I am tempted to leave it as is (and document it), so it uses the "true" Hadamard from the Q++. Other option is to just add a minus sign when parsing the QASM, so h behaves the way it's defined in QASM. I think asking QASM to change their definition is something that may take a while; any suggestions?

IBM (Qiskit) is presumably the leading user of the QASM. If the fundamental H gate had been wrong, that would have affected thousands of users for a few years. I couldn't believe it. So, I take a look at the Qiskit QASM implementation. It turns out their code does not match their QASM specification either, the code being correct.
The root cause is not the gate h a { u2(0,pi) a; }, instead the U gate. The Qiskit uses the matrix here. It is drastically different from that in the spec.
Using the information of that matrix, I change the Quantum++ UGate::evaluate() in the ast.h and make the matrix look like this:
        cmat u{cmat::Zero(2, 2)};
        u << cos(theta / 2) ,
            -(sin(theta / 2)) * std::exp(1_i * lambda),
            sin(theta / 2) * std::exp(1_i * phi),
            cos(theta / 2) * std::exp(1_i * (phi + lambda));

Now, the u2(0,pi) q; works like a correct H gate. The new matrix is still unitary. So, I'd like to suggest you think about it.
Well, the U gate change would affect pretty much every single gate in the qelib1.inc. I am not sure if all other gates could pass the unit tests.

@DevelopDaily Fixed, now all gates in include/qasm/preprocessor.h are defined as they are in Qiskit, and the u3 (u matrix in include/qasm/ast.h) is defined also as in Qiskit (as you mention above).

Here is a little piece of useful information.
I stated earlier that the Qiskit implementation is "drastically" different from that in the spec. As a matter of fact, my statement was inaccurate.
I just realize the matrix in the spec is not that different. If we divide the matrix by exp(-i * (phi + lambda) / 2), we get the matrix that is used by the implementations in both Quantum++ and Qiskit now. That is perfect because the division by that factor has no observable effects.

@DevelopDaily Thanks! So I hope that the fixes are also OK?

Definitely, the fixes are perfect. I have been using them since they were released. Thanks.


[9.x] Support preloading assets with Vite

Preloading is a mechanism that informs the browser which assets are required for the current page load. You can read more about preloading on web.dev.
Using this PR on a real-world application increased the Lighthouse score from 59 to 90. These were the average results from a controlled environment. Your mileage may vary, but this PR should generally work for the 95% usecase (IMO).
Preloading is not something to opt into. With this PR it becomes the default behaviour for applications using Vite, however the middleware does need to be applied manually if you want to have the preloading headers sent with the initial Laravel HTTP response.
I'll outline the problem we are looking to solve: for SPA applications building with Vite, or any modern build tool using code splitting, the resulting assets look similar to the following:

app.123.js
Welcome.123.js
Login.123.js
Register.123.js
...

Each of these top-level "pages" will often have imports:

Login.123.js

TextInput.123.js
InputLabel.123.js
PrimaryButton.123.js

"Code splitting" like this is a performance optimisation so you load only the JavaScript required for the current page, which makes the initial page load faster.
Currently in Laravel, when loading the very first page of an application, we specify the following entry point:
@vite(['resources/js/app.js'])

This results in the following waterfall of requests:

/login.html...
app.js...
Login.js, TextInput.js, InputLabel.js, PrimaryButton.js...

This waterfall of requests is, of course, less than ideal. Working through this waterfall:

The browser must first download the HTML and parse it to know what CSS and JavaScript the document has specified. Our document has specified "app.js", so the browser proceeds to fetch it.
Once app.js js fetched and parsed, the JavaScript kicks in an informs the browser that it should be loading the Login.js file and it's imports.
The browser begins fetching, parsing, and executing the required imports.

Possible solutions are:

Bundle everything into a single app.js with "eager globing"
Preloading

Before I dig into these solutions, let me post the results of my Lighthouse performance testing against a real-world application. These tests were run against "mobile".
I acknowledge that this is a single application and need further verification.

Lighthouse screenshots
Although all these screenshots are of the same page, I found similar results across other pages with the application.
Preloading w/ Code split + vendor split

Preloading w/ Code split

Not Preloading w/ Code split + vendor split

Not Preloading w/ Code split

Preloading w/ Eager glob + vendor split

Preloading w/ Eager

Not preloading w/ Eager glob + vendor split

Not preloading w/ Eager glob

Although eager globing does solve the waterfall issue, I believe that the Vite setup for Laravel should also support code splitting the best it can. Preloading is utilised by Vite itself when doing things "the Vite way". This is the mechanism that all code splitting usually works. Additionally, if you utilise vendor splitting with eager globing, you are back to the original waterfall problem, as the app.js has to be fetched and parsed before vendor.js is requested and parsed.
With this PR in place, we are able to, at best, remove the waterfall entirely for all configurations:

/login.html, app.js, Login.js, TextInput.js, InputLabel.js, PrimaryButton.js...

and at worst, the non-SPA waterfall:

/login.html
app.js, Login.js, TextInput.js, InputLabel.js, PrimaryButton.js...

This PR works by adding "preload" <link tags into the HTML for any asset required by the current page and if used the middleware will send preload Link:  headers to the browser.
Preload tags are generated for the JavaScript and CSS entry points and their imports.
To take full advantage of this, applications do need to specify the page / chunk they are currently trying to load in the Vite tag:
@vite(["resources/js/Pages/{$page['component']}.vue"])

Applications do not have to update the Vite directive may still find this PR beneficial, as it can send the headers with the document instructing the browser to start fetching the app.js and any additional CSS it imports.
With that in mind, preloading is beneficial to all configurations: eager glob, vendor split, code split, etc.

Note Applications that are vendor splitting will still need to add the app.js into the Vite directive:

@vite([
    'resources/js/app.js',
    "resources/js/Pages/{$page['component']}.vue",
])

Browser support
For CSS files, we have great browser support.
For JavaScript "Module preloading" unfortunately out of the main browsers Firefox and Safari do not currently support this feature. According to caniuse 73% of browsers in use globally support this feature. Their stats are provided by statscounter.
A lot of JavaScript eco-system is relying on this feature and we are all waiting for Firefox and Safari to roll the feature out.
The good news is that this feature has no negative impacts on un-supprted browsers. They simply ignore the tag and move on with their existing behaviour.
However, because CSS preloading is supported, applications will still likely get a boost in Firefox and Safari.

@timacdonald
How would you picture doing this in an Inertia app? Do you put this in the main layout? Having trouble picturing it.
@vite(["resources/js/Pages/{$page['component']}.vue"])

That is correct. I would suggest we make that the default for Inertia across the started kits.
Take a fresh Breeze application for example:
Before
LAYOUT
@vite('resources/js/app.js')

HEADERS
n/a

HTML
<link rel="stylesheet" href="http://<IP_ADDRESS>:8000/build/assets/app.f31a18ec.css" />
<script type="module" src="http://<IP_ADDRESS>:8000/build/assets/app.9bf14e2c.js"></script>

Waterfall

login.html
app.js, app.css
Login.js, PrimaryButton.js, TextInput.js, ApplicationLogo.js

After
LAYOUT
@vite("resources/js/Pages/{$page['component']}.vue")

HEADERS
Link: <http://<IP_ADDRESS>:8000/build/assets/app.f31a18ec.css>; rel="preload"; as="style",
      <http://<IP_ADDRESS>:8000/build/assets/Login.5e7e8a19.js>; rel="modulepreload",
      <http://<IP_ADDRESS>:8000/build/assets/app.9bf14e2c.js>; rel="modulepreload",
      <http://<IP_ADDRESS>:8000/build/assets/PrimaryButton.62d440f3.js>; rel="modulepreload",
      <http://<IP_ADDRESS>:8000/build/assets/TextInput.d97ddb4c.js>; rel="modulepreload",
      <http://<IP_ADDRESS>:8000/build/assets/ApplicationLogo.fc364aed.js>; rel="modulepreload"

HTML
<link rel="preload" as="style" href="http://<IP_ADDRESS>:8000/build/assets/app.f31a18ec.css" />
<link rel="modulepreload" as="script" href="http://<IP_ADDRESS>:8000/build/assets/Login.5e7e8a19.js" />
<link rel="modulepreload" as="script" href="http://<IP_ADDRESS>:8000/build/assets/app.9bf14e2c.js" />
<link rel="modulepreload" as="script" href="http://<IP_ADDRESS>:8000/build/assets/PrimaryButton.62d440f3.js" />
<link rel="modulepreload" as="script" href="http://<IP_ADDRESS>:8000/build/assets/TextInput.d97ddb4c.js" />
<link rel="modulepreload" as="script" href="http://<IP_ADDRESS>:8000/build/assets/ApplicationLogo.fc364aed.js" />
<link rel="stylesheet" href="http://<IP_ADDRESS>:8000/build/assets/app.f31a18ec.css" />
<script type="module" src="http://<IP_ADDRESS>:8000/build/assets/Login.5e7e8a19.js"></script>

Waterfall

login.html
app.js, app.css, Login.js, PrimaryButton.js, TextInput.js, ApplicationLogo.js

However with the headers, the browser is able to prioritise and connect etc. in advance of parsing the DOM.

In your after example. How do we actually get $page['component] to the layout? And doesn't that page component change in between page navigations? Is the entire layout re-rendered on those navigations?

In your after example. How do we actually get $page['component] to the layout?

$page['component] is injected by Inertia for us. Don't need to do anything to make it work.
I believe it is handled here: https://github.com/inertiajs/inertia-laravel/blob/540b953ec383364264f9bd633849db16560a4461/src/Response.php#L99-L110

And doesn't that page component change in between page navigations?

It does, but future navigations are done in SPA land and the blade layout is not re-rendered.
@php
    logger()->info('rendering blade');
@endphp

You only get one log statement on initial load. Future navigations do not log.
Additionally, what I am proposing we do on initial load is what already happening for us on subsequent navigations, if the components required for the page have not already be preloaded before...
https://user-images.githubusercontent.com/24803032/195722527-270e34ff-03c1-40b2-8fbe-e5a568da10c0.mov
If we are keen on this in general, I would also like to propose that we optimize future navigations as well - but I feel that is fine for a different PR, which is why it isn't included here. The full story I have in my head is that we remove the waterfall from the initial load, but then in the background we offer the option to preload all (or some) of the sites assets, which will mean that even on future navigations, the only request to the server is the Inertia request.

Just some more info on this one:  these link headers are what would power the recent “Early Hints” feature in some caches.
Cloudflare’s implementation is based on these headers.

Jetstream PR: https://github.com/laravel/jetstream/pull/1169
Breeze PR: https://github.com/laravel/breeze/pull/196

Hi there. We fixed the failing tests on 9.x which are causing this PR to fail as well. Can you please rebase your PR with 9.x and mark this PR as ready for review when all tests are passing again? Thanks

Is there any way to disable this ?
it preloads every thing, even modules that 99% of users will most likely never need

@lk77 I also get warnings in the console that scripts were preloaded that haven't been used later on. I was able to disable it using the following line in a service provider's boot method:
ˋˋˋphp
Vite::usePreloadTagAttributes(fn () => false);
ˋˋˋ

If you can provide a reproduction repository that shows assets being preloaded that are not used by the current page, I'm happy to look into this for you.
I'm unable to replicate the issue myself.

@timacdonald i don't see how you can know in advance if the asset will be needed or not, for me it's more business logic than anything.


unity: Calling Shader.WarmupAllShaders() crashes renderdoc

Using Unity, a function that ensures all shaders have been compiled, crashes if renderdoc is injected (ie if the app is run from renderdoc).
Repro:
http://loopit.dk/ref/renderdoc_warmup_all_shaders.zip
Creating a unity-scene with a single script that contains e.g.
public class warmupscript : MonoBehaviour {
void OnEnable() {
Shader.WarmupAllShaders();
}
}

tested on amd-hardware, win8, unity4.3.

I think this change should fix the issue. I don't know if you're compiling renderdoc yourself - if not then the nightly build will include it in ~10 hours.
The problem seemed to be some very oddly formatted DXBC (DX bytecode) blobs, which my parsing was choking on. I had a look and other DXBC parsers online - wine and HLSL-Cross-Compiler would also fail on this input, so I must admit I'm a little curious how it got like that. The shader in question was using a "UnityFFVertex" cbuffer if that narrows it down at all. I don't know if some odd transformation or compilation went on.
Hopefully it will all work now - the test case you provided (thank you for that!) certainly works now for me - but the joy of reverse engineering means that it might break some other time down the road :smile:.

Fix verified :) https://twitter.com/pixelmager/status/560041441855279104


ci: notice file issue #626 updates

Current behavior
Currently the NOTICE file is out of date with no automated way to update that easily.
Proposed changes
Added job to all.yml to run the parseCrates.sh script. It will check if the notice file needs updating and fail if it's out of date. Cargo-deny can be piped into the parseCrates.sh file and it will create an updated NOTICE file in a similar format to the current version.
Checks

[X] All commits in this Pull Request are signed and Verified by Github.
[X] All commits in this Pull Request follow the Ockam commit message convention.
[X] I accept the Ockam Community Code of Conduct.
[X] I have accepted the Ockam Contributor License Agreement by adding my Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam-contributors repository. The easiest way to do this is to edit the CONTRIBUTORS.csv file in the github web UI and create a PR, this will mark the commit as verified.

Hello @kat-coding just wanted to check in on this PR, are you still working on it?

@metaclips I pulled this PR branch locally and made some changes but I'm not sure how to push them to this PR? Should I push to my own fork and make a new PR?

@metaclips I pulled this PR branch locally and made some changes but I'm not sure how to push them here? Should I push to my own fork and make a new PR?

@Wryhder yes please, create a new PR.


iOS 7.1

Hi,
I'm building with Xcode 5.1.1 targeting iOS 7.1, any settings that were created previously throw the following:
Cannot receive object from encrypted data storage:
*** -[NSKeyedUnarchiver initForReadingWithData:]: incomprehensible archive
Any ideas how to save them?
Thanks

Try to clean original nsuserdefaults before using secure version. Just delete the app on simulator or you device.

i think library not working on ios 7.1, you should explain that on readme..


SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=localhost.localdomain [<IP_ADDRESS>] input="MAIL<EMAIL_ADDRESS>

It appears that smtp-conneciton does not wait for the headers and triggers some kind of spam block within Exim4. Below is the basic code I'm trying to execute:
var oSMTPConnectionModule =  require("../andris9-smtp-connection/src/smtp-connection");
	var oSMTPConnection = new oSMTPConnectionModule();
	oSMTPConnection.connect();
	oSMTPConnection.send(
		{
			from<EMAIL_ADDRESS>			,to<EMAIL_ADDRESS>		}
		,'this is a test'
	)

And Exim4 logs show::
2015-12-11 23:19:42 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=localhost.localdomain [<IP_ADDRESS>] input="MAIL<EMAIL_ADDRESS>2015-12-11 23:23:19 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=localhost.localdomain [<IP_ADDRESS>] input="MAIL<EMAIL_ADDRESS>

The comment here might help: http://stackoverflow.com/a/2264697/913223

This happens when you call connection.send before waiting for the connection.connect and/or connection.login callbacks to return


Allow using variables as part of path and args values in terminal settings

Using Terminal profiles introduced in 1.55 (via #45444) I tried to use system variables as part of path and args values but w/o success.
Example for path:

this one works:

"terminal.integrated.profiles.windows": {
        "Yet Another PowerShell": {
            "path": "c:\\Users\\Piotr\\AppData\\Local\\Microsoft\\WindowsApps\\pwsh.exe"
        }
}

this one does not work - it's not even listed on the list of available profiles:

"terminal.integrated.profiles.windows": {
        "Yet Another PowerShell": {
            "path": "%LOCALAPPDATA%\\Microsoft\\WindowsApps\\pwsh.exe"
        },
}

Same thing is observed if variable is used as part of value of args. Following configuration:
"terminal.integrated.profiles.windows": {
        "Yet Another PowerShell": {
            "path": "c:\\Users\\Piotr\\AppData\\Local\\Microsoft\\WindowsApps\\pwsh.exe"
            "args": [
                "-noexit",
                "-file",
                "%APPDATA%\\PowerShell\\oh-my-posh.ps1"
            ]
        }
}

fails with error:
The terminal process "c:\Users\Piotr\AppData\Local\Microsoft\WindowsApps\pwsh.exe '-noexit', '-file', '%APPDATA%\PowerShell\oh-my-posh.ps1'" terminated with exit code: 64.

This is supported but using a different cross-platform syntax:
"terminal.integrated.profiles.windows": {
        "Yet Another PowerShell": {
            "path": "${env:LOCALAPPDATA}\\Microsoft\\WindowsApps\\pwsh.exe"
        }
}

The %VAR% syntax may work but only if your shell resolves them, VS Code will not by design.
You can read more about the variables at https://code.visualstudio.com/docs/editor/variables-reference

Created https://github.com/microsoft/vscode-docs/issues/4661 to add to the documentation

This example still does not work, though:
        "tmux test": {             "path": "tmux",             "args": [ "new-session", "-A", "-s", "${workspaceFolderBasename}" ]
The session ends up being named "${workspaceFolderBasename}" instead of using the name of the folder.

@dhgsg I'll look into it in the similar sounding https://github.com/microsoft/vscode/issues/126066. Can you post that example with machine information there? (OS, version, remote info if any, etc.)

@dhgsg you might also be seeing https://github.com/microsoft/vscode/issues/115560

Both of those look like they are related to what I see, thanks.


For API Deployments

We've had a few projects recently that use rails API-only. Since rails-api is merged into rails (still coming soon), and your guides now have recommendations in regards to API specs, it might be worthwhile to add some flags to suspenders to automate those types of projects.
Would that be in-scope for suspenders?

I would love it if you could use Suspenders to create an API-only app. An API app is more than just creating a Rails app with --api-only, though -- it's also the tools that help you build that API. And as far as I know, we have yet to come to agreement on what tools we would want (although I'm pretty sure those of us that have been on projects involving APIs have opinions).
So what I think we need first is to decide on a core set of tools. We discussed some of that in https://github.com/thoughtbot/guides/pull/365.
Internally, we create a card in a special Trello board we reserve for project experiments, and someone will try out a tool on a project for a while and report back later on whether the experiment was a success or failure. We probably need to go through some of the options that were mentioned in the PR above and do just that.

As stated in https://github.com/thoughtbot/suspenders/issues/706, after https://github.com/thoughtbot/suspenders/pull/676, we'll be able to solve this with generators, which might live in a separate extension project. Will close this issue, and we can continue discussing in 706. Thanks!

It sounds like JSON-API is the API Spec of choice for Thoughtbot then. Is that correct?

It sounds like JSON-API is the API Spec of choice for Thoughtbot then. Is that correct?

Replied in https://github.com/thoughtbot/suspenders/issues/706#issuecomment-220165560.

Maybe a dumb question, but can you explain what you mean by being able to solve this with generators?

Maybe a dumb question, but can you explain what you mean by being able to solve this with generators?

See PRs introducing behavior as generators:

https://github.com/thoughtbot/suspenders/pull/767
https://github.com/thoughtbot/suspenders/pull/676


can't connect

Error
Error:
   0: An error occurred during the proxy handshake procedure
   1: The proxy received `CONNECT mail.google.com:443 HTTP/1.1` (179 additional bytes not shown), which looks like an HTTP request. Please ensure that you have properly configured the proxy as a SOCKS proxy and not an HTTP proxy.

Metadata

key
value

Version
0.1.0

OS
Windows 10 Enterprise

Command
dispatch -d start <IP_ADDRESS>

SpanTrace

SpanTrace:
   0: dispatch::socks::handle_version_error
           with self=SocksHandshake { reader: ReadHalf(PollEvented { io: Some(TcpStream { addr: <IP_ADDRESS>:1080, peer: <IP_ADDRESS>:62620, socket: 1752 }) }), writer: WriteHalf(PollEvented { io: Some(TcpStream { addr: <IP_ADDRESS>:1080, peer: <IP_ADDRESS>:62620, socket: 1752 }) }), dispatcher: WeightedRoundRobinDispatcher(Mutex { data: WeightedRoundRobinDispatcherInner { ipv4: State { addresses: [WeightedAddress { ip: <IP_ADDRESS>, weight: 1 }], address_idx: 0, count: 0 }, ipv6: State { addresses: [], address_idx: 0, count: 0 } } }) } err=InvalidVersion(67)
             at C:\Users\Norbi\.cargo\registry\src\github.com-1ecc6299db9ec823\dispatch-proxy-0.1.0\src\socks.rs:93
   1: dispatch::server::handle_socket
           with socket=PollEvented { io: Some(TcpStream { addr: <IP_ADDRESS>:1080, peer: <IP_ADDRESS>:62620, socket: 1752 }) } dispatcher=WeightedRoundRobinDispatcher(Mutex { data: WeightedRoundRobinDispatcherInner { ipv4: State { addresses: [WeightedAddress { ip: <IP_ADDRESS>, weight: 1 }], address_idx: 0, count: 0 }, ipv6: State { addresses: [], address_idx: 0, count: 0 } } })
             at C:\Users\xxxx\.cargo\registry\src\github.com-1ecc6299db9ec823\dispatch-proxy-0.1.0\src\server.rs:19

Backtrace

Backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: BaseThreadInitThunk
  24: RtlUserThreadStart

You need to configure the proxy created by dispatch as a SOCKS proxy, and not an HTTP(s) proxy.
On this guide: https://imgur.com/pZjcb2A/ you need to enter the address in the "Socks" field and not the "HTTP" field.


[HOLD for payment 2023-10-05] [$500] Web - Focus Border is not disappearing on Click

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

Action Performed:

Open chat, hover over a chat to get popup with menu items.
Use Tab/f11 to navigate to that element.
Once it's on Focus click on it, Click multiple times, Click on neighbouring elements,

Expected Result:
Border should be disappeared after clicking
Actual Result:
Border is not disappeared even clicking
Workaround:
Unknown
Platforms:

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

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/17c795e5-51cc-4b22-836b-467bc69169c2
Expensify/Expensify Issue URL:
Issue reported by: @Charan-hs
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693035839221489
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0165692f1106821d38
Upwork Job ID:<PHONE_NUMBER>359552512
Last Price Increase: 2023-09-12
Automatic offers:

DylanDylann | Contributor | 26739286
Charan-hs | Reporter | 26739289

I am not sure if this is an error because you see as soon as you move the mouse out of the message the circle goes away, right?

Not overdue. This was just triaged, Melv.

@DylanDylann I think document.activeElement can be used only in index.website.js files, so this should be a separate function or maybe is another way to blur the active element?

e.preventDefault()
As my first solution, we can remove the e.preventDefault()

@ArekChr
I just tested on the Desktop and saw that document.activeElement.blur(); work well as below video
https://github.com/Expensify/App/assets/141406735/0d1c3bc2-3912-4b0f-9456-c254d6093f52
So that, If we come up with  this solution we need to define a new function for native and web/desktop separately

Proposal
Please re-state the problem that we are trying to solve in this issue.
Focused outline is not dismissed on click
What is the root cause of that problem?
In
https://github.com/Expensify/App/blob/6b1a6679042c4fa9bb628360e028f93a5f27b2f2/src/components/BaseMiniContextMenuItem.js#L56
We have e.preventDefault() which prevents the default behavior of blurring and transferring the focus to the clicked target element, which makes it preserve the previously focused element.
In first place the e.preventDefault() was added to avoid the composer being blurred when we click on the emoji inside mini context menu. which was introduced here https://github.com/Expensify/App/pull/24252 aiming to solve https://github.com/Expensify/App/issues/20079
What changes do you think we should make in order to solve the problem?

we should call e.preventDefault() only if the focused element is not an input. this will make sure we fix this issue without re-introducing https://github.com/Expensify/App/issues/20079
It will be something like this.
onMouseDown={(e) => {
     if (!['TEXTAREA', 'INPUT'].includes(DomUtils.getActiveElement())) { return; }
     e.preventDefault()
}}

Since we are using DomUtils.getActiveElement it won't be necessary to separate the files.
https://github.com/Expensify/App/blob/57b76067cd3d7b59e84c4a387d11ad33e6a97d05/src/libs/DomUtils/index.js#L5-L7
We can also utilize blurActiveElement if we decided to manually blur the focus.

Result

https://github.com/Expensify/App/assets/75031127/4edcf683-fbd4-4014-8b5a-e49d2f84bcde

What alternative solutions did you explore? (Optional)
N/A
cc @ArekChr

@ArekChr Updated proposal https://github.com/Expensify/App/issues/26431#issuecomment-1706236926. Please help review again. Thanks!

@DylanDylann you updated your proposal after mine and your solution is also based on my approach.

@getusha your proposal will check if the current active element is [input, textarea] or not, If not, we will blur the current active elements. My proposal will check if the current active element is exactly the main composer/edit composer or not, if not, we will blur the current active. I want the blur action will affect all the elements except exactly the main composer and the edit composer because we cannot guarantee that there will be other input elements in the future or not

@getusha your proposal will check if the current active element is [input, textarea] or not, If not, we will blur the current active elements. My proposal will check if the current active element is exactly the main composer/edit composer or not, if not, we will blur the current active. I want the blur action will affect all the elements except exactly the main composer and the edit composer because we cannot guarantee that there will be other input elements in the future or not

the only difference is that you're using Focus manager which can be suggested by c+, the main proposal is we are triggering e.preventDefault when the composer is not focused, which you updated to it after my proposal.

@getusha yeah. The GitHub will store the edit history. I just want to make sure this issue is fixed as best as possible.

Hi @DylanDylann, @getusha, please send a new message if you're making significant edits to your original posts. This will help keep everyone on the same page and avoid confusion. Thanks!

@DylanDylann Since we have DomUtils with the getActiveElement function, we can use that as you suggested in your first proposal. Also, a solution that prevents default behaviour on events works for me. Let's go with your proposal. as you understood the root cause first and provided a working solution.
:ribbon: :eyes: :ribbon: C+ reviewed

@ArekChr
@DylanDylann's proposal was blurring activeElement on click, but after my proposal of adding a condition to the e.preventDefault or blurring depending on the composer focus status, i also mentioned why preventDefault was needed in the first place, that's when he modified his, can you take a look? I am also open for collaboration for a fair decision, Thanks!

@ArekChr I had updatedd my proposal: My proposal will check if the current active element is exactly the main composer/edit composer or not, if not, we will blur the current active. I want the blur action will affect all the elements except exactly the main composer and the edit composer, because we cannot guarantee that there will be other input elements in the future or not

@ArekChr
I mentioned why we need the e.preventDefault needed and why we need to preserve it when the composer is focused. the differences between proposals should be significant and not a simple change using the focus manager or checking the active element. please check the times when the proposals were edited.

Note: Before submitting a proposal on an issue, be sure to read any other existing proposals. ALL NEW PROPOSALS MUST BE DIFFERENT FROM EXISTING PROPOSALS. The difference should be important, meaningful or considerable.

after my proposal of adding a condition to the e.preventDefault or blurring depending on the composer focus status

@getusha You are right. I checked that, and there is a regression with composer focus without the conditional blur, which was fixed in the PR you mentioned. Thanks for mentioning that.
@DylanDylann You added that condition after @getusha proposed this in his proposal first.
We should proceed with the @getusha approach.

@ArekChr yeb. But my proposal  will check if the current active element is exactly the main composer/edit composer or not. @getusha `s proposal just check if the current active element is [input, textarea] or not

@DylanDylann as i mentioned before, i don't think the difference is important, meaningful or considerable other than change in code snippet, it's the idea of the proposal and the root cause and why we need to preserve the code you suggested to be removed.
I have similar experience before here is a comment about our situation.

If we get into the nitty gritty, we’ll keep doing a back and forth in the issue which isn’t really effective.
Doing a back and forth in a PR is faster because we can test and reference code.
We stopped code diffs as proposals because of this reason only. To avoid back and forth of small tweaks to a proposal until it’s perfect.

@DylanDylann Yes, although we can't guarantee the presence of other input elements in the future, @getusha's insight was crucial. Without it, @DylanDylann, you might not have modified your original proposal, and we could have ended up with a regression.
@johncschuster Do you think should split payment here?

@ArekChr I agree with your opinion on splitting the bounty. Going to wait on @johncschuster's input here.

We request a review from the internal engineer 2.5 days after being assigned. There are also no changes after that. The timeline lasts because the internal engineer @jasperhuangg forgot to merge PR. So are we eligible for a bonus in this issue?

@johncschuster this is 1 week overdue, could you also consider this before processing the payment?

Discussing in Slack. I'll be back to this shortly!

Ok, I'm back! Thanks for your patience, everyone. I needed to discuss two items:
Should we split the payment?
Is the issue eligible for the bonus?
For the first, I confirmed with @DylanDylann (the assignee) that they are okay with splitting the payment, as I wouldn't feel comfortable with that without their express consent, which I didn't see in the above threads. We spoke in Slack, and they have agreed.
For the second, I spoke with Jasper, and confirmed the timeline mentioned in this comment. Yes, this issue is eligible for the bonus.
With that in mind, I will be issuing the following payments:
C+ Reviewer: @ArekChr - does not require payment (Contractor)
Contributor that wrote the code/fixed the issue: @DylanDylann - $500 (half of $1000) - paid via Upwork
Contributor that gave crucial insight to help fix the issue: @getusha - $500 (half of $1000) - paid via Upwork
Bug Reporter: @Charan-hs - $50 - paid via Upwork
@getusha, I've invited you to the job directly on Upwork, can you please accept that and ping me when you've done that? Thank you!

@johncschuster I created PR and updated PR totally and tried to catch up with the timeline. So I think I should receive 100% bonus timeline in this case. (@getusha doesn't take part in PR phrase)

@getusha, I've invited you to the job directly on Upwork, can you please accept that and ping me when you've done that? Thank you!

@johncschuster Accepted!
hank you, everyone, for your involvement in this fair decision 🙏

Oh wow, good catch on the math, @DylanDylann! I agree and will adjust.

Ok! I've issued payment to @DylanDylann and @Charan-hs. @getusha, can you accept the proposal in Upwork? I'll issue payment to you as soon as that's done.
Thanks, everyone!

@johncschuster accepted.

Awesome. Thank you! I'll get payment issued now.

Payment has been issued to @getusha! Thanks for your patience while I worked this out, everyone!

Oh, whoops. I think I forgot to close this one.
@ArekChr, do you think we need regression test steps?

Yes, we can add regression steps here.
Regression test proposal.

Open chat and hover over a chat to get a popup with menu items.
Use Tab/f11 to navigate to that element.
Once it's on Focus, click on one of the emojis multiple times.
Click another emoji and verify if the hover border from the previous one disappears.

Do we agree :+1: or :-1:

Thanks, @ArekChr! I'll get that regression test issue created shortly.

This is on me. I need to get the regression issue going. Will do that shortly.

Everything is done except the regression test issue. Doing that now.


Experimantal Branch gave error about SpectralAnalyzer and some other stuff...

Describe your bug here.
I was tryna build experimental branch and some errors came up.
Command Prompt/Terminal logs (if existing)
ERROR  source/states/stages/objects/ABotSpeaker.hx:3: characters 8-39

   3 | import funkin.vis.dsp.SpectralAnalyzer;
     |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     | Type not found : funkin.vis.dsp.SpectralAnalyzer

 ERROR  source/states/stages/objects/ABotSpeaker.hx:17: characters 15-31

  17 |  var analyzer:SpectralAnalyzer;
     |               ^^^^^^^^^^^^^^^^
     | Type not found : SpectralAnalyzer

 ERROR  source/states/stages/PhillyBlazin.hx:155: characters 8-11

 155 |   abot.snd = FlxG.sound.music;
     |        ^^^
     | states.stages.objects.ABotSpeaker has no field snd

 ERROR  source/states/stages/PhillyStreets.hx:391: characters 9-18

 391 |    abot.lookRight();
     |         ^^^^^^^^^
     | states.stages.objects.ABotSpeaker has no field lookRight

 ERROR  source/states/stages/PhillyStreets.hx:393: characters 9-17

 393 |    abot.lookLeft();
     |         ^^^^^^^^
     | states.stages.objects.ABotSpeaker has no field lookLeft

 ERROR  source/states/stages/PhillyStreets.hx:400: characters 8-11

 400 |   abot.snd = FlxG.sound.music;
     |        ^^^
     | states.stages.objects.ABotSpeaker has no field snd

Are you modding a build from source or with Lua?
Source
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
no

fixed


Dimension 1 bug

I'm not entirely happy with this fix because I don't understand why it works :| It make sense that writing the data bytes of a (1, 5, 5, 5) image is the same as writing them for a (5, 5, 5) image. The first dimension adds nothing interesting that should concern the write_data function. However, it looks like iterating on a dim=1 change the ordering. When I skip the dim=1, it works as intended.
Anyway, I'm still pushing this branch because I have other things to do, but if you have a better understanding of the problem than me, I'm interested!
Fix #63

I requested you as reviewer because I don't even know if you saw this PR.


charts,manifests: Fix the olm.skipRange CSV annotation being rendered incorrectly.

In the art.yaml, which defines the substitution rules for ART, we search for this olm.skipRange annotation in the Metering CSV file:
    - search: 'olm.skipRange: ">=4.3.0 <{MAJOR}.{MINOR}.0"'

What's problematic here is that we're searching for strings that start with double-quotes, but helm renders many of the chart's CSV annotations as single quotes, instead of double-quotes, so the search for substitution rule fails and the end result is ART cannot properly substitute the 4.6 version.

/cherrypick release-4.5

/lgtm

/bugzilla-refresh

/bugzilla refresh

/retest

Test failed due to many-to-many PVC-related metrics bug that's already being tracked in BZ.
/override ci/prow/metering-e2e-aws


Check if /dev/fb1 exists and select /dev/fb0 when not.

When using the hdmi, /dev/fb0 is available and not /dev/fb1. The change check if /dev/fb1 exists and when not , switch to /dev/fb0

Interesting find. Does "using the hdmi" means that a HDMI display is "connected"? Because this could also then be used to "auto-detect" what is at the moment a "manual switch": https://github.com/rootzoll/raspiblitz/blob/v1.6/FAQ.md#can-i-run-the-raspiblitz-without-a-displaylcd

I have connected the hdmi to a 7zoll LCD.
The hdmi is always /dev/fb0 and the spi display is always /dev/fb1,
I think it is possible to use fb1 and fb0 for autodetect.

@holgern did you tested this also with the LCD hat on and Touchscreen on? In my tests with the PR it does not show the images/qr anymore and instead shows the pi-terminal. Will push this PR to v1.7 milestone.

@holgern I moved your code into a new PR because it needed to be rebased on dev branch -->  #2064
So this fix got merged by the PR #2064 and will be part of the v1.7 release. Closing this one.


Tech debt

Remove custom HTTP calls that rely on releases.json, and manually parsing the JSON responses:

Use the preview Microsoft.Deployment.DotNet.Releases package
Delete unused files
Fix unit tests

Fixes #7

Hmm. I'll review the code changes, but it looks like there is an issue with your .gitignore. There are a number of files that I don't think you want to add to the repo in this PR.

Reading the diffs, the changes look great. Let me know if you want me to look again after cleaning the PR files.

Yeah, for this to be containerized we have to build out the .dll/.exe files and I put them in the /dist directory. This is intentional.

Hey @BillWagner - I created another issue to track the effort of removing the dlls and exes, and instead build the container from source. See, https://github.com/dotnet/versionsweeper/issues/18


Add candle to setup_service

What was wrong?
Candle chain was missing
How was it fixed?
Added candle chain deployments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
78 unchanged lines in 10 files lost coverage.
Overall coverage decreased (-1.2%) to 87.472%

Files with Coverage Reduction
New Missed Lines
%

safe_transaction_service/tokens/clients/kraken_client.py
3
73.53%

safe_transaction_service/history/services/collectibles_service.py
4
90.48%

safe_transaction_service/tokens/tasks.py
4
89.86%

safe_transaction_service/tokens/clients/coingecko_client.py
6
80.72%

safe_transaction_service/tokens/clients/kucoin_client.py
6
60.0%

safe_transaction_service/tokens/clients/zerion_client.py
8
78.95%

safe_transaction_service/tokens/clients/binance_client.py
11
40.74%

safe_transaction_service/tokens/clients/kleros_client.py
11
64.71%

safe_transaction_service/tokens/services/price_service.py
11
90.11%

safe_transaction_service/tokens/clients/coinmarketcap_client.py
14
47.17%

Totals

Change from base Build<PHONE_NUMBER>:
-1.2%

Covered Lines:
5858

Relevant Lines:
6697

💛  - Coveralls

Please rebase and resolve conflicts so we can merge 🙏🏻

Also https://github.com/safe-global/safe-deployments/pull/108 needs to be merged first

Please rebase and resolve conflicts so we can merge 🙏🏻

Will do

Also safe-global/safe-deployments#108 needs to be merged first

Done sir

Also safe-global/safe-deployments#108 needs to be merged first

Done sir

No, it's not


Logout view template config

So to implement the logout view I had to add registration/logged_out.html to my templates/ dir. This appears to be due to the use of the Django builtin LogoutView in def finish_logout. It would be nice to make this easier to configure the template. Albeit it wasn't particularly hard I think it could cause namespace issues or just confusion if there was an app named "registration" and it wasn't necessarily related to login/logout. I think there might be 2 ways of doing this.

Have settings.LOGOUT_TEMPLATE and then in the function call AuthLogoutView.as_view(template_name=getattr(settings, "LOGOUT_TEMPLATE", AuthLogoutView.template_name)
Have settings.LOGOUT_VIEW and then just grab the user defined view or use the default builtin.

I'm partial to 2 as it gives you more customization.

have you consider to simply  configure a logout redirect path in global settings?

@peppelinux If I'm understanding you correctly you're referring to settings.LOGOUT_REDIRECT_URL. That does appear to avoid using the template. That appears to work. I was hoping I was just overthinking it and there was an easier way of handling this.

I keep this issue open for two months, feel free to make a PR on one of your previous points if It sounds fun to you

Sounds good. There might be another use for this feature. Thanks for your help!

If someone else expresses interest I'd be happy to implement it but I don't think I foresee the need anymore as the way you suggested works perfectly fine and takes advantage of what is already baked into Django.

yes Adam, less is more!


Lazy loading with same "event" on different plugins

If we register same command (and also same key) on multiple plugins, it stops working.
Not working:
call jetpack#begin(g:packages_home)

Jetpack 'habamax/vim-select', { 'on': ['Select'] }
Jetpack 'habamax/vim-select-more', { 'on': ['Select'] }

call jetpack#end()

Working
call jetpack#begin(g:packages_home)

Jetpack 'habamax/vim-select', { 'on': ['Select'] }
" Jetpack 'habamax/vim-select-more', { 'on': ['Select'] }

call jetpack#end()

For reference, I have the same configuration in vim-plug and works as expected.

I hope that the latest commit solves your problem. Please check it.
Further, could you close this issue if it is solved. Thanks.

Works as of b0658a7

Great! Thank you for checking it :)


FSSpecFileLister error with S3 root

🐛 Describe the bug
The following code — listing files on S3 — fails:
import torchdata.datapipes as dp

pipe = dp.iter.FSSpecFileLister(root="s3://my-bucket/...")
item = next(iter(pipe))

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/.../.venv/lib/python3.9/site-packages/torch/utils/data/_typing.py", line 366, in wrap_generator
    response = gen.send(None)
  File "/Users/.../.venv/lib/python3.9/site-packages/torchdata/datapipes/iter/load/fsspec.py", line 57, in __iter__
    is_local = fs.protocol == "file" or not self.root.startswith(fs.protocol)
TypeError: startswith first arg must be str or a tuple of str, not list

What's happening is that for the S3, fs.protocol is a List[str] (specifically ["s3", "s3a"]) which is breaking self.root.startswith(fs.protocol) which excepts Union[str, Tuple[str, ...]].
https://github.com/pytorch/data/blob/71a16a3b63966af0f60af74d3044b3c963cfc5fb/torchdata/datapipes/iter/load/fsspec.py#L55-L57
I think that the code expects fs.protocol to be a str all the time (i.e., not even a tuple), given the following line at the end if FSSpecFileListerIterDataPipe.__iter__():
https://github.com/pytorch/data/blob/71a16a3b63966af0f60af74d3044b3c963cfc5fb/torchdata/datapipes/iter/load/fsspec.py#L74-L75
so a simple fix like replacing the list with a tuple might not work...
Versions
Collecting environment information...
PyTorch version: 1.11.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.2.1 (arm64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-13<IP_ADDRESS>)
CMake version: version 3.22.3
Libc version: N/A

Python version: 3.9.10 | packaged by conda-forge | (main, Feb  1 2022, 21:25:34)  [Clang 11.1.0 ] (64-bit runtime)
Python platform: macOS-12.2.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy==0.941
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torch-cluster==1.6.0
[pip3] torch-geometric==2.0.4
[pip3] torch-scatter==2.0.9
[pip3] torch-sparse==0.6.13
[pip3] torch-spline-conv==1.2.1
[pip3] torchdata==0.3.0
[conda] mypy                      0.941                    pypi_0    pypi
[conda] mypy-extensions           0.4.3                    pypi_0    pypi
[conda] numpy                     1.22.3                   pypi_0    pypi
[conda] torch                     1.11.0                   pypi_0    pypi
[conda] torch-cluster             1.6.0                    pypi_0    pypi
[conda] torch-geometric           2.0.4                    pypi_0    pypi
[conda] torch-scatter             2.0.9                    pypi_0    pypi
[conda] torch-sparse              0.6.13                   pypi_0    pypi
[conda] torch-spline-conv         1.2.1                    pypi_0    pypi
[conda] torchdata                 0.3.0                    pypi_0    pypi

Since fs.protocol is a class variable, a very hacky workaround is:
import s3fs

s3fs.core.S3FileSystem.protocol = "s3"

(assuming you know the filesystem will always be "s3"

Thanks for finding such issue. Please feel free to open a PR to fix it.
And, we are currently trying to land a PR that uses AWSSDK to load s3. https://github.com/pytorch/data/pull/165 . But, in order to use it, you may have to compile awssdk by yourself.
We are still working on releasing a nightly wheel with awssdk library.

Will do! And thank for letting me know about awssdk

@nrlugg
I currently just submitted a solution to this issue as well in my solution to another issue. Could you please assign me to this issue?

@ykabusalah
Sorry for my slow reply... And thank you for solving this issue! It looks like you have already been assigned to this issue?

Fixed by #383


Bump SNAPSHOT versions to 0.18.0-SNAPSHOT

Add minor updates to ILP-core to support STREAM
Reorg poms for STREAM
Add stream-core module
Defer ConnectionManager to #241

Signed-off-by: David Fuelling<EMAIL_ADDRESS>

Codecov Report

Merging #244 into master will decrease coverage by 6.6%.
The diff coverage is 31.39%.

@@             Coverage Diff              @@
##             master     #244      +/-   ##
============================================
- Coverage     74.65%   68.05%   -6.61%
- Complexity      394      408      +14
============================================
  Files           110      140      +30
  Lines          1752     2019     +267
  Branches        156      160       +4
============================================
+ Hits           1308     1374      +66
- Misses          374      574     +200
- Partials         70       71       +1

Impacted Files
Coverage Δ
Complexity Δ

...edger/stream/frames/ConnectionNewAddressFrame.java
0% <0%> (ø)
0 <0> (?)

...ava/org/interledger/core/InterledgerConstants.java
0% <0%> (ø)
0 <0> (?)

.../java/org/interledger/stream/frames/ErrorCode.java
0% <0%> (ø)
0 <0> (?)

...dger/stream/frames/ConnectionMaxStreamIdFrame.java
0% <0%> (ø)
0 <0> (?)

...rg/interledger/stream/frames/StreamMoneyFrame.java
0% <0%> (ø)
0 <0> (?)

...ava/org/interledger/stream/frames/StreamFrame.java
0% <0%> (ø)
0 <0> (?)

...re/src/main/java/org/interledger/core/Wrapper.java
0% <0%> (ø)
0 <0> (?)

...rg/interledger/stream/StreamConnectionDetails.java
0% <0%> (ø)
0 <0> (?)

...org/interledger/stream/frames/StreamDataFrame.java
0% <0%> (ø)
0 <0> (?)

...java/org/interledger/stream/ConnectionManager.java
0% <0%> (ø)
0 <0> (?)

... and 51 more

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 f7d7ea5...d5731ac. Read the comment docs.

Ordinarily I wouldn't make a bunch of issues for unit test work, but since there's so much here, I figured I'd using issues so anyone can parallelize this work.


Deprecate is_async and replace with isawaitable

The isawaitable function is available from the inspect module in python 3.5
Therefore we want to use that for python 3.5 and a proxy for python 3.4
is_async still available for versions 1.1.*

Done and released with ver 1.2


Lokalise: Translations update: Updating existing languages (en-us, en-uk, zh-tw, de, pl, es_es)

This pull request was initiated by Lokalise (user Do Hee Kim) at 2020-10-10 21:54:50

@joshmorel
While verifying the fix in STG, I have observed that the error messages for avatar feature are Not translated. refer below image.

Below changes done in this PR have been verified as in below GIF.

Thanks @rabbi08 that totally makes sense. We do want to default to English if there's not a translation.
Can we add translations for this other in a day or 2 @doheekim93 @jyclam

@joshmorel @rabbi08 Translations will depend on the translators (no guarantees). But yes, the default is set to English already, so if this is not a huge blocker, I think we should go ahead for the merge? Otherwise, we will be stuck in an infinite wait loop: things get merged to staging (despite the code freeze) and then we have to wait for translations for those new things 😅


getAvailablePurchases() always giving error like this : [Error: An unknown error occurred] in ios, i don't know what is the issue?

"react-native-iap" : ^12.12.2
"react-native": "0.71.11",

I am getting this error when I call getAvailablePurchases()
RNIapIos.getAvailableItems was called with 1 arguments but expects 0 arguments. If you haven't changed this method yourself, this usually means that your versions of the native code and JavaScript code are out of sync. Updating both should make this error go away.

-[RCTModuleMethod invokeWithBridge:module:arguments:]
    RCTModuleMethod.mm:549
facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&, int, (anonymous namespace)::SchedulingContext)
facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int)::$_0::operator()() const
invocation function for block in facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int)
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_lane_serial_drain
_dispatch_lane_invoke
_dispatch_root_queue_drain_deferred_wlh
_dispatch_workloop_worker_thread
_pthread_wqthread
start_wqthread

<SKReceiptRefreshRequest: 0x6000006b2f40>: Finished refreshing receipt with error: Error Domain=ASDServerErrorDomain Code=500328 "Unhandled exception" UserInfo={NSLocalizedDescription=Unhandled exception, NSLocalizedFailureReason=An unknown error occurred}

[react-native-iap] restoreCompletedTransactionsFailedWithError


CatsMonadAsyncError shouldn't use eval for blocking

Reported here: https://softwaremill.community/t/sttp-monad-monaderror-blocking-for-cats-effect/314/3
CatsMonadAsyncError uses the default implementation from MonadError:
def blocking[T](t: => T): F[T] = eval(t)

and eval is implemented as follows:
override def eval[T](t: => T): F[T] = F.delay(t)

So, delay is used for blocking actions.

Fixed here: https://github.com/softwaremill/sttp/pull/1993 :)


feat(openid4vc): jwt format and more crypto

Adds support for receiving JWT credentials in the openid4vc client, and also extends support for supported proof of possession JWA signature algorithms.
To be able to support multiple signature algs, I had to remove the kid parameter, as the crypto that will be used, and the did methods the issuer supports has a big impact of the kid that will be selected.
For this, a new proofOfPossessionVerificationMethodResolver function MUST be supplied when requesting a credential through the openi4vc-client in AFJ, that is called whenever a verification method id (kid) must be determined for a to be created proof of possesion. The callback takes the following options, which should give the caller enough  information to determine the verification method:
export interface ProofOfPossessionVerificationMethodResolverOptions {
  /**
   * The credential format that will be requested from the issuer.
   * E.g. `jwt_vc` or `ldp_vc`.
   */
  credentialFormat: SupportedCredentialFormats

  /**
   * The JWA Signature Algorithm that will be used in the proof of possession.
   * This is based on the `allowedProofOfPossessionSignatureAlgorithms` passed
   * to the request credential method, and the supported signature algorithms.
   */
  proofOfPossessionSignatureAlgorithm: JwaSignatureAlgorithm

  /**
   * This is a list of verification methods types that are supported
   * for creating the proof of possession signature. The returned
   * verification method type must be of one of these types.
   */
  supportedVerificationMethods: string[]

  /**
   * The key type that will be used to create the proof of possession signature.
   * This is related to the verification method and the signature algorithm, and
   * is added for convenience.
   */
  keyType: KeyType

  /**
   * The credential type that will be requested from the issuer. This is
   * based on the credential types that are included the credential offer.
   */
  credentialType: string

  /**
   * Whether the issuer supports the `did` cryptographic binding method,
   * indicating they support all did methods. In most cases, they do not
   * support all did methods, and it means we have to make an assumption
   * about the did methods they support.
   *
   * If this value is `false`, the `supportedDidMethods` property will
   * contain a list of supported did methods.
   */
  supportsAllDidMethods: boolean

  /**
   * A list of supported did methods. This is only used if the `supportsAllDidMethods`
   * property is `false`. When this array is populated, the returned verification method
   * MUST be based on one of these did methods.
   *
   * The did methods are returned in the format `did:<method>`, e.g. `did:web`.
   */
  supportedDidMethods: string[]
}

It adds a bit of complexity for the caller, but there's simply no way for AFJ to know which did method or key we should use in a proof of possession, as that's heavily reliant on business logic. And passing it upfront also doesn't work, as the caller is missing important information.
The crypto that can be used for the proof of possesion is based on what is supported by the wallet and the registered JSON-LD signatuer suites. So if we were to add new key types / JWA siganture algortihms or signature suites, the openid4vc client wouldn't have to be changed at all.
You can limit which algs and credential formats you want to allow, so those aren't considered as option when the issuer supports them through the allowedCredentialFormats and allowedProofOfPossessionSignatureAlgorithms properties. (e.g. I only want to receive jwt_vc credentials with ES256 alg, even if my wallet and the issuer both support Ed25519Signature2018. We may want to also add a property for allowedDidMethods so we won't consider an option if your specific did method, or all did methods arern't supported by the issuer.
Dependant on #1468

For just the changes from this PR, see https://github.com/TimoGlastra/aries-framework-javascript/compare/feat/jwt-vc...TimoGlastra:aries-framework-javascript:feat/openid4vci-jwt-cyprot?expand=1

Codecov Report

Merging #1472 (bf90537) into main (5075658) will decrease coverage by 0.94%.
The diff coverage is 84.01%.

@@            Coverage Diff             @@
##             main    #1472      +/-   ##
==========================================
- Coverage   85.84%   84.90%   -0.94%
==========================================
  Files         912      942      +30
  Lines       21759    22514     +755
  Branches     3727     3906     +179
==========================================
+ Hits        18679    19116     +437
- Misses       2901     3188     +287
- Partials      179      210      +31

Impacted Files
Coverage Δ

...ncreds/src/formats/LegacyIndyProofFormatService.ts
80.10% <ø> (ø)

.../src/updates/0.3.1-0.4/credentialExchangeRecord.ts
100.00% <ø> (ø)

...crypto/signing-provider/SigningProviderRegistry.ts
87.50% <0.00%> (-12.50%)
:arrow_down:

...les/basic-messages/services/BasicMessageService.ts
94.44% <ø> (-0.30%)
:arrow_down:

.../modules/connections/services/ConnectionService.ts
87.86% <ø> (-0.05%)
:arrow_down:

...les/credentials/protocol/BaseCredentialProtocol.ts
94.91% <ø> (-0.17%)
:arrow_down:

...fication/services/RevocationNotificationService.ts
98.24% <ø> (-0.06%)
:arrow_down:

packages/core/src/modules/oob/OutOfBandService.ts
98.93% <ø> (-0.03%)
:arrow_down:

...e/src/modules/proofs/protocol/BaseProofProtocol.ts
55.55% <ø> (-1.59%)
:arrow_down:

...ules/routing/services/MediationRecipientService.ts
82.35% <ø> (-0.23%)
:arrow_down:

... and 141 more

... and 7 files with indirect coverage changes

Some very small comments. Already looking forward to resolving the merge conflicts regarding the openid4vc-client package :).

Yeah that's going to be tedious :(


Remote Service Images upload to server again after calling processFiles

I am adding in files via the config files array and this all works great via the load function.
But later in my UI the user clicks a button that does a batch processFiles on the component and for some reason the remote images try and upload again.
This seems like a bug considering on initial load the upload button from all loaded images is invisible cause it knows its remote. But the processFiles function doesn't seem to know.
I was going to try and hack and set the status to the PROCESS_COMPLETE value but that doesnt seem to be a elegant solution.
Version 4.4.2

Should be fixed in version 4.4.6, please confirm.

@northkode for me the workaround was to initially set the instant upload to true and then check if a profile image is available => if available set this.pondOptions.instantUpload to false else to true
I put this into the section where I set the values of the modelForm
I use Angular and the version 4.4.0

@rikschennink seems to be resolved in 4.4.6, thanks!


Adapter to honour CollectSourceInformation Flag and not DesignMode

@jayaranigarg,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Install Yourls with Big Commerce Site.

Hello,
I am the beginner for this feature, just want to know what and how to integrate yourls with BigCommerce site.
The scenario is as below.

We have our BigCommerce site (www.bigcomxyz.com) up and running perfectly and it has (www.bigcomxyz.com/admin) for admin panel.
We have our shortened domain purchased/setup at domaindiscount24.com .
shortened url as:  "shrt.gs/"
Now where and how should we should install the yourls feature to be work with the above short url. We know we have to setup the database and install respective url on that, but how and where the redirection occur based on the database settings.

Kindly revert back at the earliest.
Regards,
Prashant

That's not a YOURLS question, that's a hosting question. Where should you install YOURLS so it works with your domain shrt.gs? Your hosting provider will tell you.

Hello ozh
Do we require intermediate domain compulsory?
i.e if i write the shrt.gs then it will redirect to that domain and there based on the admin settings into the database it will redirect to the main site?
I have uploaded the yourls code to our hosting server and apply the respective value in the config file. we have the shortened url setup there at the hosting environment.
Now, based on the Yourls Installation steps, its written as visit shrt.gs/admin to access your admin panel. Hence, want to know about this?
Can you please elaborate more on the installation?.
I have followed the steps written over here but don't know how to move forward.
http://yourls.org/#Install
http://yourls.org/#Config (set up the config file based on this.

Again: not a YOURLS question. You're asking how to install software on a server, can't help with that.
Install YOURLS somewhere so that you can point your browser to shrt.gs/admin or whatever your URL is. If you don't know how to do that, ask your server admin.


[fix] Skip the build of ui and api add the build command in pull_request

Purpose of the pull request

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
If your pull request contains incompatible changes, you should also pull request the documentation to https://github.com/datasophon/datasophon-website

There is currently a problem with the npm build in datasophon ui, and datasophon api will rely on datasophon ui, so the two modules are currently skipped from the build test.


Java

We have been using the desktop Java app with version 7.0.0. I was trying to set it up with a new worker and it is not working correctly. Are we still able to use the desktop Java app? Or do we need to use the RESTful API?

We removed the deprecated access methods, including Java, in the 8.0.0 release.  The RESTful API is the only supported access method post-7.0.0.


Increase the character limit for study descriptions

Right now, study descriptions have a character limit of 1000. This should be increased considerably.

What is the purpose in your view of this study description field? I intended it to be used for a short elaboration on what the study is about, if the title is not descriptive enough, and not to contain a long text of instructions on how the experiment should be run. I also designed the GUI for this field to be used in that way (e.g. the subtitle lines in the list items for studies on the study page, and by using a large font to show the description below the title on the study detail page).
If you do intend to use this field for longer instruction texts, it may be a better idea to add an extra field to the study table and add this to the interface.

"If you do intend to use this field for longer instruction texts, it may be a better idea to add an extra field to the study table and add this to the interface."
Yes, that's the idea, to be able to add comments on the study, maybe an event that happened during the experiment for instance... e.g. there was a covid pandemic that shut the lab for three months!

Alright, so that sound more like you need some sort of logbook or even comments functionality. One big text field would also suffice though, but I would keep that separated from the study description (which serves other display purposes as well) and just add a new field or fields for this.

I added an editable study info section and pushed this to the develop branch. It supports basic markdown for formatting as well (was really easy and out-of-the-box to add this). You'll find it as an extra tab on a study page. Please try it out.
One small note: studies that have been created before this field was added will show 'null' if the information field is empty, but newer studies do not. I don't think I need to find a solution that works around this problem.


minor: Update core package to version 1.10.0

Signed-off-by: Gloria Delgado<EMAIL_ADDRESS>

I'm adding the minor tag for triggering a new release later today. We have accumulated quite a lot of stuff with no release.


[5.8] Improve command "route:list" message

For a long time, an empty table (only headers are displayed) has been nothing to me.

Domain
Method
URI
Name
Action
Middleware

Such as the message "Your application doesn't have any routes.", I think a clear message "Could not find any matched routes." looks like more informative and pretty for anyone.

This test "1) Illuminate\Tests\Queue\QueueWorkerTest::test_job_is_not_released_if_it_has_expired" my case by the travis system.


Pair Orientation vs. Strand Bias

Hi,
What is the difference between Pair Orientation vs. Strand Bias ?
Thank you.

An error is displayed as shown in the figure below, how to solve it?


Can not access mongo DB after run a container

I run a Docker container with the cmd:
$ docker run --name my_mongo -d mongo:3.5

It can successfully create a container.
$ docker ps -a
CONTAINER ID        IMAGE           COMMAND                  CREATED               STATUS                  PORTS               NAMES
ede5e98eb958        mongo:3.5      "docker-entrypoint.sh"   14 minutes ago   Up 14 minutes      27017/tcp           my_mongo

When I try to connect to this DB, it goes wrong.
root@ubuntu:~# mongo
MongoDB shell version: 2.4.9
connecting to: test
Wed May 10 04:02:56.530 Error: couldn't connect to server <IP_ADDRESS>:27017 at src/mongo/shell/mongo.js:145
exception: connect failed

When I enter this container, use cmd "mongo" to connect the mongo DB it will stuck...
root@ubuntu:~#  sudo docker exec -it my_mongo bash
root@411e98f22781:/# mongo
MongoDB shell version v3.5.6
connecting to: mongodb://<IP_ADDRESS>:27017

What's worse, this container can not been stopped or removed.
my docker version
root@ubuntu:~# docker version
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 21:44:32 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 21:44:32 2016
 OS/Arch:      linux/amd64

my OS:
root@ubuntu:~# uname -a
Linux ubuntu 4.2.0-27-generic #32~14.04.1-Ubuntu SMP Fri Jan 22 15:32:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Using the mongo client from the host will require you to specify the IP address of the container to connect to.
$ myMongo="$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' my_mongo)"
$ mongo "$myMongo"

Or you need to run the MongoDB container and expose its port as a port on your host:
$ # this will allow you access via localhost on your host, but will prevent external connections
$ # but does not prevent access from other containers on your host
$ docker run --name my_mongo -d -p <IP_ADDRESS>:27017:27017 mongo:3.5
$ mongo
> db
test

$ # this exposes it to anyone that can access port 27017 on your host from your network
$ # can be a security concern if host IP is accessible publicly
$ docker run --name my_mongo -d -p 27017:27017 mongo:3.5

I have never seen the MongoDB container as unstoppable or non-removable.
The above command will remove the mongo image as the command "rmi" will delete the Mongo image.
Please be noted that you should only include the mongo image.  For my case, the images are  mongo and mongo-express, use the image id accordingly.  The command "docker image ls" will list all the docker image Id.

You may need to run the command a few times until you don't see the images.  Then you just need to rebuild the Mongo image.
Next, you have to restart the docker process to ensure that the mongo stuff not left in the memory.


Refactor GUI scripts as per release 1.12.0-RC2.ee

Below tests needs to be refactored:

Profile
Dashboard
OpenEBS version check

PR: https://github.com/mayadata-io/gui-automation/pull/46/


Change icon

WIP: Please do not merge this PR until this warning has been removed by the author.

Todo

[ ] change the icon to the vectorized version

Motivation
To make the icon more recognizable
Summary of changes
changed manifest.json file to allow google chrome to show the icon correctly
changed the icon to the vectorized version
Attached GitHub issue
#24
Checklist

Documentation
Local Build

[ ] Extension has been tested to build correctly cd extension && yarn && yarn build
[ ] Extension test suite has been run locally cd extension && yarn && yarn test

GitHub

[ ] Target branch has been set correctly
[ ] PR has been rebased onto target branch
[ ] PR has been assigned an owner
[ ] Author has performed a self-review of the code

Codecov Report

Merging #36 (3a105a8) into main (dd5d4da) will increase coverage by 0.95%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #36      +/-   ##
==========================================
+ Coverage   74.42%   75.37%   +0.95%
==========================================
  Files           8        8
  Lines         262      264       +2
  Branches       42       42
==========================================
+ Hits          195      199       +4
+ Misses         43       42       -1
+ Partials       24       23       -1

Impacted Files
Coverage Δ

backend/src/__init__.py
79.24% <0.00%> (+4.73%)
:arrow_up:

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


Is interpolating expressions something that could be added?

From looking at the source, it doesn't seem like adding this would be extremely difficult, however I'm not sure if there's some subtle effect that actually would make this impossible.
I'm also not sure if you'd be adding features that diverge from the existing quote! macro.
I don't think this could be done in a way that is 100% compatible with quote!, but one approach would be to a separate macro that allows some extended features. Maybe something like xquote!
Here's an example use case:
struct Blah { x: Ident, y: Ident }

impl ToTokens for Blah {
  fn to_tokens(&self, tokens: &mut TokenStream) {
    let x = self.x;
    let y = self.y;
    // Ignore that the actual generated code is nonsense, just an example.
    tokens.append_all(quote!( #x #y ))
  }
}

Instead of having to create a bunch of bindings before calling quote!:
struct Blah { x: Ident, y: Ident }

impl ToTokens for Blah {
  fn to_tokens(&self, tokens: &mut TokenStream) {
    tokens.append_all(xquote!( #$(self.x) #$(self.y) ))
  }
}

Another common case is having something that implements IntoIterator like an Option, but you have to create bindings with let x = x.into_iter() or to use an iterator multiple times it's necessary to do some something like:
let my_iter1 = blah.iter();
let my_iter2 = blah.iter();
quote!( #( #my_iter1 )* #( #my_iter2 )* )

Instead:
xquote!( #( #$( blah.iter() ) )* #( #$( blah.iter() ) )* )

Of course, it doesn't have to be #$( ... ) for the expression interpolation syntax.
Anyway, if this isn't something you'd be opposed to on principle then I'd probably look into working on this and submitting a PR if I get it to a workable state.

This was suggested for quote, too, but the author decided against adding it.

Yes, given that the original quote crate doesn't and will never support this, I also think that it won't be a good idea to add support in this crate, as that would promote a split ecosystem in the rust proc macros. I think that the transition between quote and proc-quote (and the other way around) should be as easy as possible, ideally just changing the crate name, and that is not possible if proc-quote starts supporting features that won't ever be implemented in the original quote crate.
That said, this doesn't mean I'm not open to other experimental ideas if there is potential interest in eventually implement then in the original quote crate.


test: wait for failed status for invalid pod

This assertion seems to occasionally fail in CI, most likely due to a race condition with the InProgress status. Update the assertion to check the Failed status instead.

/unhold
It looks like the root cause here was more likely a transient Failed state with the Pod on autopilot - I realize now the TODO is still valid.


feat: update documents of editor

Please check if the PR fulfills these requirements

[x] It's the right issue type on the title
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[x] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] It does not introduce a breaking change or has a description of the breaking change

Description

Thank you for your contribution to TOAST UI product. 🎉 😘 ✨

PR명이나 브랜치명도 feat 대신 커밋 정책 따라서 docs 로 하면 어떨까요?


Add Qwt

It would be great to have a port for the Qwt ( Qt Widgets for Technical Applications  ) library ( http://qwt.sourceforge.net/ ).

Qwt uses a qmake based build system, so I guess that a first step would be to add qmake support in vcpkg_find_acquire_program.

Actually qmake should be provided by the qt5 port, similarly to how protoc is provided by the protobuf port.

I think the route of find_acquire_program is better for "non-deployable" utility programs, such as sed, python2 (when used as a build tool), qmake, cmake, etc.
The argument here is that building something from source is most critical when it will be injected into your application's address space and you need to "support" it. For tools that you use during the build but do not deploy, there is significantly less gain in building it locally compared to a precompiled download.
Tools that involve a deployed runtime such as protoc are an interesting intersection that seems best to solve case-by-case.

I was preparing to reply to your comment @ras0219-msft , but then I saw that the PR https://github.com/Microsoft/vcpkg/pull/494 was merged. Replying anyway, motivating some design choices behind that PR.

For tools that you use during the build but do not deploy, there is significantly less gain in building it locally compared to a precompiled download.

The main problem with qmake is that the qt5 port already installs it in <install_prefix>/tools as the protobuf port installs protoc, and consequently, as all qmake-based projects I am aware of also depend on qt5 as a library, it is drastically simpler to use the qmake already available in the system.
Furthermore, no upstream binaries for the qmake as itself are available, but only binaries for the complete qt5 set of libraries and tools are available, and that would mean several MBs of additional download just to download a binary version of qmake.
Note also that qmake is always provided in all package managers together with qt5 and all its tools. Sincerely, I would really prefer to avoid being the first package manager to test the situation in which the qmake can come from a version of qt5 different from all the qt5 libraries and tools used by the project.
This three points were for me sufficient to prefer to use the qmake version installed by the qt5 port.
Note that at the moment the qt5 port install the tools that it compile, and this would be a problem for crosscompiling on ARM, but I consider this a problem of the qt5 port rather then of all the projects depending on qt5 for its tools.

Fixed by https://github.com/Microsoft/vcpkg/issues/494 .

Great point, I concur with your conclusions.


Adding more query examples

Learn Build status updates of commit 7a770b3:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/azure-functions/analyze-telemetry-data.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@ggailey777

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Apply the repo check workflow to all push events

This allows to check for formatting and big change in history as early as someone pushes to the repo.
If we encourage developers to test earlier, with a push hook, then we could change the repo check so that it emails the author of the push?
What we could do anyway is to log the branches that do not pass the test.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#2282
@adrienbernede
@tzanio
@tzanio + @pazner
06/02/21
⌛due 06/16/21
⌛due 06/23/21

What will be the effect of merging this, i.e. what will happen if this check fails?

This applies the checks on any latest commit pushed (the latest of a branch when pushing several commits).
So if it fails, the commit gets a red-cross next to it, if it’s not in a PR, there will be no additional whistle.
Note: this is not blocking the push. For that I’ll push some suggested git hooks with a readme later on.

Ok, so for branches that don't have a PR there will be no notification to the user unless they browse the branch commits on GitHub, correct?

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

Correct.

Correct.

LGTM

Merged in next for testing...

In the above summary of checks, a number of checks show up two times, e.g. "documentation", "code-style". I don't think we really want to run (and see) these checks twice.


Fix/disable wq setprovider

disable workqueue.SetProvider temporary
workqueue.SetProvider only set once.
Due to some weird init order issues, knative.dev/pkg/controller always init firstly instead of sigs.k8s.io/controller-runtime/pkg/metrics.
it will conflict to sigs.k8s.io/controller-runtime/pkg/metrics/workqueue.go and cause method in controller-runtime to be invalid
and no client-go metrics will be reported when we use controller-runtime framework

流水线问题看起来像是bug， 沟通解决中


Public dashboard does not work due to JS error in findPermission.ts

A clear and concise description of what the bug is.
Setting up a public dashboard does not work and fails on the findPermission.ts file due to JS error for undefined roles object passed as an argument.
Expected results
A dashboard to open and without user login.
Actual results
JavaScript error and dashboard fails to load
Screenshots

How to reproduce the bug

Clone the repository locally
Add the following to the superset_config.py PUBLIC_ROLE_LIKE = "Gamma"
Start superset using docker-compose up
Log in as admin and edit the public roles to have all required permissions for one of the dashboards.
Log-out or in a private browser window try to open the public dashboard.

Environment

superset version: Version: 0.999.0dev
python version: Python 2.7.18
node.js version: v12.18.2

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

Here too. Version as of today.

This should be fixed by #14626

for me it is still present.

Hmm, that's actually a different error. I will push a fix shortly. Thanks for following up.
We clearly need to add some end-to-end tests for public dashboards.

now it's solved !

That's great to hear! Closing this again 😃