#13 partial. Added geomath::ang_diff test and benchmark

Currently uses a static truncated dat file. I hope to improve on that in later pull requests.
The current draft makes geomath public. This is required for testing its operations using integration tests, but wouldn't be required if I created the test as a unit test instead. I think we'll want it to be public eventually, some of my non-CI geomath suggestions (e.g. #10) include breaking changes, so it might be preferable to avoid making geomath public in master until after those breaking changes are either applied or rejected.

The dat file format is my making. The character escaping is something I could leave out for now. The reason it's there is that some later geographiclib classes use string inputs and outputs that can contain spaces, colons, single and double quotes, etc. But yes, I can drop that logic for now and wait to restore it until we get to things that need it.
I can arrange to drop most dat file comments, and some content, without much issue. Specifically, I now think we'll mostly be relying on the criterion framework for time comparisons, so there's less value in the SYSTEMTAG, LIBRARYTAG, and TESTSTATUS lines than I'd originally been thinking. The same is true for the time section on individual operation lines, and the statistics section. I'll plan to drop all of those.
There should be no issue removing section comments. I'll plan to drop those as well.
This still leaves the operation code line (e.g. Math_AngDiff_x_y_e), and the format comment. While we could infer the operation from the file name, or have the knowledge hard-coded in the tests, I think there's value in keeping it. Similarly, because the line interpretation varies from one operation to another, and there are so many operations, I think there's value in including it in the dat file explicitly, rather than only having it in the test code. I propose that I combine these two items into a single line, which would now always be the first line of the file.
Would that be an acceptable compromise?

I've also given some more thought to the sections within lines, and I think I'm satisfied that we can drop them. As I mentioned in my previous comment, I think we can drop the time section.
I originally separated the error section from outputs in part to retain the option to report ending reference or state values even in error cases, and in part to avoid ambiguity for functions that return non-numeric outputs. In practice, I'm not reporting any outputs in error cases, and it's probably fine to assume that no non-error case will result in an actual output value of "ERROR". So I think dropping that separation should be ok.
In terms of removing the separation between inputs and outputs, I think that in order to do this safely while also retaining support for a variable number of inputs (as will come up in some later array-based cases), I may need to make the outputs required rather than optional. That shouldn't have any effect on the rust side of things, where those outputs are of central interest, but it may require some more work on the C++ side in my case creation logic. I currently use a 2-stage approach where some special value cases are initially created as input-only lines, but I think I can avoid that.
Anyway, I'll proceed with trying to remove all of the line-level section separators.
As I mentioned in my previous comment, I still favor including a single header line in each data file that specifies the operation code and (as an implicit comment) the line format.
In my current pass, I also don't plan to change formatting of NaN and infinity values to something that rust's f64::parse will accept. The current values use the default C++ standard library formatting. I think it makes the most sense to stick with the C++ convention, since I think the change would be pretty coding-time intensive, and no single convention will match every language's preferred approach. We can revisit that topic after this pass if you wish.
I'm attaching a couple of heavily truncated sample files illustrating a format I think I can get us to at the end of my current pass. I've renamed the files, so github will let me attach them unzipped.
Geodesic_C3f.dat.txt
Math_AngDiff_x_y_e.dat.txt

Thanks for your response!

The dat file format is my making. The character escaping is something I could leave out for now. The reason it's there is that some later geographiclib classes use string inputs and outputs that can contain spaces, colons, single and double quotes, etc. But yes, I can drop that logic for now and wait to restore it until we get to things that need it.

Yes let's keep it as simple as possible for now.

I can arrange to drop most dat file comments, and some content, without much issue. Specifically, I now think we'll mostly be relying on the criterion framework for time comparisons, so there's less value in the SYSTEMTAG, LIBRARYTAG, and TESTSTATUS lines than I'd originally been thinking. The same is true for the time section on individual operation lines, and the statistics section. I'll plan to drop all of those.

Great - yep I think criterion is a good way to go.

There should be no issue removing section comments. I'll plan to drop those as well.
This still leaves the operation code line (e.g. Math_AngDiff_x_y_e), and the format comment. While we could infer the operation from the file name, or have the knowledge hard-coded in the tests, I think there's value in keeping it. Similarly, because the line interpretation varies from one operation to another, and there are so many operations, I think there's value in including it in the dat file explicitly, rather than only having it in the test code. I propose that I combine these two items into a single line, which would now always be the first line of the file.

I was most nervous about lines like this:
 #STATS-SECTION
 #COUNT_TESTS 300
 #COUNT_USED 300
 #TOTAL_TEST_SECONDS 2.4075000000000033e-05
 #MIN_TEST_SECONDS 6.5999999999999995e-08
 #MAX_TEST_SECONDS 1.1119999999999999e-06
 #MEDIAN_TEST_SECONDS 6.8e-08
 #MEAN_TEST_SECONDS 8.0250000000000113e-08

Which to me looked less like "comments" and more like structured data written and parseable by a machine.
I'm ok with a single comment at the top.
Another thought, if you're feeling bold, we could just do csv/tsv where a top row with field names is a common convention.

I originally separated the error section from outputs in part to retain the option to report ending reference or state values even in error cases

I'm not sure what this means - what are "error"s in this context? Are we trying to match geographic lib crash for crash? 😆

I originally separated the error section from outputs in part to retain the option to report ending reference or state values even in error cases

I'm not sure what this means - what are "error"s in this context? Are we trying to match geographic lib crash for crash? laughing

I know it sounds funny, but that's pretty close to the truth. When a geographiclib call errors out, it's not usually because of a coding error -- it's usually because the inputs fall into a category that's explicitly rejected by the geographiclib code. In fact, many of Karney's geographiclib test cases are specifically confirming that a function rejects certain inputs. By default, I think the rust code should use the same behaviors. For both this and other variations, we're likely to encounter some cases where the rust version has a legitimate reason to behave differently from the C++, but I think it will be the exception rather than the rule. We can decide how to address those cases when we encounter them.

That makes sense. Thanks for explaining.

On Dec 9, 2020, at 21:29, stonylohr<EMAIL_ADDRESS>wrote:

I originally separated the error section from outputs in part to retain the option to report ending reference or state values even in error cases
I'm not sure what this means - what are "error"s in this context? Are we trying to match geographic lib crash for crash? laughing
I know it sounds funny, but that's pretty close to the truth. When a geographiclib call errors out, it's not usually because of a coding error -- it's usually because the inputs fall into a category that's explicitly rejected by the geographiclib code. In fact, many of Karney's geographiclib test cases are specifically confirming that a function rejects certain inputs. By default, I think the rust code should use the same behaviors. For both this and other variations, we're likely to encounter some cases where the rust version has a legitimate reason to behave differently from the C++, but I think it will be the exception rather than the rule. We can decide how to address those cases when we encounter them.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

I'll give the csv/tsv option some more thought. If nothing else, tabs might be less likely to show up in string values than spaces are, when we eventually get to that point. Unfortunately, I don't see how to make the header line a proper csv/tsv header line, in part because the operation code is something that doesn't correspond to any particular item on the later lines, and in part because some items in the header line correspond to a variable number of items on the later lines. More frequently, they refer to a fixed number of items in an abbreviated form, but I'm not excited to bend over backwards for a format change that I know is going to fall apart eventually anyway.

For now I'd be fine sticking with the .dat as you have it if that's your preference - especially since, as I understand it, you're saying there are other examples where something like a tsv won't work well.
Later if we can find a way to easily use a format which doesn't require reading parser code to understand, that could be a future improvement.

@michaelkirk I've committed a new set of changes that I think should address your concerns with my previous draft. It also adds a fairly complete set of tests and benchmarks for public Geodesic and geomath functions.
I also tried to simplify the process of getting logged c++ data: After cloning, run "git submodule update --remote". The test and benchmark code should handle everything else.
Let me know if you'd like further adjustments or discussion.

@michaelkirk I've committed a new set of changes that I think should address your concerns with my previous draft. It also adds a fairly complete set of tests and benchmarks for public Geodesic and geomath functions.
I also tried to simplify the process of getting logged c++ data: After cloning, run "git submodule update --remote". The test and benchmark code should handle everything else.
Let me know if you'd like further adjustments or discussion.

@michaelkirk Since my earlier draft, I've also started leaning toward switching my tests from being integration tests to unit tests. As I noted previously, their mechanics aren't ideal for being categorized as unit tests, but I'm coming to think that the increased access available to unit tests probably outweighs the "not ideal unit tests" consideration. I'd be curious to hear whether you have any thoughts on the topic in either direction.

@michaelkirk Since my earlier draft, I've also started leaning toward switching my tests from being integration tests to unit tests. As I noted previously, their mechanics aren't ideal for being categorized as unit tests, but I'm coming to think that the increased access available to unit tests probably outweighs the "not ideal unit tests" consideration. I'd be curious to hear whether you have any thoughts on the topic in either direction.

I've also started leaning toward switching my tests from being integration tests to unit tests. As I noted previously, their mechanics aren't ideal for being categorized as unit tests, but I'm coming to think that the increased access available to unit tests probably outweighs the "not ideal unit tests" consideration. I'd be curious to hear whether you have any thoughts on the topic in either direction.

re: unit vs. integration - I'm not really sure what you mean in this context.
I highly value the testing of the higher level public methods and think there's less value in, e.g. testing each individual method in geomath.
The overall "flow" of data in your branch makes sense to me. My biggest concern right now is that you're relying on a instrumented version of geoagraphic lib to generate the test input. I'd much prefer to use Karney's published (and maintained) test data so we're not in a situation down the road where we have to remember how this works and pray the patches still apply. Conversely it'd be relatively easy to download the updated test data from Karney.

I've also started leaning toward switching my tests from being integration tests to unit tests. As I noted previously, their mechanics aren't ideal for being categorized as unit tests, but I'm coming to think that the increased access available to unit tests probably outweighs the "not ideal unit tests" consideration. I'd be curious to hear whether you have any thoughts on the topic in either direction.

re: unit vs. integration - I'm not really sure what you mean in this context.
I highly value the testing of the higher level public methods and think there's less value in, e.g. testing each individual method in geomath.
The overall "flow" of data in your branch makes sense to me. My biggest concern right now is that you're relying on a instrumented version of geoagraphic lib to generate the test input. I'd much prefer to use Karney's published (and maintained) test data so we're not in a situation down the road where we have to remember how this works and pray the patches still apply. Conversely it'd be relatively easy to download the updated test data from Karney.

I've also started leaning toward switching my tests from being integration tests to unit tests. As I noted previously, their mechanics aren't ideal for being categorized as unit tests, but I'm coming to think that the increased access available to unit tests probably outweighs the "not ideal unit tests" consideration. I'd be curious to hear whether you have any thoughts on the topic in either direction.

re: unit vs. integration - I'm not really sure what you mean in this context.
I highly value the testing of the higher level public methods and think there's less value in, e.g. testing each individual method in geomath.
The overall "flow" of data in your branch makes sense to me. My biggest concern right now is that you're relying on a instrumented version of geoagraphic lib to generate the test input. I'd much prefer to use Karney's published (and maintained) test data so we're not in a situation down the road where we have to remember how this works and pray the patches still apply. Conversely it'd be relatively easy to download the updated test data from Karney.

For a general discussion of unit testing vs integration testing in Rust, this may be helpful:
https://doc.rust-lang.org/book/ch11-03-test-organization.html
I agree that Karney's dataset is a useful testing tool, but the results in that dataset are specific to WGS84, so can't be relied on to catch bugs in the handling of other ellipsoids. Also, I don't see the GeodTest-100.dat file on the geographiclib data page (https://sourceforge.net/projects/geographiclib/files/testdata/). Depending on how it's created and how the original files are structured, I'm not sure that it can be relied on to test all the categories of cases that the original GeodTest files are designed for. If it's just the first 100 lines, that's fine if Karney's case categories are evenly distributed, but less so if they're clumped.
I also agree that it may eventually make sense to abandon my instrumentation-based tests entirely, once the effort of maintaining them exceeds the value they provide. I think they're likely to be helpful for a while yet, though.
While geomath operations are currently non-public, and likely to see less outside use even if that changes, their C++ counterparts are publicly accessible, and I see them as something that is likely to make sense to expose at some point. I think there is also value in testing these lower level functions, in terms of helping to pinpoint where issues may be originating in the higher level functions. This is value that is likely to fade as geographiclib-rs becomes more stable, and could be dropped at some point in the future, but I think there's a bit of work before we get to that point.
Anyway, I propose the following as a broad strokes version of next steps:

I'll replace my current integration tests with corresponding unit tests, and enable additional checks in them that need access to non-public items. However, I'll mark these tests using #[ignore], so they'll only run if specifically requested.
I'll add unit tests based on Karney's C++ tests, and not mark these as ignored.
I'll add unit tests that use GeodTest-short as their basis, initially marked as ignored.

I've also started leaning toward switching my tests from being integration tests to unit tests. As I noted previously, their mechanics aren't ideal for being categorized as unit tests, but I'm coming to think that the increased access available to unit tests probably outweighs the "not ideal unit tests" consideration. I'd be curious to hear whether you have any thoughts on the topic in either direction.

re: unit vs. integration - I'm not really sure what you mean in this context.
I highly value the testing of the higher level public methods and think there's less value in, e.g. testing each individual method in geomath.
The overall "flow" of data in your branch makes sense to me. My biggest concern right now is that you're relying on a instrumented version of geoagraphic lib to generate the test input. I'd much prefer to use Karney's published (and maintained) test data so we're not in a situation down the road where we have to remember how this works and pray the patches still apply. Conversely it'd be relatively easy to download the updated test data from Karney.

For a general discussion of unit testing vs integration testing in Rust, this may be helpful:
https://doc.rust-lang.org/book/ch11-03-test-organization.html
I agree that Karney's dataset is a useful testing tool, but the results in that dataset are specific to WGS84, so can't be relied on to catch bugs in the handling of other ellipsoids. Also, I don't see the GeodTest-100.dat file on the geographiclib data page (https://sourceforge.net/projects/geographiclib/files/testdata/). Depending on how it's created and how the original files are structured, I'm not sure that it can be relied on to test all the categories of cases that the original GeodTest files are designed for. If it's just the first 100 lines, that's fine if Karney's case categories are evenly distributed, but less so if they're clumped.
I also agree that it may eventually make sense to abandon my instrumentation-based tests entirely, once the effort of maintaining them exceeds the value they provide. I think they're likely to be helpful for a while yet, though.
While geomath operations are currently non-public, and likely to see less outside use even if that changes, their C++ counterparts are publicly accessible, and I see them as something that is likely to make sense to expose at some point. I think there is also value in testing these lower level functions, in terms of helping to pinpoint where issues may be originating in the higher level functions. This is value that is likely to fade as geographiclib-rs becomes more stable, and could be dropped at some point in the future, but I think there's a bit of work before we get to that point.
Anyway, I propose the following as a broad strokes version of next steps:

I'll replace my current integration tests with corresponding unit tests, and enable additional checks in them that need access to non-public items. However, I'll mark these tests using #[ignore], so they'll only run if specifically requested.
I'll add unit tests based on Karney's C++ tests, and not mark these as ignored.
I'll add unit tests that use GeodTest-short as their basis, initially marked as ignored.

I just committed changes addressing many of the items we've discussed, but not all:

Commented out integration test code. Assuming you approve of the direction I'm taking things, I expect to remove those files entirely soon.
Added unit tests corresponding to the now-disabled integration tests. These tests are flagged as ignored, so they only run if specifically requested. With that in place, I've tightened their expectations, so many of them will fail if run. I expect those failures to eventually be resolved through a combination of bug fixes and re-loosening of test criteria, though not as part of this PR.
Added geodesic unit tests corresponding to Karney's test cases found in various versions of geographiclib. Some of these also fail, so I've marked the failing ones as ignore for now as well. Some parts are also commented out because they test operations that don't appear to be present or public in geographiclib-rs (mostly things related to GeodesicLine). I'd prefer to leave sorting that out as a task for after the current PR as well.
Made geomath non-public again. This breaks the geomath benchmarks, so I've commented those out for now. I figured I'd check your preferences before removing those benchmarks entirely.
Moderately expanded comments in my code.
Made some changes to "utilities" code. It compiles, but I haven't tested it yet.
Probably a few other things I'm forgetting...

I just committed changes addressing many of the items we've discussed, but not all:

Commented out integration test code. Assuming you approve of the direction I'm taking things, I expect to remove those files entirely soon.
Added unit tests corresponding to the now-disabled integration tests. These tests are flagged as ignored, so they only run if specifically requested. With that in place, I've tightened their expectations, so many of them will fail if run. I expect those failures to eventually be resolved through a combination of bug fixes and re-loosening of test criteria, though not as part of this PR.
Added geodesic unit tests corresponding to Karney's test cases found in various versions of geographiclib. Some of these also fail, so I've marked the failing ones as ignore for now as well. Some parts are also commented out because they test operations that don't appear to be present or public in geographiclib-rs (mostly things related to GeodesicLine). I'd prefer to leave sorting that out as a task for after the current PR as well.
Made geomath non-public again. This breaks the geomath benchmarks, so I've commented those out for now. I figured I'd check your preferences before removing those benchmarks entirely.
Moderately expanded comments in my code.
Made some changes to "utilities" code. It compiles, but I haven't tested it yet.
Probably a few other things I'm forgetting...

I've been thinking about test naming conventions and would be interested in your thoughts on the topic. There are several different pieces I think might have value, and I think that using a consistent ordering to the pieces would be preferable. Being consistent in test (and benchmark) naming conventions will make it easier to run just a subset of test or bench routines. I'll list pieces in the order I would currently favor, which doesn't match the order used in my commit:

"test": This is kind of redundant with the test tag, but may still have some value. I could go either way on including it at all.
The test's group: Examples in my most recent commit include "vs_python" (which I applied to the pre-existing tests, since that's what they appeared to be), "std" (applied to Karney's unit tests), "vs_cpp" for my tests against instrumented c++. Later this weekend, I hope to add some "geodtest" tests that use a GeodTest*.dat file as the basis.
The name of the test's parent module (or something equivalent for integration tests): For example, all tests in geodesic.rs would use "geodesic".
An identifier for the specific test within the categories above: For example, each of the "vs_cpp" tests uses an operation name for this piece, and each of the "std" tests uses an all-lower-case version of the name of the test it's based on.

I've been thinking about test naming conventions and would be interested in your thoughts on the topic. There are several different pieces I think might have value, and I think that using a consistent ordering to the pieces would be preferable. Being consistent in test (and benchmark) naming conventions will make it easier to run just a subset of test or bench routines. I'll list pieces in the order I would currently favor, which doesn't match the order used in my commit:

"test": This is kind of redundant with the test tag, but may still have some value. I could go either way on including it at all.
The test's group: Examples in my most recent commit include "vs_python" (which I applied to the pre-existing tests, since that's what they appeared to be), "std" (applied to Karney's unit tests), "vs_cpp" for my tests against instrumented c++. Later this weekend, I hope to add some "geodtest" tests that use a GeodTest*.dat file as the basis.
The name of the test's parent module (or something equivalent for integration tests): For example, all tests in geodesic.rs would use "geodesic".
An identifier for the specific test within the categories above: For example, each of the "vs_cpp" tests uses an operation name for this piece, and each of the "std" tests uses an all-lower-case version of the name of the test it's based on.

I've now added tests based on GeodTest.dat, tagged "ignore". As with other tests, it will take me some time to pin down a good level of tolerance to allow.

I've now added tests based on GeodTest.dat, tagged "ignore". As with other tests, it will take me some time to pin down a good level of tolerance to allow.

I just made a commit that I think is a good candidate for fully resolving #13. I would be interested in your feedback.
A few highlights include:

I standardized naming for all my new tests and benches, but restored all pre-existing tests and benches to their original names.
I added benches that use the full GeodTest.dat file.
I set all slow and/or failing tests ignored. Currently failing tests should later be un-ignored as the underlying bugs are resolved, but that doesn't fall under #13.
I enabled a previously-commented-out test from java geographiclib for arc-mode direct, but set it ignored because it fails.
I improved my testing infrastructure in the utilities mod, and used it to improve the tolerances used in some tests
I removed the tests folder. I've concluded that I'm happier with all current tests in their current "unit test" formulation in the src folder than with my previous "integration test" formulation in the tests folder.

I just made a commit that I think is a good candidate for fully resolving #13. I would be interested in your feedback.
A few highlights include:

I standardized naming for all my new tests and benches, but restored all pre-existing tests and benches to their original names.
I added benches that use the full GeodTest.dat file.
I set all slow and/or failing tests ignored. Currently failing tests should later be un-ignored as the underlying bugs are resolved, but that doesn't fall under #13.
I enabled a previously-commented-out test from java geographiclib for arc-mode direct, but set it ignored because it fails.
I improved my testing infrastructure in the utilities mod, and used it to improve the tolerances used in some tests
I removed the tests folder. I've concluded that I'm happier with all current tests in their current "unit test" formulation in the src folder than with my previous "integration test" formulation in the tests folder.

I did think of a few remaining rough edges that I'll work on polishing, but the changes should be more contained than other recent commits. I hope to make the changes over this weekend.

I did think of a few remaining rough edges that I'll work on polishing, but the changes should be more contained than other recent commits. I hope to make the changes over this weekend.

I've now committed the changes I alluded to yesterday.
I think the main point of interest is that I've removed use of a submodule and zip logic to handle the C++ instrumented data files. Instead, created an approach more similar to that used for GeodTest.dat: I've made zip files available for download on my sourceforge wiki page (https://sourceforge.net/u/alephknot/wiki/Home/), and leave it to the user to download and unzip the files to the appropriate location. If a file isn't found, the error message tries to include both the expected data file location, and instructions on how to find zipped files, much like the approach for GeodTest.dat. Recall that all of the affected tests are set ignored, so do not run by default.
Note that I had hoped to use a single zip file for all of my data files using a kind of fakey release, but sourceforge isn't letting me create a release (perhaps because of the project's forked status). The full data file zip is too large to do as a wiki attachment. Instead, I've broken it into a separate zip file for each of the 3 largest class outputs (Geodesic, GeodesicLine, and Math), and a fourth zip file for all others (none of which matter yet to geographiclib-rs).

I've now committed the changes I alluded to yesterday.
I think the main point of interest is that I've removed use of a submodule and zip logic to handle the C++ instrumented data files. Instead, created an approach more similar to that used for GeodTest.dat: I've made zip files available for download on my sourceforge wiki page (https://sourceforge.net/u/alephknot/wiki/Home/), and leave it to the user to download and unzip the files to the appropriate location. If a file isn't found, the error message tries to include both the expected data file location, and instructions on how to find zipped files, much like the approach for GeodTest.dat. Recall that all of the affected tests are set ignored, so do not run by default.
Note that I had hoped to use a single zip file for all of my data files using a kind of fakey release, but sourceforge isn't letting me create a release (perhaps because of the project's forked status). The full data file zip is too large to do as a wiki attachment. Instead, I've broken it into a separate zip file for each of the 3 largest class outputs (Geodesic, GeodesicLine, and Math), and a fourth zip file for all others (none of which matter yet to geographiclib-rs).

While looking around validate-geographiclib and the core geographiclib some more, I realized that geographiclib has a few different categories of tests in different places, and my tests so far missed some. I'll look into adding those as well.

While looking around validate-geographiclib and the core geographiclib some more, I realized that geographiclib has a few different categories of tests in different places, and my tests so far missed some. I'll look into adding those as well.

After a bit of offline discussion, it's become clear that my branch is way more involved than @michaelkirk is looking for. I'll create a new branch and pull request with the much more limited change I now think he'd like. Other items from this branch may be resubmitted at points in the future under separate issues.

After a bit of offline discussion, it's become clear that my branch is way more involved than @michaelkirk is looking for. I'll create a new branch and pull request with the much more limited change I now think he'd like. Other items from this branch may be resubmitted at points in the future under separate issues.


Push Notifications work on iPhone but not iPad

Here's something I don't get, and hopefully you can help out. I'm working with someone else on a project and he is using PushSharp to send the notifications. I am using this plugin on the devices side.
We've tested extensively to make sure we have everything working. I have a couple of Android devices the thing works fine on. Perfectly dandy! And notifications also work perfectly on my iPhone 5 (iOS 7.1) and iPhone 6 (iOS 9.0.2).
But my iPad Air would never get the notifications. I tested on 9.0.1 and 9.0.2, but still nothing. I'm not sure that code snippets would help, as neither the notification appears in my notification tray, nor does NSLog(@"didReceiveNotification"); ever happen when the app is open.
I'm at a bit of a loss, if you can help me out.

Similar to https://github.com/phonegap/phonegap-plugin-push/issues/216

@jvjvjv marking as duplicate of #216. Apparently I need to go buy and iPad Air or something.


Add allowUserToSkipBackCapture parameter

Story: https://app.shortcut.com/smileid/story/11625
Summary
Adds a new allowUserToSkipBackCapture boolean parameter to allow partners to enforce capturing the back of ID. This parameter is only relevant when captureBothSides is set to true
(see also: https://github.com/smileidentity/ios/pull/131)
Test Instructions
Update MainScreen to pass captureBothSides to true and allowUserToSkipBackCapture to false for DocumentVerification and EnhancedDocumentVerification. Notice that the skip button doesn't show

Won't do


[Bug] can't load wallpapers when open app

I can't find any wallpaper when open app. I use vpn also, but didn't worked. I tried to change directory but same. I find out that when I go to app info and "mobile data and wifi" section, I cant enable data access to this app. Maybe permission problem?
Screenshot:

Android 14 crdroid 10.2 poco x3pro

It's an offline wallpaper manager app, you'll have to select a directory where you store your wallpapers to have them show in the app.

It's an offline wallpaper manager app, you'll have to select a directory where you store your wallpapers to have them show in the app.

Wow! :) I didn't kow that! Thx for ur reply


Missing instructions support

The following instructions are not implemented and required by Jolden.

UnaryInstruction
LoadTokenInstruction
SwitchInstruction

LoadTokenInstruction appears in the Root class static constructor.

All instructions have been implemented.


proposal: flag: Add IgnoreOnError ErrorHandling

Related Issue: #15352
Go's flag package does not support parsing flags when undefined flags exist.
Go's flag.FlagSet struct has ErrorHandling support with three values: ContinueOnError, ExitOnError, and PanicOnError. ExitOnError and PanicOnError are straightforward, but ContinueOnError stops processing arguments if an error is encountered.
There should be a fourth option to silently ignore undefined flags and keep parsing.
What would this be called?
Potential names for a new ErrorHandling constant could be:

OmitOnError (omit the bad flag and keep parsing)
KeepParsingOnError (omit the bad flag and keep parsing)

Why do users need this ability?
Integration point between two services. Suppose there are two processes/services: caller A and callee B, where B is a go binary. These two services could change over time, meaning that invocations of B could fail due to arg parsing. Suppose there are multiple versions of B but one version of A. A would need to know the exact sets of flags to pass into B1 and B2.
A similar case is how JSON parsers have the option to ignore unknown fields. This is the same problem, solved for REST microservices which use JSON as the interface for passing information between two services.
Deploying Kubernetes applications is another use case. I might want my service to resiliently accept flags to ensure my Pod runs successfully.
What alternatives do users have?

Ensure unknown flags are never passed in the first place (nil argument)
Use another mechanism for passing information between two services, like config files or environment variable. This is the most plausible alternative, but unsuspecting users who build arg support initially will have to migrate to another solution. It's simpler for users to set the ErrorHandling to a value which meets their needs instead.
Use ContinueOnError and ensure that unknown fields are always at the end of the argument list. If the user could ensure this, then using ContinueOnError is sufficient. However, keeping this invariant true would be very challenging and most likely not worth the effort if not impossible.
Use another library for argument parsing
Use another language, one that permits undefined flags

How would this be implemented?
Flag parsing must remain consistent for all cases. However, there's one case which makes the implementation difficult: undefined boolean flags. This is highlighted in the earlier proposal, https://github.com/golang/go/issues/6112#issuecomment-66083768

If you don't know the type of the flag, and for an unknown flag you never know it's type, in general you can't parse the command line.

When parsing an unknown flag, the unknown flag's argument should be skipped in order to correctly parse the rest of the defined flags. The loop must keep the invariant that no part of a defined flag was skipped.
This would require looking ahead to the next argument to see if it's a value (doesn't start hyphen) or a flag (starts with hyphen). It would also require understanding the = separator, even for undefined flags.
I haven't tested extensive, but here are some examples:

Example
Description
Current Index
Solution

./main -a=2 -b 3 -undefined-bool-flag
Undefined boolean flag at the end
4
End of array, so it's ok to stop parsing

./main -a=2  -undefined-bool-flag -b
Undefined boolean flag followed by a defined flag
2
Look ahead, see the -, skip

./main -a=2  -undefined-int-flag 5 -b 3
Undefined int flag with value followed by a defined flag
2
Look ahead, see no -, skip 2

./main -undefined-bool-flag1 -undefined-bool-flag2
Multiple undefined bool flags
1
Look ahead, see the -, skip

It's impossible to know the intended type of the undefined flag, but I don't think that means it's impossible to parse the command line arguments. These examples show the intended type of the flags, but the solution to parse them, look ahead and conditionally skip by 1 or 2, is the same regardless.
I haven't thought about more complicated flags, such as repeated flags ( -some a -some b -> [a, b] or -some a b -> [a, b], other than to quickly say the look ahead could proceed until an argument started with a hyphen and skip up to that point.

CC @robpike

The flag package serves well for the uses it's intended for. Given the depth of analysis you have done, I think what you're really looking for is a more capable replacement. I would prefer we don't add more (and more confusing) features to the existing interface.
Also, given the way flags are interpreted, I do not believe it is possible in general to ignore unknown flags, which is a strong argument against adding this feature.

