ENH: Add Wigner-Ville distribution

Reference issue
This was mentioned in #3533, which was closed due to inaction.
What does this implement/fix?
Add Wigner-Ville distribution method for time-frequency analysis applications in signal processing.
Additional information
The method is implemented in a new module called wigner. I think about adding further methods related to the Wigner-Ville distribution, e.g. the Smoothed pseudo-Wigner–Ville distribution and the Gabor–Wigner transform. If desired, I can change the PR and add it to the spectral module.

One general remark: Also it is called a distribution, the WVD is a tool mostly used for time-frequency signal analysis and should thus be labeled scipy.signal.

This is an interesting work. I am not expert in quantum mechanics (just started out with some introductory lectures and have some intuitive knowledge of this field). I was reading Wigner quasiprobability distribution which defines the distribution in terms of position and momentum of a particle having wave function f. May be we can have this definition in scipy.stats. In the Mathematical properties the wikipedia article also defines probability distributions for x, p by marginalising W(x, p). Please let me know if you are also doing the same thing.

This is an interesting work. I am not expert in quantum mechanics (just started out with some introductory lectures and have some intuitive knowledge of this field). I was reading Wigner quasiprobability distribution which defines the distribution in terms of position and momentum of a particle having wave function f. May be we can have this definition in scipy.stats. In the Mathematical properties the wikipedia article also defines probability distributions for x, p by marginalising W(x, p). Please let me know if you are also doing the same thing.

I am also not into quantum mechanics, the proposed implementation is more aimed at usage in signal analysis (time-frequency-analysis to be specific), hence the placement in scipy.signal. The appropriate wiki article would be https://en.wikipedia.org/wiki/Wigner_distribution_function. Unfortunately, naming is all over the place, not only on wikipedia. So, while the basic idea is similar, the applications are so different that I wouldn't say that they are the same thing.

Hello everyone, I'd like to see this feature in scipy! Thanks for the hard work @lndr ! Is there anything I could do to support this PR?

Shouldn't the Gabor transform be a distinct function by itself, just like STFT and CWT?

Shouldn't the Gabor-Wigner transform be a distinct function by itself, just like STFT and CWT?

It should, but it may be possible to reuse some of the code written for the Wiegner-Ville distribution. It could thus be placed in the same module.

@larsoner we discussed this in the community meeting today, and figured it will make sense to move it to _spectral_py.py. Does that sound good? Also, maybe you'd be interested to have a look at this?

@larsoner @lndr I'm hoping to branch for SciPy 1.12.0 on December 6th, in case this PR has a chance of getting revived before then.

I would hope so. When we talked about in in the community meeting a year ago, the only thing missing, aside from maybe moving it to the spectral module, was for someone to review the math.

I found some time to investigate this WVD implementation a bit: The following statements should be read in the light of @rgommer's comment as being thought food for reasoning about the api a little more:

The WVD being a pseudo power density is its distinguishing feature among time-frequency representations. This means its marginals, which can be determined by (numerically) integrating over time or frequency, are the power spectral density (PSD) and the instantaneous power (i.e., |x(t)|²). It would be nice if there would be unit tests as well an example in the docstring verifying that. (For background information on the PSD of a sampled signal, you are more than welcome to review PR #19488 😁).
It seems that a scaling factor is missing. It can be verified by investigating the marginals.
The provided function only determines the WVD for non-negative frequencies. The negative part is needed for complex-valued signals. The fft_mode property of the ShortTimeFFT shows an example on how to parametrize the FFT for different use cases.
IMHO, it would be straightforward to extend this function to be able to calculate a cross-WVD.
One of the lessons of new ShortTimeFFT implementation was that the signal's borders need to be carefully considered (the legacy stft/istft were a bit intransparent in that regard):

My guess is the time domain of the WVD is larger than that of the input signal—at least when the inverse WVD should be able to reconstruct the original signal.
It might be nice to be able to assemble WVDs of sequential signal chunks into a large WVD (the cross-WVD could be helpful in that regard).

It would be nice to have the inverse WVD (with the same api of course).
The WVD is not guaranteed to be non-negative (the reason for naming it "pseudo-density"). Smoothing the WVD with an appropriate Gaussian kernel removes the negative parts at the expense of resolution (e.g., consult Chap. 4.4 of Gröechnig's book). Hence, having a smoothed WVD would enhance the usability for real-world problems a lot.

Thank you for the review @DietBru! Nice to see some activity in the PR.
1: Such a test case would indeed be quite sensible. I'll have a look into it, but wouldn't you say that having it as an example would be quite a lot of code?
2: I'll look that up.
3: Seems sensible to include a feature like fftmode. I'll have a look at that to.
5.1: It should be len(x) * 2 - 1 because of the autocorrelation, right? Might be a good idea to keep it that way.
5.2: That seems like quite an advanced feature, maybe a bit out of the scope of this PR?
4,6,7: I've considered the additional functionality you proposed (IWVD, cross-WVD PWVD, etc.) and concluded to first implement only a basic function to judge if there is interest in such features.
Thanks again for the feedback. Unfortunately, I'm quite busy at the moment and it was quite some time since it wrote that code. I'll try to work on it, but any support is welcome.

It looks like there is some good feedback here now. Perhaps if the discussion remains active for a little bit longer folks could agree on keeping the scope to some reasonable target. The requests for adding more tests might be considered important enough to delay a merge though.
I'll probably bump the milestone to 1.13.0 here, but note that 1.13.0 is likely going to be less than six months away, because it will aim to support NumPy 2.0.0 when it comes out, so there may be another medium-term opportunity to get this in if things align.

I finally found some time to work on the PR again. I added an additional test following the suggestion by @DietBru, which tests for the marginals. While implementing that, I noticed some problems with the algorithm and looked up the implementation by Bradford that inspired it. I added an additional reference to the documentation for that, which is freely available at Caltech. @DietBru already suspected that there is something wrong with the scaling, but I found the problem lying somewhat deeper. The implementation at hand, while quite efficient, achieves this by requiring the input signal to be an analytic signal. It does unfortunately not represent the general case of the Wigner-Ville distribution.
I'm not quite sure one would continue from here. There are suggestions for efficient, general implementations and other python implementation in smaller packages, for example in pytftb. If we are to continue, I would suggest starting with the cross Wigner-Ville distribution, then implementing the ordinary WVD as a special cases of that, and then implement pseudo-WVDs etc. I guess we would do this in a different PR then, because not much of the current code would survive.
However, interest in making the WVD and its derivatives a part of scipy has not been on the high side in the two and a half years this PR has been oben. So before we/I start pouring more work in this project, I'd like to ask everyone how contributed thus far: Do we want the Wigner-Ville distribution in scipy or not?

I'm not quite sure one would continue from here. There are suggestions for efficient, general implementations and other python implementation in smaller packages, for example in pytftb. If we are to continue, I would suggest starting with the cross Wigner-Ville distribution, then implementing the ordinary WVD as a special cases of that, and then implement pseudo-WVDs etc. I guess we would do this in a different PR then, because not much of the current code would survive.
However, interest in making the WVD and its derivatives a part of scipy has not been on the high side in the two and a half years this PR has been oben. So before we/I start pouring more work in this project, I'd like to ask everyone how contributed thus far: Do we want the Wigner-Ville distribution in scipy or not?

@larsoner any opinion in light of this?

I finally found some time to work on the PR again. I added an additional test following the suggestion by @DietBru, which tests for the marginals. While implementing that, I noticed some problems with the algorithm and looked up the implementation by Bradford that inspired it. I added an additional reference to the documentation for that, which is freely available at Caltech. @DietBru already suspected that there is something wrong with the scaling, but I found the problem lying somewhat deeper. The implementation at hand, while quite efficient, achieves this by requiring the input signal to be an analytic signal. It does unfortunately not represent the general case of the Wigner-Ville distribution.
I'm not quite sure one would continue from here. There are suggestions for efficient, general implementations and other python implementation in smaller packages, for example in pytftb. If we are to continue, I would suggest starting with the cross Wigner-Ville distribution, then implementing the ordinary WVD as a special cases of that, and then implement pseudo-WVDs etc. I guess we would do this in a different PR then, because not much of the current code would survive. However, interest in making the WVD and its derivatives a part of scipy has not been on the high side in the two and a half years this PR has been oben. So before we/I start pouring more work in this project, I'd like to ask everyone how contributed thus far: Do we want the Wigner-Ville distribution in scipy or not?

I think the Wigner-Ville Distribution is one of those things nobody knows about untill they need it. I found myself in this situation a couple of years ago and turned to scipy to find an implementation of the WVD, and then being stumped as to why there was no implementation of this. In the end I just created my own version of a pseudo-wigner ville distribution. Not to toot my own horn or anything but I have a repo implementing the Wigner distribution without a for loop using only numpy and scipy methods, which I assume would be a free speedup over a Python loop, although I have no metrics on how they compare both time-wise and in qualitatively (pytftb also uses python for loops from what I could gather). At the time I created it with the goal of sometime opening a PR to scipy and merging it but I think approaching it from the general implementation and implementing other parts as special cases makes sense. Then again, if it takes too much work to solve the general problem while we only need a pseudo wigner ville distribution most of the time, that might be overkill.

I finally found some time to work on the PR again. I added an additional test following the suggestion by @DietBru, which tests for the marginals. While implementing that, I noticed some problems with the algorithm and looked up the implementation by Bradford that inspired it. I added an additional reference to the documentation for that, which is freely available at Caltech. @DietBru already suspected that there is something wrong with the scaling, but I found the problem lying somewhat deeper. The implementation at hand, while quite efficient, achieves this by requiring the input signal to be an analytic signal. It does unfortunately not represent the general case of the Wigner-Ville distribution.
I'm not quite sure one would continue from here. There are suggestions for efficient, general implementations and other python implementation in smaller packages, for example in pytftb. If we are to continue, I would suggest starting with the cross Wigner-Ville distribution, then implementing the ordinary WVD as a special cases of that, and then implement pseudo-WVDs etc. I guess we would do this in a different PR then, because not much of the current code would survive. However, interest in making the WVD and its derivatives a part of scipy has not been on the high side in the two and a half years this PR has been oben. So before we/I start pouring more work in this project, I'd like to ask everyone how contributed thus far: Do we want the Wigner-Ville distribution in scipy or not?

I think the Wigner-Ville Distribution is one of those things nobody knows about untill they need it. I found myself in this situation a couple of years ago and turned to scipy to find an implementation of the WVD, and then being stumped as to why there was no implementation of this. In the end I just created my own version of a pseudo-wigner ville distribution. Not to toot my own horn or anything but I have a repo implementing the Wigner distribution without a for loop using only numpy and scipy methods, which I assume would be a free speedup over a Python loop, although I have no metrics on how they compare both time-wise and in qualitatively (pytftb also uses python for loops from what I could gather). At the time I created it with the goal of sometime opening a PR to scipy and merging it but I think approaching it from the general implementation and implementing other parts as special cases makes sense. Then again, if it takes too much work to solve the general problem while we only need a pseudo wigner ville distribution most of the time, that might be overkill.

Thanks for your input. Judging from the responses to this PR, interest in having the WVD in SciPy does not seem to be high, unfortunately.
I had a look at your implementation. Did you develop the algorithm yourself? The problem with there implementation I used is that we can’t really track it to its origin anymore. Maybe we can use your approach but keep the interface already in the PR which we already had some discussion about.
While I concur that you’d use a smoothed pseudo WVD most of the time, the plain WVD has its applications as well, so I’d suggest at least we would need these two, don’t you think?

Yes, I developed it myself, based on the paper I link in the docstring. Specifically equations 2.10 and 2.11. The implementation is just some manipulation of indices to get the desired terms (n+k) and (n-k) per row of data in the wigner_integrand matrix and then let the FFT do the heavy lifting. I think my implementation easily extends to the cross-wigner distribution (defined over f and g) by the way. On the topic of the smoothed wigner distribution, although I agree that it is useful I'm not sure if it should be a part of SciPy directly.

Yes, I developed it myself, based on the paper I link in the docstring. Specifically equations 2.10 and 2.11. The implementation is just some manipulation of indices to get the desired terms (n+k) and (n-k) per row of data in the wigner_integrand matrix and then let the FFT do the heavy lifting. I think my implementation easily extends to the cross-wigner distribution (defined over f and g) by the way. On the topic of the smoothed wigner distribution, although I agree that it is useful I'm not sure if it should be a part of SciPy directly.

That sounds promising. If it is okay for you I'll try to modify the code in the PR with your algorithm, keeping the interface, when I find some time to spare. Afterwards, you can review it.

That sounds promising. If it is okay for you I'll try to modify the code in the PR with your algorithm, keeping the interface, when I find some time to spare. Afterwards, you can review it.

Sure.
I would like to add that I could also contribute in my own spare time. I'm not quite sure what the most appropriate way to do that is, should I fork your fork?

I just invited you as a collaborator on my fork of scipy. Since I find it hard to work on this one at the moment, you can push to the wigner branch. Some thoughts I had since it last worked on it:

I think we should not compute the analytic signal of the input inside the wigner method, even if it is somewhat of a default case. People should know what they are doing when they use the method, and there are quite some use cases where we compute the WVD of a complex signal.
If you like you could also implement the cross-wigner distribution, with the same interface but two input signals, and just make the WVD as a special case of that.
Feel free to implement further tests. I find it quite challenging to come up with good test cases.
Just have a look a the discussion above. Maybe there are some points it missed ;)

Thanks again for digging this up. I was about to call it off and close the PR.


Hide Dark Manuscript with Config option

Added a config in the Kourend Library setting to hide dark manuscripts, since they become irrelevant once you have 100% favor in the Arceuus faction.

Dark Manuscripts can still be used for Magic XP so I disagree that they become irrelevant. Still always good to be able to config things off whenever you like.

Dark Manuscripts can still be used for Magic XP so I disagree that they become irrelevant. Still always good to be able to config things off whenever you like.

I didn't knew that, the wiki doesn't states that. As well the plugin doesn't support the NPC Horphis to handle dark manuscripts.
But I will update the previous comment slightly, thanks for the information.

Maybe hiding them under 20% favour as well?

Maybe hiding them under 20% favour as well?

It will be a setting and users can decide for themselves if they want to hide these dark manuscripts.
Removing it for them is unwanted, I can imagine, besides the whole dark manuscript aspect is quite unsupported in the plugin, if I'm correct.

It will be a setting and users can decide for themselves if they want to hide these dark manuscripts.
Removing it for them is unwanted, I can imagine, besides the whole dark manuscript aspect is quite unsupported in the plugin, if I'm correct.

It's not accurate indeed. It's just that until 20% favour you can't even get any dark manuscripts.


Issue with custom trained ResNet50 model

First, thanks for this awesome project. My 13 year old daughter is using it for her science fair project this year.  She is testing out how the 4 algorithms do at classifying images of different types of sharks.  So far, we've made a custom trained model for MobileNetV2 and InceptionV3, using images of 5 different types of fish (four types of sharks and one of swordfish, as a control). The results we've gotten for the first two algorithms make sense to us, and it has worked pretty well.  Next we trained a model for ResNet50 using the same images, but for some reason, the model is outputting weird and very inaccurate info.
Here is the script we wrote to do the custom image classification using ResNet:
from imageai.Classification.Custom import CustomImageClassification
import os

execution_path = os.getcwd()

prediction50 = CustomImageClassification()
prediction50.setModelPath(model_path=os.path.join(execution_path, "model_ex-058_acc-1.000000.h5"))
prediction50.setJsonPath(model_json=os.path.join(execution_path, "model_class.json"))
prediction50.setModelTypeAsResNet50()
prediction50.loadModel(num_objects=5)

results, probabilities = prediction50.classifyImage("thresher1.png", result_count=3)

for eachResult, eachProbability in zip(results, probabilities):
    print(eachResult , " : " , eachProbability)

After running this, no matter what type of shark image we have it try to classify, these are the results we get back:
nurse  :  100.0
thresher  :  0.0
swordfish  :  0.0
This can't possibly be right.  It doesn't even look like the right kind of output. Do you have any suggestions?

@ag4apple I am really delighted to know ImageAI is helping your daughter with her science fair project.
As per the ResNet50 model, there is a known issue with custom models with the ResNet50 since the upgrade to T.F 2.4 backend. I will advice that you work with the previous 2 model types you mentioned + the DenseNet121 model for now.
I will let you know when the Resnet50 issue is fixed.

@OlafenwaMoses good info, thank you!


Fixes to OpenPMD from M Kim.

Description
This are some fixes from M Kim for the OpenPMD reader.
Turn off HDF5 diagnostic output.
change "cerr" to "debug5."
Type of change

[X] Bug fix

How Has This Been Tested?
Ran the test suite and it passed.
Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] New and existing unit tests pass locally with my changes

