adding exercise10 and towards final project

The attached files are heavy so I had to separate them into three files and also zip to be able to load them.
The actual file name in colab that contains the separated folders submitted here is 'python project_exercise10_and_final_project" to make it easier for you to reference it.

Excellent project organization, though the zip files were a bit cumbersome to unpack. I removed the simplified_data shapefile from the repo because it is created when running the notebook; this also greatly reduced its size on disk. Thanks for including a discussion of how your results could to be used to support recommendations for policymakers. Very thorough.


[3.x] Fixed issue in SkeletonIK leading to some root bones being twisted incorrectly

I think I have finally fixed the issue in the SkeletonIK node leading to the root bone being twisted when rotated. This PR also combines the fix in #48166 - where the for checking the bone forward direction was not working correctly.
(I will port the fix in this PR to #48166)
I tested the minimum replication projects in #48078 and #47803, and both projects seem to be fixed in my testing. However, additional testing is appreciated to make sure the fix in this PR truly does solve the issue.
Closes #48078
Closes #47803

CC @macryc @yaelatletl @Naurk @wojtekpil New try :)
You can download artifacts from the CI build of this 3.x PR to test it:

Linux: https://github.com/godotengine/godot/runs/2452423028
Windows: https://github.com/godotengine/godot/runs/2452422871

Specifically with the "Artifacts" menu here:

CC @macryc @yaelatletl @Naurk @wojtekpil New try :)
You can download artifacts from the CI build of this 3.x PR to test it:

Linux: https://github.com/godotengine/godot/runs/2452423028
Windows: https://github.com/godotengine/godot/runs/2452422871

Specifically with the "Artifacts" menu here:

Thanks @akien-mga. It does seem to fix the issue partially. The bone isn't twisted by 180 degrees any more but it's still twisted to the left by about 20-30 degrees or so. See attached screen shot:

Thanks for your work  @akien-mga : like macryc it seems to work better, but there's some issue yet and I don't understand completely the behaviour, but it is still different from 3.2.3 and previous.

Artifact
It untwisted the bones that were twisted but seemed to change how bones behave, those shoulders have tracking behaviour

RC 4

Okay, I think I found a new, better solution. It has a few unique pros and cons, but ultimately I think its the best fix so far.
@macryc @Naurk @yaelatletl - can you all try the latest build artifact to see if it works for you.
Below is an explanation of the change, but the TLDR is that I made a minor adjustment to the Skeleton node and now it can use the previous rotation code, which should fix the regression while still working with BoneAttachment nodes.

With the change, I reverted the code back to how it was prior to fix, where it wasn't working with BoneAttachment nodes but it was otherwise working okay. Instead of trying to rotate the root bone or apply a patch that way, I decided that perhaps the best way to work around this issue is to instead change the code in SkeletonIK so it no longer resets the global pose override multiple times to get the global pose without any overrides, which was the issue causing it to not work with BoneAttachment nodes.
To do this, I added a new transform to the bone struct in the Skeleton node called global_pose_no_override, which is simply the global pose of the bone without any bone overrides applied. This does have the minor con of meaning that the code can no longer take a short cut when the bone global pose override is over 0.999, as we need to calculate the global pose without overrides. So, this may lead to slightly lower performance for projects that have lots of bone global pose overrides with interpolations over 0.999, but I do not expect it to be noticeable.
I was going to add this anyway in the 3D IK PR, so this PR will just be adding it a touch earlier anyway. Once that PR is merged in, the performance loss for calculating the bone global pose without overrides should be even lower, as only the bones that actually changed will be calculated.
For SkeletonIK itself, it actually should be a little faster! Now the code doesn't force the Skeleton to reset all its transforms, recalculate all the transforms, cache the global poses without overrides, and then recalculate the poses again with overrides. Now it just gets the global poses without overrides, and then calculates the poses with overrides, skipping an entire recalculation cycle.
Additionally, because it is using the previous SkeletonIK code for rotation, all of the regressions and differences in how it calculates the bone angles and rotation should be fixed as well!
Ultimately, I think its a positive change with very few cons. Hopefully this will be the final change needed to fully fix the SkeletonIK regressions found.

Okay, I think I found a new, better solution. It has a few unique pros and cons, but ultimately I think its the best fix so far.
@macryc @Naurk @yaelatletl - can you all try the latest build artifact to see if it works for you.

Hi @TwistedTwigleg , thanks for this and the explanation, I'm keen to try this new build but the only one I can find is the previous one from 5 days ago. Could you post a link to the new one?

Click on the green tick next to the last commit to get a list of CI runs, and then pick the one that matches your platform to access artifacts:

@TwistedTwigleg , just tested the fix and the root bone seems to be working correctly, however somehow the fix has had an effect on the interpolation property. Basically, interpolation has now become all-or-nothing. The property has no effect between 0-0.01, and 100% from 0.01 - 1.

Okay, awesome! I'm glad the root bone issue is fixed. I have a hunch that the interpolation issue is just somewhere the code is using the global pose with overrides rather than without, so fingers crossed its just that and easy to fix. I'll take a look once I can and see if I can fix the issue.
Thanks for testing, I really appreciate it!

I've done a quick test, but it seems like macryc said: the root bone issue seems fixed and the interpolation is now just 0 or 1, but this is the way! I'll do some extensive comparative tests nex days. Ty! :)

I think I fixed the interpolation bug, at least its fixed on my end. :+1:
I think this PR should be good to go now. If you want, I can squash the previous commit so this is just one (since the stuff in the first commit didn't work), just let me know and I'll tackle it this weekend. I'll also port the code to the master branch this weekend as well.

Awesome work! If that works for everyone we should be nearly ready for 3.3.1 RC 1 :)
To pass CI you'll have to add the documentation for the new method, we recently added a check that makes it a requirement:
diff --git a/doc/classes/Skeleton.xml b/doc/classes/Skeleton.xml
index 244cb29..fe4e909 100644
--- a/doc/classes/Skeleton.xml
+++ b/doc/classes/Skeleton.xml
@@ -80,6 +80,14 @@
 				Returns the overall transform of the specified bone, with respect to the skeleton. Being relative to the skeleton frame, this is not the actual "global" transform of the bone.
 			</description>
 		</method>
+		<method name="get_bone_global_pose_no_override" qualifiers="const">
+			<return type="Transform">
+			</return>
+			<argument index="0" name="bone_idx" type="int">
+			</argument>
+			<description>
+			</description>
+		</method>
 		<method name="get_bone_name" qualifiers="const">
 			<return type="String">
 			</return>

(Ideally with the description completed :))

Awesome, will add documentation later tonight 🙂

Documentation is now added and I squashed it all down into a single commit :+1:

Cherry-picked for 3.3.1.


[Candidate 3v3 Glacier 6 ZH v1] Oil Derricks do not show flag optimally and have random rotations

Observed behavior
Oil Derricks do not show flag optimally and have random rotations. There is no symmetry. Affects all Oil Derricks.
Expected behavior
Oil Derricks rotations make an effort to show the flags well and perhaps there is a system for their rotations.
Screenshots

all oils show in mid now

Is it possible to rotate them some other way so that no flag is hidden?

updated

Flags are now visible, but they still appear to have random rotations with no system. Perhaps there is a better way to optimize it, so I will leave this report open for now. This map has no blockers.


Game seems to crash if you tab-out while the save loads if using this mod.

I have a couple other mods installed but this only started happening when I installed this one. Seems to be repeatable.

Please provide more information.


Email not shown for new user in the contact method (on Profile page)

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

Action Performed:

Go to staging dot on web chrome and login with a new user -create a new account (important step)
Click on Settings > Profile
You're on the Profile page and notice that on 'Contact method' that is just present below the 'Display name' doesn't shown the email
Follow the same steps on production with a new user and notice that on the Profile page, email is shown as default under 'Contact method'

Expected Result:
Email should be shown for new user in the contact method (on Profile page)
Actual Result:
Email not shown for new user in the contact method (on Profile page) in staging but works well on production
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

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

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