How about adding an extra callback instead of extending the enum? A callback would get the tail of unprocessed args and returns an int, telling how many args the callback consumed (= how many args flag core can skip). If a user callback returns 0 it means falling back to the default ExtraHandling processing.
IMHO this would give users freedom of handling arguments, at the same time not bloating flag with extra logic.
Such user callback might look like this:
integration := func(args []string) uint {
  switch args[0] {
     case "-serviceAparam", "-oddWindowsFlag":
        return 1
     case "-serviceBparam":
         if len(args) > 1 && args[1] == "--foobar" {
            return 2
         }
         return 1
     default:
        return 0
  }
}

Flag.ErrorHandlingFunc = integeration

It still seems to me that a richer, externally provided flags package is what you're after. The one in the standard library is deliberately minimalist.

Personally, I'm fine with flag. However, since functions are first-class things in Go, I'd choose custom functions over additional enum values if the proposal got proceeded.

I don't think it's possible to ignore unknown flags either, an argument passed to a flag can start with a -. Example:
cmd -known1=val1 -featuregates=-featureA -known2=val2
cmd -known1 val1 -featuregates -featureA -known2 val2

If -featuregates isn't a registered flag, -featureA is ambiguous and it would be incorrect to treat it as a flag.

@seankhliao I tested the case where a - directly follows an =: https://go.dev/play/p/wp1h3wN6bCv
From this sample, it looks like flag will treat everything from the right of = to the next space as the flag's value.
In your first example:
at -featuregates
-> skip up to the next space (skip -featuregates=-featureA )
-> land on -known2=val2 and keep parsing
Second example:
at -featuregates
-> skip up to the next space (skip -featuregates )
-> land on -featureA -known2 val2  and keep parsing
->  skip up to the next space (skip -featureA )
-> land on -known2=val2 and keep parsing
Both use the same approach of skipping until the next space, and both should parse -known2 correctly.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