This is a failed attempt to merge some changes. I've picked up way too many changes.


doc: fix a markup issue that is flagged up by odoc

I think we'll need the same change in ctypes-foreign-unthreaded/foreign.mli, too.

Good catch; pushed.


Add vulcanjs to Front-end Development list

[Insert URL to the list here]
[Explain what this list is about and why it should be included here]
By submitting this pull request I confirm I've read and complied with the below requirements.
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.

I have read and understood the contribution guidelines and the instructions for creating a list.
This pull request has a descriptive title.For example, Add Name of List, not Update readme.md or Add awesome list.
The entry in the Awesome list should:

Include a short description about the project/theme of the list. It should not describe the list itself.Example: - [Fish](…) - User-friendly shell., not - [Fish](…) - Resources for Fish..
Be added at the bottom of the appropriate category.

The list I'm submitting complies with these requirements:

Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
It's the result of hard work and the best I could possibly produce.
Non-generated Markdown file in a GitHub repo.
Includes a succinct description of the project/theme at the top of the readme. (Example)
The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
Not a duplicate.
Only has awesome items. Awesome lists are curations of the best, not everything.
Includes a project logo/illustration whenever possible.

Either fullwidth or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
Includes the Awesome badge.

Should be placed on the right side of the readme heading.
Should link back to this list.

Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of sub-lists, preferably none.

Has an appropriate license.

That means something like CC0, not a code licence like MIT, BSD, Apache, etc.
If you use a license badge, it should be SVG, not PNG.

Has contribution guidelines.

The file should be named contributing.md. Casing is up to you.

Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Drop all the A / An prefixes in the descriptions.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

Doesn't include a Travis badge.You can still use Travis for list linting, but the badge has no value in the readme.

Go to the top and read it again.

The list I'm submitting complies with these requirements:
Has been around for at least 30 days.

The list also doesn't have much content except for official blog posts and some videos. Could use some more community content, like external blogs posts, libraries, etc. Many of the above guidelines are also not followed.
Try again in a couple of months, when the list is more mature.


How could issue a api request in command line, does harbor support http basic authentication?

No idea how to issue api request in command line, keeping get 401 Unauthorized response.

Will add basic auth support.


Query object 'myNumberToReturn'

I see this code in the class (231 - 245):
 if (isBatchSizeSet()) {
            if (isLimitSet() && (myLimit <= myBatchSize)) {
                myNumberToReturn = -myLimit;
            }
            else {
                myNumberToReturn = myBatchSize;
            }
        }
        else if (isLimitSet() && (myLimit <= DEFAULT_BATCH_SIZE)) {
            myNumberToReturn = -myLimit;
        }
        else {
            myNumberToReturn = 0;
        }

Why you set the myNumberToReturn to - limit??

That is a feature of MongoDB.  There is not location for sending the limit of a query to MongoDB but it will view a negative batch size as the limit.
See https://docs.mongodb.com/manual/reference/method/cursor.batchSize/
Rob.

Hi Rob,
if you will try this:
object TestMongo extends App {

  private val collection: MongoCollection = AcsUtils.mongoDatabase.getCollection("test")