Version Number: 1.3.29-0
Reproducible in staging?: y
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/43996225/c44cac4a-29fe-4b25-a8e5-f4fb40c3975e

Expensify/Expensify Issue URL:
Issue reported by: @priya-zha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1687155411925429
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

This had the same root cause of #fireroom-getpersonaldetailslist and it's no longer reproducible after the latest Auth deploy. Closing.

@luacmartins It's still reproducible on staging. Can you please check it once more?

Just tried again with a brand new account and still can't reproduce
https://github.com/Expensify/App/assets/22219519/8ff5befd-7151-468f-a987-399205298d2b

It seems weird that I'm still able to reproduce it. Also the same issue was posted by some other contributor today here :. I tried this on chrome web with a gmail account. I don't know whether it's related or not , but have you tried with a gmail account?  Thanks
https://github.com/Expensify/App/assets/34065075/f68828fb-a0a6-4721-b512-f94f96313338

Just tried with a new gmail account and I still can't reproduce the issue.


Hot reload

Codecov Report

Merging #13 (8a11c8a) into master (fd42ff5) will increase coverage by 0.69%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #13      +/-   ##
==========================================
+ Coverage   88.81%   89.50%   +0.69%
==========================================
  Files          75       44      -31
  Lines        1010      610     -400
  Branches       59       59
==========================================
- Hits          897      546     -351
+ Misses        109       60      -49
  Partials        4        4

Impacted Files
Coverage Δ

src/modules/errors/error.ts
100.00% <ø> (ø)

src/modules/toJSON/toJSON.ts
100.00% <ø> (ø)

src/routes/v1/swagger.route.ts
100.00% <ø> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


[TASK] No need to add kind/test tickets to Longhorn Sprint board

What's the task? Please describe
kind/test tickets should only be added to QA Sprint board.
Describe the sub-tasks

Additional context


Update KIC 2.5 docs with updated Gateway Listener handling

Where is the problem?
https://docs.konghq.com/kubernetes-ingress-controller/latest/guides/using-gateway-api/
What happened?
KIC 2.5 is expected to change how it handles Gateway resources. Gateway Listeners will no longer be auto-populated from Kong listens, and KIC will be able to load certificates from Listener configuration.
Current guides may request Listeners that are not actually available without additional Kong environment and Service configuration, and do not include certificate examples.
What did you expect to happen?
Gateway Route guides demonstrate loading certificates if applicable (HTTPRoute attached to an HTTPS Listener, TLSRoute).
Gateway guides that include a Gateway resource use Listeners that are compatible with the default listens in the all-in-one manifests, or instruct users to add Kong listen configuration and Service ports for the Listener used in the guide.
This should be completed by a member of the Kubernetes team following the 2.5 release, assuming https://github.com/Kong/kubernetes-ingress-controller/pull/2580 is merged. The issue is listed on our TODO board.
Code of Conduct and Community Expectations

[X] I agree to follow this project's Code of Conduct
[X] I agree to abide by the Community Expectations

https://github.com/Kong/docs.konghq.com/blob/524aa6485fac51201b748c1d4a7c52659d772e35/src/kubernetes-ingress-controller/guides/using-gateway-api.md#add-a-gatewayclass-and-gateway is actually fine as far as Listener compatibility with Kong configuration, since we do create an HTTP listen by default which uses that port in the Service.


Photoshop showing lighter tones

Before anything else, thank you very much for this software! I have installed the latest Dev version of Windows 11 (26058) to test the new color management, as it has been updated in this version. I have generated a profile with DisplayCAL using the default sRGB preset and have converted it using your program with the "sdr-acm" command. I have verified the results in DisplayCAL using the following configuration:

Simulation profile: sRGB
Use simulation profile as display profile
Apply black output offset (100%)

I have obtained very good results! However, I have noticed an anomalous behavior in Photoshop. Photoshop allows viewing tones beyond sRGB when a wide color space is chosen, this is an advantage that I appreciate, however, I have noticed that all tones look somewhat lighter in Photoshop, it seems that the correct gamma value is not displayed or that the profile correction is applied twice. I attach the profile I am using, in case it helps.
I am posting this here just in case, but maybe it's just a bug with Photoshop. Thank you very much for everything.
sdr-acm_VG27A.zip
Example: https://files.catbox.moe/f1liqy.png
EDIT: I have just noticed Windows' "Photos" image viewer is also capable of displaying wide gamut images but it does show the correct gamma values so I guess it's just a Photoshop bug. In that case sorry for the inconvenience!
EDIT2: The gamma issue in Photoshop can be resolved by disabling the "Use legacy display ICC color management" option. However, this adjustment prevents the display of colors beyond the sRGB spectrum. In contrast, the Windows "Photos" image viewer functions flawlessly. A workaround to make Photoshop work correctly involves re-enabling the "Use legacy display ICC color management" and changing the "Color Settings" to "Monitor Color".

Seems the issue is only related to ICC shim ("Use legacy display ICC color management" in compatibility settings) and it is a totally black box.
In my previous tests, the app will see a generated profile slightly off from the installed profile. Maybe there are some precision issues.


X509_time_adj_ex normalizes the object type or not depending on how it was created

The X509_time_adj_ex() function overwrites an existing ASN1_TIME value with a new time depending on the arguments passed.  It has this signature:
ASN1_TIME *X509_time_adj_ex(ASN1_TIME *asn1_time, int offset_day, long
                            offset_sec, time_t *in_tm);

The given asn1_time value (if not NULL) can have a type of either ASN1_UTCTIME (tag 0x17) or ASN1_GENERALIZEDTIME (tag 0x18).  If the object was first created using ASN1_UTCTIME_new or ASN1_GENERALIZEDTIME_new or d2i_ASN1_TIME, the object's existing type will be preserved, regardless of what new time is specified.
However, if the asn1_time object was previously created with ASN1_TIME_new(), then the call to X509_time_adj_ex() will change the type of the object to UTC or Generalized depending on the year of the specified time.
The fact that X509_time_adj_ex() can change the object type is not documented, in contrast with ASN1_TIME_adj().
Furthermore, the fact that whether it does so is dependent on the history of object reuse is troubling, as one would normally expect that history to be irrelevant; a reused object should have the same behavior as a newly-allocated object.
Example (excerpt of test program):
void test_x509_time_adj(int bug)
{
  ASN1_TIME *t = NULL;
  if (!bug) {
    t = ASN1_GENERALIZEDTIME_new();     // Works.
  }
  else {
    t = ASN1_TIME_new();                // Leads to the bug.
  }

  // Use 'd2i' to populate 't' with a GeneralizedTime.
  d2i_ASN1_TIME(&t, &p, sizeof(derGen));
  assert(t->type == 0x18);

  // Use 'adj' to change the time.
  X509_time_adj_ex(t, 0, 0, NULL /*in_tm*/);
  if (t->type != 0x18) {
    printf("bug detected!  type has changed to 0x%X\n", t->type);
  }
}

x509_time_adj.c.txt is a complete program demonstrating this behavior.  Its output is:
---- test_x509_time_adj, bug=0 ----
ASN1_GENERALIZEDTIME_new:
  len=0 type=0x18 flags=0x0 data: ""
d2i_ASN1_TIME(derGen):
  len=15 type=0x18 flags=0x0 data: "20101108181047Z"
  Nov  8 18:10:47 2010 GMT
X509_time_adj_ex:
  len=15 type=0x18 flags=0x0 data: "20210326024544Z"
  Mar 26 02:45:44 2021 GMT
---- test_x509_time_adj, bug=1 ----
ASN1_TIME_new:
  len=0 type=0xFFFFFFFF flags=0x40 data: ""
d2i_ASN1_TIME(derGen):
  len=15 type=0x18 flags=0x40 data: "20101108181047Z"
  Nov  8 18:10:47 2010 GMT
X509_time_adj_ex:
  len=13 type=0x17 flags=0x40 data: "210326024544Z"
  Mar 26 02:45:44 2021 GMT
bug detected!  type has changed to 0x17