As people have noticed, this is infeasible because you don't know whether an unrecognized flag takes arguments or not. Plenty of flags take flag-like arguments, like -ldflags=-w in the go build command, which could be written go build -ldflags -w. And parsing needs to stop at the first non-flag argument, not keep going. Consider go test -asdf pkg -foo. We can't assume -asdf takes pkg as its argument and continue on to -foo.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

This proposal has been declined as retracted.
— rsc for the proposal review group


Update auth library and bump version to release

gax: 1.3.0
gax-grpc: 0.19.0
auth: 0.7.0

Codecov Report

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

@@            Coverage Diff            @@
##             master     #319   +/-   ##
=========================================
  Coverage     69.81%   69.81%
  Complexity      355      355
=========================================
  Files            73       73
  Lines          1925     1925
  Branches        157      157
=========================================
  Hits           1344     1344
  Misses          513      513
  Partials         68       68

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 7772e37...5ae4461. Read the comment docs.

Due to git issues, updated as https://github.com/googleapis/gax-java/pull/320.


Pulsar Manager Docker Image v0.2.0 - needs some updates

Is your feature request related to a problem? Please describe.
The apachepulsar/pulsar-manager:v0.2.0 docker image is getting pretty out of date.
I cannot install it in my org because the containers are so out of date they need bumped for versions to fix known CVEs.
Describe the solution you'd like
Let's bump the pulsar-manager container to get some fixes for java libraries and container libraries.
Describe alternatives you've considered
n/a

I think I need to take the time to look at it

Pulsar Manager has released a 0.3.0 and the 0.4.0 in under-voting - https://lists.apache.org/thread/qrobzlrcsvbz18j6ft5vhwy5p8665k9x
Also, it has a dedicated repo https://github.com/apache/pulsar-manager to handle issues.
So close this issue here.


Adding product recognition to cognitive service python samples

Purpose

...

Does this introduce a breaking change?

[ ] Yes
[ x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[x ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Get the code

git clone [repo-address]
cd [repo-name]
git checkout [branch-name]
npm install

Test the code

What to Check
Verify that the following are valid

...

Other Information

It could be confusing to have a folder for product reco and a folder for model customization, as product reco has model customization as well

need update for readme.md

It could be confusing to have a folder for product reco and a folder for model customization, as product reco has model customization as well.
Many documentations such as quota limit, faq, aiq faq in model customization applies or requires update from PoS as well

Yes, and the model customization part of the product recognition is still in the model_customization folder, the product recognition only contains image stitching, product recognition prediction, planogram compliance. Does that work

need update for readme.md

Gina will be working on that

pkg requres version update as well


Loading extensions

Is there a way to load sqlite extensions? I'd like to work with the JSON1 extension specifically but it's not clear how I'd go about loading it. Is there a way to override the built in libsqlite3.dylib and build from the amalgamation file with the necessary compiler flags turned on? Is there an easier way?
Great lib BTW, thanks!

Same point here, we want to use the ICU extension in SQLite.swift.

Right now the easiest way is to integrate SQLite as a pod and require a standlone version of SQLite, cf.
https://github.com/stephencelis/SQLite.swift/blob/master/Documentation/Index.md#requiring-a-specific-version-of-sqlite

This can be done via pods, closing.


Flutter demo app: Could not find com.android.tools.build:gradle:7.6.3.

Steps to reproduce

flutter create test
flutter build apk

Actual results
$ flutter build apk
Resolving dependencies...
Downloading packages...
  flutter_lints 3.0.2 (4.0.0 available)
  leak_tracker 10.0.4 (10.0.5 available)
  leak_tracker_flutter_testing 3.0.3 (3.0.5 available)
  lints 3.0.0 (4.0.0 available)
  material_color_utilities 0.8.0 (0.11.1 available)
  meta 1.12.0 (1.15.0 available)
  test_api 0.7.0 (0.7.1 available)
  vm_service 14.2.1 (14.2.2 available)
Got dependencies!
8 packages have newer versions incompatible with dependency constraints.
Try `flutter pub outdated` for more information.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':gradle:compileGroovy'.
> Could not resolve all files for configuration ':gradle:compileClasspath'.
   > Could not find com.android.tools.build:gradle:7.6.3.
     Searched in the following locations:
       - https://dl.google.com/dl/android/maven2/com/android/tools/build/gradle/7.6.3/gradle-7.6.3.pom
       - https://repo.maven.apache.org/maven2/com/android/tools/build/gradle/7.6.3/gradle-7.6.3.pom
     Required by:
         project :gradle

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1s
Running Gradle task 'assembleRelease'...                         1,594ms
Gradle task assembleRelease failed with exit code 1

Logs

Logs

<!-- Paste your logs here -->

Flutter Doctor output

Doctor output

$ flutter doctor -v
[✓] Flutter (Channel stable, 3.22.1, on EndeavourOS 6.9.1-zen1-1.1-zen, locale en_US.UTF-8)
    • Flutter version 3.22.1 on channel stable at /nvme-data/Android/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision a14f74ff3a (28 hours ago), 2024-05-22 11:08:21 -0500
    • Engine revision 55eae6864b
    • Dart version 3.4.1
    • DevTools version 2.34.3

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /ssd2/csaba/Android/Sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /ssd2/csaba/Android/Sdk
    • Java binary at: /opt/android-studio/jbr/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11572160)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[✓] Linux toolchain - develop for Linux desktop
    • clang version 17.0.6
    • cmake version 3.29.3
    • ninja version 1.12.1
    • pkg-config version 2.1.1

[✓] Android Studio (version 2023.3)
    • Android Studio at /opt/android-studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11572160)

[✓] Connected device (2 available)
    • Linux (desktop) • linux  • linux-x64      • EndeavourOS 6.9.1-zen1-1.1-zen
    • Chrome (web)    • chrome • web-javascript • Google Chrome 125.0.6422.76

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Hi @mihalycsaba, there is a similar issue at https://github.com/flutter/flutter/issues/130667. Please look a https://github.com/flutter/flutter/issues/130667#issuecomment-1637541437, it's pointing out that the AGP version you are using doesn't exist on https://mvnrepository.com/artifact/com.android.tools.build/gradle?repo=google. You should use one of available versions there.
Closing this as it's more like a Gradle issue than a Flutter framework issue.

@huycozy I have tried a lot of things for hours. setting different Gradle and AGP versions, deleting every possible cache and Android Studio settings. I don't understand gradle enough.
It is just weird that the default Demo app fails. I just need help with troubleshooting.

Could you please share the entire output of flutter build apk -v? Thanks!

@huycozy It's weird it works now. I have noticed it still uses 7.6.3, saw this in the output /.gradle/daemon/7.6.3/daemon-73102.out.log  Maybe something was up with the servers a few days ago and now it managed to download it.
It was weird I couldn't change the version to 7.6.4 the other day changing the distributionUrl, I have tried many times and it only wanted to download 7.6.3 didn't matter what version I tried, I have tried a few. But now it works .gradle/daemon/7.6.4/daemon-77868.out.log , I can change it back too to the older version...

