Planning CI/test for the 0.4.0 release

Motivation
Alongside the previous three releases:

We left some technical debits behind (e.g., re-use of Kata's tests on operator CI is a hack)
We experienced instability (e.g. SEV jobs failing)
We released features/support not covered on CI (e.g. AMD SEV-ES support)

Also there will be more/new demands for 0.4.0. For example, e2e testing for cloud-api-adaptor (a.k.a peer pods).
Goal
My assessment is that we ended up with a good list of work items to tackle but that is spread on several places: issues on several repos, slack discussions, people's brain (or hopefully hand-written on paper), etc. So I'm opening this issue so that we can collectively and openly:

Flush ideas
Transform on actionable items (i.e. in issues)
Prioritize the issues
Assign to people
Finally put on @ariel-adam 's magic planning board.

Work items

ID
Description
Priority (Low, Medium, High)
Owners
Issues
Include in v0.4.0 (Y/N) ?
Notes

01
Get the Operator CI out of Kata CI (Jenkins)
High?
@wainersm,  @fitzthum(?)
https://github.com/confidential-containers/community/issues/67
Y
-

02
Collapse operator and Kata tests into one
-
@ryansavino @fitzthum
?
Y
Done

03
Caching for SEV components
?
?
?
?
-

04
Add test for SEV-ES
?
?
?
?
-

05
Add test for signed images with SEV
?
?
?
?
-

06
Add memory dump test
Low?
?
?
?
-

07
SNP tests
Low?
?
?
?
There are a three different tests for the three phases of SNP support

A few initial comments,
First, using Kata's CI for the operator is really a political/business issue. CNCF won't really support Jenkins and we don't want to use GHA. One path forward is to find someone who wants to donate a node to be a Jenkins server. We would also need to find some resources to run the non-tee tests. This could be on a cloud somewhere or we might consider running these tests in VMs on one of the nodes that is running a baremetal test. I haven't had much luck finding these sorts of resources, but we could probably hunt them down.
Second, here are the CI changes that come to mind for SEV.

Collapse operator and Kata tests into one (sev.bats) -- this already happened.
Caching for SEV components -- Unmesh has PR for OVMF. Initrd has dependency on kernel build for module, which is suboptimal.
Add test for SEV-ES - this test should be more or less trivial but it is waiting behind Jim's annotation PR, which is waiting on some changes to the CI that I am working on.
Add test for signed images with SEV - This is a little bit more involved, but I think Alex is looking into it.
Add memory dump test -- Ryan and I have long wanted to add a test that searches the memory for sensitive information. Not a huge priority, but it could come soon.
SNP tests. There are a three different tests for the three phases of SNP support.

I will leave discussion of the spurious network issues to @ryansavino

and we don't want to use GHA

We actually cannot use GHA as it doesn't support nested virtualisation AFAIU.
If it does support, I'm all in for switching to that (not really needed for CC, but also relevant: https://github.com/kata-containers/ci/issues/529)

A comment I'd have on the SEV CI tests is that we already have testing for signature that the other platforms use. I'd much rather see the SEV testing move to run the existing tests and thereby give SEV the same test coverage as everything else and stay in sync with them when updates then add even more duplication, so I'd like to see the move in that direction if at all possible. As it stands I'm not sure how easy it would be to get agreement for the SEV tests (and therefore function) to be merged into main as it doesn't seem to follow the same approach as all the other integration tests, so I'd rather see it refactored now than expand and cause a bigger problem later. @ryansavino - we've mentioned this is passing a number of times, do you have any thoughts on the feasibility of this?

A few initial comments,

btw, very good comments, thanks!

First, using Kata's CI for the operator is really a political/business issue. CNCF won't really support Jenkins and we don't want to use GHA. One path forward is to find someone who wants to donate a node to be a Jenkins server. We would also need to find some resources to run the non-tee tests. This could be on a cloud somewhere or we might consider running these tests in VMs on one of the nodes that is running a baremetal test. I haven't had much luck finding these sorts of resources, but we could probably hunt them down.

I'm volunteering to co-owner that. For 0.4.0 I will be mostly work with the e2e CI for peer pods and there is an intersection with that because I don't to put yet another job on Kata's Jenkins nor use their sponsored Azure VMs.
I assume it will tracked on  https://github.com/confidential-containers/community/issues/67

Second, here are the CI changes that come to mind for SEV.
* Collapse operator and Kata tests into one (sev.bats) -- this already happened.

Cool! Could you please share the issue link?
For the below work items, I added them on the table in the description of this issue. It is missing their issues, owners and priorities (assume 06 and 07 are low; let me know if I am wrong).

* Caching for SEV components -- Unmesh has PR for OVMF. Initrd has dependency on kernel build for module, which is suboptimal.

* Add test for SEV-ES - this test should be more or less trivial but it is waiting behind Jim's annotation PR, which is waiting on some changes to the CI that I am working on.

* Add test for signed images with SEV - This is a little bit more involved, but I think Alex is looking into it.

* Add memory dump test -- Ryan and I have long wanted to add a test that searches the memory for sensitive information. Not a huge priority, but it could come soon.

* SNP tests. There are a three different tests for the three phases of SNP support.

I will leave discussion of the spurious network issues to @ryansavino

The other day we talked briefly about those errors. Quoting @ryansavino:
These are the errors that I've seen that I think are related to AMD network issues:

* openssl connect error
* spurious network error
* k8s apt key install error
* docker repository add error

@ryansavino do we already have issues for those errors?

@stevenhorsman
I'm not sure it makes sense to use the existing signature tests for SEV. The signature test that we have in mind uses the KBS to get the signature files after an attestation has taken place. Don't the current tests just put the signature information in the image? I guess it wouldn't hurt to also run those tests with SEV, but it wouldn't be testing attestation codepath. It's also not really a suggested use of CoCo with SEV.
Similarly I guess we could also run the existing authenticated registry tests with SEV, but really we should be getting that information via the KBS. Authenticated registries haven't really been on my mind, but we probably should add that test at some point. It should be fairly similar to the signature test.
In general, I think there is probably more code sharing that could be done between the tests, but I am a little bit wary of thinking of the non-tee tests as the definitive tests given that they don't have any attestation code. There are also a few pieces there that I find a little bit weird about the non-tee tests, like continuing to use Jakob's ssh-demo for the encrypted image (and checking out the docs repo to get it). It also does a few things that are redundant when running on the operator CI and directly modifies the kata config and the image (some places this is inevitable, but we are hoping to avoid both with the SEV CI). To be clear, I think non-tee tests are solid. The code looks lovely and they have really led the way for the project, but I get a bit defensive when you say that the SEV tests couldn't be accepted in main.
A few things I think we can do to converge would be to look into using some of the existing library functions, although I think many of them would have to change some, and to use the same images between tests. If there are other specific issues with the code, please let us know.

and we don't want to use GHA

We actually cannot use GHA as it doesn't support nested virtualisation AFAIU. If it does support, I'm all in for switching to that (not really needed for CC, but also relevant: kata-containers/ci#529). The thing we'd do for Kata Containers is to use our Azure sponsorship with GHA, but one thing we cannot be doing is using Kata Containers' Azure sponsorship to run the Confidential Containers CIs).

Thanks for the input @fidencio ! btw, we will be tracking that discussion on https://github.com/confidential-containers/community/issues/67 on CoCo side.
Any other work I think we should include on 0.4?

@wainersm
Many of those things have issues already. I will dig them up (was being a bit lazy yesterday) or make them and add to table.

We actually cannot use GHA as it doesn't support nested virtualisation AFAIU.
If it does support, I'm all in for switching to that (not really needed for CC, but also relevant: https://github.com/kata-containers/ci/issues/529). The thing we'd do for Kata Containers is to use our Azure sponsorship with GHA, but one thing we cannot be doing is using Kata Containers' Azure sponsorship to run the Confidential Containers CIs).

I think that it would not be impossible to use GHA. At the very least we could use a self-hosted runner for non-tee tests and do the virtualization ourselves. There are also some rumors about beta support for nested virt, but it's hard to find details. My sense is that this would be more messing around than it is worth, especially if we were trying to do it with so-called CNCF resources.

@stevenhorsman
I'm not sure it makes sense to use the existing signature tests for SEV. The signature test that we have in mind uses the KBS to get the signature files after an attestation has taken place. Don't the current tests just put the signature information in the image? I guess it wouldn't hurt to also run those tests with SEV, but it wouldn't be testing attestation codepath. It's also not really a suggested use of CoCo with SEV.
Similarly I guess we could also run the existing authenticated registry tests with SEV, but really we should be getting that information via the KBS. Authenticated registries haven't really been on my mind, but we probably should add that test at some point. It should be fairly similar to the signature test.

Thanks for the comments and sorry that I wasn't clear. What I'd intended to imply, (and I think the path that TDX & EAA are working on) is to improve those tests to support the remote KBS's as well, so we could have the same test scenarios for non-TEE with offline_fs_kbc, TDX with EAA_kbc and SEV with online_sev_kbc, but the specific data and images probably would differ for some of the cases.

In general, I think there is probably more code sharing that could be done between the tests, but I am a little bit wary of thinking of the non-tee tests as the definitive tests given that they don't have any attestation code. There are also a few pieces there that I find a little bit weird about the non-tee tests, like continuing to use Jakob's ssh-demo for the encrypted image (and checking out the docs repo to get it). It also does a few things that are redundant when running on the operator CI and directly modifies the kata config and the image (some places this is inevitable, but we are hoping to avoid both with the SEV CI). To be clear, I think non-tee tests are solid. The code looks lovely and they have really led the way for the project, but I get a bit defensive when you say that the SEV tests couldn't be accepted in main.

I in no way mean to imply that the current tests are perfect as they definitely aren't, I'd just prefer for us to converge so we can make everything better with enhancements we make, rather than having duplicated library code and test scenarios in multiple places so improvement to one is not reflected in others.

@stevenhorsman

Thanks for the comments and sorry that I wasn't clear. What I'd intended to imply, (and I think the path that TDX & EAA are working on) is to improve those tests to support the remote KBS's as well, so we could have the same test scenarios for non-TEE with offline_fs_kbc, TDX with EAA_kbc and SEV with online_sev_kbc, but the specific data and images probably would differ for some of the cases.

Yeah it's true that the codepaths for the other online KBS are wildly different. I'm not even 100 percent sure where those tests are. Would be good to bring them together somehow.

I in no way mean to imply that the current tests are perfect as they definitely aren't, I'd just prefer for us to converge so we can make everything better with enhancements we make, rather than having duplicated library code and test scenarios in multiple places so improvement to one is not reflected in others.

Yeah I think it would be good to have more shared library code. We can take a look at extracting some of the stuff we use for SEV. A lot of the complexity in those tests is SEV specific stuff, but there are definitely a few things that could be shared.

savino do we already have issues for those errors?

I'm tracking these internally at AMD as we investigate potential causes. I can provide updates here.

A comment I'd have on the SEV CI tests is that we already have testing for signature that the other platforms use. I'd much rather see the SEV testing move to run the existing tests and thereby give SEV the same test coverage as everything else and stay in sync with them when updates then add even more duplication, so I'd like to see the move in that direction if at all possible. As it stands I'm not sure how easy it would be to get agreement for the SEV tests (and therefore function) to be merged into main as it doesn't seem to follow the same approach as all the other integration tests, so I'd rather see it refactored now than expand and cause a bigger problem later. @ryansavino - we've mentioned this is passing a number of times, do you have any thoughts on the feasibility of this?

@stevenhorsman are you referring to the k8s tests? 5358 removed the custom SEV run.sh and converged all testing to the sev.bats file. Also, the target now follows the same pattern as the other kubernetes targets in the Makefile. This means that all the other K8S_TEST_UNION tests are now running for the SEV tests as well. Also, no more custom installing k8s and cleanup in our scripts. So I think this is done. Am I missing some other conformity to the integration tests that we need to address?

What I'm referring to a couple of things:

the SEV tests running the same test cases as the other platforms (with the required customisations of course, similar to the approach that EAA is taking e.g.: https://github.com/kata-containers/tests/blob/b76b3fa4dfc08e72bf5e30552393d125f061649b/integration/confidential/lib.sh#L295-L306), so that we can share them across platforms. As stated above, I completely agree that the current tests aren't perfect, but that's one of the main motivations to get them consolidated so that improvements to a single platform helps all of them.
Removing all the duplicated code in sev.bats e.g. at an initial glance I can see methods: get_version, configure_containerd, kubernetes_wait_for_pod_ready_state, get_container_id etc. From my understanding these are no specific to SEV and I know that we have code for most of them elsewhere. Obviously if we did 1. then it should do this automatically in the refactor process, but I'd be very happy to see this part done first and separately to start the process.

I hope that helps, but let me know if you want to chat through it further.

@stevenhorsman - Most of the items you mentioned are organizational, related to the consolidation/sharing of methods for setting things up in the scripts. The link you provided points to the methods for setting up signature verification.
I agree, we can organize/consolidate/share the scripting methods better in the sev.bats file and lib shell scripts. We'll start a PR for this. However, you mentioned that the SEV testing is not running all the existing tests and does not have the same test coverage. Are you referring to the signature verification discussed above? Or something else? I want to make sure that the SEV flows are not missing any tests.
@UnmeshDeodhar

However, you mentioned that the SEV testing is not running all the existing tests and does not have the same test coverage. Are you referring to the signature verification discussed above? Or something else? I want to make sure that the SEV flows are not missing any tests.
Maybe I'm out of date, but we have 13 test cases for the other platform's:
22:10:51 ok 1 [cc][agent][cri][containerd] Test can launch pod with measured boot enabled
22:11:06 ok 2 [cc][agent][cri][containerd] Test cannot launch pod with measured boot enabled and rootfs modified
22:11:21 ok 3 [cc][agent][cri][containerd] Test can pull an unencrypted image inside the guest without signature config
22:11:36 ok 4 [cc][agent][cri][containerd] Test can pull a unencrypted signed image from a protected registry
22:11:51 ok 5 [cc][agent][cri][containerd] Test cannot pull an unencrypted unsigned image from a protected registry
22:12:06 ok 6 [cc][agent][cri][containerd] Test can pull an unencrypted unsigned image from an unprotected registry
22:12:20 ok 7 [cc][agent][cri][containerd] Test unencrypted signed image with unknown signature is rejected
22:12:36 ok 8 [cc][agent][cri][containerd] Test unencrypted image signed with cosign
22:12:51 ok 9 [cc][agent][cri][containerd] Test unencrypted image with unknown cosign signature
22:13:06 ok 10 [cc][agent][cri][containerd] Test pull an unencrypted unsigned image from an authenticated registry with correct credentials
22:13:20 ok 11 [cc][agent][cri][containerd] Test cannot pull an image from an authenticated registry with incorrect credentials
22:13:34 ok 12 [cc][agent][cri][containerd] Test cannot pull an image from an authenticated registry without credentials
22:13:55 ok 13 [cc][agent][cri][containerd] Test agent API endpoint can be restricted

whereas SEV is not running any of them, but has 4 of it's own tests and they are only cover 2/3 of the above cases?:
17:52:38 ok 1 [cc][kubernetes][containerd][sev] Test SEV unencrypted container launch success
17:53:03 ok 2 [cc][kubernetes][containerd][sev] Test SEV encrypted container launch failure with INVALID measurement
17:53:11 ok 3 [cc][kubernetes][containerd][sev] Test SEV encrypted container launch success with NO measurement
17:53:21 ok 4 [cc][kubernetes][containerd][sev] Test SEV encrypted container launch success with VALID measurement

Okay got it. Thanks. We'll work to enable these for the SEV flow.

all, I feed the planning board (https://github.com/orgs/confidential-containers/projects/6/views/12) with items 02-05 from the table above. Feel free to add/remove/adapt items on the board.
I also added an item that I will be most of my time working on: https://github.com/confidential-containers/cloud-api-adaptor/issues/599

Ok, it seems like there is still some confusion about what type of consolidation we want. @UnmeshDeodhar created https://github.com/kata-containers/tests/pull/5449 to add some code sharing between sev.bats and the other tests, but it seems like what @fidencio had hoped for was to use just one set of tests (agent_image.bats and agent_image_encrypted.bats) and to add SEV cases to the tests that are already there (see
https://github.com/kata-containers/tests/pull/5449#pullrequestreview-1307828950). Is this correct?
Obviously we don't just want to run the non-tee tests for SEV because they don't have attestation, but most of the non-tee tests do have SEV counterparts, some of which are already in sev.bats. I don't think that we will support measured boot, but otherwise we could create an SEV case for all the non-tee tests. I see the appeal of having some sort of common flow. I think it could really help us understand the flows across different platforms, but keep in mind that a considerable amount of effort has gone into developing sev.bats which is finally starting to settle. There are also a number of pending development efforts to support signatures, authenticated registries, etc. Consolidating these tests is going to take time and will probably delay the introduction of new tests as well as reset the clock on the maturity of the existing ones. Is it worth the effort to end up with something that will be functionally the same (but with a ton of switch statements)?
If we are set on this consolidation, should we try to do that sooner (and delay adding new tests) or later (and have more tests to move over). Also keep in mind that we will soon start to have SNP tests, which will be largely disjoint from the SEV tests. The plan had been to create snp.bats and make a new SNP job. Should we do something different?
@stevenhorsman

Good point @fitzthum. I was also under the impression that, since SEV tests require additional steps to be done, it will make more sense to keep them separate from the common flow. Otherwise, in the common test, we need multiple switch cases to perform extra steps needed for SEV.

@UnmeshDeodhar

Good point @fitzthum. I was also under the impression that, since SEV tests require additional steps to be done, it will make more sense to keep them separate from the common flow. Otherwise, in the common test, we need multiple switch cases to perform extra steps needed for SEV.

I think the big drawback is that right now nobody who isn't working on SEV looks sev.bats. Maybe consolidating would help get some more eyes on the code. Realistically, though, people would probably still mainly look at the parts that they care about. I have a suspicion that if we did a bunch of work to consolidate them we would end up with a ton of switch statements and then someone down the line would suggest just separating out the SEV tests to make it simpler. I think the most important thing is that we have parity, and that is what we are aiming for either way.

I'd like to have a call, maybe at some point next week to have a final decision and agreement on where we're going to, as I have the feeling the discussion here will just be going back and forth on what the Kata Containers maintainers who are working on CoCo prefer, and what the AMD folks want to do.
I'd like to also have AliBaba into the call, as they're adding support to TDX with dragonball, then we discuss what's the best way to move forward, as a community, for the whole set.
For now, let's just put this on hold.

Ok, it seems like there is still some confusion about what type of consolidation we want. @UnmeshDeodhar created kata-containers/tests#5449 to add some code sharing between sev.bats and the other tests, but it seems like what @fidencio had hoped for was to use just one set of tests (agent_image.bats and agent_image_encrypted.bats) and to add SEV cases to the tests that are already there (see
kata-containers/tests#5449 (review)). Is this correct?

No, this is not correct, and I'd prefer keeping this discussion in the specific PR.  But as we're here ...
The PR consilidates the methods used into sev.bats but ignores that there are ways to achieve that using the infrasctruture already provided (as in other methods already existent) as part of the tests.
If there's a way to improve the current methods (and hey, I do think there is), then the PR should cover the improvement on all tests, not only in the SEV ones.
Apart from that, which was the comment that I made as part of my review (and I still don´t get why it was not answered there), there's the point that @stevenhorsman raised and @ryansavino said they'd work on this (see: https://github.com/confidential-containers/community/issues/69#issuecomment-1409026891).  The "
Okay got it. Thanks. We'll work to enable these for the SEV flow." gave me the idea that the consolidation would come enabling the tests as part of the SEV flow.
@fitzthum, is there anything that was missing from my review / take on this that you'd like to have clarified?

Ok, let's setup a call for next week and really get on the same page. @fidencio I guess you suggestion was not as extreme as I had first thought. You want to not merely copy the code from sev.bats to lib.sh, but to actually consolidate functionality. Very understandable. And you are saying that rather than join all the bats files together we should move them from integration/kubernetes/confidential to integration/kubernetes when we are ready to merge into main. Is that right?
That sounds totally compatible with the development that we have planned to bring full coverage to the sev tests.

There are two points, Tobin.
The first one is, and I just discussed this with @UnmeshDeodhar, is that we should create a kubernetes/libs.sh and actually consolidate there the common functions (or common code that can be replaced by functions) that are used by the kubernetes/*.bats, kubernetes/confidential/*.bats, and kubernetes/sev/*.bats.  This is what I consider the very first stage of consolidation.   Examples of this are common methods to install / configure containerd, or functions / ways to change the Kata Containers configuration files.  Those things are already there and we shouldn't be doing those in different ways.
Whether we'll get to the point to merge sevs.bats into  agent_image.bats  is the second point and it's a conversation we'll have to have and decide this as a community.  If the maintainers of the project see the benefit of doing that, that's the way we should go, and I had understood that @ryansavino was okay with this approach based on https://github.com/confidential-containers/community/issues/69#issuecomment-1409026891, but let's have this discussion next week.
One problem that I'm having here is the perception, my perception, that any review provided by the community is not exactly welcome as it'll  generate more work (and that's generally the case, reviews will end up generating more work, even if it's to simplify the work ...).  We're not here to provide just a rubber-stamp on things that have a green CI, mainly if we foresee those things will generate us headache in the future, and I'd appreciate if everyone could take the "criticism" in the best way possible.

Ok. Point 1 is very reasonable and I agree that we will have to figure out what is optimal on the second front.
There's no hesitation to do work on the CI. It's guaranteed that there is going to be a lot of work to get anywhere. There are some real tradeoffs that we will have to think about, but I don't see this as too dramatic. We're all aiming for the best possible solution.

I think we are 4 releases out from 0.4.0 should we close this one?


fix "astro build"

This doesn't seem to be looking for the correct path in the key.

Thanks.. difference between the local repo and deployed node_modules I imagine.


Ligatures in Linux Libertine are displayed incorrectly

I have the following document created in LuaTeX using the Linux Libertine OpenType font:
http://refsmmat.com/files/microcosmographia.pdf
In Firefox 29.0.1 on Mac OS 10.9.3, some of the ligatures are displayed corrupted (both in-browser and in the online viewer). For example, from the first page of that document:

and

Curiously, the "fi" ligature in the second image is fine, but the "ft" ligature is not.
The document displays fine in Preview and Adobe Reader. I tried switching to the Apple-supplied Times font and ligatures appear fine. But Libertine has an abundance of unusual ligatures.

I've just tried the web viewer again (Firefox 39, OS X 10.10.4) and the ligatures work correctly. The pdf.js version shipped with Firefox 39 still has the bug. Some recent change must have fixed it. I assume the fix will land in Firefox fairly soon?

@capnrefsmmat Yes, probably within one or two versions.


start lightning network daemon lnd again

now that we've

generated a new TLS cert
added a new neutrino.addpeer entry into lnd.conf (see issue #8)

we can start lnd again and see if it can connect to the bcoin node that we're running on the same server
## Run LND

# switch to bash if you are using another shell
$ bash
$ nohup /root/go/bin/lnd > /root/.lnd/lnd.log 2>&1 &
$ lncli create

first attempt

➜  ~ bash
root@vultr:~# nohup /root/go/bin/lnd > /root/.lnd/lnd.log 2>&1 &
[1] 20475
root@vultr:~# lncli create
Input wallet password:
Confirm wallet password:

Do you have an existing cipher seed mnemonic you want to use? (Enter y/n): n

Your cipher seed can optionally be encrypted.
Input your passphrase you wish to encrypt it (or press enter to proceed without a cipher seed passphrase):

Generating fresh cipher seed...

[lncli] unable to generate seed: rpc error: code = Unimplemented desc = unknown service lnrpc.WalletUnlocker
root@vultr:~#


sim handles dendro + hydro application within the same frame incorrectly

viewer link: https://gcsim.app/v3/viewer/share/de85789c-0c9a-41dd-aeb0-c6f1b2e94215
at frame 709

a bit of a known issue i guess. has to do with the way "srp" gets handled. don't have a good solution just yet. let me think about it

related to #390


Yolo 9000 for object detection

Hello Everyone, i am trying to use yolo 9000 for object detection. i read yolo9000.cfg file using darknet. but, i am unable to read the weight files using darkflow.. could any one please help me out..
`
net=cv2.dnn.readNetFromDarknet("(r"C:\Users\Desktop\darknet-master\darknet-master\cfg\yolo9000.cfg")
net1=cv2.dnn.readNetFromDarknet(r"C:\Users\Desktop\darknet-master\darknet-master\yolo9000.weights")`
error                                     Traceback (most recent call last)
 in
----> 1 net1=cv2.dnn.readNetFromDarknet(r"C:\Users\Desktop\darknet-master\darknet-master\yolo9000.weights")
error: OpenCV(4.1.2) C:\projects\opencv-python\opencv\modules\dnn\src\darknet\darknet_importer.cpp:207: error: (-212:Parsing error) Failed to parse NetParameter file: C:\Users\Desktop\darknet-master\darknet-master\yolo9000.weights in function 'cv::dnn::dnn4_v20190902::readNetFromDarknet'

What's the md5 for C:\Users\Desktop\darknet-master\darknet-master\yolo9000.weights?

Does OpenCV have an implementation of YOLO9000? Mine (OpenCV 4.4.0) complained that
CV_Error(cv::Error::StsNotImplemented, "Yolo9000 is not implemented");

Does OpenCV have an implementation of YOLO9000? Mine (OpenCV 4.4.0) complained that
CV_Error(cv::Error::StsNotImplemented, "Yolo9000 is not implemented");

i have same erorr still with opencv 4.5.0
have you successful to solve this problem ?

Has same issue with OpenCV 4.4.0. It's said Yolo9000 is not implemented in function 'cv::dnn::RegionLayerImpl::RegionLayerImpl'

@philipperemy
@wwJinkla
@mv2050arshad
@khumam
@srividya91
i want to use yolo9000 model in android application, what is the process to convert the model to tflite model or other android suitable model, please respond ....


[RFC] break, next and return and blocks

Currently the rules for those keywords are dramatically different depending on whether the block is captured or not.
With a not captured block

break exits from the calling method, the argument provides the methods return value
next exits from the block, the argument provides the blocks return value
return exits from the method the block is defined in

With a captured block

break is disallowed
next is disallowed
return exits from the block, the argument provides the blocks return value

Proposal
I think it would be more consistent to swap the meanings for next and return in the captured block case. This way, if the library decides to not capture the block or vice versa, less code on the caller side is affected. More importantly the caller doesn't need to think about whether the block is captured or not in order to understand what the return inside a block is doing.

"return" escaping closures is the same in other languages, such as scala. That's why it's generally discouraged.

Maybe, that's not my point though. My point is that I shouldn't have to think about whether the block will be captured or not when I want to exit it early.

@jhass I think what you propose makes total sense. For example this code:
def foo
  bar do
    return 1
  end
end

Without knowing what bar does, I read it and I associate that return with exiting foo. If bar doesn't capture the block, that's fine. But if it captures it, the meaning will suddenly change and I will probably have a bug in my code. If we change it to what you propose, I will get a compile-time error, knowing that the block was captured, and that I have to rethink the code.
/cc @waj, @bcardiff what do you think?

@jhass What about inline procs?
f = ->{
  break # disallowed

  # Which of the following exists f?
  next
  return
}

Mmh, tricky. Ruby differentiates whether it's Proc.lambda? apparently.
# In Ruby
proc { break :a; :b }.call # LocalJumpError
proc { return :a; :b }.call # LocalJumpError
proc { next :a; :b }.call # :a
def foo; proc {  break :a; :b }.call; :c; end; foo # LocalJumpError
def foo; proc {  return :a; :b }.call; :c; end; foo # :a
def foo; proc {  next :a; :b }.call; :c; end; foo # :c
def foo(a) a.call; :c; end; foo proc { break :a; :b } # LocalJumpError
def foo(a) a.call; :c; end; foo proc { return :a; :b } # LocalJumpError
def foo(a) a.call; :c; end; foo proc { next :a; :b } # :c

-> { break :a; :b }.call # :a
-> { return :a; :b }.call # :a
-> { next :a; :b }.call # :a
def foo; -> {  break :a; :b }.call; :c; end; foo # :c
def foo; -> {  return :a; :b }.call; :c; end; foo # :c
def foo; -> {  next :a; :b }.call; :c; end; foo # :c
def foo(a) a.call; :c; end; foo -> { break :a; :b } # :c
def foo(a) a.call; :c; end; foo -> { return :a; :b } # :c
def foo(a) a.call; :c; end; foo -> { next :a; :b } # :c

So the lambda is very close to an anonymous function but retains the block semantics of break and next too. Since in Crystal the literal is even closer to an anonymous function, I think it would be fair to disallow next and break and only allow return to exits the function itself.
However that means Crystal would need to differentiate the -> { } literal and a captured block def foo(&block), which I'm not sure it does atm. This also raises the question on what to do in the foo(&-> { }) case, I'd argue retain the -> { } semantics since that's what the caller sees and knows.
So I'm not 100% sure, what do you think?

What is the status on this one. I'm glad it will be changed to be consistent to the users intention (if I didn't misunderstand).


Fix typo

Thanks @NIC619 https://github.com/ethereum/eth2.0-specs/pull/1219#discussion_r298818138
Curious if linting could have caught this.

@CarlBeek Please open an issue for the linting.


/input/LookVertical ?

OSC can move forward/back/left/right and look left/right but without up/down it is incomplete..

Since LookHorizontal works for both desktop and VR, it would make sense for LookVertical to work for both aswell.
BUT it would only pratically make sense in desktop, because if you think about it, you can not really force a players viewpoint in VR to look up or down, that comes down to the persons actual head rotation.
IMO LookVertical can be implemented, but it should only work in desktop.


fix(curriculum): 2 typos in curriculum files

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #47689

It Fixes typos in two different files.

Hey @slayeh17
This PR seems to make similar changes as the existing PR <#47690>. As such, we are going to close this as duplicate.
If you feel you have additional changes to expand upon this PR, please feel free to push your commits and request this PR be reopened.
Thanks again! 😊

If you have any questions, feel free to ask questions on the 'Contributors' category on our forum or the contributors chat room.

Alright Thank you 😊


fieldset disabled attribute  I was hoping a wide support but looks like it only works in Chrome and ...

fieldset disabled attribute
I was hoping a wide support but looks like it only works in Chrome and FF.

This issue was imported from Google Moderator
Moderator votes: +3
Issue added by Stefano on 2014-05-09
To vote this issue up or down, simply include +1 or -1 in your comment.

+1


Request: Add I’m feeling lucky button on mini player

Adding this button would be a cool improvement for the lazy ones (like me)

This has been addressed before and is a limitiation of how GPM works.  Simulating clicks on the I'm feeling lucky button doesn't work for whatever reason


PHPDoc order

In the past I ordered phpdoc like this: params first, then return and throws at the end.
However phpdoc_order fixer follows param, throws, return order.
Honestly, I followed the upper way because I thought that's some kind of standard. Isn't it?
/cc @dbu

i have never seen that order styleci seems to want. i always had param,
return, throws as well. i would prefer to keep it that way, seems so
much more logic.

This means, that we turn off any ordering (param, return, throws).

okay. i think we will notice during review when they are out of order.


Run bootstrap before linting on CI

See https://storybooks.slack.com/archives/C4Q0S3MQR/p1503243475000043
I've added only those bootsrappers, lack of which produced issues for me. Maybe it's worth to add some more (or remove bootstrap:docs)
The issues I faced are:

In, #1676, the only reason we can't promote import/extensions to "error" level is that packages highlight.js and fuse.js are treated by this rule as local files unless they're actually installed
In #1696, I have to add dependencies to eslint-plugin-flowtype, eslint-plugin-flowtype-errors, and flow-bin to root package instead of lib/components so that they're installed with simple yarn install without bootstrapping

The main problem is that all those issues are discoverable only when it actually fails on CI (unless you run git clean --fdx before each commit)

I'm not opposed to this at all, but please state the reasons clearly in the PR, Slack messages get lost over time, and the message you link to does not give a comprehensive picture of why this is exactly needed, thanks 👍

I've added some clarifications

Using close colours for background and text leads to bad readabiity =(

Are those lines really needed?

I'm currently working on enabling yarn workspaces, which should make this PR partially obsolete.
@ndelangen is there any solid reason why we bootstrap docs package separately from others?

In fact, even with #1810 there's still a sense in running bootstrap: it removes a bunch of imports/no-unresolved warnings which are present because of lack of dist folders. This can allow to raise this rule to error level as well

Well the reason for not bootstrapping docs along with core, is because often it's not needed.
I would like to be able to bootstrap sections individually.
So a developer can choose what to work on, and get some faster bootstrap.
BUt it's a nice to have, I do not oppose including docs into the default bootstrap, but it is unnecessary for 90% of the development that occurs currently. (And even if the code-change is in docs, often it can be worked on from github GUI or without running the docs app to begin with)

Let‘s measure how much does it add up to clean bootstrap time

Unfortunately, when I try to add docs to workspaces, the build command fails:
Error: Error: Cannot find module './addons/_template.jsx'.
    at render-page.js:31859:42
    at webpackContextResolve (render-page.js:31859:90)
    at webpackContext (render-page.js:31856:30)
    at render-page.js:25774:36
    at Array.forEach (<anonymous>:null:null)
    at module.exports (render-page.js:25744:27)
    at render-page.js:90:40
    at module.exports (render-page.js:31819:11)
    at Object.<anonymous> (render-page.js:89:2)
    at __webpack_require__ (render-page.js:30:30)

Superseded by #1934


Update webdrivermanager to 5.3.0

Updates io.github.bonigarcia:webdrivermanager from 3.8.1 to 5.3.0.
Changelog
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (3.8.1).
You might want to review and update them manually.
metabrowse-js/yarn.lock

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.github.bonigarcia", artifactId = "webdrivermanager" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "io.github.bonigarcia", artifactId = "webdrivermanager" }
}]

labels: library-update, early-semver-major, semver-spec-major, old-version-remains, commit-count:1

Seems the commits are wrong.


Drop Python 3.7 support

Summary
Qiskit has dropped support Python 3.7 and this follows suit for Finance.

[ ] Update branch rules

Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 75.822%

Totals

Change from base Build<PHONE_NUMBER>:
0.03%

Covered Lines:
646

Relevant Lines:
852

💛  - Coveralls


issue with spark-ui-proxy

Hi,
I followed all steps until Step 2:
$ kubectl create -f staging/spark/spark-ui-proxy-controller.yaml
replicationcontroller "spark-ui-proxy-controller" created

$ kubectl create -f staging/spark/spark-ui-proxy-service.yaml
service "spark-ui-proxy" created

$ kubectl get svc spark-ui-proxy -o wide
NAME             TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE       SELECTOR
spark-ui-proxy   LoadBalancer   <IP_ADDRESS>    <pending>     80:31945/TCP   9m        component=spark-ui-proxy

i dont get the external IP, why is that? i waited 10 min between spark-ui-proxy and kubectl get svc spark-ui-proxy -o wide...

@Arnold1  this is not an issue, since LoadBalancer type service need a cloud provider such as  GCE,  do you have it?

@huxiaoliang I am also having same issue and I am running it on GCE .
Note : It was working earlier and external ip was showing up .

hi, what is GCE and how to install it? does it say that in step 2?


[FEATURE REQUEST] About Me Section

I am not sure if the theme has the updated about me section for userpopouts. It doesn't say "about me" when you click on the userpopouts. Also, some of the words are cut off on the about me section

The about me section is there, just the title is removed. E.g. here aaaaaaaa is the status and eeeeeeee is about me. Is this confusing to you? Should I add the title back?

And could you tell me where you're seeing words being cut off?

Oh okay. Yeah, I think I just got confused because I didn't see the about me.

It's when you click on view profile.


N=1024 or N=2048

Is there any theoretical reason that N=1024, 2048 can not be used for this protocol? Or is it just a technical limitation in SEAL? If the limitation is theoretical, can you point me to any papers which discuss this limitation?
Thanks.

SealPIR depends on RLWE encryption (BFV cryptosystem in particular). This encryption has 3 parameters that all interact with each other in particular ways.
N = polynomial degree
q = coefficient modulus (i.e., modulus of coefficients in ciphertext polynomials)
t = plaintext modulus
For security, N and q need to have certain values based on t. For correctness (to get a valid result that's not corrupted by too much noise), they also need to have certain values based on the number of operations that you will be performing.
I'm not sure N = 1024 will work for large databases. Perhaps.
N = 2048 should work (indeed we used this in our prior implementation), but the current version of SEAL does not support certain operations we need (e.g., key switching, galois automorphisms)  with N = 2048.

So aside from choosing parameters which are secure and the noise does not corrupt the message, there is no limitation?

Thanks Sebastian for your answer.
I'm looking through the SEAL repository and the condition on which they allow galois automorphisms is captured in this line:
https://github.com/microsoft/SEAL/blob/206648d0e4634e5c61dcf9370676630268290b59/native/src/seal/context.cpp#L494
Tracing back the code, the reason that the condition on this line fails for N=1024 is that the coefficient modulus chain is of length one. Do you have insight as to why the developers of seal placed this limitation? Is a coeff mod chain of length 1 an actual limitation?
I should note that I am interested in PIR over a small database, which is why N=1024 might still be an option for me.


google-common/webauth/gauth [patch]: Fixes for error, safety, and image handling

Addresses several oddly related issues:

New error handling tailored to Google's error codes and messages
Prompt block errors and exceptional finish reasons now raise an Error

This is tailorable by writing a handler that treats this differently, including rewriting the response

Provide custom .stream() and .invoke() methods for the GoogleLLM classes so they can accept image parts.

This is done by creating an calling a chat model.

This included extensive additional tests.
(There are also some tests that are currently skipped because Google is raising safety errors on them. Other tests have been added to replace these.)
Fixes #4374 #4375

@jacoblee93  - If you can look at GoogleBaseLLM.stream() to make sure the solution to create an IterableReadableStream<string> makes sense, I'd appreciate it.

Mostly looks great! Will dig in and override the proper method hopefully tomorrow.

@jacoblee93 - The integration tests for google-gauth and google-webauth pass
Everything looks good to me.
Please update the version on all three packages when merged.
Thanks for your help!

Thank you!


[docs] Update sizes for responsive media queries

The docs still say "768 to 940" and "940 and up" when there was a recent commit to change it to 980.
This should be updated.

Resolved, thanks!


notFound Template doesn't work

Hello,
I have this Code:
var wpsearch = new Bloodhound({
  datumTokenizer: Bloodhound.tokenizers.obj.whitespace('value'),
  queryTokenizer: Bloodhound.tokenizers.whitespace,
  remote: {
    url: wp_typeahead.ajaxurl + '?action=ajax_search&fn=get_ajax_search&terms=%QUERY',
    wildcard: '%QUERY'
  }
});

$('#input-typeahead').typeahead(null, {
  name: 'search',
  display: 'value',
  source: wpsearch,
  templates: {
        suggestion: function(data){
            return ''+data.value+'';
        },
    }
});

When it's nothing found, it just returning undefined.
Suggestion works but if I add notFound in templates, it just doesn't work. I tried pending, header, footer, they work but notFound doesn't.
Anyone experienced this problem? Am I doing something wrong?
Thanks.

// here's what i've done
var notFound;
notFound = function () {
// put whatever
return 'Not found'
}
$('#input-typeahead').typeahead(null, {
name: 'search',
display: 'value',
source: wpsearch,
templates: {
suggestion: function(data){
return ''+data.value+'';
},
notFound: notFound
}
});

Thanks for the code @rhokstar but still doesn't work. Still returning suggestion template instead of notFound...

same here. It works though, if I set notFound's value to string instead of a function like:
notFound: 'no result'

+1
At first I thought notFound was not happening because of the !this.async thing but switching my bloodhound to 'local' does not allow it to work.
We may just be doing it wrong but I've tried about everything, I'd love a simple jsfiddle that demonstrates it working. Then we can figure out what we're doing wrong and/or if there is a bug/missing feature.

Working version of using notFound template - http://jsfiddle.net/gmerideth/v9erxmpd/1/

suggestion overwrites notEmpty when using remote/bloodhound - why?

+1

+1

I was able to get notFound working with ...
templates: {
    notFound: function (data) {
        return '
Sorry, no results found for query: ' + data.query + '
';
    }
}


2165 bug trade refresh

Coverage remained the same at 68.361% when pulling 0ea81bf83f3f44de5b6df7b52dde1c32fc45c618 on 2165-bug-trade-refresh into dff9dfa4f8d344403b32a7327fa7a6ad98e0093d on master.


Multiple view inputs

Hi,
Do you have plans to implement multiple view inputs as in PIFu?

It is definitely possible to incorporate HRI and even DOS into a multi-view PIFu. We do not have plans to add that as a feature, but we have seen that it works. You might want to start by implementing a multi-view PIFu first. Then simply add HRI to the encoder/filters of the multi-view PIFu. So instead of combining the multi-view features of the multi-view PIFu's encoder in the MLP, we will combine the multi-view features of the HRI in the MLP.


List is not working as expected

The list is not working properly

List. ---> "List"
getting this in out put

To me its working fine:

Did you include a stylesheet?

yes I have include

is  this issue of stylesheed

Closing due to no activity


Graphic themes missing

The additional graphic themes from GDash are missing (boulder_rush.png, c64_gfx_bd2.png, c64_gfx.png). Best adding these to a separate folder called "themes".

Will be done in the next release. Have you noticed duplicate entries?
GDash will search for themes in installation directory and current directory and if they are identical (which is usually the case) we get duplicates. Don't really know how to avoid this without breaking the code...

working now! :)


Inconsistent language-code strings lead to inconsistent normalization

This has apparently been the case for a while, but we should fix it in an update:
The tokenize function assumes it's getting a nicely-normalized language code. But when looking up word frequencies, we don't actually normalize the language code until later, and we do it inside get_frequency_list without returning it.
I can think of an ugly fix we could make right away, or a nice fix that would require a change to langcodes to make simple cases of language matching faster.

This was fixed by #49.


command 'HookyQR.beautifyFile' not found

EDIT: Issue stopped happening, please close.

Operating System (+Version): MacOS 10.13.1
VS Code Version: 1.20.1
beautify Version: 1.3.0

NOTE: Please provide code snippets instead of screen shots. Your issue needs to be replicated, and we need the failing code (text) to do this.
Provide the settings you use:
(VS Code workspace and user settings, .jsbeautifyrc, .editorconfig)
eg.:
VS Code:
{
    "editor.fontSize": 13,
    "workbench.iconTheme": "material-icon-theme",
    "git.confirmSync": false,
    "vim.disableAnnoyingNeovimMessage": true,
    "editor.fontFamily": "'Menlo for Powerline', Menlo, Monaco, 'Courier New', monospace",
    "workbench.colorTheme": "One Dark Pro",
    // "window.titleBarStyle": "hidden",
    // "workbench.editor.showTabs":false,
    "vim.statusBarColorControl": true,
    "vim.statusBarColors" : {
        "normal": "#004242",
        "insert": "#282c34",
        "visual": "#43007e",
        "visualline": "#005f87",
        "visualblock": "#86592d",
        "replace": "#000000"
    },
    "workbench.colorCustomizations": {
        "statusBar.background": "#004242",
        "statusBar.noFolderBackground": "#004242",
        "statusBar.debuggingBackground": "#004242"
    },
    "materialTheme.cache.workbench.settings": {
        "themeColours": "Darker"
    },
    "window.zoomLevel": 0,
    "git.enableSmartCommit": true
}

Action performed
Format javascript file with HookyQR.beautifyFile command
Any file. I'm just using a standard JSON one.
Expected results
Code to be beautified
Actual results
VS Code Error: command 'HookyQR.beautifyFile' not found
Beautify selection also does not work:
command 'HookyQR.beautify' not found
I've seen some past issues with this same error, but those fixes don't seem to work (namely npm install --production)

My issue stopped happening when I tried disabling and re-enabling some other extensions, please close.


docs: Improve Azure Pipelines page

I noticed a weird error here. If I set the Dagger cloud token the pipeline always fails.
2024-09-10T19:11:40.8831113Z 11  :   resolving module ref
2024-09-10T19:11:44.1331199Z 12  :   installing module
2024-09-10T19:11:44.3329138Z 11  :   resolving module ref DONE [3.3s]
2024-09-10T19:11:45.5039315Z 12  :   installing module
2024-09-10T19:11:45.5040832Z 13  :     ModuleSource.asModule: Module!
2024-09-10T19:11:45.5041233Z 13  :     ModuleSource.asModule ERROR [1.4s]
2024-09-10T19:11:45.5042348Z 13  :     ! failed to create module: select: failed to update codegen and runtime: failed to generate code: failed to get modified source directory for go module sdk codegen: select: failed to compute cache key: failed commit on ref "layer-sha256:949a3a8507e41f94a4bc081b12d58cd47ba52ad6c4ed9ccc3b154c4fed530f42": "layer-sha256:949a3a8507e41f94a4bc081b12d58cd47ba52ad6c4ed9ccc3b154c4fed530f42" failed size validation: 127 != 102: failed precondition
2024-09-10T19:11:45.5042986Z 12  :   installing module ERROR [1.4s]
2024-09-10T19:11:45.5059672Z 12  :   ! input: moduleSource.asModule resolve: failed to create module: select: failed to update codegen and runtime: failed to generate code: failed to get modified source directory for go module sdk codegen: select: failed to compute cache key: failed commit on ref "layer-sha256:949a3a8507e41f94a4bc081b12d58cd47ba52ad6c4ed9ccc3b154c4fed530f42": "layer-sha256:949a3a8507e41f94a4bc081b12d58cd47ba52ad6c4ed9ccc3b154c4fed530f42" failed size validation: 127 != 102: failed precondition
```

And when I remove the token, it always passes. Any idea why? Is it related to the Dagger Cloud cache?

@jedevc @gerhard your thoughts?


AsyncLoad warnings in console (Webpack 4)

I am getting a few warnings from AsyncLoad.js. Are you planning to fix these?
client:148 ./node_modules/mathjax3/mathjax3/util/AsyncLoad.js 8:15-34
Critical dependency: the request of a dependency is an expression

client:148 ./node_modules/mathjax3/mathjax3/util/AsyncLoad.js 8:15-34
System.import() is deprecated and will be removed soon. Use import() instead.
For more info visit https://webpack.js.org/guides/code-splitting/

This is a duplicate of (part of) #88.  This comment tells you how to work around the warning.

I tried using the webpack (4.16.5) workaround with beta1 as described in #88 .
      new webpack.NormalModuleReplacementPlugin( // remove MathJax3 warnings
          /AsyncLoad\.js/,
          function (resource) {
            resource.request = resource.request.replace(/AsyncLoad/,"AsyncLoad-disabled");
          }
      )

However, I'm getting:
client:162 ./node_modules/mathjax3/mathjax3/input/mathml/MmlEntities.js
Module not found: Error: Can't resolve '../../util/AsyncLoad-disabled.js' in '/Users/stnor/devel/src/nomp/frontend/node_modules/mathjax3/mathjax3/input/mathml'
errors @ client:162

Also I'm thinking the regexp should be more specific to mathjax rather than everything matching    /AsyncLoad.js/,
Any ideas?

There doesn't seem to be any JS version of "AsyncLoad-disabled.ts" in the beta.

I'd rather wait for a new beta rather than creating a class for my app that would do the same as the (not) provided workaround.

Also I'm thinking the regexp should be more specific to mathjax rather than everything matching /AsyncLoad.js/,

Sure, use whatever is necessary in your situation.

There doesn't seem to be any TS or JS version of "AsyncLoad-disabled.ts" in the beta.

I've just checked the GitHub beta branch and ts file is there (See here, and I just downloaded the the npm packaged version, and both the files are there.   (The .js files aren't stored on github, but are included in the npm package.)
Are you sure you are using the beta branch (if from GitHub), or the current version (if from npm)?

I'd rather wait for a new beta rather than creating a class for my app that would do the same as the (not) provided workaround.

I'm not sure I understand.  The AsynchLoad.js file is not expected to change in the next beta, so waiting for beta.2 will not change this.

I have a massive JS app, and the best way i can limit the regexp is by using something like:
/../util/AsyncLoad.js/ and that seems like too much of a risk to hit other libraries or my own code.
Would it be possible to make it include mathjax3 even thought the imports are ..\util... in mathjax?

Doh, I switched branch (master was using alpha1) and forgot to yarn install... sorry

Would it be possible to make it include mathjax3 even though the imports are ..\util... in mathjax?

I'm not sure what "it" refers to in "make it include..."  If you mean webpack, I'm afraid I am only a novice webpack user, and don't know if it is possible to force path expansion before the regex.  Did you try /mathjax3\/util\/AsyncLoad\.js/ to see if it could be found that way?
If you mean MathJax itself, then I suppose it could be done by changing
import {asyncLoad} from '../../util/AsyncLoad.js';

to
import {asyncLoad} from '../../../mathjax3/util/AsyncLoad.js';

It looks like the only reference to AsyncLoad uses two sets of double dots, so you might be able to reduce the chance of incorrect matches by using
/\.\.\/\.\.\/util\/AsynchLoad\.js/

if that helps.

This is a safe approach should anyone else want to remove the warnings:
      new webpack.NormalModuleReplacementPlugin( // remove MathJax3 warnings
          /AsyncLoad\.js/,
          function (resource) {
            if (resource.context.endsWith('mathjax3/util')) {
              resource.request = resource.request.replace(/AsyncLoad/,'AsyncLoad-disabled');
            }
          }
      )

Thanks for finding the solution!


Release Google.Cloud.BigQuery.Connection.V1 version 2.1.0

Changes in this release:
New features

Add service_account_id output field to CloudSQL properties (commit c72ac43)

Created release for Google.Cloud.BigQuery.Connection.V1-2.1.0


IteratorEnvironment fixes

closes #4810

Fixed some inconsistencies and bugs in (non-test) implementations of IteratorEnvironment

Fixed RFileScanners unexpected UnsupportedOperationException when calling env.getServiceEnv() or env.getConfig() (both deprecated) or env.getPluginEnv()
Some impls returned a new ServiceEnvironment for each call to getServiceEnv()/getPluginEnv(). This did not align as well with the IteratorEnvIT which would assert that these two calls return the same object. Memoize a supplier to the ServiceEnvironment to avoid creating the object unless needed and to return the same object each time.
Seems like isUserCompaction() and isFullMajorCompaction() are supposed to be throwing an IllegalStateException if it's not a major compaction. Added missing javadoc to isUserCompaction() and changed impls that were not adhering to these docs.

Added tests for these environments to IteratorEnvIT

Questions:

Need confirmation, but it was my interpretation that a TableId doesn't make sense in the context of RFileScanner. Is this correct? ANSWERED
I have getConfiguration() throw an error in RFileScanners IteratorEnvironment since I'm not sure how we would return the system config in this context and I don't think it would even make sense here. Does this seem right? ANSWERED
Made the IteratorEnvironment for RFileScanner return null and not throw an error on env.getTableId() so something like: env.getPluginEnv().getConfiguration(env.getTableId()) can be done. Thoughts on this? ANSWERED

After a conversation with @kevinrr888, I added commit 5924b02c065297886ede479fbcf9750e699e4362 to incorporate some of the changes we discussed, that he intends to build on and polish up. The main points included were:

Push a reasonable getConfig() implementation up into IteratorEnvironment's default method (depends on the ability to have getTableId() return a null value)
Include concrete implementations of getPluginEnv() instead of just getServiceEnv() to make it easier to just drop the deprecated one when merging to newer branches
Consider using a Proxy instance of TableId instead of a real instance, so it isn't possible to be confused with any similar user-constructed TableId (may not work)
Update javadocs in RFile to make it clearer how properties set on the scanner builder (such as iterators) will be available to client-side iterators from the plugin environment

The main thing left unresolved after our conversation was how to fix the mismatch between the implementations and the javadoc for all the methods that inconsistently return null or throw IllegalStateException or UnsupportedOperationException, when calling a method that doesn't apply to a given situation (like asking for a table ID or table name when operating directly on RFiles or asking if it's a user-initiated compaction when it's a scan). Nearly every caller seems to have a unique set a requirements/implementation, and it's a bit hard to home in on the best implementation, especially for the default methods, and make sure the javadoc matches the behavior.

Comment about IteratorEnvironment.getConfig():
It might be strange to have a default impl for this method but not others... If we do want a default impl for this that isnt just throwing a UOE, we should probably change the others too... But that should be done in a follow on if that is desired. Keeping the default as throwing a UOE keeps it consistent with the other default impls/more inline with the original approach (throw UOE by default, concrete impls should have an actual impl). The only IteratorEnvironment which would be using the default getConfig() would be ClientSideIteratorScanner. But we can just add the impl there (done in latest commit). It is also hard to know what would be a good default impl since its not exactly clear how getConfig() was originally working.
Comment about RFileScanner.IterEnv.getTableId()
Proxy can only be used to create proxies for interfaces, not concrete classes, so can't be used for TableId. Opting to just return null with added javadoc.
Background: we want to support getConfiguration(TableId) since this is the method defined as returning the props set on the table and getConfiguration() should not be returning table props, so we cant substitute that method. So, something needs to be passed, but it doesn't matter what since it wont be used. The way getConfiguration(TableId) will be called is env.getPluginEnv().getConfiguration(env.getTableId()) (from javadocs for IteratorEnvironment.getPluginEnv()) So, we should have env.getTableId() returning something.
No solutions seem great, but Proxy is a no-go, a real dummy id may be confusing (e.g., a user may think that it is a real table id), null may lead to NPE. I figure null makes the most sense here. A NPE would only occur if the user is trying to do something with the table id which they shouldnt be doing anyways. It is also now noted in the javadocs that null will be returned so if a NPE does occur, it should be easy to see why.
Comment about UOE/ISE
Did not change anything further than I had already changed in my earlier commits relating to when/how UOE or ISE are thrown, how its documented etc. Some future considerations would be

IteratorEnvironment.getAuthorizations() currently documented as throwing UnsupportedOperationException if scope != scan (should probably be ISE if anything).
IteratorEnvironment.isFullMajorCompaction() and isUserCompaction() should maybe throw ISE in the default if the scope is majc

Maybe these shouldn't be throwing exceptions at all and only returning false... This would probably be the cleanest if possible. Would have to look more into why these are throwing exceptions in the first place.

Comment about RFileScanners createServiceEnv()
Christopher suggested having this be an inner class instead of anon class. Leaving this comment as a reminder. Will do once the other more important changes are looked at; want to avoid confusing diff between commits for now.


Draft work on CustomError

@ItsShadowl We have implementation of CustomErrors, working with Hardhat - please take a look into the tests in action here https://github.com/TrueFiEng/Waffle/blob/12c2d7209a310202e8b03862972a88735e5803a0/waffle-hardhat/test/reverted.test.ts#L37

@ItsShadowl We have implementation of CustomErrors, working with Hardhat - please take a look into the tests in action here https://github.com/TrueFiEng/Waffle/blob/12c2d7209a310202e8b03862972a88735e5803a0/waffle-hardhat/test/reverted.test.ts#L37

The error args and errorName can't be pulled from UseDapp

@ItsShadowl Ah sorry I confused UseDapp with Waffle because I switch from one to another during the day 🤦♂

@ItsShadowl Ah sorry I confused UseDapp with Waffle because I switch from one to another during the day 🤦♂

I did notice that, LOL

Hey, we'll add it to our roadmap. Closing for now. Please feel free to reopen if needed. 😄


Add IQair exporter to exporters.md

https://github.com/Packetslave/iqair_exporter

@Packetslave
Your commit doesn't have signed off! To fix this, first ensure you have a local copy of your branch by checking out the pull request locally via the command line.  Next run
git push --force-with-lease origin patch-1


2.0.0/rubygems/specification.rb:2504:in `stat': File name too long - .gitignore (Errno::ENAMETOOLONG)

Error details
Errno::ENAMETOOLONG: File name too long - .gitignore

while running 'bundle / rake db:create'

Hi, can you provide the generated bundle error report? From the look of your issue title, it seems that the error might stem from Rubygems and not Bundler.

Here is the complete details:
--- ERROR REPORT TEMPLATE -------------------------------------------------------

What did you do?
I ran the command /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/bin/bundle

What did you expect to happen?
I expected Bundler to...

What happened instead?
Instead, what actually happened was...

Error details
Errno::ENAMETOOLONG: File name too long - .gitignore

.rspec
.travis.yml
CHANGELOG.rdoc
Gemfile
LICENSE.txt
README.md
Rakefile
app/controllers/impressionist_controller.rb
app/models/impression.rb
app/models/impressionist/bots.rb
app/models/impressionist/impressionable.rb
impressionist.gemspec
lib/generators/active_record/impressionist_generator.rb
lib/generators/active_record/templates/create_impressions_table.rb
lib/generators/impressionist_generator.rb
lib/generators/mongo_mapper/impressionist_generator.rb
lib/generators/mongoid/impressionist_generator.rb
lib/generators/templates/impression.rb
lib/impressionist.rb
lib/impressionist/bots.rb
lib/impressionist/controllers/mongoid/impressionist_controller.rb
lib/impressionist/engine.rb
lib/impressionist/models/active_record/impression.rb
lib/impressionist/models/active_record/impressionist/impressionable.rb
lib/impressionist/models/mongo_mapper/impression.rb
lib/impressionist/models/mongo_mapper/impressionist/impressionable.rb
lib/impressionist/models/mongoid/impression.rb
lib/impressionist/models/mongoid/impressionist/impressionable.rb
lib/impressionist/version.rb
logo.png
spec/spec_helper.rb
test_app/.gitignore
test_app/.rspec
test_app/Gemfile
test_app/README
test_app/README.rdoc
test_app/Rakefile
test_app/app/assets/images/rails.png
test_app/app/assets/javascripts/application.js
test_app/app/assets/stylesheets/application.css
test_app/app/controllers/application_controller.rb
test_app/app/controllers/articles_controller.rb
test_app/app/controllers/dummy_controller.rb
test_app/app/controllers/posts_controller.rb
test_app/app/controllers/widgets_controller.rb
test_app/app/helpers/application_helper.rb
test_app/app/mailers/.gitkeep
test_app/app/models/.gitkeep
test_app/app/models/article.rb
test_app/app/models/dummy.rb
test_app/app/models/post.rb
test_app/app/models/user.rb
test_app/app/models/widget.rb
test_app/app/views/articles/index.html.erb
test_app/app/views/articles/show.html.erb
test_app/app/views/dummy/index.html.erb
test_app/app/views/layouts/application.html.erb
test_app/app/views/posts/edit.html.erb
test_app/app/views/posts/index.html.erb
test_app/app/views/posts/show.html.erb
test_app/app/views/widgets/index.html.erb
test_app/app/views/widgets/new.html.erb
test_app/app/views/widgets/show.html.erb
test_app/config.ru
test_app/config/application.rb
test_app/config/boot.rb
test_app/config/cucumber.yml
test_app/config/database.yml
test_app/config/environment.rb
test_app/config/environments/development.rb
test_app/config/environments/pg_test.rb
test_app/config/environments/production.rb
test_app/config/environments/test.rb
test_app/config/initializers/backtrace_silencers.rb
test_app/config/initializers/impression.rb
test_app/config/initializers/inflections.rb
test_app/config/initializers/mime_types.rb
test_app/config/initializers/secret_token.rb
test_app/config/initializers/session_store.rb
test_app/config/initializers/wrap_parameters.rb
test_app/config/locales/en.yml
test_app/config/routes.rb
test_app/db/migrate/20110201153144_create_articles.rb
test_app/db/migrate/20110210205028_create_posts.rb
test_app/db/migrate/20111127184039_create_widgets.rb
test_app/db/seeds.rb
test_app/lib/assets/.gitkeep
test_app/lib/tasks/.gitkeep
test_app/lib/tasks/cucumber.rake
test_app/log/.gitkeep
test_app/public/404.html
test_app/public/422.html
test_app/public/500.html
test_app/public/favicon.ico
test_app/public/images/rails.png
test_app/public/index.html
test_app/public/javascripts/application.js
test_app/public/javascripts/controls.js
test_app/public/javascripts/dragdrop.js
test_app/public/javascripts/effects.js
test_app/public/javascripts/prototype.js
test_app/public/javascripts/rails.js
test_app/public/robots.txt
test_app/public/stylesheets/.gitkeep
test_app/script/cucumber
test_app/script/rails
test_app/spec/controllers/controller_spec.rb
test_app/spec/controllers/impressionist_uniqueness_spec.rb
test_app/spec/fixtures/articles.yml
test_app/spec/fixtures/impressions.yml
test_app/spec/fixtures/posts.yml
test_app/spec/fixtures/widgets.yml
test_app/spec/initializers/initializers_spec.rb
test_app/spec/models/bots_spec.rb
test_app/spec/models/counter_caching_spec.rb
test_app/spec/models/model_spec.rb
test_app/spec/rails_generators/rails_generators_spec.rb
test_app/spec/spec_helper.rb
upgrade_migrations/version_0_3_0.rb
upgrade_migrations/version_0_4_0.rb
  /home/yuva/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/specification.rb:2504:in `stat'
  /home/yuva/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/specification.rb:2504:in `block in validate_permissions'
  /home/yuva/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/specification.rb:2503:in `each'
  /home/yuva/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/specification.rb:2503:in `validate_permissions'
  /home/yuva/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/specification.rb:2435:in `validate'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/rubygems_integration.rb:51:in `block in validate'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/ui/shell.rb:80:in `silence'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/rubygems_integration.rb:51:in `validate'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler.rb:346:in `block in load_gemspec_uncached'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/shared_helpers.rb:53:in `chdir'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/shared_helpers.rb:53:in `block in chdir'
  /home/yuva/.rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/shared_helpers.rb:52:in `chdir'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler.rb:339:in `load_gemspec_uncached'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler.rb:329:in `load_gemspec'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/source/path.rb:135:in `block in load_spec_files'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/source/path.rb:134:in `each'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/source/path.rb:134:in `load_spec_files'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/source/git.rb:188:in `load_spec_files'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/source/path.rb:92:in `local_specs'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/source/git.rb:159:in `specs'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/lazy_specification.rb:53:in `__materialize__'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/spec_set.rb:90:in `block in materialize'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/spec_set.rb:87:in `map!'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/spec_set.rb:87:in `materialize'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/definition.rb:163:in `missing_specs'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/installer.rb:187:in `block in resolve_if_need'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/ui/shell.rb:80:in `silence'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/installer.rb:184:in `resolve_if_need'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/installer.rb:69:in `run'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/installer.rb:21:in `install'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/cli/install.rb:105:in `run'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/cli.rb:172:in `install'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/vendor/thor/lib/thor.rb:359:in `dispatch'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/vendor/thor/lib/thor/base.rb:440:in `start'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/cli.rb:10:in `start'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/exe/bundle:19:in `block in <top (required)>'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/lib/bundler/friendly_errors.rb:7:in `with_friendly_errors'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/gems/bundler-1.11.2/exe/bundle:17:in `<top (required)>'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/bin/bundle:19:in `load'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/bin/bundle:19:in `<main>'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/bin/ruby_executable_hooks:15:in `eval'
  /home/yuva/.rvm/gems/ruby-2.0.0-p0@sellrest/bin/ruby_executable_hooks:15:in `<main>'

Environment
Bundler   1.11.2
Rubygems  2.0.0.rc.2
Ruby      2.0.0p0 (2013-02-24 revision 39474) [i686-linux]
GEM_HOME  /home/yuva/Desktop/payal/Valeda/sellrestvaleda/vendor/bundle/ruby/2.0.0
GEM_PATH
RVM       1.25.30 (stable)
Git       <IP_ADDRESS>

Bundler settings
gem.test
  Set for the current user (/home/yuva/.bundle/config): "false"
gem.mit
  Set for the current user (/home/yuva/.bundle/config): "true"
gem.coc
  Set for the current user (/home/yuva/.bundle/config): "true"
cache_all
  Set for your local app (/home/yuva/Desktop/payal/Valeda/sellrestvaleda/.bundle/config): "true"
frozen
  Set for your local app (/home/yuva/Desktop/payal/Valeda/sellrestvaleda/.bundle/config): "1"
path
  Set for your local app (/home/yuva/Desktop/payal/Valeda/sellrestvaleda/.bundle/config): "vendor/bundle"
disable_shared_gems
  Set for your local app (/home/yuva/Desktop/payal/Valeda/sellrestvaleda/.bundle/config): "1"

--- TEMPLATE END ----------------------------------------------------------------
Unfortunately, an unexpected error occurred, and Bundler cannot continue.
First, try this link to see if there are any existing issue reports for this error:
https://github.com/bundler/bundler/search?q=File+name+too+long+-+.gitignore&type=Issues
If there aren't any reports for this error yet, please create copy and paste the report template above into a new issue. Don't forget to anonymize any private data! The new issue form is located at:
https://github.com/bundler/bundler/issues/new

Can you please add your Gemfile to that error report as well?

This is GemFile:
source 'https://rubygems.org'
gem 'rails', '~> 4.0.5'
dalli for cache
gem 'dalli'
gem 'devise', :git => 'git://github.com/plataformatec/devise.git', :branch => 'master'
gem "authority", "~> 2.6.0"
gem 'sqlite3'
gem "paperclip", "~> 3.5"
gem "fog", "~> 1.19.0"
gem 'country_select'
gem "make_flaggable", github: 'medihack/make_flaggable', :ref => 'd7309'
gem 'sidekiq'
gem "capistrano-sidekiq"
gem 'ruby-graphviz', :require => 'graphviz'
gem 'geokit'
gem 'geokit-rails'
#twitter for blog
gem 'twitter'
#seo-friendly-urls
gem 'friendly_id', '~> 5.0.0'
Admin Interface
gem 'ransack', github: 'ernie/ransack', branch: 'master'
gem 'inherited_resources', github:'josevalim/inherited_resources', branch: 'master'
gem 'activeadmin', github: 'gregbell/active_admin', branch: 'master'
gem 'gibbon'
Impressions
gem 'impressionist', :github => 'bennick/impressionist', :branch => 'rails_4'
Log events
gem 'event_logger'
Cron jobs
gem 'whenever', :require => false
CC Processing
gem "twocheckout", "~> 0.1.4"
gem 'coffee-rails', '~> 4.0.0'
gem 'sass-rails',   '~> 4.0.0'
gem 'haml-rails'
gem 'haml', '~> 4.0'
gem 'formtastic', github: 'justinfrench/formtastic', branch: 'master'
gem 'uglifier', '>= 1.0.3'
Turbolinks makes following links in your web application faster. Read more: https://github.com/rails/turbolinks
gem 'turbolinks'
Build JSON APIs with ease.
gem "active_model_serializers"
Modernizr for stupid IE
gem "modernizr-rails"
Bootstrap
gem 'bootstrap-sass', '~> <IP_ADDRESS>'
Font-Awesome for icons
gem 'font-awesome-rails'
group :development do
LocalTunnel
gem "localtunnel", "~> 0.3"
Dev Errors
gem "better_errors"
gem 'binding_of_caller'
gem 'meta_request'
gem 'pry-rails'
gem 'awesome_print'
gem 'guard-rspec'
gem 'hirb'
end
group :test, :development do
gem "rspec-rails", "~> 2.14.2"
gem "rb-fsevent"
gem 'capybara'
gem 'database_cleaner', "~> 1.0.1"
gem 'selenium-webdriver'
gem "factory_girl_rails", "~> 4.0"
gem "faker", "~> 1.1.2"
gem 'shoulda-matchers', "1.4.0"
end
group :production, :staging do
gem 'mysql2'
end
To use ActiveModel has_secure_password
gem 'bcrypt-ruby', '~> 3.0.0'
Use unicorn as the app server
gem 'unicorn'
Deploy with Capistrano
gem 'capistrano', group: :development
gem 'capistrano'
gem 'rvm-capistrano', :require => false
To use debugger
gem 'debugger'
Application Monitoring
gem 'newrelic_rpm'

Bundler could not find compatible versions for gem "railties":
  In Gemfile:
    coffee-rails (~> 4.0.0) was resolved to 4.0.1, which depends on
      railties (< 5.0, >= 4.0.0)

    coffee-rails (~> 4.0.0) was resolved to 4.0.1, which depends on
      railties (< 5.0, >= 4.0.0)

    devise was resolved to 4.0.0.rc2, which depends on
      railties (< 5.1, >= 4.1.0)

    factory_girl_rails (~> 4.0) was resolved to 4.6.0, which depends on
      railties (>= 3.0.0)

    activeadmin was resolved to 1.0.0.pre2, which depends on
      inherited_resources (~> 1.6) was resolved to 1.6.0, which depends on
        railties (< 5, >= 3.2)

    rails (~> 4.0.5) was resolved to 4.0.5, which depends on
      railties (= 4.0.5)

    rspec-rails (~> 2.14.2) was resolved to 2.14.2, which depends on
      railties (>= 3.0)

The issue you originally reported seems to be with impressionist, and I cannot reproduce that issue

Closing due to lack of response.


Feature Request: Send to... functionality in right-click menu

When a user selects text in their browser the extension should check if it is a viable address, if it is then an entry should be added to the right click menu. For example, Pali Wallet Send to... . After the user clicks this Pali wallet will then open on a page with a selection of icons + names of which blockchain they would like to send the transaction on (Syscoin, Bitcoin, Matic etc). Once this has been selected they will be taken to the relevant sending page to complete the transaction.

hi @LucidLunacy, i guess i didn't really get how you imagine this feature, could you send some more examples to specify better? we are implementing new features so maybe this one already has been implemented (if it is what i'm thinking about), but pls specify maybe with some images or steps and sure we can try to put it in the code (:

Sure, it would be like in the attached image.

User selects and right clicks the text with an address.
User clicks "Pali Wallet | Send to... address".
Pali opens with a selection of the networks that use this address format, the user selects which network to use.
Pali then opens the Send page for that specific network with the address already added.

This means when users want to send to a specific address they don't need to copy the address, open pali, select the network, select send, paste the address then input the amount to send, they will only need to right click the address, choose send, select the network then input the amount to send.
Hope that makes better sense!


🐛 [bug]: pipx is missing

🐛 What happened?
The upgrade to v2 require to have pipx already available on the workers, this may be true for github runners:

https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2004-Readme.md#package-management
but is not true for self-hosted runner.

🔬 How to reproduce?
Create a pipeline executed in a self-hosted worker (e.g. using act) where pipx is not installed
🏗 Code Sample / Log
Cache restored from key: actionlint-1.7.1-Linux-X64
Run actions/github-script@v7
Error: Unable to locate executable file: pipx. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.
    at Object.<anonymous> (/runner/_work/_actions/actions/github-script/v7/dist/index.js:4381:27)
    at Generator.next (<anonymous>)
    at fulfilled (/runner/_work/_actions/actions/github-script/v7/dist/index.js:4234:58)
Error: Unhandled error: Error: Unable to locate executable file: pipx. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

🌌 Environment (actionlint action)
v2
🌌 Environment (actionlint)
1.7.1
🌌 Environment (GitHub Runner OS)
Linux
📷 Screenshots
No response
📈 Expected behavior
I suggest to check if pipx is installed and if missing evaluate to include it at runtime.
The changelog do not report it as requirement, so may be worth to mention it in the changelog/doc.
📎 Additional context
No response
📜 Code of Conduct

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

hi @mavimo
It's mentioned in the README

and changelog as well

and this is one of the reasons why is major bump

@DariuszPorowski in the changelog was not highlighted as pre-requirement and the PR open dependabot do not report the changes in the readme.
Anyway I should have read the readme better, sorry for the noise.

It's not a noise, it's actionable feedback for me to improve changelog in te future releases. Thanks 😊

I got bit by this, too, due to using a self-hosted runner. Turning this into Docker container might help alleviate dependency woes.  If you're interested in going that route, I could help contribute.


naja: init at 0-unstable-2024-07-21

Description of changes
naja is a structural Netlist API (and more) for EDA post synthesis flow development.
Work funded by NLNet through the NGI0 Entrust fund
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 330385 run on x86_64-linux 1

6 packages built:

libdwarf-lite
libdwarf-lite.dev
libdwarf-lite.lib
naja
naja.dev
naja.lib

Applied changes from https://github.com/ngi-nix/ngipkgs/pull/323
Thanks @OPNA2608 for the suggestions.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2024-summer-of-nix-program-updates/46053/4


made header fun ;)

put rainbow header

There are merge conflicts. Please could you pull from upstream and resolve the conflicts?


503 returned from REST API reference link

I constantly get 503 response by clicking Image Analysis REST API link.
I need to access the API reference page because I need to see the list of supported azure regions.

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

ID: 46e0ccf9-a032-6201-f0c3-e2424404aa35
Version Independent ID: 42ca4fb4-273d-1fb9-9e4f-9d59e910d162
Content: Call the Image Analysis API - Azure Cognitive Services
Content Source: articles/cognitive-services/Computer-vision/how-to/call-analyze-image.md
Service: cognitive-services
Sub-service: computer-vision
GitHub Login: @PatrickFarley
Microsoft Alias: pafarley

@yeohan
Thanks for your feedback! We will investigate and update as appropriate.

@PatrickFarley
Could you please update the correct link in the Doc.

The reference sites were down due to some internal issues but they have been restored already. Please let us know if you still see these issues. Thanks!
#please-close


Error using $output from Symfony Command

Hi, thanks for your effort and sharing this library.
I have optimized some of our Symfony CLI apps with this parallels extension. So far all works, but I can't use the Symfony Output anymore.

Simple example for a task:
<?php

use Amp\Parallel\Worker\Environment;
use Amp\Parallel\Worker\Task;

class MyTask implements Task {

  private $output;

  public function __construct($output) {
    $this->output = $output;
    $this->output->writeln("OUTPUT INSIDE CONSTRUCT WORKS");
  }

  public function run(Environment $environment) {
    echo "THIS WORKS\n";
    $this->output->writeln("OUTPUT INSIDE RUN BREAKS");
    $sleep = rand(1, 3);
    sleep($sleep); // Blocking call in thread.
    return 0
  }

}

And my Symfony Command looks like (I tried to simplify as much as possible):
<?php

use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\Input\InputArgument;
use Symfony\Component\Console\Input\InputOption;
use Symfony\Component\Console\Formatter\OutputFormatterStyle;

use Amp\Loop;
use Amp\Parallel\Worker\DefaultPool;

use MyTask;

class MyCommand extends Command {

  protected function configure(){
    $this->setName("Process:Amp")
         ->setDescription("This will run some parallel processes.")
         ->addArgument('count', InputArgument::REQUIRED, 'Number of concurrent pool processes.');
  }

  protected function execute(InputInterface $input, OutputInterface $output){

    $output->writeln('START COMMAND ...');

    // We can first define tasks and then run them
    $tasks = [
      new MyTask($output),
      new MyTask($output),
      new MyTask($output),
      new MyTask($output),
      new MyTask($output),
    ];

    try {

      // get parameters
      $cnt_parallels = $input->getArgument('count');

      $pool = new DefaultPool($cnt_parallels);

      foreach ($tasks as $task) {
        $pool->enqueue($task);
      }

      // Event loop for parallel tasks
      Loop::run(function () use (&$pool) {
        return $pool->shutdown();
      });

    }
    finally {

      $output->writeln('WELL, COMMAND Finally reached!');

    }

  }

}

The above will immediately stop but not shown any exception.
If changing the loop code with Coroutines then following exception is shown and formatted via Symfony:

In TaskFailure.php line 55:
Uncaught Symfony\Component\Console\Exception\RuntimeException in worker with message "Unable to write output." and code "0"

Thanks for some hints or solution in advance
Cheers, Tom

When var_dumping in vendor/symfony/console/Output/StreamOutput.php the content of
$this->stream in function doWrite($message, $newline),
then normally returns:

resource(57) of type (stream)

but when calling from inside run:

int(0)

Any idea what happens there?

@TomFreudenberg You can't directly write to STDOUT in workers, because STDOUT is used for the IPC with the parent. Until we change that, you either need to write to STDERR or write to your own logging channel, e.g. a file. echo / print works, because we use output buffering to redirect those calls to STDERR and the parent just forwards the child's STDERR to its own STDERR.

Hi Neklis @kelunik
understood!
Sorry for maybe silly question, but:
Do you have any idea how to define a Symfony Output which will "print the information to console" while task / loop is running?
Thanks for your help
Tom

You can use a new StreamOutput(STDERR) as far as I can tell.

Hi Niklas @kelunik
When I add
$this->output = new \Symfony\Component\Console\Output\StreamOutput(STDERR);

into function run() from MyTask it will work!
It does not work if I create that StreamOutput object outside or in __constructor()
Do you know why?
$this->stream will be emptied to int(0) when creating and setting the $output outside of the MyTask run function?

Hi Niklas @kelunik
one additional question:
Is it possible to not use STDOUT for channel / IPC communication but some extra or none?
If yes, do you have a hint about "how"

Just to give you a better understanding for my needs:
In my case, there is no communication necessary between the parent and child threads. I just want run a number of the same command function (within external processes) in parallel. The function will log and handle its errors etc. by itself. I do not return a value or check that in loop.

Thanks for your help
Tom

It's converted to 0, because resources aren't serializable. If you don't need any IPC, you can use child processes manually with amphp/process.

It's converted to 0

@kelunik could you point to the code, where this conversation happens?

Hi Niklas @kelunik
I was looking for pthreads but in case that this is not available per default, I looked for other solutions with less maintenance. Compiling php and pthreads always by ourselfs or trusting some ppa from Ondřej Surý, is not what we are willing to do.
So I looked on amp/parallel.

If you don't need any IPC, you can use child processes manually with amphp/process

The issue with amphp/process is, that I just can run external programs from that. My need is to run a internal function more than once (like threads).
Sure, I could create a SymfonyCommand to call for just one file and then call that in a loop. But in case that we need a lot of settings during the function (like database connection etc.) I had to create some huge command line arguments or serialization of values. This is for what I like the comfort of amp/parallels.
I guess, amp/process is too rudimental for that case.

Hi Niklas @kelunik
Last comment here - a bit offtopic -
I tried to send an initialized PDO object to my Task function, but that won't work either. Looks like that those kind of vars (objects) can't be handled by IPC / PARALLELS either?
Seems to me like I am doing the wrong things with the wrong toolkits :-(

@TomFreudenberg PDO objects can't be serialized.

Hi Eugene @rybakit
thanks for Feedback. Yes I understood.
Is it correct to say that the function run() of my Task class would be handled inside the new (separated) en-queued process.
If so, I can understand now, why and where to define the necessary (complex) objects in that function.

@rybakit PHP does that internally during serialize.
@TomFreudenberg PHP is shared nothing. Everything you share needs to be serializable and is copied not shared. In case of database connections, you need to establish a new connection in the child / thread.

@kelunik Thanks for help and clarification


HW5 task 4: add results to table... but what name should we call the column?

should we specify the label of the column assigned to the array we are adding to the table?

Good question, @futbol4me. Currently, we are not checking the column label for the column that is added, so use any label you want for that column.
I'll leave this open until the assignment deadline.


Add scripts compatible with the MNIST dataset

This prepares the mnist dataset of images of numbers for training.

Lgtm


Is the eventgateway project open source still active

Hi Team,
Based on the frequency of the updates on the git would like to know if the project is still active or not ? The last update is almost 8months back.
Regards
Arun

I don't think sadly. The best site is down: https://www.serverless.com/event-gateway and there did not make an update to the repo for a long time.
Also last time that the web site was up : https://web.archive.org/web/20190401032758/https://serverless.com/event-gateway/


Volume restored with PersistentVolume information from Backup Label does not get updated

The Label: KubernetesStatus is automatically applied to Backups to store the KubernetesStatus if it exists so that this data can be reused later once the Backup is restored. However, PVName on KubernetesStatus is supposed to only reflect the current status of a connected PersistentVolume and not hold historical data, unlike what PVCName and the other fields that have a LastRefAt attribute do.
When restoring a Backup that has the PVName and PVStatus fields set, the longhorn-manager will not only populate these fields on the new Volume even if the PersistentVolume doesn't actually exist, but also not update these fields to clear them despite the polling from the KubernetesController.
There are two fixes that need to be pursued here to fix these fields:

Fix the bug causing the KubernetesController to not clear the PVName or PVStatus of the KubernetesStatus on a restored Volume.
Either avoid storing these fields on the Label: KubernetesStatus of Backups, or avoid restoring these particular fields.

I think it's better to avoid restoring these fields. Maybe we don't want to store them at all, but no matter what the value was, we shouldn't restoring those.

Done.


The parameter current is not implemented (feature request)

A lot of projects try to fetch node version through nvm (if detected) via nvm current, for ex. zsh themes (proof).
Expected Behavior
nvm current shows current node version (as a global version does, ref)
Actual Behavior*
λ nvm current

Running version 1.1.7.

Usage:

  nvm arch                     : Show if node is running in 32 or 64 bit mode.
  nvm install <version> [arch] : The version can be a node.js version or "latest" for the latest stable version.
                                 Optionally specify whether to install the 32 or 64 bit version (defaults to system arch).
                                 Set [arch] to "all" to install 32 AND 64 bit versions.
                                 Add --insecure to the end of this command to bypass SSL validation of the remote download server.
  nvm list [available]         : List the node.js installations. Type "available" at the end to see what can be installed. Aliased as ls.
  nvm on                       : Enable node.js version management.
  nvm off                      : Disable node.js version management.
  nvm proxy [url]              : Set a proxy to use for downloads. Leave [url] blank to see the current proxy.
                                 Set [url] to "none" to remove the proxy.
  nvm node_mirror [url]        : Set the node mirror. Defaults to https://nodejs.org/dist/. Leave [url] blank to use default url.
  nvm npm_mirror [url]         : Set the npm mirror. Defaults to https://github.com/npm/cli/archive/. Leave [url] blank to default url.
  nvm uninstall <version>      : The version must be a specific version.
  nvm use [version] [arch]     : Switch to use the specified version. Optionally specify 32/64bit architecture.
                                 nvm use <arch> will continue using the selected version, but switch to 32/64 bit mode.
  nvm root [path]              : Set the directory where nvm should store different versions of node.js.
                                 If <path> is not set, the current root will be displayed.
  nvm version                  : Displays the current running version of nvm for Windows. Aliased as v.

* Any windows environment with any NVM4W version (up to 1.1.7)
Instead of conclusion
I believe that such parameters should be consistent between nvm versions to work properly.

@coreybutler Are you planning to implement it? If so, in which version it may appear?


Fixed MultiSelect DoubleTap (#4437)

Resolved / Related Issues
In MultiSelect mode, a double tap/click on a item opens the item.
The expected behavior is to click twice on the selection checkbox.
#4437
Details of Changes
Add a test in the DoubleTap event for to do nothing in multiselect mode.

@cinqmilleans What's the status of this pull request?

This is my first commit on Github. I wasn't sure if I should commit myself or if a contributor with write rights was going to do it. I visited the Android app of GitHub and closed the ticket by mistake. I don't know how to commit on main now that the pull request is closed. Thank you for helping me.
I really like this software. I intend to keep improving it. This pull request is a small test before more ambitious contributions.

@cinqmilleans I reopened the PR for you, thank you so much for all your help!

Thank you.