I have observed this behavior with OpenSSL 1.1.1b and 1.1.1j running on Windows 10, built from source.
Recommended fix: This bug occurs because asn1_ex_c2i() does not set or clear the ASN1_STRING_FLAG_MSTRING flag when an object is reused.  The only place this flag is read is in X509_time_adj_ex(), where its effect is to normalize the object type rather than preserving it (i.e., to cause this bug).  I suggest simply removing the ASN1_STRING_FLAG_MSTRING flag altogether to fix this bug.  With that change, X509_time_adj_ex would always preserve the object type when it is ASN1_UTCTIME or ASN1_GENERALIZEDTIME.
Discussion of severity: The d2i_ASN1_TIME() man page explains that object reuse is discouraged, and I agree with that advice, but so long as the functionality is made available, bugs in it ought to be fixed since, among other things, they could contribute to security vulnerabilities.  (I'm filing this publicly because I think it is very unlikely that this alone would be such an issue, although it is impossible to completely rule it out.)

Thanks for the report and diagnosis; I looked through most of the referenced openssl code and your analysis seems accurate.
I'm less sure about the proposed fix, since commit 17b5326ba9d072fbf9dca35f70e74361b91a3944 seems to indicate that the whole point of the ASN1_STRING_FLAG_MSTRING flag is to be able to preserve type information about UTCTime/GeneralizedTime/Time.
Unfortunately, most of the team is focusing on getting the 3.0.0 release ready, and this does not look like it is going to be a release blocker, so the issue report is likely to sit around untouched for some months until resources free up to look into it.

Thanks for looking at it.  I did look at 17b5326, but the rationale there didn't (and still doesn't) make sense to me.  It says:

This makes it possible to tell if the underlying type is UTCTime, GeneralizedTime or Time when the structure is reused

But why?  There isn't an "underlying type" of Time; there is no ASN.1 tag for just "Time".  OpenSSL has ASN1_TIME_new(), but it is not documented.  A user might reasonably extrapolate that ASN1_TIME_new() is like ASN1_STRING_new(), which says:

ASN1_STRING_new() returns an allocated ASN1_STRING structure. Its type is undefined.

Hence one might expect that ASN1_TIME_new() also returns a structure with undefined type that can be populated with either of the ASN.1 time types, and thereby acquires the type it was populated with.  But in fact it also retains this hidden bit of state (ASN1_STRING_FLAG_MSTRING) that means it "remembers" it was originally a "Time".
Is this really how the API is meant to work?  If so, one could simply address this by documenting ASN1_TIME_new() and adding documentation to X509_time_adj()/X509_time_adj_ex(), but it would still seem like odd behavior to me.
Anyway, I agree that this is not urgent.


[zh] sync 1.24 ref-k8s-api-config: config-map-v1.md

This is the first localization task in #34158. The path is:
content/en/docs/reference/kubernetes-api/config-and-storage-resources/config-map-v1.md

/approve


Using [selected] property trigger re-rendering and animation