    (0 until 500).foreach {
      case index =>
        val build = new DocumentBuilderImpl().add("index", index).add("_id", "id:" + index).build()
        collection.insert(build)
    }

  val limit = 100
  private val find: Builder = Find.builder().query(query).batchSize(1000).skip(108).limit(limit)

  (0 until 1).par.foreach {
    case e =>
      import scala.collection.JavaConversions._
      val size: Int = collection.find(find).toList.size()
      if (size < limit) {
        println("&&&&&&&: " + size)
      }
      println("****>>> " + size)
  }
}

send this request to mongos -> mongod (version 3.2)
you will see you will get 0 docs as result if you change the negative to positive you will get the right response,
we open case with mongodb and get this response from them:

There have been a number of significant changes in the product that were introduced in versions 3.0 and 3.2 that were released in 2015.  One such change is enhancements to our wire protocol.  Previously the legacy OP_QUERY spec had a single parameter, ntoreturn, which was overloaded to be used with both limit and batchSize options.  This behavior is described in our legacy CRUD API specification.  The ambiguity in terms of what the client was expecting when ntoreturn was provided resulted in suboptimal handling of the request in some situations.

so this actual in compatible with 3.x mongodb

@allanbank Any update on this?


[DateTimePicker]Changed return value to Date JS

✅ Closes: #351

:tada: This PR is included in version 9.7.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Template with SELECT *

When creating a template where the query uses a SELECT instead of CONSTRUCT (as done in the example), the result of the template is not as expected.
Consider the following example.
SELECT * WHERE {
<@@@entity_uri@@@> rdfs:comment ?comment.
}

The result will only provide you with the comments, and the to which entities it belongs is not given. Though, we are asking for everything, using SELECT *.
By using a CONSTRUCT the issue is solved. However, I don't think the current behavior of the SELECT * is the expected behavior.

yes, e-Link is using templates which are defined as CONSTRUCT queries. So, CONSTRUCT queries are supported at the moment only.

Will this change in the future?
Can you add it to the documentation that a CONSTRUCT is required?

I would rather stay with CONSTRUCT since it returns triples which can be easily added to any RDF model. For example, if the SELECT returns one resource, then it is not possible to an RDF model.
In your, example you want to enrich an entity with a comment information. The SELECT will return just the comment text. How should we then attach this to the document? we have no info how to do this. On the other hand, CONSTRUCT enforces the clients to include this info so we can very easily add this to the model.

Can you add it to the documentation that a CONSTRUCT is required?

@jnehring can you?

Actually the documentation of POST /e-link/templates says you have to submit a CONSTRUCT query. I created an issue to add one more sentence to make it clearer:
https://github.com/freme-project/Documentation/issues/143


Backport build_torcx_store manifest changes

This backports https://github.com/coreos/scripts/pull/737
We'll want to pull in https://github.com/euank/scripts/commit/e858e727b05668da98ebb74878c298097cf2a03b once this branch goes to beta as well.

Missed the branch dropdown, thanks github.


cmake-fail: updated libsdk cmake to utilise CSDK_DIR

Based on issue raised by @tonyespy in https://github.com/edgexfoundry-holding/device-bluetooth-c/pull/22
@tonyespy could you check this change allows you to build the device service now?

Doesn't work for me, you need to add LIBCSDK_INCLUDE_DIR to include_directories

change made

@FraserG01 It works for me now too, thanks!


[camera]bump default camera_web package version

Follow up this PR that updates permission exceptions for camera_web package.
This should be landed together with the Android change since both are breaking changes.
List which issues are fixed by this PR. You must list at least one issue.
https://github.com/flutter/flutter/issues/97199
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[x] I signed the CLA.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
[x] I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

This should be landed together with the Android change since both are breaking changes.

Why is it a separate PR then? If landed, this would just be a breaking change.
To land them separately we would have to follow this process, which doesn't seem necessary given that this is a small change that could easily be combined with the other PR.

@stuartmorgan Oh my bad. I intended for this to be rebased by @camsim99


siac renter upload to accept stdin

A basic unix way of programs interacting with programs is with stdin and stdout using pipe (|). I have a use case where I want to send a backup of a ZFS snapshot to Sia cloud storage with compression and encryption. For example on a unix command line:
zfs send storage@20170625 | gzip | openssl enc -aes-256-cbc -a -salt | siac renter upload - storage_20170625.gz.ssl
This has many advantages:

Local HDD space is saved by not having to save the ZFS snapshot to file
Compression is leveraged using gzip
The file is encrypted with openssl before it leaves the computer independent of Sia protocol

My current snapshot size after compression is 122.7 GB ... so a broken pipe would be a bummer if the upload failed for some reason, i.e. a timeout. As there would be no way to resume from where it failed.
Does Sia have this capability? Has anyone tried this before? BTW, I am a total Sia noob and have been reading a lot about it this past week and will be setting up a Sia host this week. I would like to start using the Sia network as a renter, but this would be my use case. Thanks!

Currently Sia does not support uploading from stdin because it seeks around a lot in the file, uploading different chunks in parallel instead of sequentially. It's certainly feasible for Sia to support sequential uploads, but in your case I wouldn't recommend it. Uploading 120 GB will take a while, and with no way to resume, you'd just have to hope that nothing interrupted the transfer. If hosts disconnect or unacceptably increase their prices or run out of space or the contract runs out of funds or your computer crashes, you're outta luck and have to restart from scratch.
btw, piping through openssl shouldn't be necessary, since Sia automatically encrypts everything you upload. (No harm in it if you want a little more security, though.)

I don't think we plan to support streaming uploads in the near future. The use-case is narrow and I don't see a way to make the operation "safe" (i.e. recoverable in the event of a failure)


Model config missing?

Hi,
The model file configs/50e.6h.500pro.ignore.yaml seems missing.
python3 train_net.py --num-gpus 8 \     --config-file configs/50e.6h.500pro.ignore.yaml

Found, the path should be under ./projects.
https://github.com/megvii-research/Iter-E2EDET/blob/main/projects/sparse-rcnn-baseline/configs/50e.6h.500pro.ignore.yaml


Spike a GitVersionControlSystem

I just created this Pepper so it would be a little less spammy to leave comments.  We can close it later.

This spike just shows as a proof of concept how we can generically
approach version control system integration. This spike demonstrates:

The use of a VersionControlSpec to define the url of the
remote repository.
The use of a VersionControlSystem as the high-level abstraction
for all version control systems.
A very rudimentary implementation of the populate method
for a GitVersionControlSystem
An initial fixture for testing our Git integration.

The spike does not yet cover:

How to get an instance of the correct type of version control
system based on the type of the version control spec that was
provided. But, we'll probably use some version control
system registry.
Sophisticated handling for many common scenarios when
populating a working directory from a repository.

Working directory exists and has correct remote.
Working directory exists but is not a git repository.
Working directory exists but has other remote.
Multiple working directories for the same remote.
Poorly formed user-input.

Related to https://github.com/gradle/gradle-native/issues/107
Context

Contributor Checklist

[ ] Review Contribution Guidelines
[ ] Sign Gradle CLA
[ ] Link to Design Spec for changes that affect more than 1 public API (that is, not in an internal package) or updates to > 20 files
[ ] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[ ] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:check

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation including proper use of @since and @Incubating annotations for all public APIs
[ ] Recognize contributor in release notes

We're going to try this one again.


Refactor for wgpu v23 compatibility

Checklist

[x] Confirmed that run-checks all script has been executed.
[ ] Made sure the book is up to date with changes in this PR.

[ ] After this PR merged, contributor-book/src/guides/adding-a-new-operation-to-burn.md needs to be updated.

[x] Check dependencies.

Related Issues/PRs

Dependent on gfx-rs/wgpu#6465
Dependent on tracel-ai/cubecl#211
Blocked by #2451

Changes

Update cubecl
Update wgpu
Update WgpuDevice::id() in burn-tensor

Testing
(Solved)
I run ./run-checks.sh all, but too many errors occurred on macOS (Metal) 🥺. Fixing the bugs ...

Discovery
The least recent version of wgpu that breaks burn-wgpu tests on Metal is found, see the difference here.

Discovery

The least recent version of wgpu that breaks burn-wgpu tests on Metal is found, see gfx-rs/wgpu@9c781d6.

I started to do some experiments on macOS.
I noticed that the test cargo t -p burn-wgpu jit::module_avg_pool2d::tests::test_avg_pool2d_simple failed when the pool2d_direct kernel was executed in Checked mode, but it passed in Unchecked mode.
Therefore, the reason of these 200+ errors on macOS tests should be some out-of-bound writes happen, because wgpu-hal/metal used BoundsCheckPolicy::Restrict in v23.0.0. You can see the source code here.

Status Update
After merging the latest cubecl into my branch,
I have executed ./run-checks.sh all on my macOS (Metal 3+, Vulkan 1.2+), it looks no error here.
[2024-11-25T19:59:54Z INFO  xtask] Time elapsed for the current execution: 00:08:29

After running CI on tracel/burn, I see there are 8 errors in linux-std-tests. Nevertheless, this change passing macos-std-tests is a good news.
Thanks to the contributions of @ArthurBrussee.