It could be a network issue with gradle hosting. I will close this as it doesn't occur currently. If you see the issue again, please write in the comments and I will reopen this.


Thread Safety

Right now the simple collector is "thread-safe" in that everything is !Send. It's not possible to send garbage collected pointers across threads, so no synchronization is ever needed.
As it stands, the API is pretty agnostic to whether or not the underlying implementation is thread-safe. It exects thread safety to be marked by the appropriate Send and Sync implementations.
The main issue with allowing multiple threads to use the collector is that a collection would have to pause all threads. Once we decide its time to collect, we'd have to block until all other collectors reach a `safepoint!'. This is done cooperatively (like all of zerogc's safepoints), meaning that a single thread could hold up collection by waiting too long to invoke a safepoint.
Internally other VMs, they just don't have an issue with uncooperative threads, since the VM automatically inserts safepoints. The JVM's JIT inserts a safepoint on every single loop iteration (implemented as a test against a guard page).
This is almost analogous to the tradeoff between cooperative and preemptive multitasking. ZeroGC is designed as a low-cost abstraction. We already rely on the user to insert regular safepoints in the single-threaded case, so it's reasonable to expect them to be responsible in multithreaded case as well.
Currently, ZeroGC safepoints are expected to return very quickly if there's not a collection (usually just checking memory usage).
The ZeroGC API should be updated to allow a user to "freeze" a GcContext at a safepoint. This would prevent future allocations (until unfrozen), ensuring that the context's set of roots is known. This is essentially a long-term safepoint, that would other threads to collect while the first set is still working.
The simple collector will probably need a little bit of internal synchronization for this (we'll add a feature-flag to control threading support). We'll need to support thread-local caches for the small-object-arenas. A good experiment would be attempting to reimplement the binary-trees example using multiple threads.
This is basically a requirement for DuckLogic. Although Python is essentially single-threaded (due to the GIL), it's still technically possible for python code to be invoked from different threads.

Our current implementation seems to result in a performance regression for single-threaded code.
For the single-threaded binary_trees (n=21):
As of 774106545cb4d06b268b46064f3a24093def5cf2 we have 34 s + 385 MB
As of 0c190e55413f6e516d95b04a368556c1743729c7 we have 47 s + 385 MB
Thread safety is incomplete and the current implementation deadlocks. I have put no effort into optimization yet, and I bet there's probably plenty of low-hanging fruit.

It turns out that using roots with frozen collectors was unsound. I suspect this is why the parallel implementation was crashing with optimizations. See 9ad529d9bd929e6c376f413dea82f2f7c for details.
As of dc30ec029c4babe38912a8e5c6d99dd6b73f024d we should be thread-safe, aside from the frozen roots (which I removed next commit).
I'll have to implement an Object Handle interface as a replacement (#9). This was needed for DuckLogic anyways.


add stale, lastSearchTerm & reset to useSearch

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Other information:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Bug Report] People can't use DJ commands when dj set to @everyone

Describe the bug
Basically people can't use DJ commands if I set the DJ roles to everyone.
Since this is used on my private server and there's no need to vote skip or stuff, I tried setting DJ group to everyone. The only workaround for now is putting everyone in temporary created group and set the group as DJ.
To Reproduce

Admin use '!setdj everyone'
Some person use DJ command like '!play' on paused music

Expected behavior
Everyone can use DJ commands
Screenshots

Version Info (please complete the following information):

Operating System: Ubuntu 18.04.3
JMusicBot Version: 0.2.5

I believe the role is called @everyone and that it doesnt search for a role. I might be wrong tho.

I believe the role is called @everyone and that it doesnt search for a role. I might be wrong tho.

It search for the role. The id in the config file is the same as the @everyone id.
For example:

The role exists, but technically nobody has the @ everyone role, it is just used as the base permissions set. I'll need to explicitly check for this.

So... I'm looking through the source and it turns out I actually do check for this already. Therefore, DJ-level commands should work perfectly fine (I'm guessing you'd be able to reproduce this; try setting @ everyone to DJ and see if people can run pause or stop).
The bug here is that I didn't replicate those identical checks into the play command (as it is a normal command, just with DJ-specific behavior if the player is paused). I'll fix this in the next release.

This should be fixed as of 0.2.6


Feature/linking questions to video

This PR Adds:

1 When creating a question, users now have the option to link it to a specific video.
2 Users can search a video from the search bar present inside the Add Questions Dialog.
3 This feature is optional, as we still want to allow questions without associated videos.
4 Each video has a button that, when clicked, redirects the user to all questions related to the video.
5 Made the necessary database changes
6 Dynamically calculating height of the MEditor to fix the overflow of the Modal Components in Questions Page

Resolves #862
Screenshots Below:

[✅] I have performed a self-review of my code
[✅ ] I assure there is no similar/duplicate pull request regarding same issue

Open to any changes/suggestions/commits to this PR.
For contact, DM me on Twitter: https://x.com/DewanganSajal

@Sajal0208 what if we have 500 videos? how the dropdown will look?
can we improve it further?

@siinghd Should I group it like this -
Course Dropdown ->Week Dropdown -> Then Videos
Or anyother suggestions?

@siinghd Should I group it like this -
Course Dropdown ->Week Dropdown -> Then Videos Or anyother suggestions?

I have already mentioned this in the issue post, try to look at it buddy

@siinghd Should I group it like this -
Course Dropdown ->Week Dropdown -> Then Videos Or anyother suggestions?

I have already mentioned this in the issue post, try to look at it buddy

Apologies, I might have skipped that point.
The above commit fixes the issue

@Sajal0208 looking promising, will wait little see other PRs too, in while improve with any idea u have

Hey @siinghd, any updates on the bounty?

@siinghd , can you please merge this PR?

@Sajal0208 i saw zero prs other than this for that issue, will test it today and merge it

@Sajal0208 i saw zero prs other than this for that issue, will test it today and merge it

@siinghd Alright, makes sense. Let me know if we need to add something else in the PR.

Hey @siinghd, you still haven't merged this PR 😅

@Sajal0208 can you fix the conflicts ?

@Sajal0208 can you fix the conflicts ?

Hey @siinghd, I have resolved the conflicts

Hey @siinghd, a gentle reminder to merge this PR

Hey @siinghd, I know you are running busy but this PR is on hold since a month. Can you please take a look at the same. I have already resolved the conflicts 3 times and I don't know why the resolve conflict button is not working now. Please have a look at this whenever you have time.
Thanks.


[BEAM-12716] Update XLang Kafka taxi example to use BigQuery sink

If --bq_dataset is given, use BigQuery sink. Otherwise, just print the log.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @chamikaramj

Run Python PreCommit

two failing tests look irrelevant.


Parallelism

When training the model, both lightning and huggingface both try to parelize the code and a warning pops up.

Warning message from terminal
huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
- Avoid using tokenizers before the fork if possible
- Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)


Koda domains 500 or unresponsive

What happened?
not the first time that I've gotten this
also don't know if it's my connection but sometimes it takes a lot of time to load or multiple retries, just with koda domains other websites work fine
Anyone else experiencing the same?
cc @preschian

Anyone else experiencing the same?

Yes, I also rarely face this issue. Reduce js size probably could help resolve the issue

additional context, this is nothing with the domain.

maybe anyone want to take a look this one https://github.com/vitejs/vite/issues/11804

this is nothing with the domain.

bad wording I meant to say the koda deployed app


refactor(pbft_manager): move queue with sync blocks into the pbft_mgr…

Purpose
So the only change here is that I moved(copy paste) sync_queue + methods related to processing data from this queue into the pbft_manager. Logic behind is this:

the only thing that tarcap does is that it push data into this queue + check it's size. Similar to other queues, e.g. queues for tx_manager, dag_manager, etc...
pbft_manager is working with data from this queue so I moved processing methods inside pbft_manager. In original PR they were inside tarcap and pbft_manager would simply call those functions from it's internal processing function.
As a result 4 methods from intermediate network  "interface" could be deleted:uint64_t pbftSyncingPeriod() const;
std::optional<SyncBlock> processSyncBlock();
void syncBlockQueuePush(SyncBlock const &block);
size_t syncBlockQueueSize() const;

I am totally for moving all syncing logic from pbft_manager somewhere else (even to tarcap), but I am for solution where processing of syncing data would not be triggered from pbft_manager so until we figure out how to get rid of the dependency of syncing data on pbft_manager, I think this is cleaner solution + similar to approach used in other managers and theirs queues...
To have a bigger picture about design, original PR must be checked. Check where is processSyncBlock() called

I don't think there is much difference in these two implementations. Since this data is pbft, it is slightly better to be in the pbft class.
But I also agree with its revision in future and I think that it is more global design problem with networking or/and some other modules

I don't think there is much difference in these two implementations. Since this data is pbft, it is slightly better to be in the pbft class.
But I also agree with its revision in future and I think that it is more global design problem with networking or/and some other modules

Yes you are right with both points

prnet cleaned-up successfully


[Go][Parquet] Round trip Parquet schema