I'm submitting a ...
[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter

Current behavior
1- Make table selectable with custom checkboxes (ng2-material) and add [selected]="selected"
2- Add column with ng2-material toggle
3- clicking any of the checkboxes will rerender the whole table and the toggle buttons will re-animate
<ngx-datatable
  #table
  *ngIf="filteredAssets"
  class="material expandable"
  [rows]="filteredAssets"
  [columnMode]="'flex'"
  [headerHeight]="40"
  [footerHeight]="40"
  [rowHeight]="'auto'"
  [selected]="selected"
  [selectionType]="(selectable) ? 'checkbox' : ''"
  [limit]="50"
  [selectionType]="(selectable) ? 'multi' : ''"
  (activate)="onActivate($event)"
  >
  <ngx-datatable-column
    *ngIf="selectable"
    [width]="30"
    [flexGrow]="1"
    [sortable]="false"
    [canAutoResize]="false"
    [draggable]="false"
    [resizeable]="false">
    <ng-template let-row="row" ngx-datatable-cell-template>
      <md-checkbox [ngModel]="selected.indexOf(row) !== -1" (change)="toggleSelection(row)"></md-checkbox>
    </ng-template>
  </ngx-datatable-column>

Expected behavior
clicking the checkbox should not trigger rendering
Reproduction of the problem
What is the motivation / use case for changing the behavior?
1- performance
2- using toggles (with animation) in other columns of the data table
Please tell us about your environment:
Angular cli, macOS

Table version: 0.8.x
swimlane/ngx-datatable": "^9.3.0"

Angular version: 2.0.x
angular/cli: 1.2.0
node: 7.7.3
os: darwin x64
angular/animations: 4.2.6
angular/cdk: 2.0.0-beta.8
angular/cli: 1.2.0
angular/common: 4.2.6
angular/compiler: 4.2.6
angular/compiler-cli: 4.2.6
angular/core: 4.2.6
angular/flex-layout: 2.0.0-beta.7
angular/forms: 4.2.6
angular/http: 4.2.6
angular/material: 2.0.0-beta.8
angular/platform-browser: 4.2.6
angular/platform-browser-dynamic: 4.2.6
angular/platform-server: 4.2.6
angular/router: 4.2.6
angular/language-service: 4.2.6

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
All

Language:
All

Its because we watch rows and since thats a property on the row it calls render. :S
I'll look into this, we have a lot of re-rendering going on.


chore: bump pipelines build agent and node versions to latest LTS values

Description of changes
Unblocks #198
Pull request checklist

[x] PR title respects Conventional Commits (starts with fix:, feat:, etc, and is suitable for user-facing release notes)
[x] PR contains no breaking changes, OR description of both PR and final merge commit starts with BREAKING CHANGE:
[n/a] (if applicable) Addresses issue: #0000
[n/a] Added relevant unit tests for your changes
[x] Ran yarn precheckin
[x] Verified code coverage for the changes made

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Merging oscNext high stats sample PISA branch

A few changes implemented as part of the oscNext high stats sample analyses.
Description of changes:

Data loading changes, contained in simple_data_loader, events_pi and hdf (see dedicated PR #607, this is the same changes so if we merge that one first this one is then handled too)
Fix to theta23 octant handling (was a bug where the forcing into differnt fit octants didnt work for a particular case)
Made fitting octants separately the default behaviour (this seems to be the consensus on what the best practice is)
Fix for case where user's numba version doesn't have the NumbaDeprecationWarning
User can specify output_mode when calling Pipeline.get_outputs() if they want to request e.g. events instead of binned data. Useful for making plots from the output of the PISA pipeline.
Improvements to MCEq stage speed, and a few general style improvements to the code

Thanks for the review. All suggestions have been implemented now. Let me know if anything else comes, particularly when you test drive the code.


Handle non-positive length in protocol parsing

Ensure that usize won't underflow by adding guard clauses before substractions. Fixes #26.
I'm not sure about the error code/value. I just used whatever what used elsewhere, but it probably should be something other.

Thanks for the fix!


Lazy evaluation and no segmentation fault when reading str arrays

A few fixes.

both groups and variables can be lazily evaluated and,
no h5py object is stored in subsequent classes. This feature was causing segmentation faults when reading arrays with str datatype.

The changes are fairly minor with only a few additions to the hidden API.

Thanks for working on this! I'm optimistic this may fix the segmentation fault on Travis-CI that stopped me from merging https://github.com/shoyer/h5netcdf/pull/11.
A few notes:

You probably know this already, but distinct changes like are much easier/faster to review in separate PRs.
Could you please explain the use case for lazy evaluation for groups and variables? Does this make a meaningful performance difference for you? Are there tradeoffs to adding lazy=True? If not, we should switch to that unilaterally.
Please add a test for your bug fix -- that's essential to ensuring it remains fixed! See h5netcdf/tests/test_h5netcdf.py for examples.

I also have some style suggestions but I'll hold off on them for now.

Please rebase on master to get the fix for your failing test (related to _NCProperties) from #19.

Hi Stephan,
Please do suggest styles improvements!
This is my first contribution, so apologies for fitting too much into one pull request.
A short summary of the latest changes:

Made lazy=True by default. For my use case (large datasets recorded down 10 hierarchical groups), this makes a huge difference. My hunch (based on limited testing) is that smaller datasets would not experience big slow downs.

The new lazy implementation that always refer to the h5py.File object does not have a seg fault anymore (test_reading_str_array_from_netCDF4 with latest Anaconda 2.7 has a seg fault with previous h5netcdf version).

To ensure a successful build, the tests are now attempting the char test using pure h5py firstand are performing the test only if it is successful. Here, I was assuming that h5netcdf should fail when h5py fails.

Is there any reason why one would want to write lazy=False? If not, let's remove the option.
Please take a look at PEP8 for general Python style guidelines. In particular, note the guidelines about whitespace and variable names. I recommend running a PEP8 checker like pyflakes or pep8 to check this automatically while you write your code. pylint is also good, though it's rather strict by default. You can automatically run these tools whenever you save your code.

Ok,

I've folowed your advice and cleaned up the code using pylint and pyflakes.
I've Made lazy_objects a collections.Mapping and added an add method. It does not use OrderedDict anymore.
I've made a more generic function for testing against h5py.

Alright, I think I have implemented all your suggestions. Just give me a few minutes and I will push it!

Sounds good. Let me know if you need anything else.

I like it. I think it's important to have Lazy in the name. I think it's a fairly descriptive terminology.

It might also be a good idea to include a test for object iteration order.

Thanks @laliberte !

No problems! I might look into adding a few more tweaks to increase compatibility with the netCDF4 API. I've identified a few low hanging fruits already.
I also have been working on a patched pydap version that works very well with the ESGF. At the moment I've given it the netCDF4 API but it might make more sense to streamline it with h5netcdf since netCDF4 already has DAP support.

I also have been working on a patched pydap version that works very well with the ESGF. At the moment I've given it the netCDF4 API but it might make more sense to streamline it with h5netcdf since netCDF4 already has DAP support.

Yes, a thin wrapper around scipy, h5netcdf and pydap could be a drop-in replacement for netCDF4-Python (though you could also just use xarray). This probably makes more sense as a sister project, though we could also consider renaming h5netcdf.


[Feature request] Close button on the window bars

Would closing a window by middle-clicking the title bar be a legit substitute?

In my mind this is sort of against the philosophy of i3/sway. Wayland already gives you CSD for better or for worse, so you can just use the close button drawn by the clients if you want this feature.

@thejan2009 I worry about accidently closing a window if I'm middle-clicking on web browser tabs to close them.
@mikkeloscar What is CSD?

@sfgasdfsafggfgg CSD = "Client-Side Decorations", that is, the client itself draws its own window border and title bar.


Make 'yes' 1000 times faster.

See #1085.
On my computer, it makes coreutils' yes go from 3MB/s to 4GB/s. As a comparison, GNU yes is at 5GB/s.

But doesn't this make yes slower in terms of latency? ;D

I guess it does, but I have no idea how to measure it

Maybe a bufsize option or something should be added if we do this (I'm not really sure this is even necessary though).

@ProgVal @Arcterus So what about this? :)

Someone would have to test if it does not affect performance too much by having a run-time constant instead of a compile-time constant.

I'm still kind of ambivalent about this but feel like it's fine to merge.


_item[SiteRequestFields.STATUSMESSAGE_NAME] = statusMessage does not work for long messages

In SPSiteRequestManager.cs method UpdateRequestStatus the statusMessage is written to the Item's field SiteRequestFields.STATUSMESSAGE_NAME. That field is limited to 255 characters in the SharePoint list instance and the update will break if the message is longer than that.
Some truncation of the message would be a good idéa:
if (statusMessage.Length >= 255) { statusMessage = statusMessage.Substring(0, 252) + "..."; }

Thx Niklas, fixed now in the dev branch.


Add - share permissions not created properly for local groups

Should add another known issue -  share permissions assigned to local groups are not created properly; the permission is granted to a invalid SID (one that does not match the SID of the migrated local group and may not match any local security principal).  Details can be found in MS support case<PHONE_NUMBER>001563.
[Enter feedback here]

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

ID: f348eda3-6195-cd36-9bf9-769b6c37927b
Version Independent ID: a2255385-394e-7ee0-a90d-dcaca017a3d4
Content: Storage Migration Service known issues
Content Source: WindowsServerDocs/storage/storage-migration-service/known-issues.md
Product: windows-server
Technology: storage
GitHub Login: @nedpyle
Microsoft Alias: nedpyle

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


A better message error for account balance is too low

Description
The error message should be more user-readable when the account doesn't have enough TFT to submit any transition.

Blocked on https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1665

should be resolved in playground
https://github.com/threefoldtech/tfgrid-sdk-ts/assets/62248851/69eb7f4c-d1f8-4617-8028-5b28e23c4703

Verified,
Devnet 842ebef.
TC2443 - Set Fee

Verified:

Devnet
2.3.0-alpha3


Updates to Rollup & Tree updates

Codecov Report

Merging #71 (5d36c8d) into master (e9f1eda) will increase coverage by 0.13%.
The diff coverage is 85.45%.

@@            Coverage Diff             @@
##           master      #71      +/-   ##
==========================================
+ Coverage   79.87%   80.01%   +0.13%
==========================================
  Files         109      109
  Lines        9856     9885      +29
  Branches     1004     1012       +8
==========================================
+ Hits         7872     7909      +37
+ Misses       1984     1976       -8

Flag
Coverage Δ

unittests
80.01% <85.45%> (+0.13%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

packages/lib/components/carousel/carousel.tsx
85.21% <ø> (-0.07%)
:arrow_down:

packages/lib/components/tree/tree-utils.ts
57.14% <0.00%> (+6.39%)
:arrow_up:

packages/lib/components/tree/tree.tsx
91.22% <85.71%> (+4.04%)
:arrow_up:

...lib/components/accordion-group/accordion-group.tsx
87.27% <100.00%> (+0.73%)
:arrow_up:

packages/lib/components/accordion/accordion.tsx
96.84% <100.00%> (+0.19%)
:arrow_up:

packages/lib/components/input/input.tsx
98.06% <100.00%> (+0.05%)
:arrow_up:

packages/lib/components/menu/menu.tsx
96.42% <100.00%> (ø)

packages/lib/components/sidebar/sidebar.tsx
83.89% <100.00%> (-0.11%)
:arrow_down:

packages/lib/components/tree/tree-node.tsx
91.26% <100.00%> (+0.73%)
: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 e9f1eda...5d36c8d. Read the comment docs.


Add a field to modify backup times

Add a field to modify backup times
In case of regular crashes etc.
I don't know if it's 15minutes by default

planned with #30


Error: Input buffer has corrupt header: pngload_buffer: too many text chunks

I'm converting a PNG file to JPG but getting the following error:
Error: Input buffer has corrupt header: pngload_buffer: too many text chunks
The code I'm running:
const got = require('got');
const sharp = require('sharp');

const url = 'https://gateway.pinata.cloud/ipfs/QmeJLkBxYayBNmpMej8C6dN5FHHbkiTN5G9jRyuynfxmGB/nft.png';
const request = await got(url).buffer();

const data = await sharp(request).resize({ width: 512 }).jpeg({ quality: 70 }).toBuffer();

It's an image of an NFT artwork stored on IPFS, which is why it can take some time to load the image. But that doesn't have anything to do with the error.
The only other related issue I could find is this, but it doesn't solve the problem I'm facing.
I'm using the latest version of sharp, 0.29.2.
envinfo:
System:

OS: Windows 10 10.0.22000
CPU: (6) x64 AMD Ryzen 5 4500U with Radeon Graphics
Memory: 5.25 GB / 15.37 GB

Binaries:

Node: 14.18.1 - C:\Program Files\nodejs\node.EXE
npm: 7.19.0 - C:\Program Files\nodejs\npm.CMD

Please see #2917


Immersive Mode in Dialogs?

Is it possible to show the dialogue in Immersive Mode (without navigation buttons)??

No


add HTML5 tag and ARIA landmark

I added HTML5 tag (header nav footer main) and ARIA landmark (navigation main banner contentinfo) on templates.
See WAI-ARIA recommendation
No design impact (no need to modify CSS files)
And that's really good for screen reader users :-)
If interested, i can go further and I can work on making it all accessible, as I done for our society installation.

Big :+1: for the goal! :smile:
That said, I'm not a big fan of all these new HTML elements, and ARIA conventions are focused on roles, not HTML5 elements.
See my inline comments. :arrow_down:

And that's really good for screen reader users

And just for the joke, I'm quite curious of who use YOURLS on a screen reader! :laughing: :computer:
At the end, thanks a lot for the contribution.

Hey :-)
One of our colleague use Yourls with a screen reader. By screen reader users, I mean visual deficient user.

By screen reader users, I mean visual deficient user.

My bad, you're totally right. :smiley:

Any CSS fix to add?
@LeoColomb you merge this one when you're OK with it

No CSS fix, in my local testing, no impact with my commit.

@audreymaniez Nevertheless, I'm globally OK for your pretty cool contribution, can you just merge elements when possible (keep ids/classes, for CSS!)? :smile:
Thanks again! :+1:


Badges.

@devoncarew

badges are great!
You may want to TBR smaller doc changes; they're almost always harmless, and you can keep you velocity up.


check both isGreaterThan isLessThan

Feature summary
I feel that if I asserThat(...).isGreaterThan it should also verify isLessThan at the same time.
note: I went source diving
Example
assertThat(2).isGreaterThan(1);
// should also do the equivalent of

assertThat(1).isLessThan(2);

By doing this we can half the code required to compare. This ensures that the comparable is implemented correctly.

I'm not sure I understand what you have in mind. In your example, the first assertion fails while the second succeeds.

I should I have used integer's, 🤦🏻♂. Updated the original example. I just want one call to check that both things are true instead of only checking greater than, it should check greater than, and less than.

I guess you are looking for assertThat(value).isStrictlyBetween(startExclusive, endExclusive)?

no, that would require 3 inputs. What I'm saying is code like this should fail. If this compiled it would pass because it's ONLY checking isGreaterThan. It should also (under the hood) check isLessThan and isNotEqualTo. I think the term is reflexity. If s1 is greater than s2, then s2 must be less than s1 and s1 must not be equal to s2.
  @Test
  void gt() {
    Comparable<String> s1 = that -> 1;
    Comparable<String> s2 = that -> 0;
    assertThat(s1).isGreaterThan(s2);
  }

For the sake of a more complete example
package com.xenoterracide.gradle.semver;

import static org.assertj.core.api.Assertions.assertThat;

import java.util.stream.Stream;
import org.apache.maven.artifact.versioning.ComparableVersion;
import org.gradle.util.VersionNumber;
import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.extension.ExtensionContext;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.ArgumentsProvider;
import org.junit.jupiter.params.provider.ArgumentsSource;
import org.semver4j.Semver;

// not really our test, just test our assumptions about upstream parsing
@Disabled
public class VersionSortTest {

  @ParameterizedTest
  @ArgumentsSource(RcVersionList.class)
  void maven(String thisVersion, String thatVersion) {
    assertThat(new ComparableVersion(thisVersion)).isGreaterThan(new ComparableVersion(thatVersion));
  }

  @Disabled
  @ParameterizedTest
  @ArgumentsSource(RcVersionList.class)
  void gradle(String thisVersion, String thatVersion) {
    assertThat(VersionNumber.parse(thisVersion)).isGreaterThan(VersionNumber.parse(thatVersion));
  }

  @ParameterizedTest
  @ArgumentsSource(RcVersionList.class)
  void semver(String thisVersion, String thatVersion) {
    assertThat(new Semver(thisVersion)).isGreaterThan(new Semver(thatVersion));
  }

  static class RcVersionList implements ArgumentsProvider {

    @Override
    public Stream<? extends Arguments> provideArguments(ExtensionContext context) {
      return Stream.of(
        Arguments.of("0.1.1-alpha.10.17129409589+6.g3aae11c", "0.1.1-alpha.10+1.g3aae11d"),
        Arguments.of("0.1.1-alpha.10.17129409589+6.g3aae11c", "0.1.1-alpha.2.1712940957+2.g3aae11c"),
        Arguments.of("0.1.1-alpha.10.17129409589+6.g3aae11c", "0.1.1-alpha.6.1712940957+6.g3aae11c"),
        Arguments.of("0.1.1-alpha.10.17129409589+6.g3aae11c", "0.1.1-alpha.6.17129409589"),
        Arguments.of("0.1.1-alpha.0.17129409589+6.g3aae11c", "0.1.1-alpha.0.10+1.g3aae11d"),
        Arguments.of("0.1.1-alpha.0.17129409589+6.g3aae11c", "0.1.1-alpha.0.17129409578+2.g3aae11c"),
        Arguments.of("0.1.1-alpha.0.17129409589+6.g3aae11c", "0.1.1-alpha.0.17129409578+10.g3aae11c"),
        Arguments.of("0.1.1-alpha.0.17129409589+6.g3aae11c", "0.1.1-alpha.0.17129409588"),
        Arguments.of("0.1.1-rc.10.17129409589+6.g3aae11b", "0.1.1-alpha.0.10+1.g3aae11d"),
        Arguments.of("0.1.1-rc.10.17129409589+6.g3aae11b", "0.1.1-alpha.0.17129409578+2.g3aae11c"),
        Arguments.of("0.1.1-rc.10.17129409589+6.g3aae11b", "0.1.1-alpha.0.17129409578+10.g3aae11c"),
        Arguments.of("0.1.1-rc.10.17129409589+6.g3aae11b", "0.1.1-alpha.0.17129409588"),
        Arguments.of("0.1.1-rc.10.17129409589+6.g3aae11b", "0.1.1-rc.1.17129409588+6.g3aae11b"),
        Arguments.of("0.1.1-rc.10.17129409589+6.g3aae11b", "0.1.1-rc.1.17129409588"),
        Arguments.of("0.1.1-rc.10", "0.1.1-rc.9")
      );
    }
  }
}

I don't want to isGreaterThan isLessThan and 2x isNotEqualTo for the reflective test. To be fair I control none of these classes so I assume their comparable implementation is generally not massively broken (although it turns out VersionNumber doesn't compare correctly, arguably correctly, but that's a different bug).

If I understand correctly, you're looking for a way to verify the correctness of a Comparable implementation, similar to what EqualsVerifier does with the equals/hashCode.
Usually, AssertJ doesn't have such responsibilities behind a single assertion method. Plus, I'd consider that users might end up with fancy combinations due to usingComparator.
I was curious to see what the ecosystem offers today and I found jqno/equalsverifier#129 – I guess the world is small after all 🙂
What you're asking would impact all the ComparableAssert methods, if we did it consistently. I'm not yet convinced that we should have such an aggressive change.
@joel-costigliola thoughts?

The big difference between the two of course is that equalsverifier actually creates the object and fills in all the fields and such.  I'm just talking about comparing existing instances.

Oh, another thought I had. I'm not testing my own implementation of equals like I would use equalsverifier for. What I'm really doing here It is asserting that the versions I'm generating actually have the precedence that I think they do. Turns out nothing about how these particular classes are interpreting these are how I thought they interpret these.

My concern if we go that way is that the assertion error could be confusing on the additional hidden assertion because you are switching actual and expected.
With parameterized tests, you can achieve your goal with minimal effort IMHO so overall I'm not convinced of the value of such an evolution.


Add pod support

New in Marathon 1.4.0: https://github.com/mesosphere/marathon/blob/master/changelog.md#changes-from-1310-to-140
This adds support to query pods. Testing done on a Marathon deployment with version 1.4.2.
Addresses issue https://github.com/gambol99/go-marathon/issues/271

Hmm that TestMarkDown appears to have a race condition as the cluster.markDown function starts a goroutine.

Pod support in go-marathon, fantastic! :tada:
This PR is fairly big, so I'll need some time to work through everything.
On a first glance, it looks like traditional applications and pods share a number of APIs. Can we consider extracting a common interface to possibly share or at least minimize the amount of (now duplicated) code?

The test failure is likely a flake that #296 should address. I'll try to kick Travis again.

Thanks for looking @timoreimann!
Because of the pod and application spec differences, most of the code which appears to be duplicated is difficult to de-dup. I'm happy to take recommendations though!
In terms of interfaces, we could create some sort of Service interface that encompasses Pods and Applications; you'd retrieve one with the current marathon client but could then perform actions using that object itself, e.g. s := client.GetPod("foo"); s.Scale(5). I like the idea of performing actions on a Service object as opposed to a single mega client, but otherwise the interface itself feels a little low value to me, particularly as I don't see more "Service" types being created in Marathon.

@dfturn in general, I'd be okay with having only two implementations of the Service for the foreseeable future if it helps us to cut down on the amount of code we'd have to manage. I'd probably have to reserve some time to better see if clever usage of interfaces could help with  significantly dropping the code volume this PR brings -- maybe you already have a better feel for how much of a gain that would be?
There are also other alternatives we can consider; like generating, or loosening type safety and go with more interface{}s. They are definitely not my first-picks, however. I'd just like us to consider all reasonable options prior to committing to adding 2k LOC for pod support.
Maybe @gambol99 and/or @marco-jantke may want to chime in with ideas on how to handle the new code best.
Thanks again for making the motion to bringing in pod support. 👏  Looking forward to the merge already. 😃

@timoreimann @gambol99 @marco-jantke
Hi guys, just pinging for some feedback on this PR. I know it's pretty large but I'd love to get this in!

@dfturn I'd like to explore the idea of introducing an interface (as we discussed before) to reduce the amount of duplicated code. Do you think you could give it enough of a try just to see if the approach pays off?

I did a little exploration in commit a26c160 but didn't really like how it felt, and I don't think it will reduce any of the duplication for the reasons I described before. To make it work we have to sneakily embed the marathon client in the Service instance in Get and Create calls, and only then can we do direct calls with the Service object with the hidden client. But it's tricky because it won't be transparent to the user, since if they tried to create a new pod in code then call Create on it, it wouldn't work without the embedded client being initialized. So the workflow is odd; some calls you have to do with the client and some with the Service object.
client := marathon.NewClient()
pod := client.GetPod("pod_id")
pod.Scale(5)

podNew := NewPod().Name("second_pod_id") // do some other things to actually create it
client.CreatePod(podNew)

Sorry for the very late response..
I agree with @dfturn that the interface would be rather awkward to use through the introduction of a Service interface. I also checked whether we could internally leverage some code reuse, but this seems hard as well through the API differences mentioned above. Have a look at the following examples:
func (r *marathonClient) GetPodByVersion(name, version string) (*Pod, error) {
	uri := fmt.Sprintf("%s/%s", buildPodVersionURI(name), version)
	result := new(Pod)
	if err := r.apiGet(uri, nil, result); err != nil {
		return nil, err
	}

	return result, nil
}
....
func (r *marathonClient) ApplicationByVersion(name, version string) (*Application, error) {
	app := new(Application)

	path := fmt.Sprintf("%s/versions/%s", buildPath(name), version)
	if err := r.apiGet(path, nil, app); err != nil {
		return nil, err
	}

	return app, nil
}

AFAICS there is no abstraction that we could derive from these samples without losing their context. I could only think about a signature like this: UnitByVersion(path string, result interface{}) (interface{}, error) which would make it even more difficult for the clients.
Long story short, I don't see a useful to reuse a lot of code.

Appreciate you chiming in @marco-jantke. Could I get some eyes on the specifics of the PR so we can move toward merging it?

@dfturn sorry for the awfully long delay, been running short on bandwidth lately.
I'll make sure this PR gets back on my radar and try to review it some time next week.

Hi @timoreimann, any chance we can get a review going on this PR?

hey there @dfturn. Sorry I couldn't keep up with my promise to review soon. :( I have actually already started the review but I'm yet to finish. Hopefully I can get this done soon.

I appreciate all of the feedback! I'll start going through it.
For your overall comments:

omitempty: I'll make a thorough pass.
convenience methods: when I originally created this fork, I was using the pod structures without any convenience methods. I can definitely say it feels a lot cleaner to interact with the library while using them. But as an owner on the repo, if you have preferences there, I can trim them down.

Prior to removing the convenience methods, could you please first add a Pod usage example to the examples folder? That might give a clearer picture of their value.

Sorry for the lack of attention. Github actually doesn't always send out notifications when commits are just pushed. It's usually helpful to me to leave an extra comment, also to know that a PR is ready for review again.
I suppose I can have another look, right?

Hey @timoreimann, apologies, that commit is actually unrelated to this PR. I've gotten distracted myself and need to give this PR some attention. I'll address your feedback this weekend and let you know when it's ready for another look.

@dfturn no worries, appreciate the heads up.
Looking forward to wrapping things up soon.

@timoreimann I've pushed another commit which should handle your feedback. I'm not sure how to fix the test failures in Travis, since it seems to be overriding my import of the dfturn fork in the pod example to get my changes pulled in.
Per your request for an example of the convenience methods, I've added that into the examples/pods directory. As a user, using the methods feels much cleaner to me than interacting with raw structs.
Regarding the secrets implementation in #299, I see no way to use that marshaling logic without copy/pasting and updating for pods. And I don't think that it buys the end user much. While we do have an interface{}, those convenience methods described above should abstract that away from the user. For instance, to add a secret to a pod, you are doing the following, and never interact with the raw interface:
pod := marathon.NewPod()
pod.AddFullSecret("secret0", "APP_ENVIRONMENT_VARIABLE", "APP_SECRET_KEY")

Thanks again for all of the feedback and helping me improve this PR!

Any news on this? I'd like to use the pod functionality for https://github.com/virtual-kubelet/virtual-kubelet/issues/15 Thanks!

@timoreimann I'd appreciate another pass on this PR when you've got a chance.

@timoreimann made another pass, Replied to a couple of the threads as well, specifically about secrets and pointerized fields.

The secrets and the general question on whether we should keep those convenience methods or not is all that's left at this point. And even though we haven't crossed the finishing line yet: @dfturn, great work -- thanks a ton for all the work you've invested. 👏

@gambol99 do you have time to comment on the question of whether we should introduce convenience methods for basically all new Pod-related fields or just those that are managed by pointers? It's basically a trade-off between (fullI) convenience and code we need to maintain.
I noted down my initial concern in this comment with @dfturn's response to prefer keeping all convenience methods living here. The difference in convenience can be observed in the example file. I can't tell for certain how many LOCs we'd be able to drop with all "unnecessary" convenience methods gone, but I guess it'd be quite a few hundreds taking both code and test and account.

One more thing: Please extend .gitignore by examples/pods/pods.


HTTP-Server-in-Python3-By-Prajjwal-Datir

Implemented RFC of HTTP using SOCKET programming in python3
Fixes #(172)
#172
Have you read the Contributing Guidelines on Pull Requests?

[x] Yes
[ ] No

@all-contributors please add @PrajjwalDatir  for code and documentation

@all-contributors please add @PrajjwalDatir  for code and documentation


Custom image to run ./install.sh

Connects the "Open in Cloud Shell" button directly to the new custom image which automatically runs the ./install.sh script.
Still TODO: move the custom image out of my temporary project ("natural-night" alias issued by GCP), and into an official Stackdriver Sandbox project.

It looks like the CI is failing because you need to add a license header to your Dockerfile. You can either copy it from another file, or use this tool to add them automatically: https://github.com/google/addlicense


AppCompat does not support Theme.Swipe.Back features

When creating an activity using the SwipeBack theme, the aplication crashes with the following error:
java.lang.IllegalArgumentException: AppCompat does not support the current theme features: { windowActionBar: false, windowActionBarOverlay: false, android:windowIsFloating: false, windowActionModeOverlay: false, windowNoTitle: false
Presumably, as a result, swiping back does not show the activity behind it but instead fades it in after the animation completes.

Update your style to this


feat: update to angular 14 with some minor changes

Update to Angular 14
Style changes: remove underscore for private variables,  set up simple-import-sort plugin
Repace subscription.add() with takeUntil(destroy$)
Refactor usage of some RxJS operators
Improve folder structure

Codecov Report

Merging #173 (9132e62) into master (ba36fd3) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #173   +/-   ##
=======================================
  Coverage   99.51%   99.52%
=======================================
  Files          13       14    +1
  Lines         616      625    +9
  Branches       89       83    -6
=======================================
+ Hits          613      622    +9
  Misses          3        3

Impacted Files
Coverage Δ

...-yandex-maps/src/lib/angular-yandex-maps.module.ts
100.00% <100.00%> (ø)

.../components/ya-clusterer/ya-clusterer.component.ts
97.50% <100.00%> (-0.04%)
:arrow_down:

.../lib/components/ya-control/ya-control.directive.ts
100.00% <100.00%> (ø)

.../components/ya-geoobject/ya-geoobject.directive.ts
100.00% <100.00%> (ø)

...maps/src/lib/components/ya-map/ya-map.component.ts
100.00% <100.00%> (ø)

...omponents/ya-multiroute/ya-multiroute.directive.ts
100.00% <100.00%> (ø)

...s/ya-object-manager/ya-object-manager.directive.ts
100.00% <100.00%> (ø)

...ib/components/ya-panorama/ya-panorama.directive.ts
100.00% <100.00%> (ø)

.../components/ya-placemark/ya-placemark.directive.ts
100.00% <100.00%> (ø)

...yandex-maps/src/lib/event-manager/event-manager.ts
97.50% <100.00%> (ø)

... and 3 more

Continue to review full report at Codecov.

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


Affecting my project style.

How can I avoid the CSS CDN in this project is affecting my site style.

I have the same problem, the library add some styles to project, that styles issue my app.

Same problem ! Did you find a solution?

+1 For not wanting to load in bootstrap and font awesome.
Hopping #27 will be merged eventually

@bollerdominik Sorry for the long wait, but the spaghetti of code used for the component is too messy for me to fix in one small PR. The code has lots of troublesome issues, including:

Hardcoded styles (ugh)
Unfinished tests

Tests using the wrong APIs altogether! (for e.g. using e2e-related infrastructure in component tests)

Unfinished CI (continuous integration) system (currently only builds the project, nothing else)

And some other minor issues that need major refactoring, which require way more time than necessary to fix.
In the meantime, the only other thing you could do at the moment would be to create your own component or rely on another library altogether.
P.S. I've submitted an issue to the Angular Components repository regarding an audio player (at angular/components#17513) but has been closed and locked (which was automatically done by their new infrastructure - a GitHub Action workflow - which automatically locks issues/PRs that are stale) as they "don't have any plans to build any kind of audio/video components".
Hope this helps!

Fixed in https://www.npmjs.com/package/ngx-audio-player/v/10.1.0


Helm3: No 'init', doesn't use existing ~/.helm

./helm version version.BuildInfo{Version:"v3.0.0-beta.1", GitCommit:"f76b5f21adb53a85de8925f4a9d4f9bd99f185b5", GitTreeState:"clean", GoVersion:"go1.12.9"}
I've upgraded from helm v2 by downloading the beta v3 client.
I've deleted the tiller account with the v2 client.
No helm commands using v3 seem to work -- it knows nothing about repositories.
If I supply them on command line, it still doesn't DTRT:
➜  helm-darwin-amd64 ./helm --repository-cache ~/.helm/repository/cache --repository-config ~/.helm/repository/repositories.yaml repo update
Error: couldn't load repositories file (): open : no such file or directory

But it clearly can read the config therein:
➜  helm-darwin-amd64 ./helm --repository-cache ~/.helm/repository/cache --repository-config ~/.helm/repository/repositories.yaml repo list
NAME  	URL
stable	https://kubernetes-charts.storage.googleapis.com
local 	http://<IP_ADDRESS>:8879/charts
gitlab	https://charts.gitlab.io/

But installing any chart fails:
➜  helm-darwin-amd64 ./helm --repository-cache ~/.helm/repository/cache --repository-config ~/.helm/repository/repositories.yaml install stable/kong --set ingressController.enabled=true -g
Error: failed to download "stable/kong" (hint: running `helm repo update` may help)
[1]    66253 exit 1     ./helm --repository-cache ~/.helm/repository/cache --repository-config

Why not add a virtual subcommand helm init like in v2, which either reconfigures helm based on v2 config, or explains properly how to modify the existing config? This is really not obvious. The docs on the v3.helm.sh/docs all refer to v2 and talk about helm init and so on. If the docs are this unready then it's not in Beta, surely? This is just silly.
Can you please point out the docs that explain how to upgrade to v3 without losing all functionality? Surely they exist?

@joelbernstein It looks like you might be using beta.1. There was some issues with this release and are fixed in beta.2.  Can you try using that instead and see if it works as expected? FYI, default repos like stable are no longer set-up OOTB.
The upgrade/migration path is still WIP: https://github.com/helm/helm/issues/5892

@hickeyma thanks for getting back to me. You're right, it looks like I'm using beta.1 which I guess was linked off some docs. I'll try with beta.2 and comment back.
Re upgrade/migration, i think that's to do with differences in user-supplied chart syntax? Whereas I'm just trying to use helmv3 to deploy some packaged code (e.g. Kong proxy) to my kubernetes cluster without needing RBAC and a Tiller namespace and so on. Is this a reasonable expectation on my part?

@hickeyma that worked! Thanks
➜  helm-darwin-amd64 ./helm repo update
Error: no repositories found. You must add one before updating
[1]    66403 exit 1     ./helm repo update
➜  helm-darwin-amd64 ./helm --repository-cache ~/.helm/repository/cache --repository-config ~/.helm/repository/repositories.yaml repo update
Hang tight while we grab the latest from your chart repositories...
...Unable to get an update from the "local" chart repository (http://<IP_ADDRESS>:8879/charts):
	Get http://<IP_ADDRESS>:8879/charts/index.yaml: dial tcp <IP_ADDRESS>:8879: connect: connection refused
...Successfully got an update from the "gitlab" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈```

@joelbernstein The migration is for using any configuration and releases from Helm v2. If you just want to use the cluster you can use Helm v3 side-by-side with Helm v2 without removing Tiller etc. More details about use cases: https://github.com/helm/helm/pull/5582

@hickeyma by "releases", do you mean "any charts created and published with helm v2"?
I've just - experimentally - used helmv3b2 to deploy stable/kong and it seems to have worked fine.

by "releases", do you mean "any charts created and published with helm v2"?

Yes
You should be good to go then.

Closing @joelbernstein. If you find any other issues, just raise an issue for that.

I'm also using the helm v3.0.0-beta2 client, but from a completely fresh state (no ~/.helm directory).  How do I add the correct repositories without the helm init command?

Found this in another issue:
helm repo add stable https://kubernetes-charts.storage.googleapis.com

Closing @joelbernstein. If you find any other issues, just raise an issue for that.

Thanks, hope this comment doesn't reopen the issue (!) just wanted to say that I really approve of the design changes in helmv3 and I'm sorry if this issue wasted your time.

FWIW one of the docs linked to v3beta1 but I can't recall which one. If I find it I'll send a PR to fix it.

@tammersaleh Docs have good info also, like: https://helm.sh/docs/using_helm/#helm-repo-working-with-repositories

@tammersaleh check out my blog post https://rimusz.net/helm_v3_beta on how to use helm v3 and changes it introduced

Thanks @hickeyma - The docs do list which url each repo points to, but doesn't quite explain what @rimusz' post does: that init was removed, and exactly how to add stable on a fresh helm3 installation.

The reason why the documentation doesn't explain how to add back the stable repository is because the charts team are planning to deprecate that repository. The cloud bucket hosting that chart repository will eventually be shut down and will no longer host charts.
Even though Helm is designed to work with numerous distributed repositories, the stable repository has given the impression or feel of a "central" repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of growth in the community.
This is where Helm Hub comes in. We want to encourage people to host their own chart repositories and share them in a more discoverable place. The charts team is working on that migration plan, and we will have more information to share once that is ready.
RE: the docs not explaining this, thanks for pointing that out. It's on our roadmap to update the documentation prior to the 3.0 final release. We've been focusing on bug squashing, but once Helm Summit is finished, we should have breathing room to update the documentation
Anyways, this is starting to get off topic from OP's discussion. Feel free to ask these questions on Slack if you have further questions about that decision. Thanks!

Thanks @bacongobbler, that explanation is very helpful!  Sorry if I came off as unhappy with the docs situation - I'm using a beta pre-release, so I completely understand the lack of docs.

we still should properly document the stable remove removal and how to use it in the mean time till it gets shut down, as right now not documenting its removal properly I see it makes a big confusion that helm v3 beta is not working

RE: the docs not explaining this, thanks for pointing that out. It's on our roadmap to update the documentation prior to the 3.0 final release. We've been focusing on bug squashing, but once Helm Summit is finished, we should have breathing room to update the documentation

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Sorry for being noob . But isn't this supposed to be included by default OR isn't it supposed to be documented ? Is it my fault that I did not find this anywhere in documentation OR is it not there at all ?

https://helm.sh/docs/intro/quickstart/#initialize-a-helm-chart-repository


[REQUEST] Make NPCs open two doors at a time

Is your feature request related to a problem? Please describe.
My villagers only open 1 door out of two
Describe the solution you'd like
Make NPCs (e.g. villagers) open/close both doors instead of just one
This would be a nice little addition to the mod

Implemented as of mod version 2.1.9 of Dramatic Doors for Forge on 1.19.2. I will look to backport the changes to 1.18.2.


Music Bot Won't run because wasn't installed using Git

     idk what to do to get it running again

The bot wasn’t installed using Git. As in, you haven’t properly installed it using the guides on our wiki. Use https://github.com/Just-Some-Bots/MusicBot/wiki.


Correcting Chrome dependency size

Whenever I install puppeteer I get a node_modules/puppeteers folder that is 282Mb (instead of the advertised ~90Mb).

Signed the CLA...

FWIW, .local-chromium folder is 280 MB on Windows 7 x64.

I wonder where the Readme values come from in that case... I have tried to install different versions but never came close to the ~90Mb


Confusion around applicability tests in yaml recipes

Our current documentation around yaml applicability tests might contain slight imperfections that lead to confusion in an issue and pull request last week:

should anySource match when any or all of the argument recipes match any file?
https://github.com/openrewrite/rewrite-testing-frameworks/pull/320

should FindSourceFiles be used to limit applicability to specific files, or should one use HasSourcePath instead?
https://github.com/openrewrite/rewrite/issues/2919

Should be good to clear these up, as they lead to questions and debugging currently.

@timtebeek, the way that this was explained to me was that it is logical AND all around.
So to be explicit:
applicability:
  anySource:
    - com.example.A
    - com.example.B

The above only applies if both are true. If one of them is false, then the recipe does not apply. This works the same for single source and a combination of single source and any source.

I'm going to close this ticket as I think this no longer applies. YAML recipes no longer work with applicability tests. If I've misunderstood please let me know and feel free to reopen.


🐛 Bug Report: Disabling "register component" button doesn't work anymore

📜 Description
Following the documentation. I added this setting to my config file:
app:
  routes:
    bindings:
      scaffolder.registerComponent: false

This used to work, and the register existing component button disappeared but not anymore.

👍 Expected behavior
The register existing component button should disappear.
👎 Actual Behavior with Screenshots

👟 Reproduction steps
Add this to your app-config file
app:
  routes:
    bindings:
      scaffolder.registerComponent: false

And build the project locally.
📃 Provide the context for the Bug.
No response
🖥 Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, but I'm happy to collaborate on a PR with someone else

Duplicate of #27337

Hello @GersonTrj, I'm closing this question because it's a duplicate with https://github.com/backstage/backstage/issues/27337.

Hello @GersonTrj, I'm closing this issue because it's a duplicate with #27337.

thank you so much @camilaibs


webkitgtk: drop wayland dependency on Darwin

Motivation for this change
I'm trying to build webkitgtk on Darwin, but it requires wayland, which is no need nor available on Darwin. So we may drop the dependency.
Things done
Make wayland required in nativeBuildInputs only on Linux.
@matthewbauer Would you please review this? I'm a newbee on Nix and not sure if it is right on this. Thanks.

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs 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/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Great, thanks.


Fix 97

Overview
This PR fixes #97
Changes:

Added a GeoJSON representation for a shape.

Related Issue / Discussion
Additional Information
Links to other issues or sources.

@huard feel free to review this PR. All done here.


[MRG] Replace coveralls by codecov

seems better than coveralls @nippoo ...

ready to merge @nippoo

ready to merge


Make address entry optional

[ ] Use the drawings' coordinates to select weather data
[ ] Use the reverse endpoint from the BAN API to get the city name and water prices

May be we could also use geolocalisation


Add js primitive encodeURIComponent to globals.

As suggested here.

Thanks! Could you please add the others as well though?

encodeURI
decodeURI
decodeURIComponent

Done.  (I feel I should also update /docs, but I'm not sure how.  I'll look into it.)

Sorry, I didn't mean to close this, I think I hit the wrong button by mistake. I'll merge the other PR.


Update Zstandard to v1.4.5

zstd 1.4.5 was released today. It boasts some speed improvements which would be nice to have at some point in the near future.

Looks like it has been added now in https://github.com/gyscos/zstd-rs/commit/0be78635723e9fe2dce6556455309ab240956925

Awesome! Closing.


Username/password credential support for OPC Twin?

Is your feature request related to a problem? Please describe.
We're trying to leverage the OPC Twin Edge Module to write values to OPC UA servers. We don't want to deploy the entire IIOT solution, instead, we want to use the edge module in combination with our own platform. The servers in question use username/password security. I can't find any documentation about the support of this scenario. Is this supported?
Describe the solution you'd like
I want to use the write (and possibly read) functionality of the OPC Twin to endpoints that support username/password credentials.
Describe alternatives you've considered
For publishing values, we currently use OPC Publisher, it supports username/password validation.

I have the same question, does opc twin not check pn.json or acquire this from publisher?.
How to support this? Also, if certificates are used?

Hi,
I have the same question as MatthijsvdVeer, and hope someone can give a quick reply regarding this issue.

is it possible to use "Username/Password" as authentication method for the twin module, or is the only supported method "Anonymous"? And if possible, how?
We are using the entire Industrial-IoT platform. Can username/passsword authentication method be specified through REST microservice?

Hi again,
this can be solved by using a json body like in the following example.
/twin/v2/write/{endpointId}
{    "nodeId":"nsu=mynamespace;s=mynode",    "value":15.7,    "header":{       "elevation":{          "type":"UserName",          "value":{             "user":"myuauser",             "password":"myuapassword"          }       }    } }

Thanks @mwiot for providing the information.
Closing it for now.


CUDA Out of Memory

Dear authors,
When I run python test.py, there is an error: Cuda out of memory. Could I use multiple GPUs to run this command?

Hi @AmingWu,
You can, but the test.py is only used to verify that the deformable attention is compiled correctly. It basically tests the performance of transformers with varying numbers of tokens (N).
As long as the tests for the number of tokens (N) were OK, then this will not affect the rest of your results at all and I really wouldn't bother trying to run this on multiple GPUs.
Best,
Orr


[barker29/cg-converged-bugfix] add checks for indefinite preconditioner in CGSolver

Current if CGSolver has an indefinite preconditioner, it may get a negative (Br, r) inner product, compare that to desired tolerance, and conclude that the iteration has converged. This PR adds a check to catch that and correctly report GetConverged() == 0.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#1391
@barker29
@tzanio
@delyank + @dylan-copeland
04/01/20
⌛due 04/15/20
⌛due 04/22/20

Does linalg/test_cg_indefinite.cpp need to be added to tests/unit/CMakeLists.txt?

LGTM

Merged in next for testing...