Miscellaneous
Continued with the previous post, I paste the logs on CI here:

  failures:

  ---- tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_batched stdout ----
  Testing bias
  Testing input
  Testing offset
  thread 'tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_batched' panicked at crates/burn-wgpu/src/lib.rs:108:5:
  Tensors are not approx eq:
    => Position 72: 270 != 0 | difference 270 > tolerance 0.2700000000000001
    => Position 73: 277.5 != 0 | difference 277.5 > tolerance 0.2775000000000001
    => Position 74: 285 != 0 | difference 285 > tolerance 0.2850000000000001
    => Position 75: 292.5 != 0 | difference 292.5 > tolerance 0.2925000000000001
    => Position 76: 67.5 != 0 | difference 67.5 > tolerance 0.06750000000000002
  67 more errors...
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

  ---- tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_kernel_size stdout ----
  Testing bias
  Testing input
  Testing offset
  thread 'tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_kernel_size' panicked at crates/burn-wgpu/src/lib.rs:108:5:
  Tensors are not approx eq:
    => Position 1: 5.355899810791016 != 0.007523147854954004 | difference 5.348376662936062 > tolerance 0.005355899810791017
    => Position 2: 11.715299606323242 != 0.34953704476356506 | difference 11.365762561559677 > tolerance 0.011715299606323245
    => Position 3: 0.3125 != 0.10416662693023682 | difference 0.20833337306976318 > tolerance 0.0010000000000000002
    => Position 4: 8 != 2.6666667461395264 | difference 5.333333253860474 > tolerance 0.008000000000000002
    => Position 5: 10 != 3.3333334922790527 | difference 6.666666507720947 > tolerance 0.010000000000000002
  235 more errors...

  ---- tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_basic stdout ----
  Testing bias
  Testing input
  Testing offset
  thread 'tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_basic' panicked at crates/burn-wgpu/src/lib.rs:108:5:
  Tensors are not approx eq:
    => Position 1: 15 != 6 | difference 9 > tolerance 0.015000000000000003
    => Position 2: 30 != 12 | difference 18 > tolerance 0.030000000000000006
    => Position 3: 45 != 18 | difference 27 > tolerance 0.04500000000000001
    => Position 5: 3.75 != 1.5 | difference 2.25 > tolerance 0.0037500000000000007
    => Position 6: 7.5 != 3 | difference 4.5 > tolerance 0.0075000000000000015
  65 more errors...

  ---- tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_padding stdout ----
  Testing bias
  Testing input
  Testing offset
  thread 'tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_padding' panicked at crates/burn-wgpu/src/lib.rs:108:5:
  Tensors are not approx eq:
    => Position 10: 0.8950999975204468 != 0 | difference 0.8950999975204468 > tolerance 0.0010000000000000002
    => Position 11: 14.760600090026855 != 0.03129822388291359 | difference 14.729301866143942 > tolerance 0.01476060009002686
    => Position 12: 17.60420036315918 != 0.5347222089767456 | difference 17.069478154182434 > tolerance 0.017604200363159184
    => Position 13: 20.69809913635254 != 1.1215760707855225 | difference 19.576523065567017 > tolerance 0.020698099136352545
    => Position 14: 22.20039939880371 != 1.624421238899231 | difference 20.57597815990448 > tolerance 0.022200399398803715
  415 more errors...

  ---- tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_batched stdout ----
  Testing bias
  Testing input
  Testing offset
  thread 'tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_batched' panicked at crates/burn-wgpu/src/lib.rs:108:5:
  Tensors are not approx eq:
    => Position 72: 270 != 0 | difference 270 > tolerance 0.2700000000000001
    => Position 73: 277.5 != 0 | difference 277.5 > tolerance 0.2775000000000001
    => Position 74: 285 != 0 | difference 285 > tolerance 0.2850000000000001
    => Position 75: 292.5 != 0 | difference 292.5 > tolerance 0.2925000000000001
    => Position 76: 67.5 != 0 | difference 67.5 > tolerance 0.06750000000000002
  67 more errors...

  ---- tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_basic stdout ----
  Testing bias
  Testing input
  Testing offset
  thread 'tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_basic' panicked at crates/burn-wgpu/src/lib.rs:108:5:
  Tensors are not approx eq:
    => Position 1: 15 != 6 | difference 9 > tolerance 0.015000000000000003
    => Position 2: 30 != 12 | difference 18 > tolerance 0.030000000000000006
    => Position 3: 45 != 18 | difference 27 > tolerance 0.04500000000000001
    => Position 5: 3.75 != 1.5 | difference 2.25 > tolerance 0.0037500000000000007
    => Position 6: 7.5 != 3 | difference 4.5 > tolerance 0.0075000000000000015
  65 more errors...

  ---- tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_kernel_size stdout ----
  Testing bias
  Testing input
  Testing offset
  thread 'tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_kernel_size' panicked at crates/burn-wgpu/src/lib.rs:108:5:
  Tensors are not approx eq:
    => Position 1: 5.355899810791016 != 0.007523147854954004 | difference 5.348376662936062 > tolerance 0.005355899810791017
    => Position 2: 11.715299606323242 != 0.34953704476356506 | difference 11.365762561559677 > tolerance 0.011715299606323245
    => Position 3: 0.3125 != 0.10416662693023682 | difference 0.20833337306976318 > tolerance 0.0010000000000000002
    => Position 4: 8 != 2.6666667461395264 | difference 5.333333253860474 > tolerance 0.008000000000000002
    => Position 5: 10 != 3.3333334922790527 | difference 6.666666507720947 > tolerance 0.010000000000000002
  235 more errors...

  ---- tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_padding stdout ----
  Testing bias
  Testing input
  Testing offset
  thread 'tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_padding' panicked at crates/burn-wgpu/src/lib.rs:108:5:
  Tensors are not approx eq:
    => Position 10: 0.8950999975204468 != 0 | difference 0.8950999975204468 > tolerance 0.0010000000000000002
    => Position 11: 14.760600090026855 != 0.03129822388291359 | difference 14.729301866143942 > tolerance 0.01476060009002686
    => Position 12: 17.60420036315918 != 0.5347222089767456 | difference 17.069478154182434 > tolerance 0.017604200363159184
    => Position 13: 20.69809913635254 != 1.1215760707855225 | difference 19.576523065567017 > tolerance 0.020698099136352545
    => Position 14: 22.20039939880371 != 1.624421238899231 | difference 20.57597815990448 > tolerance 0.022200399398803715
  415 more errors...

  failures:
      tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_basic
      tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_batched
      tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_kernel_size
      tests::jit::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_padding
      tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_basic
      tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_batched
      tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_kernel_size
      tests::jit_fusion::autodiff::f32_ty::ad_deform_conv2d::tests::test_deform_conv2d_different_padding

  test result: FAILED. 2039 passed; 8 failed; 16 ignored; 0 measured; 0 filtered out; finished in 110.66s

  error: test failed, to rerun pass `-p burn-wgpu --lib`

That's awesome! Thanks for checking again :) I think the remaining errors are the same as here: https://github.com/tracel-ai/burn/pull/2539
The deformable convolutions might need some attention from Genna, for the others, maybe @nathanielsimard knows?

Close #2451

It just passed CI 20 hours ago ...


Update VPVC Pilot Invitation Main Page Text

https://github.com/bcgov/trust-over-ip-configurations/blob/main/openshift/templates/issuer-web/config/bcvcpilot/terms-and-conditions.html

Updated the ticket to include the content for the main page

resolved by: https://github.com/bcgov/trust-over-ip-configurations/pull/113


Added configuration for bulk mode

This partially addresses #6. Bulk mode prevents the crash, but no persistence yet for crashes. That can come in a later release. Possible to get this merged?

Cherry-picked


Collect test metadata in integration tests

What type of PR is this?
/kind enhancement
What this PR does / why we need it:
The 'go-junit-report' project is used to convert go test output to a JUnit XML report. CircleCI is instructed to store these test results.
Which issue(s) this PR fixes:

Fixes #703
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

Welcome @nfnt! It looks like this is your first PR to kudobuilder/kudo 🎉

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: nfnt
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: jbarrick-mesosphere
If they are not already assigned, you can assign the PR to them by writing /assign @jbarrick-mesosphere in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @nfnt. Thanks for your PR.
I'm waiting for a kudobuilder member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: nfnt, zen-dog
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: jbarrick-mesosphere
If they are not already assigned, you can assign the PR to them by writing /assign @jbarrick-mesosphere in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

I'm testing failed test reporting in https://github.com/kudobuilder/kudo/pull/778.