Describe the bug, including details regarding any error messages, version, and platform.
I'm using pqarrow.FromParquet() and pqarrow.ToParquet() to transform a Parquet schema into an Arrow schema and back.  It may be that I can avoid this, but I'm starting with a Parquet schema and want to make use of the pqarrow.FileWriter, so it seems like I need to work with an Arrow schema.
This is likely user error, but I was surprised to see that repetition information was lost when going from a Parquet schema to an Arrow schema and back.  Specifically, repeated fields in Parquet become required lists.
Here is an example test that tries to round trip a schema with a single repeated bool field:
func TestRoundTripSchema(t *testing.T) {
	fields := schema.FieldList{
		schema.NewBooleanNode("bools", parquet.Repetitions.Repeated, -1),
	}
	root, err := schema.NewGroupNode("root", parquet.Repetitions.Required, fields, -1)
	require.NoError(t, err)
	parquetSchema1 := schema.NewSchema(root)

	arrowSchema, err := pqarrow.FromParquet(parquetSchema1, nil, nil)
	require.NoError(t, err)

	writerProps := parquet.NewWriterProperties(
		parquet.WithRootName("root"),
		parquet.WithRootRepetition(parquet.Repetitions.Required),
	)
	parquetSchema2, err := pqarrow.ToParquet(arrowSchema, writerProps, pqarrow.DefaultWriterProps())
	require.NoError(t, err)

	assert.True(t, parquetSchema1.Equals(parquetSchema2))
	assert.Equal(t, parquetSchema1.String(), parquetSchema2.String())
}

The difference in the (string representation of the) schemas looks like this:
--- Expected
+++ Actual
@@ -1,3 +1,7 @@
 required group field_id=-1 root {
-  repeated boolean field_id=-1 bools;
+  required group field_id=-1 bools (List) {
+    repeated group field_id=-1 list {
+      optional boolean field_id=-1 element;
+    }
+  }
 }

I see that there is some special meaning to the the metadata.KeyValueMetadata pairs passed to pqarrow.FromParquet().  Should I be passing information about whether to use lists or repeated values there?  Or is there a parquet.WriterProperty that I should be passing along to pqarrow.ToParquet()?
Thanks for any suggestions on how to retain the original repetition when round-tripping a Parquet schema through an Arrow schema.
Component(s)
Go, Parquet

I can get the test above passing with a change like this: https://github.com/apache/arrow/compare/main...tschaub:arrow:round-trip-schema
This builds on the existing logic of tracking field id in the kv metadata when converting an Arrow schema to a Parquet schema.  The only case I handled is to make is to a repeated primitive round trips back to a repeated primitive (rather than a list).
If there is interest in supporting this, I can prepare a pull request (and update the tests that make assertions about the existing field metadata).

I've decided to abandon the effort to retain the Parquet schema when using the pqarrow.FileWriter.


3049 fix sockname

@rnewson, @iilyak

+1

So technically the fix of existed code should be:
sockname({ssl, Socket}) ->
    ssl:sockname(Socket).

?

/:

Yes, I seem to have tested that code snippet on a non-mochiweb socket (without the tuple), which is utterly my bad :(

@kxepal The new code reflects exactly what couchdb has always done since 2012 (that code is in couch_httpd.erl).

@rnewson that doesn't means that it couldn't be improved (;

But it's too late anyway, so ok.

We'd want them to match, though. In my opinion the version in couch_httpd is quite clear.

@kxepal I hope it's also clear that the socket is never a pid, that's the mistake, it's a port in the non-ssl case and a tuple, {ssl, blah, port, ...} if ssl.

@rnewson yes, you're right here.


Better support sending messages to SQS queue using queue URL

Type: Feature
Is your feature request related to a problem? Please describe.
We recently migrated from Spring Boot 2.7 to Spring Boot 3.3. One use case we have is that we use a SQS client configured with us-west-2 credentials to send a message to a eu-central-1 queue. With the "old" implementation it was very straightforward, we just had to specify the fully qualified queue URL as the destination (e.g. https://sqs.eu-central-1.amazonaws.com/12345/queueName). However this doesn't work anymore with the latest Spring Cloud AWS because io.awspring.cloud.sqs.operations.SqsTemplate always tried to load the queue attributes before sending the message, and that calls fails since it's trying to load it from the wrong region.
Describe the solution you'd like
Looking at the following code from SqsTemplate:
	private CompletableFuture<SendMessageRequest> createSendMessageRequest(String endpointName, Message message) {
		return getQueueAttributes(endpointName)
				.thenApply(queueAttributes -> doCreateSendMessageRequest(message, queueAttributes));
	}

	private SendMessageRequest doCreateSendMessageRequest(Message message, QueueAttributes queueAttributes) {
		return SendMessageRequest.builder().queueUrl(queueAttributes.getQueueUrl()).messageBody(message.body())
				.messageDeduplicationId(message.attributes().get(MessageSystemAttributeName.MESSAGE_DEDUPLICATION_ID))
				.messageGroupId(message.attributes().get(MessageSystemAttributeName.MESSAGE_GROUP_ID))
				.delaySeconds(getDelaySeconds(message))
				.messageAttributes(excludeKnownFields(message.messageAttributes()))
				.messageSystemAttributes(mapMessageSystemAttributes(message)).build();
	}

It seems like the only reason it's trying to get the queue attributes is to get the queue URL. It would be great if there was a check on endpointName to see if it was already a fully qualified queue URL, and skip the queue attribute load. This would make it easier to send messages to arbitrary regions.
Describe alternatives you've considered
N/A
Additional context
N/A

Sorry I might have misunderstood the code... Closing. :P


Upgrade goproxy for CVE

No matter which version of goproxy used, the Snyk scan fails. We will need to upgrade to go 1.20 to resolve this.


Update README.md with Discussions

closes #3
What does this PR do?
Update README.md file with Discussions
Description of Task to be completed?
Showcase of Open source portfolios for feedback
How can this be manually tested?
Any background context you want to provide?
What is the relevant issue link?
Screenshots (if appropriate)
Questions:

Thanks @VictoryWekwa . Can you update your fork branch, because the PR is showing changes you made in a previous PR so it is difficult to review

I don't know why that is is happening. Let me see to it

no problem @VictoryWekwa , it happens to everyone 🤓
I did a video on how to keep your fork up to date https://youtu.be/vn2SgK4IbiM
Once you update your fork don't forget to merge main in your branch, in this case VictoryWekwa

Okay.
Thank you

Hello @eddiejaoude please can you let me know if it's fine now

@VictoryWekwa did you push any changes? It looks the like there are no new commits

Yes, I did.
I added the part of showcase of portfolio for community feedbacks

thank you 🤓


Nice to have: Terraform script to create Mollie custom types

Summary
We use terraform to manage a part of our commercetools configuration. It would be a nice addition to have a piece of terraform script included in this project which has all the custom type configuration defined in it.
Developers who manage their commercetools configuration through terraform would then be able to just copy the type configuration from this project into their own terraform script.
mollie-custom-types.tf
resource "commercetools_type" "mollie-integration-payment-type" {
  key = "ct-mollie-integration-payment-type"
  name = {
    en = "Mollie Integration payment type"
  }
  resource_type_ids = ["payment"]

  # payment methods request field
  field {
    type {
      name = "String"
    }
    name = "paymentMethodsRequest"
    label = {
      en = "Payment methods request"
    }
    required   = false
    input_hint = "MultiLine"
  }

  # payment methods response field
  field {
    type {
      name = "String"
    }
    name = "paymentMethodsResponse"
    label = {
      en = "Payment methods response"
    }
    required   = false
    input_hint = "MultiLine"
  }

  # create payment field
  field {
    type {
      name = "String"
    }
    name = "createPayment"
    label = {
      en = "Create payment"
    }
    required   = false
    input_hint = "MultiLine"
  }
}

resource "commercetools_type" "mollie-integration-transaction-type" {
  key = "ct-mollie-integration-transaction-type"
  name = {
    en = "Mollie Integration transaction type"
  }
  resource_type_ids = ["transaction"]

  # line IDs field
  field {
    type {
      name = "String"
    }
    name = "lineIds"
    label = {
      en = "Line IDs and Custom Line IDs"
    }
    required   = false
    input_hint = "MultiLine"
  }

  # include shipping field
  field {
    type {
      name = "Boolean"
    }
    name = "includeShipping"
    label = {
      en = "Include shipping"
    }
    required = false
  }

  # description field
  field {
    type {
      name = "String"
    }
    name = "description"
    label = {
      en = "Description"
    }
    required   = false
    input_hint = "SingleLine"
  }

  # metadata field
  field {
    type {
      name = "String"
    }
    name = "metadata"
    label = {
      en = "Metadata"
    }
    required   = false
    input_hint = "MultiLine"
  }
}

resource "commercetools_type" "mollie-integration-interaction-type" {
  key = "ct-mollie-integration-interface-interaction-type"
  name = {
    en = "Mollie Integration payment interface interaction type"
  }
  resource_type_ids = ["payment-interface-interaction"]

  # id field
  field {
    type {
      name = "String"
    }
    name = "id"
    label = {
      en = "ID"
    }
    required   = true
    input_hint = "SingleLine"
  }

  # action type field
  field {
    type {
      name = "String"
    }
    name = "actionType"
    label = {
      en = "Action type"
    }
    required   = true
    input_hint = "SingleLine"
  }

  # created at field
  field {
    type {
      name = "DateTime"
    }
    name = "createdAt"
    label = {
      en = "Created at"
    }
    required = false
  }

  # request field
  field {
    type {
      name = "String"
    }
    name = "request"
    label = {
      en = "Request"
    }
    required   = false
    input_hint = "MultiLine"
  }

  # response field
  field {
    type {
      name = "String"
    }
    name = "response"
    label = {
      en = "Response"
    }
    required   = false
    input_hint = "MultiLine"
  }
}

Great idea, can you make a PR for that?


👷 Switch to Gradle Version Catalogs for Android builds

What and why?
This should make it easier to update versions and add libraries in the future, and ensure that all example applications are using the same version of the library.
How?
Added packages/datadog_flutter_plugin/android/datadog_version.toml as an importable version catalog, and had all gradle.settings files import that.
Review checklist

[x] This pull request has appropriate unit and / or integration tests
[x] This pull request references a Github or JIRA issue

CI Configuration (optional)

[x] Run unit tests
[x] Run integration tests

Also we need to update the dogfood.py script in the Android SDK repo, so ti can target the proper location.

Also we need to update the dogfood.py script in the Android SDK repo, so ti can target the proper location.

Dogfood.py can actually remove Flutter from its updates, since we now "pull" the correct version instead of have it pushed by the release. I'll create a PR shortly.

@0xnm Can you re-review? I had to shift naming because you can't have both datadog-sdk-android and datadog-sdk-android-ndk -- I'm curious if you're okay with what appears to be a non-standard naming convention here (which personaly I like way better)


Experience running in ECS containers?

Can I ask if you've tried running pstore within an ECS container?  I'm really not sure why mine's not working, was wondering if it was a known problem.
I'm running a container on an Amazon ECS-optimized instance.  My container has a task role to give it access to my SSM keys.   Within the container, curl <IP_ADDRESS>$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI gives the correct role.
Additionally, I can fetch the keys successfully using the aws-cli tool:
aws ssm get-parameters --region=eu-west-1 --names imogen.license --with-decryption

However, pstore seems to be unable to fetch the same key:
$ AWS_REGION=eu-west-1 PSTORE_LICENSE=imogen.license pstore exec --verbose -- /bin/bash -c 'echo val is $LICENSE'
✗ Failed to decrypt imogen.license=LICENSE (request ID: 5181b60f-be6c-11e7-af11-63590df9a94d)
ERROR: Failed to decrypt some secret values

It doesn't seem to make a difference if the parameter is encrypted or not.  Can I do anything to narrow the problem down?

Hiya! Sorry for the slow response, I was on vacation and just got back.
Yes, ECS is the primary environment in which I've been running pstore. I've been meaning to add more documentation to the README for a complete example of how to use it - especially because I think I might know what the problem is.
I switched to using the GetParameter API in places instead of GetParameters - notice the singular form instead of plural. This is a newer API and annoyingly (but understandably) IAM distinguishes between these two actions. I suppose you have granted the IAM task role access to iam:GetParameters but not iam:GetParameter.
Another source of issues (probably) would be that when specifying parameters by tag (instead of by name) I am still using GetParameters! I should probably use one or the other, but not both.
Let me know if that solves your issue. I'll update the docs too!

Sorry - I finally managed to get some time to look at this again, and you were completely right - I was missing iam:GetParameter.   Thanks for the help!


ESD protection on Vio and Vsense pins

FXMA108 gives us ESD protection on all I/O pins. However, what about the ADC and the LDO? In particular, the turned off LDO has the output in hi-Z state, which seems like it might have bad implications. Verify.

The LDO has 2 kV ESD tolerance, the ADC has 2.5 kV (on the pins in question, under the human body model). The LDO rail has 4.7 uF of capacitance, and the ADC has 12 nF before the input pin. Given that the human body model specifies 200 pF of capacitance, we have an effective 250 kV of tolerance, which should be plenty.
See https://irclog.whitequark.org/~h~openfpga/2018-05-22#22149898; for discussion with @azonenberg on this topic.

Agreed.


python3Packages.yeelight: 0.7.5 -> 0.7.6

Motivation for this change
Update to latest upstream release 0.7.6
Change log: https://gitlab.com/stavros/python-yeelight/-/blob/master/CHANGELOG.md
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

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

3 packages built:

home-assistant
python38Packages.yeelight
python39Packages.yeelight


s-tui: 1.0.0 -> 1.0.1

Semi-automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/python3.8-s-tui/versions.
meta.description for s-tui is: "Stress-Terminal UI monitoring tool"
meta.homepage for s-tui is: "https://amanusk.github.io/s-tui/"
meta.changelog for s-tui is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.0.1 with grep in /nix/store/msav5mcqv3n17giyg813ly8lmazb44cy-python3.8-s-tui-1.0.1

directory tree listing: https://gist.github.com/d0a668f32854e4b0d7980d2511e9246d

du listing: https://gist.github.com/848eaa2e0bc1021f9e8ca3b94b61cdd4

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
s-tui

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/msav5mcqv3n17giyg813ly8lmazb44cy-python3.8-s-tui-1.0.1 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A s-tui https://github.com/r-ryantm/nixpkgs/archive/6788f32141f0b1d9bc2a0f22d52e2b0caa61bbb2.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/msav5mcqv3n17giyg813ly8lmazb44cy-python3.8-s-tui-1.0.1
ls -la /nix/store/msav5mcqv3n17giyg813ly8lmazb44cy-python3.8-s-tui-1.0.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

1 package built:
- s-tui

Maintainer pings
cc @infinisil for testing.

LGTM, thanks!
(and thanks for review @stigtsp!)


automatic deletion of game after it has ended

https://github.com/sopra-fs23-group-33/sopra-server/commit/1faef5ce018c58381e070e8b2b8ff148518f7b61


chore(main): release 1.1.0

:robot: I have created a release beep boop
1.1.0 (2024-04-19)
Features

Add release please (60a190d)

Bug Fixes

Add comments (7c9eba4)
Move manifest location again (3abe3a4)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/fortytwoservices/powershell-module-schooldatasync/releases/tag/v1.1.0 :sunflower:


[Backport 2.x] Baseline Maintainers (#883)

Description
Cherry-picked from https://github.com/opensearch-project/k-NN/pull/883
Check List

[x] Commits are signed as per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #890 (a1c3ba9) into 2.x (bfb9078) will increase coverage by 0.01%.
The diff coverage is 90.90%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff              @@
##                2.x     #890      +/-   ##
============================================
+ Coverage     85.05%   85.07%   +0.01%
+ Complexity     1093     1088       -5
============================================
  Files           153      152       -1
  Lines          4423     4414       -9
  Branches        395      392       -3
============================================
- Hits           3762     3755       -7
  Misses          482      482
+ Partials        179      177       -2

Impacted Files
Coverage Δ

...n/plugin/transport/SearchModelTransportAction.java
75.00% <50.00%> (-6.82%)
:arrow_down:

...plugin/transport/TrainingModelTransportAction.java
84.84% <75.00%> (-1.27%)
:arrow_down:

...main/java/org/opensearch/knn/indices/ModelDao.java
82.67% <94.44%> (+1.19%)
:arrow_up:

...n/plugin/transport/DeleteModelTransportAction.java
100.00% <100.00%> (ø)

.../knn/plugin/transport/GetModelTransportAction.java
100.00% <100.00%> (ø)

...in/transport/TrainingJobRouterTransportAction.java
80.00% <100.00%> (-0.86%)
:arrow_down:


Data split

Thank you for releasing the source code for TD-DMN.
Would you kindly send me the data split used in the 5-fold experiment? I have license for ACE 2005 and sent email to<EMAIL_ADDRESS>My email address is<EMAIL_ADDRESS>Thank you and look forward to your reply.

Please send your license to<EMAIL_ADDRESS>:)


RFC: Associated type lifetime elision

Rendered
Summary
This RFC extends lifetime elision to associated types, treating them as output positions using the existing rules.
This is particularly helpful for the usual IntoIterator pattern:
impl<T> IntoIterator for &Container<T> {
    type Item = &T;
    type IntoIter = Iter<'_, T>;
    fn into_iter(self) -> Self::IntoIter { self.iter() }
}

No 'as needed!
Thanks
To @Centril, @moxian, and @rkruppe for commenting on this on Discord.

I feel that the proposal makes the language more consistent & uniform which should help in learning.
The proposal also improves ergonomics in the cases where it applies, so that's a nice bonus too.
All in all, I think this is a solid idea :)

How would this interact with generic associated types (with lifetime parameters) ?

@rodrimati1992 so when you define an implementation for such a trait:
impl<T> Iterable for &[T] {
    type Item<'a> = &T;
    fn next<'b>(&'b mut self) -> Self::Item<'b> { ... }
}

notice in particular that we've named the lifetime in 'a explicitly; so I wouldn't expect &T to have the lifetime 'a but rather that of &[T]. That said, if you wrote type Item<'_> = &T; then perhaps expectations would be different. However, we can make such decisions about GATs and '_ specifically when we come to it.

We discussed this RFC in the Lang Team meeting today. As mentioned in the RFC, it definitely seems profitable to pursue additional potential for elision as an alternative to approaches like in-band lifetimes, and the ergonomic win here seems pretty significant.
That said, we're worried about the overlap between the proposed elision rules and the existing ones for methods. In particular, consider the following two examples:
impl<T> Iterator for Iter<'_, T> {
    type Item = &T;
    fn next(&mut self) -> Option<&T> {  /* ... */ }
}

impl<T> Iterator for Iter<'_, T> {
    type Item = &T;
    fn next(&mut self) -> Option<Self::Item> {  /* ... */ }
}

Would the elision in Output<&T> be allowed in the first block? If so, what would it mean? Any choice has downsides:

If we disallow the elision, that's a bit of a regression and frustrating corner case.
If we follow the usual method elision rules, the signature will have the wrong type, even though we wrote the exact same syntactic phrase when defining type Item and writing a return type that's supposed to match it.
If we want to use the impl-level elision, how would we do that? Would it be based on the method definition in the trait (and hence the connection with Self::Item? That seems very subtle, and it's not clear how it should play out in inherent impl  blocks.

In short, while the proposed elision seems great in isolation, once it's used alongside method-level elision rules, it could lead to significant confusion.

@aturon

If we follow the usual method elision rules, the signature will have the wrong type, even though we wrote the exact same syntactic phrase when defining type Item and writing a return type that's supposed to match it.

That's the right choice, I think.
It is already an established fact that type aliases are not copy-pastable (uh, what's the right word? :)), i.e. &T and Item are not the same thing even if type Item = &T.
This is similar to impl Trait aliases, where impl Trait is not the same as Foo even if type Foo = impl Trait.
I personally don't find this elision rule too confusing, but share the concerns to some extent. In any case, perhaps we might give the elision rule a chance like we did to in-band lifetimes? In the end, it'll either grow on us or stay confusing.

@stjepang

I personally don't find this elision rule too confusing, but share the concerns to some extent. In any case, perhaps we might give the elision rule a chance like we did to in-band lifetimes? In the end, it'll either grow on us or stay confusing.

Indeed! I didn't mean to say this is a total show-stopper, just a concern that came up.

I was thinking about this today and I realized that the elision behavior with respect to GATs might be somewhat different from what is proposed here, as well:
impl Iterator {
    type Iter<'a> = vec::Iter<'a, Self::Item>;
}

Currently, we disallow elision in comparable places like type Iter<'a> = vec::Iter<'a> as a type alias, or in structure fields.
I think this, combined with the concerns raised in this earlier comment, are enough to convince me that associated type values are not, in fact, "outputs" of the impl in the same sense and should not be treated like they are.
In other words, I would propose that we close this RFC and reconsider.

Deferring until we know more about GATs sounds good to me.  While this is nice for containers, it's certainly not essential.


test: by default, don't generate code for runner integration

Closes #900
Summary of Changes

We now have only a few targeted generator tests for the runner integration, instead of having this scattered across almost all tests.
Use vitest's toMatchFileSnapshot to easily be able to update the expected output after changes to the code generator. Run vitest --update to do so.

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

npm package (@latest dist-tag)
npm package (@latest dist-tag)
v0.8.0
GitHub release

Your semantic-release bot :package::rocket:


Fixes pagination docs

Changes

Updates outdated class name references for a-btn__icon-on-left and a-btn__icon-on-right, which have updated names in https://github.com/cfpb/capital-framework/blob/canary/src/cf-buttons/src/atoms/buttons-with-icons.less#L15

:+1:

We'll need a change log entry if we want a new patch release for it.

We'll need a change log entry if we want a new patch release for it.

Added to CHANGELOG.md! Do I need to do anything else?


MudChip OnClick breaks in latest version (5.1.5)

Bug type
Component
Component name
MudChip
What happened?
MudChip's OnClick seems to throw an error (nullRef on some class). I've tried several different ways of calling the click-event, but same result.
Expected behavior
The OnClick-event is fired
Reproduction link
https://try.mudblazor.com/snippet/QaGbEZcMeTMxLvGR
Reproduction steps

compile/run
error

Relevant log output
System.NullReferenceException: Object reference not set to an instance of an object.
   at MudBlazor.MudChip.get_Classname()
   at MudBlazor.MudChip.BuildRenderTree(RenderTreeBuilder __builder)
   at Microsoft.AspNetCore.Components.Rendering.ComponentState.RenderIntoBatch(RenderBatchBuilder batchBuilder, RenderFragment renderFragment)
   at Microsoft.AspNetCore.Components.RenderTree.Renderer.RenderInExistingBatch(RenderQueueEntry renderQueueEntry)
   at Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue()

Version (bug)
5.1.5
Version (working)
5.1.4
What browsers are you seeing the problem on?
Chrome
On what operating system are you experiencing the issue?
Windows
Pull Request

[ ] I would like to do a Pull Request

Code of Conduct

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

@JonBunator Thank you for the fix. @henon I hope it will be released soon. After the upgrade to the last version, there is no more the display of Chips.


Set Jettywrapper URL and Marmotta Home in host

This allows a host application to run jetty rake tasks successfully.

:+1:


single-node compute plan: worker tries to delete missing image

Setup:

Setup with 2 nodes
We run a compute plan that only has training tasks on node 2

The worker in node 1 encounters an error: it tries to delete an image that doesn't exist:
ERROR 2020-05-27 19:38:56,487 substrapp.tasks.tasks<PHONE_NUMBER>42099776 404 Client Error: Not Found ("reference does not exist")
 Traceback (most recent call last):
   File "/usr/local/lib/python3.6/dist-packages/docker/api/client.py", line 261, in _raise_for_status
     response.raise_for_status()
   File "/usr/local/lib/python3.6/dist-packages/requests/models.py", line 940, in raise_for_status
     raise HTTPError(http_error_msg, response=self)
 requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.35/images/substra/algo_dc32f8dd?force=True&noprune=False
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File "/usr/src/app/substrapp/tasks/tasks.py", line 983, in remove_algo_images
     client.images.remove(algo_docker, force=True)
   File "/usr/local/lib/python3.6/dist-packages/docker/models/images.py", line 463, in remove
     self.client.api.remove_image(*args, **kwargs)
   File "/usr/local/lib/python3.6/dist-packages/docker/utils/decorators.py", line 19, in wrapped
     return f(self, resource_id, *args, **kwargs)
   File "/usr/local/lib/python3.6/dist-packages/docker/api/image.py", line 495, in remove_image
     return self._result(res, True)
   File "/usr/local/lib/python3.6/dist-packages/docker/api/client.py", line 267, in _result
     self._raise_for_status(response)
   File "/usr/local/lib/python3.6/dist-packages/docker/api/client.py", line 263, in _raise_for_status
     raise create_api_error_from_http_exception(e)
   File "/usr/local/lib/python3.6/dist-packages/docker/errors.py", line 31, in create_api_error_from_http_exception
     raise cls(e, response=response, explanation=explanation)
 docker.errors.NotFound: 404 Client Error: Not Found ("reference does not exist")

(After a quick investigation: it looks like we're not catch ing the correct exception type (NotFound instead of ImageNotFound)

I try to understand how this issue can be triggered but it should not :
https://github.com/SubstraFoundation/substra-backend/blob/master/backend/substrapp/tasks/tasks.py#L987:L993
If we look the code, we can see that (l.988) we call client.images.get(algo_docker) which can raise a docker.errors.ImageNotFound (that why we catch this exception). If the call is successful, client.images.remove(algo_docker, force=True) should not raise a docker.errors.NotFound as the image exists (unless a parallel process already remove it)
I look into the documentation (https://docker-py.readthedocs.io/en/stable/images.html#docker.models.images.ImageCollection.remove), nothing is specify about potential exception that can be raised by this method.
Looking directly in the code (https://github.com/docker/docker-py/blob/5efe28149a2060ff64faab5d4c1566f4cb994792/docker/api/image.py#L484, https://github.com/docker/docker-py/blob/c6a33f25dc7fc172c69b8935e8c1e6b7aa44be8f/docker/errors.py#L13), NotFound is raised in all case not handled for ImageNotFound (https://github.com/docker/docker-py/blob/c6a33f25dc7fc172c69b8935e8c1e6b7aa44be8f/docker/errors.py#L24:L27)
Reading multiple stuff on "reference does not exist" from a docker image removal suggests (https://github.com/moby/moby/issues/26862) that backend is trying to remove an image that was already removed (sharing the same image as another tag).
I think we can safely update https://github.com/SubstraFoundation/substra-backend/blob/master/backend/substrapp/tasks/tasks.py#L992 to
    except (docker.errors.ImageNotFound, docker.errors.NotFound):

@Kelvin-M +1 it seems like a good solution


[DOC] Adds logging to workflow functions

Begins to address (but certainly does not close) #36.
So that you know what's happening and get some stats about things when you run the functions!

Pull Request Test Coverage Report for Build 221

13 of 14 (92.86%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 97.208%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

abagen/allen.py
13
14
92.86%

Totals

Change from base Build 219:
0.04%

Covered Lines:
940

Relevant Lines:
967

💛  - Coveralls

Codecov Report

Merging #61 into master will increase coverage by 0.03%.
The diff coverage is 92.85%.

@@            Coverage Diff            @@
##           master     #61      +/-   ##
=========================================
+ Coverage   97.16%   97.2%   +0.03%
=========================================
  Files          24      24
  Lines         954     967      +13
=========================================
+ Hits          927     940      +13
  Misses         27      27

Impacted Files
Coverage Δ

abagen/allen.py
99.17% <92.85%> (+0.09%)
:arrow_up:

Continue to review full report at Codecov.

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


"Attention! Nova The page will automatically within 5 sec CliCk to cancel"

Describe the bug

Playlists get the message "Attention! Nova The page will automatically within 5 sec CliCk to cancel" every 5-7 seconds.
Reloads the page (unless cancelled manually)
Repeats Step 1.

Stuck in this loop. Not sure which enabled option is causing this.

Browser: Firefox 106.0.2 (64-bit) on Windows 10 21H2
...monkey [ex: violentmonkey 2.13.3]
Nova version: 0.32.11 (latest)

I disabled this function.
Try this ver. https://openuserjs.org/scripts/rainart/Nova_YouTube

Why is it needed?

Because of the introduction of Nova on the youtube page, unnecessary information accumulates. It can lead to slowdowns. The principle of the described functionality is that after 30 page transitionend (in the playlist), it tries to reload the page in order to reset the js cache.

every 5-7 seconds
It should not be. I'll disable it. Let the user manually reboot if necessary.

It's not doing the thing any more. Thank you for fixing it.

Because of the introduction of Nova on the youtube page, unnecessary information accumulates. It can lead to slowdowns. The principle of the described functionality is that after 30 page transitionend (in the playlist), it tries to reload the page in order to reset the js cache.

To give you a little more context: the playlist in question had 66 videos and I clicked on the 48th video. The bug kept repeating on this 48th video where it would continue to reload the 48th video upon playing the video for about 5-7 seconds.

thanks for clarifying the context

New issue: the next video in the playlist doesn't load. After finishing the current video, it just stays in that video (paused) and doesn't move on to the next video in the playlist.

I'm missing data. Namely settings and url. Without them,
I can suggest that we try in one of the plugins:

Playlist autoplay control button
Stop video preload
Video auto pause
Autopause video if tab loses focus (in Autopause all background tabs except the active one)
Add playlist reverse order button

Tou can change the settings and send a link to the video
it is also possible there is a conflict with another script

and you can also send an error message in the console tab