Small issue with error reporting of failed tests: Even though some tests failed, the overall result was reported as successful. Will have to fix this. This is how failed tests look in CircleCI.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: alenkacz, nfnt, zen-dog
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [alenkacz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Please hold with merging until I fixed the wrong reporting of failed tests.

It's working now with 7fce66b. Take a look at https://github.com/kudobuilder/kudo/pull/778 to see how failed test cases are reported.

/retest

@nfnt: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

test
7fce66b177699bb54bcd399a744dd06e1b2fdbb6
link
/test test

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


doc: update faq.md

Closing as per Sander's request

@diabhey what did Sander say about it?

@Morriz: I shall discuss it offline.


update http healthcheck docs on custom HTTP headers

See https://github.com/deis/workflow-cli/issues/279#issuecomment-267631372

When I tried this there was also some confusion wether X-Foo=bar or X-Foo:bar should be used, because the tests use colon, but the docs use equals…

That would be my fault. Sorry about that!


Release

:tada: This PR is included in version grc-stamp-fronted-v1.4.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


If an empty array is set for voice commands on the SDLMenuCell the AddCommand is rejected

Bug Report
If an empty array is set for voiceCommands when creating a MenuCell the resulting AddCommand is rejected by core because you can not send an empty array.
The screen manager should not set the vrCommands parameter on the AddCommand if the MenuCell's voiceCommands array is empty.
Reproduction Steps

Create a MenuCell with an empty array set for the voiceCommands parameter and use the screen manager to send the menu.

Expected Behavior
The menu item should show up on the HMI
Observed Behavior
The menu item is rejected by Core because of the empty VR command list
OS & Version Information

Android Version: n/a
SDL Android Version: 4.11
Testing Against: n/a

See the iOS issue: https://github.com/smartdevicelink/sdl_ios/issues/1648

Fixed with #1354


FINERACT-1587: Allow add contact details to Client entity

Description
Allow add contact details to Client entity
Apache Fineract JIRA ticket FINERACT-1587
Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!

[ ] Write the commit message as per https://github.com/apache/fineract/#pull-requests

[ ] Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.

[ ] Create/update unit or integration tests for verifying the changes made.

[ ] Follow coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions.

[ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/api-docs/apiLive.htm with details of any API changes

[ ] Submission is not a "code dump".  (Large changes can be made "in repository" via a branch.  Ask on the developer mailing list for guidance, if required.)

FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.

@josehernandezfintecheandomx le agregue el prefijo FINERACT-1587


setup error

Prerequisites

[v0.7.0] neovim version =
[yes] I'm using LSP = (select one - yes/no)
[3] laststatus = (select one - 0, 1, 2, 3)

Describe the bug
I'm getting this error when running that-line:
failed to load strash/everybody-wants-that-line.nvim; reason: ...-that-line.nvim/lua/everybody-wants-that-line/colors.lua:15: Invalid highlight name: diffAdded
To Reproduce
Steps to reproduce the behavior:

install current main: 6b3542183485e8c35209d89f8c6d2ee5bc0f011c
run:       require("everybody-wants-that-line").setup({})

Expected behavior
the plugin doesn't crash

Hey @juantascon what colorscheme are you using?


[TOPI] upsample operator 'NCHWinic' format support.

some hardware accelerator ask packed format data like NCHWinic to fit the
hardware resource, here add 'upsample' 'NCHWinic' format support to help
such requirement.

Thanks @huajsj @Laurawly @jwfromm the PR has been merged.


enable auto-merge from 0.5 to 0.6 [skip ci]

Signed-off-by: Peixin Li<EMAIL_ADDRESS>This PR is waiting for https://github.com/NVIDIA/spark-rapids/pull/2124 to get merged, and also holding for 0.4.2 release
please help review but do not merge, thanks!

NOTE: This one should be merged after #2124

build


Read <PackageName>_TARGETS from the PCF and keep the component association in a target property?

It might be a harder sell to standardize <PackageName>_COMPONENTS, which we are reading now, and to enforce the implicit association between a "component" and a target. Instead, we could define a custom target property for the component association. We need to make sure that CMake copies custom properties in the export file.

I was confused by <PackageName>_COMPONENTS as I assumed the components in question were CMake package components, but looking at the code, I think your meaning is Conan components?
Defining a <PackageName>_TARGETS variable in the PCF instead makes sense to me.
Regarding the custom target property, I had assumed there would be a one-to-one mapping from CMake targets to Conan components, but are you thinking multiple CMake targets might be wrapped up into one Conan component?

I wrote this before Conan had finished developing multiple components. Back then, every Conan package defined just a single export, and the cmake_find_package generator would create a Find Module with just a single target. I'll have to revisit this project in light of the new Conan architecture around multiple components.

I just stumbled across @SpaceIm's abseil recipe which has what looks like a missing piece of the puzzle?
https://github.com/conan-io/conan-center-index/blob/0cde6a37fc8f355f713e9b227fc037ce0d574d09/recipes/abseil/all/conanfile.py#L74


Using XMLHttpRequest causes an error when used in a ServiceWorker

https://github.com/ionic-team/rollup-plugin-node-polyfills/blob/9b5fe1a9cafffd4871e6d65613ed224f807ea251/polyfills/http-lib/capability.js#L20
ServiceWorkers do not include the XMLHttpRequest object. This could be updated to use fetch instead to fix this issue.

or maybe the hasFetch could be used to provide a fetch version.

I understand more about why this is used now. Is there any other way to perform these tests?

I'm going to close this because my issue was resolved by fixing the plugin position in the rollup config. Once I had that set properly the module that was causing issues was not imported in my service worker.

I should add the proper position. In my case I was using this with the commonjs plugin. The proper order is to use commonjs, nodePolyfill, nodeResolve. The nodePolyfill should be before nodeResolve as stated in the examples.


Multiple file upload

Codecov Report

Merging #157 (6774e8c) into main (31bd3aa) will decrease coverage by 4.34%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #157      +/-   ##
==========================================
- Coverage   88.15%   83.81%   -4.35%
==========================================
  Files          11       11
  Lines         228      278      +50
  Branches       19       28       +9
==========================================
+ Hits          201      233      +32
- Misses         25       39      +14
- Partials        2        6       +4

Impacted Files
Coverage Δ

backend/controllers/admissions.js
80.80% <100.00%> (-5.95%)
:arrow_down:

backend/services/attachment.js
100.00% <100.00%> (ø)

backend/services/mailer.js
80.00% <0.00%> (-12.86%)
:arrow_down:

Continue to review full report at Codecov.

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


[Bug]: CCIP Transfer Token with Data tutorial mix up

Describe the bug
mixed up Ethereum Sepolia with Polygon Mumbai...
on step 4 Deploy your receiver contract on Polygon Mumbai:
sub step 6 Enable your contract to receive CCIP messages from the contract that you deployed on Ethereum Sepolia:
it should be Polygon Mumbai

In Remix IDE, under Deploy & Run Transactions, open the list of transactions of your smart contract deployed on Polygon Mumbai.
Call the whitelistSender with the contract address of the contract that you deployed on Polygon Mumbai

To Reproduce

Go to Transfer Token with Data tutorial

then go to step 4 Deploy your receiver contract on Polygon Mumbai:

then go to step 6 Enable your contract to receive CCIP messages from the contract that you deployed on Ethereum Sepolia:

See error
In Remix IDE, under Deploy & Run Transactions, open the list of transactions of your smart contract deployed on Ethereum Sepolia.
Call the whitelistSender with the contract address of the contract that you deployed on Ethereum Sepolia.

It should be Polygon Mumbai for both steps 1 and 2.

URLs
https://docs.chain.link/ccip/tutorials/programmable-token-transfers
Expected behavior
No response
Additional context
No response

let me know if you want me to submit a pull request


Server now subscribes to explicit queue with name based on routing key.

Reworked the changes and put on a different branch, so closing this one.


Proposal: link data-model items to the rendered schema page

Description
Sections like Iroha Special Instructions | Hyperledger Iroha 2 Tutorial have a lot of mentions of the data model. It might be useful to add links to the Data Model Schema | Hyperledger Iroha 2 Tutorial section from there, so the readers might see more connections.
Unresolved questions:

To which channel we should make connections (to lts, dev or stable)? All of them are located on different pages.
The linking might be very fragile without anchors validation (#306)

Hello, can I work on this issue


Cannot read property 'Aspect' of undefined

I am getting this error when I try to run my project.

RN Version:
react-native-cli: 2.0.1
react-native: 0.44.0

What I have tried:

Deleting my node modules
Re - installing react-native-camera
Re - linking

I had this problem before, it stopped showing after I rebuild the project, but now it's back and I can't fix it. Does anyone have a hotfix for it?

This issue has resolved its self seemingly at random. I do not want to close this issue, because I do not think it has been resolved there is still no good solution for the problem.
Thanks!

I rebuild the app and the error was gone

Anyone still suffering from this issue?  I think I may have seen it when I first installed react-native-camera, but I believe it was because I had the app running when I ran react-native link react-native-camera, and needed to rebuild to link up all of the camera stuff.  Works fine for me.

I'm still getting the issue, even after uninstalling and reinstalling.

@tuckerjt07
Which version of react-native-camera are you using?
I had this error too but when I upgraded to the latest version and followed the readme instructions on the main page it resolved the issue.

I got this problem too
...
├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>...

I'm having the same issue. Is there any solution?

Same here!

Me too

+1 I also have this for another of my packages too
Tried linking, unlinking, removing and adding frameworks

I somehow got it working again by doing this
I completely reset my simulator and quit the simulator application
I closed the react-native packager
react-native unlink react-native-camera
react-native link react-native-camera
react-native run-ios

I also got it working by resetting content and settings for simulator

I am going to close this issue, because of @JanErikFoss answer.

@JanErikFoss Solution does not work for. Is not a link issue. I thinl that It is related to async native module loading.

ok sounds good, thanks for re-opening.

Is there any update for this? Please, I need a fix or at least a workaround for this

I was able to fix it on Android by changing the method getConstants of com.lwansbrough.RCTCamera.RCTCameraModule.java to:
@Override
public Map<String, Object> getConstants() {

    Map<String, Object> aspect = new HashMap<>();
    aspect.put("stretch", RCT_CAMERA_ASPECT_STRETCH);
    aspect.put("fit", RCT_CAMERA_ASPECT_FIT);
    aspect.put("fill", RCT_CAMERA_ASPECT_FILL);

    Map<String, Object> barcode = new HashMap<>();

    Map<String, Object> type = new HashMap<>();
    type.put("front", RCT_CAMERA_TYPE_FRONT);
    type.put("back", RCT_CAMERA_TYPE_BACK);

    Map<String, Object> captureQuality = new HashMap<>();
    captureQuality.put("low", RCT_CAMERA_CAPTURE_QUALITY_LOW);
    captureQuality.put("medium", RCT_CAMERA_CAPTURE_QUALITY_MEDIUM);
    captureQuality.put("high", RCT_CAMERA_CAPTURE_QUALITY_HIGH);
    captureQuality.put("photo", RCT_CAMERA_CAPTURE_QUALITY_HIGH);
    captureQuality.put("preview", RCT_CAMERA_CAPTURE_QUALITY_PREVIEW);
    captureQuality.put("480p", RCT_CAMERA_CAPTURE_QUALITY_480P);
    captureQuality.put("720p", RCT_CAMERA_CAPTURE_QUALITY_720P);
    captureQuality.put("1080p", RCT_CAMERA_CAPTURE_QUALITY_1080P);

    Map<String, Object> captureMode = new HashMap<>();
    captureMode.put("still", RCT_CAMERA_CAPTURE_MODE_STILL);
    captureMode.put("video", RCT_CAMERA_CAPTURE_MODE_VIDEO);

    Map<String, Object> captureTarget = new HashMap<>();
    captureTarget.put("memory", RCT_CAMERA_CAPTURE_TARGET_MEMORY);
    captureTarget.put("disk", RCT_CAMERA_CAPTURE_TARGET_DISK);
    captureTarget.put("cameraRoll", RCT_CAMERA_CAPTURE_TARGET_CAMERA_ROLL);
    captureTarget.put("temp", RCT_CAMERA_CAPTURE_TARGET_TEMP);

    Map<String, Object> orientation = new HashMap<>();
    orientation.put("auto", RCT_CAMERA_ORIENTATION_AUTO);
    orientation.put("landscapeLeft", RCT_CAMERA_ORIENTATION_LANDSCAPE_LEFT);
    orientation.put("landscapeRight", RCT_CAMERA_ORIENTATION_LANDSCAPE_RIGHT);
    orientation.put("portrait", RCT_CAMERA_ORIENTATION_PORTRAIT);
    orientation.put("portraitUpsideDown", RCT_CAMERA_ORIENTATION_PORTRAIT_UPSIDE_DOWN);

    Map<String, Object> flashMode = new HashMap<>();
    flashMode.put("off", RCT_CAMERA_FLASH_MODE_OFF);
    flashMode.put("on", RCT_CAMERA_FLASH_MODE_ON);
    flashMode.put("auto", RCT_CAMERA_FLASH_MODE_AUTO);

    Map<String, Object> torchMode = new HashMap<>();
    torchMode.put("off", RCT_CAMERA_TORCH_MODE_OFF);
    torchMode.put("on", RCT_CAMERA_TORCH_MODE_ON);
    torchMode.put("auto", RCT_CAMERA_TORCH_MODE_AUTO);

    Map<String, Object> constants = new HashMap<>();
    constants.put("Aspect", aspect);
    constants.put("BarCodeType", barcode);
    constants.put("Type", type);
    constants.put("CaptureQuality", captureQuality);
    constants.put("CaptureMode", captureMode);
    constants.put("CaptureTarget", captureTarget);
    constants.put("Orientation", orientation);
    constants.put("FlashMode", flashMode);
    constants.put("TorchMode", torchMode);
    return constants;
}

@puelocesar, I've tried out your solution but it did not work for me. I did this:
1 - Replaced method getConstants() by your code
2 - cd android && .\gradlew clean
3 - cd.. && react-native run-android
4 - The app crashed on start with red screen (Aspect is undefined)

I'm getting the same error and sometimes it works randomly. It seems the getConstants() method runs asynchronously as the properties sometimes aren't available as expected when calling the native module:
https://github.com/lwansbrough/react-native-camera/blob/master/index.js#L14
According to the react native documentation at https://facebook.github.io/react-native/docs/native-modules-android.html the getConstants() method returns the constant values exposed to JavaScript. Its implementation is not required but is very useful to key pre-defined values that need to be communicated from JavaScript to Java in sync.
So the documentation states that the getConstants() is synchronous but in my experience it acts asynchronously.  Perhaps this isn't a bug with the react-native-camera module but rather with the react documentation.
Does anyone else think this is the issue?

@ferminmoli so, I got the error again, and after digging a little more, I found out that react-native-camera was conflicting with react-native-camera-kit, because both have a NativeModule called CameraModule. Maybe this can help you?
@freakyfriday well, after changing the implementation of getConstants to make it more similar with react documentation (see the above code), the problem disappeared for me

Guys Check your Info.plist file. If you changed that file and its not correct format it can causes that error.
Info.plist file must be in a format that  and next line  after correcting. react-native run-ios or run-android.

I am seeing this issue, still no solution?

Hi @JimmyMow I'm using both react-native-camera and react-native-camera-kit where there is a clash in module names. This clash caused the react-native-camera constants to load incorrectly depending which module loaded first (which made it appear random).
I followed the advice of @puelocesar and updated the react-native-camera-kit module to rename CameraModule.java to CameraKitModule.java This solved my issue.
You can find my code at https://github.com/freakyfriday/react-native-camera-kit
Thanks @puelocesar for the tip :-)
Hope this helps you too.

@freakyfriday thanks for the reply. I'm not using react-native-camera-kit, I'm using this repo to use react-native-qrcode-scanner. I've tried everything and still no luck.
"react": "16.0.0",
"react-native": "0.50.3",
"react-native-camera": "^0.10.0",
"react-native-qrcode-scanner": "^0.0.23",

i'm getting this error too (android only).

use react-naive link react-native-camera
and build again

If you're getting this error, then that means react-native link failed for whatever reason. Here are the steps I took to get this to work for iOS

yarn add react-native-camera
react-native link react-native-camera (it'll say it's linked, but it's actually not)
Open your Xcode Project or Workspace, whichever you're using.
Drag the file ./node_modules/react-native-camera/ios/RNCamera.xcodeproj into your Libraries folder in Xcode

Add libRNCamera.a to your Linked Frameworks and Libraries

Clean your project and then run it. It should work as expected now.

Thanks @russelh15!! It worked for me :)
Only difference: I'm using version 0.12.0of react-native-camera, so I had to include

RCTCamera.xcodeproj instead of RNCamera.xcodeproj
libRCTCamera.a instead of libRNCamera.a
I hope this can bless someone

One root cause on iOS seems to be the following:
If your Xcode project has multiple TARGETs react-native link will derp and only link to the first Target. So just go to: Your Target > Build Phases > Link Binary With Libraries and be sure to add libRNCamera.a
So the issue is with react-native link which seems to always 💩 the 🛏 on multiple targets, at least in my experience.

Change RNCamera.Constants.Aspect.fill  to RNCamera.constants.Aspect.fill works for me


[AIRFLOW-243] Create NamedHivePartitionSensor

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

AIRFLOW-243

Testing Done:
Created dag using NamedHivePartitionSensor and check that it waits for the partition as expected
@plypaul

[Current coverage][cc-pull] is 67.89%

Merging [#1593][cc-pull] into [master][cc-base-branch] will decrease coverage by 0.14%

@@             master      #1593   diff @@
==========================================
  Files           116        116
  Lines          8310       8335    +25
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           5654       5659     +5
- Misses         2656       2676    +20
  Partials          0          0

Powered by Codecov. Last updated by [8aa7160...7e7acd9][cc-compare]
[cc-base-branch]: https://codecov.io/gh/apache/incubator-airflow/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/apache/incubator-airflow/compare/8aa7160c4b8bf23663c4d63c46abd5d631d8b20b...7e7acd9d43e3980e541898e899ce0d04fb3af727
[cc-pull]: https://codecov.io/gh/apache/incubator-airflow/pull/1593?src=pr

@mistercrunch and I thought that adding warning messages to HivePartitionSensor would be good to do so that users know that it can be expensive. It also makes sense for this to be the default Hive partition sensor to use - can you mention this in the docs?

@plypaul Added stuff to the docs - what do you mean by adding a warning message to HivePartitionSensor?

A note in the HivePartitionSensor docstring saying that the operator may issue large and expensive queries on the metastore DB along with a recommendation to use the NamedHivePartitionSensor.
Also, a similar warning can be printed through the logger when the operator actually runs.

@plypaul I put the docstring warning, but I don't think we should log a warning because there could be legitimate cases where HivePartitionSensor is intended (eg someone actually needs to wait on a ds > '2016-01-01' partition)

Nice work @zodiac! LGTM

@mistercrunch @aoen ^

are there any numbers on the performance difference between Named and HivePartitionSensor?

nice work @zodiac

Looks good to me 👍


Data generator for model evaluation and prediction.

Refactor __get_dataset() to always return data generator.
Modify functions to handle generator.
Closes #7.

@davidsebfischer this is ready to merge from my side. If your happy with it you can just merge :)


Add Click to View Photo to Home Screen Widget

Summary:
Add onClick Event to View Photo to the Home Screen Widget so that a user can view the original image.
Steps to reproduce:
Click on the image of Home Screen Widget
Commons app version:
latest prodDebug
Would you like to work on the issue?
Yes

@nicolas-raoul We can definitely do that, could you please suggest me the Intent


London has no locality

If you try to search London for the first time the locality field is empty. (London, United Kingdom)
But if you click on find again the results are correct. (London, UK)
http://ubilabs.github.io/geocomplete/examples/form.html
With types: ['(cities)'] it is not possible to find London at all.

👍 Same here. What's the status on this?

Looks like it works here now. I didn't change anything.


Warn on JSX file extension with check-filename-webpack-plugin

Fixes #290

Sorry for the churn, can you rebase please?

No worries, it's all synced up now, should be good. Let me know if any of the copy in the comments or the error message needs any massaging.
Thanks!

Closing now because we support JSX extension since 0.4.1 even though we don’t recommend it.
Read the release notes.
Thanks for sticking with us 😄


Migrate listener group

Closes #48

Good news: I have a functioning implementation of this. Tomorrow, I should be able to open this for review.

I've tweaked the label so that it looks good IMO. Ready for review.

I've tweaked the label so that it looks good IMO. Ready for review.

As discussed in our meeting: LGTM :-) Can be merged IMO


IDLs with 'account' suffixes cause duplicate methods

Assume an IDL with this structure:
{
  "version": "0.0.0",
  "name": "program",
  "instructions": [
      "name": "bar",
      "accounts": [
        {
          "name": "foo",
          "isMut": false,
          "isSigner": true
        },
        {
          "name": "fooAccount",
          "isMut": true,
          "isSigner": false
        }
      ]
  ]
}

As Account is stripped from the latter name, duplicate GetFoo and SetFoo receiver methods are created.  I'm running into this in the real world with an existing project.
Happy to contribute a fix but not sure what the solution should be. Possibilities:

Don't strip Account entirely
Drop strip if conflict exists.
Add extra suffix if conflict exists
Error out and don't generate code

That's a tricky issue.
Let's see what happens in each case:

Don't strip Account entirely

SetFooAccount
SetFooAccountAccount

Drop strip if conflict exists.

That's reasonable.

Add extra suffix if conflict exists

I feel this is the same as the first scenario, with a different suffix.

Error out and don't generate code

This also would make sense.

How about this:

By default, don't strip the account suffix.
A special flag allows to strip the suffix.
Fatal error if there is a name conflict (whether with flag or not).


Add to_numpy_array or to_numpy_matrix

What is the expected enhancement?
It would be great if retworkx supports to_numpy_array or to_numpy_matrix.
It is used in a tutorial of qiskit-optimization.
https://github.com/Qiskit/qiskit-optimization/blob/main/docs/tutorials/06_examples_max_cut_and_tsp.ipynb
It is not urgent because we can implement a utility function in Python.
Related to https://github.com/Qiskit/qiskit-optimization/pull/150

There is an adjacency_matrix function. See https://qiskit.org/documentation/retworkx/stubs/retworkx.adjacency_matrix.html#retworkx.adjacency_matrix

Thank for your information. It would be great if it is mentioned in https://qiskit.org/documentation/retworkx/networkx.html


Rich colors don't work when deployed to Cloudflare Pages

Describe the bug
Hi;
I wanted to point out that I couldn't see rich colours rendered when my project is deployed to Cloudflare Pages, only the defaults-ish, since only the icons seem to work, but the rest of the toast not so much.

Strange enough, locally everything is fine.
Thanks for the consideration.
Reproduction
I'll prepare a repo/repro if need be, but the only way to test this, if you don't me troubling you, is to please try deploying to CF pages and see for yourself.
Logs
No response
System Info
System:
    OS: macOS 13.6.3
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Memory: 116.98 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.11.1 - ~/Library/pnpm/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.4 - ~/Library/pnpm/npm
    pnpm: 8.15.4 - ~/Library/pnpm/pnpm
    bun: 1.0.3 - ~/Library/pnpm/bun
    Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
  Browsers:
    Chrome: 123.0.6312.87
    Firefox Nightly: 126.0a1
    Safari: 17.2.1
  npmPackages:
    @sveltejs/kit: ^2.5.4 => 2.5.4
    svelte: ^4.2.12 => 4.2.12
    svelte-sonner: ^0.3.19 => 0.3.19

Severity
annoyance

Seeing the same thing, did you find anything to fix this?

Sorry, but no. I understand Robert is busy atm, but hopefully we'll get some input soon. 🙂

Had the same bug, was fixed for me after following package updates, not sure which one included the fix:

mode-watcher: 0.1.2 -> 0.3.0
svelte-sonner: 0.3.11 -> 0.3.22

@deronek is your app deployed to CF pages as well?

@deronek is your app deployed to CF pages as well?

correct, richColors worked correctly in local Vite dev environment, while did not work on Cloudflare Pages deploy with SSR (exactly as in OP - close button was colored, while the toast was not).

I have never tried deploying an app to CF pages and this is probably the best time to do it haha. I'll let you guys know if I'm able to replicate and fix it asap

Hello;
Forgot to follow-up on this:

Had the same bug, was fixed for me after following package updates, not sure which one included the fix:
mode-watcher: 0.1.2 -> 0.3.0
svelte-sonner: 0.3.11 -> 0.3.22

Like @deronek version 0.3.22 doesn't have the bug, and it all works as expected.
Will leave this open until you can confirm @wobsoriano 🙂
Cheers.


Reduce package keyword count to 5.

Apparently crates.io allows at most 5 keywords.  So we can't publish without this change.

Since this change affects nothing but the publish process on crates.io, I'm not going to bother re-tagging the GitHub release.  Instead the published crate will have one fewer keywords than the tagged crate.


Mention enabling using the plugin in Ambiguous error messages

Enabling the -fplugin=Polysemy.Plugin ghc flag will solve 90%+ of ambiguous effect errors; the custom error messages should mention this!

I would like to try taking a stab at this.


Synchronize X11 clipboard with compositor clipboard

Currently you can't copy between X11 and wayland views.
See also: https://github.com/Cloudef/orbment/issues/47

wlc's problem imo


Communication with Python script

I want to communicate with an RFID reader connected to Pi by GPIO. I am able to process that values by Python script.
How that Python script can send some event to SPA running in Webkit?

Maybe turning WPE to multicontainer like in #29 and in second container run websocket server available only to other containers, so app in browser can access it over HTTP?

@iBobik yeah that's the general idea. Having wpe run as a separate container that gets all its data over HTTP by talking to other containers running next to it

@iBobik Communicating between containers over a websocket works well.
Here is what our docker-compose.yml looks like to do that:
version: '2.1'
services:
  my-app:
    build: ./my-app
    privileged: true
    restart: always
    depends_on:
      - display
    network_mode: host
  display:
    build: ./wpe
    devices:
      - "/dev/fb0:/dev/fb0"
      - "/dev/vchiq:/dev/vchiq"
    restart: always
    network_mode: host

I would not recommend to use network_mode: host if you do not want your internal API have exposed to other devices on a network.

2019 v 10:39, Patrick Murray<EMAIL_ADDRESS>

@iBobik https://github.com/iBobik Communicating between containers over a websocket works well.
Here is what our docker-compose.yml looks like to do that:
version: '2.1'
services:
my-app:
build: ./my-app
privileged: true
restart: always
depends_on:
- display
network_mode: host
display:
build: ./wpe
devices:
- "/dev/fb0:/dev/fb0"
- "/dev/vchiq:/dev/vchiq"
restart: always
network_mode: host
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/balena-io-projects/balena-wpe/issues/44?email_source=notifications&email_token=AAEV6WB3WTK2B54EQPOGQJLPXOM33A5CNFSM4HK3CU72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWJFXZI#issuecomment-496131045, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEV6WBKN4YVOZB4LOMN463PXOM33ANCNFSM4HK3CU7Q.


perf: impl put_many and reuse column families

This requires getting rid of a lot of async in the store. Async only in the public interface.
I want to do some more reorg here, but in the interest of getting something on main soon I will refrain from it...

Main:

This branch:

@rklaehn did you switch up things? or does this make things slower?

@rklaehn did you switch up things? or does this make things slower?

If Im reading the above correct, it's 1 sec faster but uses more CPU cores (hence user time higher)


[bug] Using Gazebo set_model_configuration srv messes up joint_states

During my RL training, the robot sometimes becomes stuck. When this happens, I use the /gazebo/set_model_configuration service to set the Panda robot to a free robot position. However, when doing this, the joint positions are sometimes reported to be outside their joint limits. This prevents third-party tools like MoveIt from functioning.
Why this happens is very clear by looking at the code:
https://github.com/frankaemika/franka_ros/blob/15f597566fd9f1aa1a66bce4c1b3b183e8aaa081/franka_gazebo/src/joint.cpp#L30
Every time the /gazebo/set_model_configuration changes the joint positions, they get added to the joint->positions attribute. As a result, when the change made by the  /gazebo/set_model_configuration  is too big, the reported joint positions are pushed outside the joint limits.
I understand why this is implemented, but providing users with a way to reset the joint positions would be very helpful since it is a common use case.
I implemented a PR to add a set_franka_model_configuration service in #226.
See the behaviour in action

Clone the https://github.com/rickstaa/franka_ros/tree/show_gazebo_set_model_config_problem.
Build the catkin workspace.
Source the catkin workspace.
Start the panda simulation roslaunch franka_gazebo panda.launch use_gripper:=false physics:=dart controller:='force_example_controller'.
Start the franka_gazebo/scripts/log_joint_violations.py script (i.e. rosrun franka_gazebo log_joint_violations.py).
Start the franka_gazebo/scripts/set_random_joint_positions.py script (i.e. rosrun franka_gazebo set_random_joint_positions.py) script.
See the reported joint positions being pushed outside the joint limits.

[!NOTE]
This branch also includes https://github.com/frankaemika/franka_ros/pull/211 because the ODE physics engine is not stable when performing force control (see https://github.com/frankaemika/franka_ros/issues/160#issuecomment-989173918).

See the fix in action

Checkout the test_fix_gazebo_set_model_config_problem branch.
Perform set  2-5 above.
Start the franka_gazebo/scripts/set_random_joint_positions_226.py script (i.e. rosrun franka_gazebo set_random_joint_positions_226.py).
See that now the joints stay within the joint limits.

TODOs

[ ] Merge #226

I've recently observed an issue stemming from the changes introduced in commit 89d25713b741631ca9f4f417585e7835d160cf4a. Specifically, after invoking the original Gazebo set_model_configuration, the robot reverts to its initial position (see gif below). I adapted #226 to allow users to set the Franka configuration still.


Lack of compatibility with quick-explorer plugin

Hey there,
One thing that I noticed is that this plugin doesn't work well with Quick Explorer. It keeps showing all files, even the excluded ones (Files and links settings). Do you think it is worth fixing?
See more details: https://github.com/pjeby/quick-explorer/issues/92
Thanks!

Hmm, finally had time to look into this.
Most I can do is hiding the folder from quick explorer, but I cannot change the numbers associated. Looks like this:

So the hidden folder would be number 2 and is just missing in this example

Yes, this is it. Perfect, thanks a lot :)

Ok I FINALLY found some time & motivation to write a solution I am happy with. Had to do some hacking around the menu positioning of quick-explorer, but I think it finally works good enough 🙏
To use it, you need to enable the experimental setting for it, it is disabled by default.
Let me know if you notice problems.
See v1.4.0 changelog regarding where to find the new experimental setting: https://github.com/JonasDoesThings/obsidian-hide-folders/releases/tag/1.4.0

Gonna close it for now since it's released in the latet update. If you encounter any issues with the experimental feature in the new version feel free to either re-open this issue, or open a new one :)
Greetings from Austria


[Voting] Name of the base repository

Hey all,
as @stonemaster has recently moved this repository to the dlang-tour organization, we have the moral obligation to find a suited name ;-)
To avoid bike-sheding, this issue can be used to post suggestions and vote for them. A couple of rules:

only one name per comment (see my examples below)
voting is done with the thumbs-up button of GH
you can vote for as many names as you like

We will give this enough time, s.t. everyone has a fair chance to propose names and vote, so the decision will be made based on a majority-vote on Thursday next week (2017-06-08).
Happy voting :+1:

base

core

server

core-web (credit to @ZombineDev)

tour-web

vote for keeping the old name

core & core-rdmd it's then. Thanks a lot @ all for participating!


Temp fix for valve update from 16 january 2022

Here is instruction of how get back NoBling to work.
ALL REGARDS AND THANKS GOES TO @Wolf49406 WHO PERSONALLY HELPED ME TO MAKE IT REAL !

Launch Hex Editor (like HxD Hex Editor)
Open file client.dll in directory
\Steam\steamapps\common\dota 2 beta\game\dota\bin\win64\

Press Ctrl+F and enter this simbols 44 38 67 39 74 39 in the search tab named HEX-VALUE .
When you found the line with that 44 38 67 39 74 39 then change 74 to EB and you will get this 44 38 67 39 EB 39
Save file.

Open file gameinfo.gi by Notepad++ programm.
File gameinfo.gi is in directory
\Steam\steamapps\common\dota 2 beta\game\dota
and
Change line 39 to
Game dota_tempcontent
and line 40 to
Mod dota_tempcontent

It will looks like this:
https://gyazo.com/918713fc4d59eeb9a6ede8a37231aeb9
Save file gameinfo.gi
Now you can start Dota 2 and enjoy with NoBling functions.

Or just use my new patcher.


[occm] Remove volume related code from occm

What this PR does / why we need it:
Remove volume related code from openstack-cloud-controller-manager. The code was initially moved from k8s in-tree code, but the volume related functions were never provided by occm, especially the cinder-csi-plugin is the way to go.
What's more, removing the code also deletes the volume related unit test from cloud-provider-openstack-unittest job, which always causes CI issues.
Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:

Release note:

NONE

/test cloud-provider-openstack-acceptance-test-csi-manila

@ramineni ready for review

Thanks.
/lgtm

To fix quota issues , merging this
/approve


add shorthand help (-h) to CLI

Closes #85

Thanks! Seems right, but I'm just doing late coffee =P will review later.


[setup] requirements, virtualenv, and misc cleanup

to @airbnb/streamalert-maintainers
size: small
pri: high

Update requirements.txt to have additional dependencies
Update Getting Started instructions to use virtualenv to make installations more consistent
Cleanup print statements from previous PR

cc @tunkaflux


Missing geometry on scene-viewer

Description
When loading this model in the scene-viewer,  parts of the geometry is missing. It should be three planes and three cubes, but only the three planes are visible. The GLTF seems to be in order, no issues when I check the model details on https://gltf-viewer.donmccurdy.com/. This does not happen in WebXR or when the scene-viewer was created via the model-viewer (with this page at least https://modelviewer.dev/editor/).
Is there a difference in how I load the scene-viewer compared to the example below? I couldn't find anything.
Live Demo
A very easy CodeSandBox to reproduce the issue:
https://codesandbox.io/s/6rrwto
The model (three cubes and three planes):
https://shapediverviewer.s3.amazonaws.com/v3/gltf/example.gltf
It works when I load the same model on the model-viewer editor and select "Default AR Mode to Scene Viewer". I looked at the code of the model-viewer and how the scene-viewer is loaded there and I could not find a difference.
Version
scene-viewer 1.0 / 1.1
Browser Affected

OS

[ X ] Android
[ ] iOS
[ ] Linux
[ ] MacOS
[ ] Windows

AR

[ ] WebXR
[ X ] SceneViewer
[ ] QuickLook

Hey @elalish ,
sure, so here you can see how it should look like and how it does look like when I start the scene-viewer via the model-viewer.
And here is how it looks like when loaded directly in the scene-viewer as I show in the CodeSandBox.
Cheers

Hi, I am also experiencing this issue with missing geometry.
Problem appears if more than one node has the same name! According to the GLTF spec, property "name" should not be interpreted as unique value, it is not even required. If I remove the name properties from nodes, everything works fine, but if two nodes have the same name it all breaks down. It really is a strange and very troublesome bug! Modifing all exsiting models to work around such a simple issue is a real pain.
Can we expect any fix soon?

Yep, verified here too - doesn't happen on a colleagues' old phone which hasn't updated SceneViewer (/Google app).
This model doesn't work, it breaks in weird ways (some models become transparent, others fail to render entirely)
Talia 1G.zip
This model works (same but manually edited the nodes with gibberish)
Talia1GTest.zip
Switching over to WebXR as a reasonable stopgap for now but SceneViewer still provides the best experience, sadly (especially on older devices)

It's been reported and the regression identified. A fix should roll out over the next week or two.

a same issue, hope on soonest fix

I have a similar issue, hope it'll be fixed soon, I'm following this git to receive good news.


cldf validate is more lenient than createdb about missing (not even a delimiter) columns

As long as none of the columns are required, cldf validate does not complain about rows where the number of delimiters does not fit the number of rows, taking the last rows as empty. The line to be inserted was given as
Numerical_ID,Name,Glottolog_Name,Glottocode,ID,Comment
1,Achagua,Achagua,acha1250,Achagua

and that passes cldf validate with no issues. (There is a note somewhere in a discussion between us that the database can only reflect fewer constraints on the data structure than the metadata, so createdb rejecting something that validate let pass is slightly confusing. I'll have another such case in a moment, when I get down to the root of it.)

NOTE: The issue may have been encountered when the Comment column was not specified in the Metadata, so it's worth checking both cases when trying to reproduce the error. But I'm pretty sure this was after I added the column to the metadata, because before createdb would just die at the encounter with an unknown column.

Converting the dataset to SQLite, on the other hand, leads to the following really unhelpful traceback.
INSERT INTO `LanguageTable` (`Numerical_ID`,`cldf_name`,`Glottolog_Name`,`cldf_glottocode`,`cldf_id`) VALUES (?,?,?,?,?)
(('1', 'Achagua', 'Achagua', 'acha1250', 'Achagua'),)
Traceback (most recent call last):
  File "/home/gereon/.local/etc/lexedata/lib/python3.8/site-packages/csvw/db.py", line 75, in insert
    db.executemany(sql, rows)
sqlite3.ProgrammingError: Incorrect number of bindings supplied. The current statement uses 5, and there are 6 supplied.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/gereon/Develop/lexedata/src/lexedata/importer/cognates.py", line 41, in <module>
    excel_parser_cognate = ExcelCognateParser(
  File "/home/gereon/.local/etc/lexedata/lib/python3.8/site-packages/pycldf/db.py", line 234, in write_from_tg
    return self.write(_force=_force, _exists_ok=_exists_ok, **items)
  File "/home/gereon/Develop/lexedata/src/lexedata/cldf/db.py", line 340, in write
    insert(db, self.translate, t.name, keys, *rows)
  File "/home/gereon/.local/etc/lexedata/lib/python3.8/site-packages/csvw/db.py", line 79, in insert
    insert(db, translate, table, keys, row, single=True)
  File "/home/gereon/.local/etc/lexedata/lib/python3.8/site-packages/csvw/db.py", line 75, in insert
    db.executemany(sql, rows)
sqlite3.IntegrityError: UNIQUE constraint failed: LanguageTable.cldf_id

There are several levels of obfuscation going on here. The first is the mismatch in complaints between validate and createdb*.
The second line of confusion is that the first exception states The current statement uses 5, and there are 6 supplied., but the print statement just before that error is encountered only shows 5 parameters.
The third issue is that due to the error handling in pycldf.db, which wants to be helpful by switching from a multi-line insert to a single-line insert to hone in on the exact row where the error happens, the original exception is masked by an sqlite3.IntegrityError: UNIQUE constraint failed: LanguageTable.cldf_id.

*) Technically, I used my own wrapper around a version of pycldf.db that treats association tables differently. No association tables were harmed in the making of this issue, and the write_from_tg() method sits at the core of the issue in both cases.

@Anaphory What do you think about this solution: https://github.com/cldf/csvw/issues/40
Seems straightforward to implement, is backwards compatible, and generally seems to make things work™?

Alternatively, augmenting the row could be done just upon inserting the data into the database. But I think the former solution is more correct, i.e. missing columns can (and should) be interpreted as shorthand for adding a bunch of NULL values.

Upgrading to csvw>=1.8 should fix this problem.


Grid support finished.

Grids have been added to Kotter, enabling the use of arbitrary sized table-like organization of text. These extensions are compatible with existing primitives, with some further additions for necessities like wrapText and wrapTextLine for better presentation of grids.
Unit tests have also been provided to cover some of the basic forms of grids that users might try to create.
Note: There is a significant drawback with the current implementation. When the user defines columns, then there must be that many cells present in every row. If not, then two failures will happen. Cells may appear out of order depending on where the missing cell is, and the last row will never render.
As a workaround, empty cells have been tested to work just fine, and should be used to ensure every row is filled.

Cloned to version name: https://github.com/varabyte/kotter/pull/108


Update example YAML to use arrays for plugins

Hi @pda! 😊
We’ve updated our recommended plugin syntax to use arrays instead of a map, to help ensure plugins are executed in the correct order with all agent versions.
This PR updates your readme example to be the new recommended syntax, and makes them pass the latest plugin-linter checks.
Let me know if you have any questions! We’d love to get the readme updated so people use the new best-practice syntax.

@harrietgrace! Thanks, I just came across this gem amongst my email noise. 💎


Add feature of linking manually created JIRA tasks to finding

Is your feature request related to a problem? Please describe
This feature is not related to any problem directly, however, it may add useful functionalities.
Describe the solution you'd like
Using put or patch requests to /api/v2/findings/{id}, I'd like to link manually created JIRA task to some finding, that is in "Active, Verified" state.
Describe alternatives you've considered
I tried to do the following thing in present API, but no changes were applied.
Additional context
n/a

Need the same functionality

We need this for our clients

+1

+1

In theory it's possible via api/v2/jira_finding_mappings but I agree an easier way would be helpful. It can be done via the UI already, but not the API.

Nice feature

@valentijnscholten
Any suggestions on if this feature will be added?


brach-2.0use 2 phase agg above union all

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

https://github.com/apache/doris/pull/26664

run buildall

#26245


Refreshing page returns Failure 70

Refreshing the page returns Failure 70 out-of-the-box. The same is true for a new tab or a different device = concurrent viewing of the same stream doesn't work. After some tweaking, I was able to avoid calling raspivid more than once, avoiding the Failure 70 error. I tried implementing pkill raspivid to no avail.

Was able to implement pkill raspivid and relaunch node server-rpi.js via script, however it requires a double refresh of the page to reload the video stream.