Authorization - Add roleassignmentmetrics calls and fix correctness issues

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[x] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[x] No, no need to refresh for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[x] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[x] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[x] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[x] Updating API in stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

Please go through the contribution checklist added as part of the review and mark them completed. This is a requirement before review can be continued.

Please go through the contribution checklist added as part of the review and mark them completed. This is a requirement before review can be continued.

@chiragg4u Thank you, fixed

There are breaking changes in the PR that has to go through the breaking changes review. Please find more information on the process here: https://dev.azure.com/msazure/AzureWiki/_wiki/wikis/AzureWiki.wiki/37684/Breaking-Changes

There are breaking changes in the PR that has to go through the breaking changes review. Please find more information on the process here: https://dev.azure.com/msazure/AzureWiki/_wiki/wikis/AzureWiki.wiki/37684/Breaking-Changes

This PR was opened during the window to fix broken for KPIs and its purpose is to fix s360 issues, would this still apply?

There are breaking changes in the PR that has to go through the breaking changes review. Please find more information on the process here: https://dev.azure.com/msazure/AzureWiki/_wiki/wikis/AzureWiki.wiki/37684/Breaking-Changes

This PR was opened during the window to fix broken for KPIs and its purpose is to fix s360 issues, would this still apply?

It makes sense to me however you need to bring it up with API Breaking Changes person who is reviewing this PR.

It makes sense to me however you need to bring it up with API Breaking Changes person who is reviewing this PR.

@filizt will do, thanks! do we need anything else for ARM sign-off prior to then?


chore: setup starlight-typedoc

This is currently broken due to https://github.com/HiDeoo/starlight-typedoc/issues/23
To run example:

Clone repo
Checkout this branch (boneskull/starlight-typedoc)
Run npm install
Run npm run dev:docs

This should fail without any obvious error; this is because of the check for groups in starlight-typedoc.
You can also run npm exec typedoc from the workspace root to see that the problem is unique to starlight-typedoc.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

main

PR #504

PR #499

PR #500

PR #501

PR #502

PR #503

PR #402

PR #533   👈
PR #403

This stack of pull requests is managed by Graphite.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

main

PR #504

PR #499

PR #500

PR #501

PR #502

PR #503

PR #402

PR #533   👈
PR #403

This stack of pull requests is managed by Graphite.


Pyarrow not adding partition columns when given a glob path

I am saving a dask dataframe to parquet with two partition columns using the pyarrow engine. The problem arises in scanning the partition columns. When I scan using the directory path, I get the partition columns in the output dataframe, whereas if I scan using the glob path, I dont get these columns
pyarrow : 0.9.0.post1
dask : 0.17.1
import dask.dataframe as dd

size = 20
tmpdir = '/tmp/test/outputParquet1'
engine = 'pyarrow'

d = {'signal1': np.random.normal(0, 0.3, size=size).cumsum() + 50,
       'fake_categorical1': np.random.choice(['A', 'B', 'C'], size=size),
       'fake_categorical2': np.random.choice(['D', 'E', 'F'], size=size)}

df = dd.from_pandas(pd.DataFrame(d), 2)
df.to_parquet(tmpdir, compression='snappy', write_index=True, engine=engine,
          partition_on=['fake_categorical1', 'fake_categorical2'])

#This doesnt scans the partitioned columns
df_partitioned = dd.read_parquet(tmpdir + '/*/*/*.parquet', engine=engine)

#this fails
#df_partitioned[df_partitioned.fake_categorical1 == 'A'].compute()

#This scans the partitioned columns
df_partitioned = dd.read_parquet(tmpdir, engine=engine)

df_partitioned[df_partitioned.fake_categorical1 == 'A'].compute()

Fastparquet supports the glob path, but somehow pyarrow doesn't
The problem lies in the _make_manifest function. For a single path, it calls the _visit_level fuction which successfully updates the partitions. For a glob path it doesnt call _visit_level fuction, it just creates a list of ParquetDatasetPiece objects with no partitions

The file in question(_make_manifest())
https://github.com/apache/arrow/blob/master/python/pyarrow/parquet.py

@pranav-kohli could you create a JIRA with this feature request? A patch would be welcome

Created the jira
https://issues.apache.org/jira/browse/ARROW-2728

Thanks!


Macro: #3495 - Is not possible to add RNA presets into the Favourite library

How the feature works? / How did you fix the issue?
(Screenshots, videos, or GIFs, if applicable)

Check list

[x] unit-tests written
[x] e2e-tests written
[ ] documentation updated
[x] PR name follows the pattern #1234 – issue name
[x] branch name doesn't contain '#'
[x] PR is linked with the issue
[x] base branch (master or release/xx) is correct
[x] task status changed to "Code review"
[x] reviewers are notified about the pull request

Tested:


No emoji support?

Needs various options to allow for thumbs up.down or happy.sad face or similar cultural emojis to visually signal success (or failure).
Alternate audio support would also be welcome.

What do you think this is, cat? Let's not add the kitchen sink in.

If emoji is added I'm switching to libalttrue

Is it time to start lib🐈?

I'm not sure lib🐈? is a good choice, might have some trouble on ascii terminals

Typical, issue descended into a bikeshed

EMISSINGBIKESHEDEMOJI

We need this as emoji: https://camo.githubusercontent.com/956360d829b049085b77cd8dcdb25c4e1288622f/68747470733a2f2f7261776769742e636f6d2f74616261746b696e732f62696b65736865642f6d61737465722f646f63732f69636f6e2e737667


chore(main): release 1.1.2

:robot: I have created a release beep boop
1.1.2 (2024-01-09)
Bug Fixes

ensure the role parameters are linked to their keyword rule (#18) (d4bb1a4)
fix empty required roles not triggered bug (#15) (4f8175b)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/rickstaa/warnings-discord-bot/releases/tag/v1.1.2 :sunflower:


Fix for wrong example files being generated.

Fixes #1066

The failure is caused by a missing dependency tempy.  I will fix that next, but it's not part of this PR.
Also self-merging.


Performance regression

We are considering using cannon-es in three.js but seems like there's a performance regression.
@Mugen87 converted cannon.js to modules and here's the running example:
https://raw.githack.com/mrdoob/three.js/dev/examples/physics_cannon_instancing.html

This is the same example using cannon-es:
https://raw.githack.com/Mugen87/three.js/dev45/examples/physics_cannon_instancing.html

https://github.com/mrdoob/three.js/pull/19709

Thanks for the issue and the usage example.
This also looks related to #16. I'll look into it soon!

I only had a moment to look at this as I'm headed to bed but I definitely agree it looks related to #16 and #18

Mugen's cannon-es code is here and the original cannon.js version here

maybe i am wrong here but the last para should be not the frameRate
https://github.com/mrdoob/three.js/blob/dev/examples/jsm/physics/CannonPhysics.js#L193
more a value of 10 for maxSubSteps

Hello friends, I've discovered the issue.
Basically there are tons or commit which are in the cannon.js repo but haven't been published to npm or built into the bundle. Here is the full list.
When we built the source files again in cannon-es, we inherited automatically all those commits.
Between these commits there is 86b0444, where schteppe implemented the fixed timestepping from the last snippet of this famouse article, however it was left unfinished or was not tested properly, leading to the framerate issues.
I've tried to fix those issues in #40, if you guys @mrdoob and @Mugen87 could test with the cannon-es bundle from that branch that would be grand 🙏
Also @codynova issue #16 should be fixed as well, could you do a test? 🙏
@arpu is right, the third parameter is used to tell how many maximum internal steps the step() function can take if there is too much lag. If you set it to 1, it doesn't take any internal steps, but the simulation is technically slower. If you set it to an high number, it takes as many steps as needed to make the interaction have a fixed timestep, however if the step is expensive (a lot of boxes), taking too many steps can cause lag by itself.

@marcofugaro The performance seems better with your changes. However I have more than 400 cubes in the scene, the performance gets drops significantly to an unusable framerate. This does not happen with the original cannon.js version.

@Mugen87 Oddly enough, that's a feature.
Please read the description of #40, it's the whole idea behind this article
If you want the behaviour of the previous cannon.js, you can call world.step(frameTime) without any other arguments. The simulation with 400 boxes will run "in slow motion" but at a stable framerate.
However now that you mention it, it makes sense to have the threshold at at least 30fps, not 10.

@Mugen87 do you have time to test again? 🙏
It shouldn't go below 30fps, rather it will slow down a bit.

Performance seems better now. Mostly around 25-27 FPS when having 400 cubes in physics_cannon_instancing.
However, the performance of cannon-es is still worse than the original cannon.js. With the same settings (400 cubes in physics_cannon_instancing) I get almost around 52 FPS.

Alright, that is working as intended! 🎉
The simulation now has more time to catch up than before, this works in favor of people using cannon.js in a web worker.
Users can still get the previous cannon.js behaviour (~60fps) by passing 1 to the third argument of the step() function (suggested when there are a lot of bodies to simulate).
world.step(frameTime, delta, 1)

Thanks for testing again!

So THREE.CannonPhysics needs an change in the following place to restore the "old" behavior?
https://github.com/mrdoob/three.js/blob/3ca144cac1c81ada7496e2f4790877848c6b4aa9/examples/jsm/physics/CannonPhysics.js#L193

Yup, currently in that line, the third parameter frameRate is wrong, as it's not related to the framerate at all.
It should be called 'maxSubSteps` and should be set to a value of 1 or a really small integer in your case.
It was like this also in the original cannon.js.

A new version of cannon-es has been released with Marco's fixes for variable framerate simulation<EMAIL_ADDRESS>


"Save and run" runs the old function

Probably due to race condition, I'm seeing it run the previous state rather than the newly saved.

I added a 200 msec delay

Tried 10 times. Reliable!


python311Packages.django-model-utils: 4.2.0 -> 4.3.1

Diff: https://github.com/jazzband/django-model-utils/compare/4.2.0...4.3.1
Changelog: https://github.com/jazzband/django-model-utils/blob/4.3.1/CHANGES.rst
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 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

[ ] Fits CONTRIBUTING.md.

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

4 packages built:

python310Packages.django-model-utils
python310Packages.django-model-utils.dist
python311Packages.django-model-utils
python311Packages.django-model-utils.dist


Some  use "href" attribute instead of "link"

The first time the <Link> component is introduced in the tutorial in the Use the  component they're properly using the link attribute

        <Link link="/">Home</Link>

        <Link link="/page/2">More posts</Link>

        <Link link="/about-us">About Us</Link>

But from the Styled components there are some links that use the href attribute that makes these links fail

    <Link href="/">Home</Link>
    <Link href="/page/2">More posts</Link>
    <Link link="/about-us">About Us</Link>

Fixed.

Fixed.


[bug] <WagmiProvider /> is deprecated

Is there an existing issue for this?

[X] I have searched the existing issues

RainbowKit Version
0.1.1
wagmi Version
0.4.0
Current Behavior
Many sections across the docs recommend using the WagmiProvider within Rainbow Kit usage.
Currently, it behaves correctly, but it was just deprecated and suggested to use WagmiConfig instead.
This is the deprecation notice
Expected Behavior
The deprecation warning should not appear
Steps To Reproduce
Follow installation steps here, and you'll get the deprecation notice if you're using Typescript
Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
https://github.com/tmm/wagmi/commit/1928685bad22e00e9440739a3f65d8a9901716a4#diff-1cee8646d2cfba37d6ce6a6e9a8d16f8caba0b99fc3a1ad0cb997ed8c7384d2eR4
Anything else?
No response

Will be resolved in #412.


(fix) - don't execute non function events and debug them

Fixes: https://github.com/developit/preact/issues/1350
debug: +67B
preact: +1B
This adds a props check to debug that throws an error when a prop starting with "on" is no function. In all honesty the other change in preact actually prevents this behavior, but yes... Didn't know what one was most desired.

Coverage remained the same at 100.0% when pulling 44bb4abf96d61fafce5f6768f5337b941632aaf5 on JoviDeCroock:fix/dont-execute-non-function-events into ce1411bfff3a50c46976c2447e027019c5b544bd on developit:master.


Timesheet - 04/05/2021- Manish Ram

Task 1: Timesheets

Reviewed timesheets

Proof of Work

Commented "Approved" for approved timesheets or left other comments to ask for additional Infos to timesheet issues dated 03/04/2021
https://github.com/thenewboston-developers/Contributor-Payments/issues

Time Spent
0.5 hour

Task 2 : Payments
Audit contributor payments 01/04/2021 and 02/05/2021[After Payment]

Checked sent payment amounts were equal to worked hours x hourly rate.
Checked payments made to the correct account.
Checked payments were not missed.
Closed paid sheets.
Updated Github board

Payment sheet review 02/05/2021 [Before Payment]

https://docs.google.com/spreadsheets/d/1qUNgxkBUOzBwycQuhBF8cPcXAvPrXXaEkgAXuWNAlCQ/edit#gid=0
https://docs.google.com/spreadsheets/d/19j3pizfXQ4Ilwn8X1n_YmfT7vtDoYpAhp5jgywjER-M/edit#gid=0

Time Spent
1.5 hours

Task 2: Timesheet Automation

Design wireframe
Discuss with Bucky on Figma

Proof of Work

https://www.figma.com/file/oCJhaSI1CbfzvYHvaCA4bn/Timesheet?node-id=0%3A1 (4.5 hrs)
Comments on Figma (0.5 hrs)

Time Spent
5 hours

Total Time Spent
7 hours
Account Number
0f92e975101eb96cea80dce430d74efd3172fa229377818d467ded85dcf2ab6c

Approved


After ~1 month, push to iOS Safari stops working

Apologies in advance for convoluted issue that may not be within the scope of your library.
We are finding that push notifications stop being delivered to iOS devices after ~1 month, and the only solution seems to be for the users to re-add the app to their home screen.
Since the dashboard does not show delivery rates for iOS devices, we have no way to know if Pushy considers the messages to be delivered or not. When we fired a message from the test UI in the dashboard, we got a "message sent successfully" toast, but the message was never seen by the test user.
Rather than a fix for the root cause (which I assume to be on the iOS / Safari side of things, given similar reports for FCM-driven push (see e.g. https://github.com/firebase/firebase-js-sdk/issues/8010)), I was hoping to know if there is any more information that you are able to retrieve / see on your side of things, e.g. delivery rates, error codes, or anything else that is not directly surfaced to us.
Note: We are using the fallback FCM solution, could that have any impact?
Sidenote: We are aware of the possibility that iOS stops sending notifications if we do not promptly display them to our users. However, (other than the FCM fallback) we believe that we do always show them promptly and should therefore not have this issue. Our service worker is based on yours with some added/altered domain-specific logic:
// Listen for incoming push notifications
self.addEventListener("push", function (event) {
  // Extract payload as JSON object, default to empty object
  var data = event.data.json() || {};

  // Notification title and body
  var title = data.title || "New message";
  var body = data.message || "";

  // Extract notification image URL
  var image = data.image;

  // Always navigate to chat page if no url is provided
  var fallbackUrl = "https://" + self.location.hostname + "/chat";

  // Notification options
  var options = {
    body: body,
    icon: image,
    data: {
      url: data.url || fallbackUrl,
      // Required for `Pushy.setNotificationListener` to work properly due to https://github.com/pushy/pushy-sdk-web/blob/351734d10785aec599152f5504f95e47be869190/src/lib/pushy.js#L218
      _pushy: true,
    },
  };

  // Support for notification collapsing
  if (data["_pushyCollapseKey"]) options.tag = data["_pushyCollapseKey"];

  // Wait until notification is shown
  event.waitUntil(self.registration.showNotification(title, options));

  // Set app badge count (if supported)
  // For now, we set a 1, not dealing with state at this point
  // Cleared when 'chat' is rendered
  navigator.setAppBadge(1);

  // Send to Pushy notification listener (if webpage is open)
  clients
    .matchAll({ includeUncontrolled: true, type: "window" })
    .then((clients) => {
      // Set pushy notification flag
      data._pushy = true;

      // Send to all open pages
      clients.forEach((client) => {
        client.postMessage(data, [new MessageChannel().port2]);
      });
    });

  // WebExtensions support
  // Dispatch event to current service worker
  serviceWorker.dispatchEvent(new CustomEvent("message", { detail: data }));
});

// Listen for notification click event
self.addEventListener("notificationclick", function (event) {
  // Hide notification
  event.notification.close();

  // Attempt to extract notification URL
  var url = event.notification.data.url;

  // Inspired by example from Mozilla: https://developer.mozilla.org/en-US/docs/Web/API/WindowClient
  const openChatPromise = clients
    .matchAll({
      type: "window",
      includeUncontrolled: true,
    })
    .then((clientList) => {
      // Inspired by: https://stackoverflow.com/a/75247524/4102048
      if (clientList.length === 0) {
        // App not open. Open it for the user
        return clients.openWindow(url).then((windowClient) => {
          // Focus the new window (if it exists)
          return windowClient ? windowClient.focus() : Promise.resolve();
        });
      }

      // Focus the existing app
      const client = clientList[0];
      return client.focus().then((resolvedClient) =>
        // Send a message to the client, asking it to navigate to the given URL
        resolvedClient.postMessage(
          { ...event.notification.data, action: "navigate" },
          [new MessageChannel().port2],
        ),
      );
    });

  // Clarification why `event.waitUntil` is required: https://stackoverflow.com/a/34250261/4102048
  event.waitUntil(openChatPromise);
});

Thankful for any light you could possibly shed on this issue!

Hi @jgarplind,
Thanks for reporting this issue. We'd be glad to assist.
Since your service worker implementation calls event.waitUntil(self.registration.showNotification(title, options)); early on, the issue does not seem to be related to https://github.com/firebase/firebase-js-sdk/issues/8010, which is a result of the Firebase SDK failing to call event.waitUntil(), leading Safari to assume that no visible notification was displayed to the user.
Unfortunately, the Web Push spec has made it impossible to query for the delivery status of push notifications. However, it is possible to track delivery by implementing a fetch() request in your service worker's push event listener, which informs your backend API that the notification was delivered successfully. This also requires implementing a backend API endpoint which handles this request accordingly.
Here is sample code for achieving the same:
self.addEventListener('push', function(event) {
    // Extract payload as JSON object, default to empty object
    var data = event.data.json() || {};

    // Notification title and body
    var title = data.title || "New message";
    var body = data.message || "";

    const showNotificationPromise = self.registration.showNotification(title, {
        body: message
    });

    const deliveryTrackingPromise = fetch('/api/track-delivery?pushId=' + data.pushId);

    const promiseChain = Promise.all([
        showNotificationPromise,
        deliveryTrackingPromise
    ]);

    event.waitUntil(promiseChain);
});

However, if the notification never actually makes it to your end user's device, the delivery tracking code will never run.
If you could please provide us with an affected Pushy device token, we will be glad to investigate further. Feel free to send the token via e-mail to<EMAIL_ADDRESS>As of today, none of your apps' registered devices have been reported as "Unregistered" by the Safari APNs service, and no other Error Logs are being reported in the dashboard for any of your apps, so it seems like the APNs service still accepts the notifications you're sending, however, possibly due to internal APNs logic decisions, the notification does not actually make it to your end user, even though the APNs service returned a 200 OK status code.
As per FCM Fallback Delivery - it is not related to the issue at hand, as FCM Fallback Delivery only affects Android app push notification delivery behavior.

Thanks for being so quick to respond.

However, it is possible to track delivery by implementing a fetch() request in your service worker's push event listener, which informs your backend API that the notification was delivered successfully.

I agree, this is probably a good course of action regardless.

If you could please provide us with an affected Pushy device token, we will be glad to investigate further. Feel free to send the token via e-mail to<EMAIL_ADDRESS>
I've now sent an email with the currently affected token. Will try to update this issue with any insights to help others who are facing similar problems.

Hi @jgarplind,
You're very welcome. Thanks for providing an affected device token.
We've tried to send a test notification to the device, and APNs responded with HTTP status code 201, indicating success. That means APNs has accepted the notification and it has not deemed the device unregistered/expired. We cannot tell, however, whether the notification has made it to the device or not.
The issue is occurring due to either a bug in Safari, iOS, APNs, or internal APNs design logic. It seems the notification does not actually make it to your end user(s), even though the APNs service returned a HTTP 201 OK status code.
Since your service worker is already calling event.waitUntil() on self.registration.showNotification(), it doesn't seem to be caused by an implementation issue with your service worker.
As per @rchan41's updated findings, it seems to be an issue with Safari:
https://github.com/firebase/firebase-js-sdk/issues/8010#issuecomment-2042441221
It is also actively being discussed in multiple threads on Apple's developer forum:
https://forums.developer.apple.com/forums/thread/728796
Most likely, it will be fixed in future versions of iOS/Safari. We greatly apologize for the inconvenience.

Then we have come to similar conclusions.
Thank you very much for offering your expert perspective.

Most likely, it will be fixed in future versions of iOS/Safari.

Hopefully, but I am a bit hesitant to believe in Safari's future in this space after the PWA withdrawal (which has since been reverted, but it still makes it clear that it is not a top priority of Apple's).

We greatly apologize for the inconvenience.

Please don't be. This is not your issue, and you are offering an extremely valuable perspective on this issue.
The path forward for us is probably any mix of the following:

"track delivery by implementing a fetch() request in your service worker's push event listener, which informs your backend API that the notification was delivered successfully." as suggested by you is probably necessary, and good for robustness
Make it extremely easy for users to become aware and to resolve this issue on their own*
Possibly move to other solutions, if we cannot make these notifications reliable

*This got me thinking... so far the solution has been to "re-install" the PWA by removing it from the home screen and adding it again. Do you happen to have any insights and/or educated guesses as to whether this is actually necessary, or if it could be enough to just register a new Pushy token, without reinstalling the app? We will have to test any way, but if you can tell with some degree of confidence that either scenario is more likely, it could help us prioritize.

Hi @jgarplind,
You're very welcome!
We do recommend native push on iOS (via native iOS app) for its robustness. There are no such issues with APNs for native iOS apps.
As per your inquiry - it seems that just re-registering the same PWA (calling Pushy.register() again) re-activates the previously-assigned APNs device token as per @rchan41's findings:

I also noticed that requesting a new messaging token seems to "reactivate" the old one. If you subscribe with this new token, and send a notification to the topic, the iOS device will get two separate notifications.

So it seems unnecessary to reinstall the PWA. Simply call Pushy.register() again and it should re-activate the token. We haven't been able to confirm this ourselves, so please give it a try yourself as well.

Your assumption was correct - re-registering works just fine without reinstalling the app.
I think we can close this issue from a Pushy-perspective now, so feel free to do so if you agree.


IGListAdapter setscrollViewDelegate crash

New issue checklist

[x] I have reviewed the README and documentation
[ ] I have searched existing issues and this is not a duplicate
[ ] I have attempted to reproduce the issue and include an example project.

General information

IGListKit version:4.0.0
iOS version(s):iOS  12.4
CocoaPods/Carthage version:1.9
Xcode version:12.0
Devices/Simulators affected: Simulators
Reproducible in the demo project? (Yes/No):Yes
Related issues:

Debug information
IGListAdapter setscrollViewDelegate crash ;
Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)

First, EXC_BAD_ACCESS - Object not in memory anymore so crash, can you show code?
Best Practices
please read and try again, maybe you find something in there.


.NET Console app insights example references outdated method for flushing telemetry

The "full example" code sample says that you must sleep for 5 seconds after flushing. However, according to InMemoryChannel documentation, you should not need this sleep after flushing: https://docs.microsoft.com/en-us/azure/azure-monitor/app/telemetry-channels#built-in-telemetry-channels.

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

ID: b189efce-ce4e-f8f8-ecf8-8803a18f9b65
Version Independent ID: aec54012-dae3-ce18-0f8c-30749c46a79c
Content: Azure Application Insights for Console Applications - Azure Monitor
Content Source: articles/azure-monitor/app/console.md
Service: azure-monitor
Sub-service: application-insights
GitHub Login: @AaronMaxwell
Microsoft Alias: aaronmax

Thanks for the feedback! We are currently investigating and will update you shortly.

@AaronMaxwell Can you please provide your insights on this?

@cijothomas Do you know if we have any outstanding bugs open that prevent us from removing the 5 second sleep from the sample code?
Task.Delay(5000).Wait();

This is being resolved in https://github.com/MicrosoftDocs/azure-docs-pr/pull/204495.
#please-close


Identify existing business banking customers

When I am processing an MSME application in Credere, I want to be able to see if an application is from an existing business banking customer, so that I can take this into account when processing the application as it will be a different process for MSMEs who are not existing customers.
FI can verify the MSME is an existing customer using the bank certification document

Closing nothing to implement


Refactor "is_condition_set" in utils -- part of #141 and #143

Codecov Report
Base: 100.00% // Head: 100.00% // No change to project coverage :thumbsup:

Coverage data is based on head (bd244b5) compared to base (31c6c4e).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #144   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           18        18
  Lines          945       946    +1
  Branches       172       172
=========================================
+ Hits           945       946    +1

Impacted Files
Coverage Δ

src/nmk/build.py
100.00% <100.00%> (ø)

src/nmk/utils.py
100.00% <100.00%> (ø)

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Create FormatCheck.yml

coverage: 92.362%. remained the same
when pulling ba5151b2380fb13c872e9c032577b1b13569e7bb on ranocha-patch-1
into ae5ef4c1bb8ac24537c53c76a6446b7944d04078 on main.


chore: update common templates

This PR was generated using Autosynth. :rainbow:
Synth log will be available here:
https://source.cloud.google.com/results/invocations/568dd2ec-07da-4a8a-80bd-f5598a72f156/targets

[ ] To automatically regenerate this PR, check this box.

Source-Link: https://github.com/googleapis/synthtool/commit/987270824bd26f6a8c716d5e2022057b8ae7b26e
Source-Link: https://github.com/googleapis/synthtool/commit/cac9eef310652bf138dd76b716e4986e757d62ac
Source-Link: https://github.com/googleapis/synthtool/commit/8b65daa222d193b689279162781baf0aa1f0ffd2
Source-Link: https://github.com/googleapis/synthtool/commit/5b48b0716a36ca069db3038da7e205c87a22ed19
Source-Link: https://github.com/googleapis/synthtool/commit/98c50772ec23295c64cf0d2ddf199ea52961fd4c
Source-Link: https://github.com/googleapis/synthtool/commit/55cdc844877d97139f25004229842624a6a86a02

I've filed #257 to investigate the Windows test failure. I'm merging this in since I want to see if we still need to merge in #250.


Import Archaeology layers

[ ] Need to identify how / where to access Arch layers

@emjohnst - Has the source of this been identified yet? I'm assuming that this would be an internal-only layer?

@bferguso I believe Elisabeth has requested this layer for fossils and is going through the process.  Could we note her ticket for that in this ticket so we can identify the layer then seek our own permissions from Arch branch? I will most this to Post MVP 2 milestone as this does not need to be completed before public site.


Fix dependency cycle in track filter API

Avoid dependency cycle through the plugin
API used by the frontend by importing globals
directly from its defining module.
This problem was found in prototyping a work-around for multiple instantiation of the Perfetto UI in which module loading ran into uninitialized variables due to this dependency cycle.

Thanks @wpaul-samsung! I didn't create a PR to pick up a new submodule commit in the host application because it isn't critical to integrate it yet and it can wait until the next update. Does that sound OK?

Sounds good.


Opening a downloaded file could be more convenient

Is your feature request related to a problem? Please describe.
When the users has downloaded an attachment via the cloud icon, they receive a notification, clicking on which leads to a list of downloaded files.
After that, they need to find this file in the downloaded file list and click “show in folder”. And it's too confusing.
Describe the solution you'd like
Clicking on a notification about a downloaded file, immediately opens the folder with it

@jeanfbrito Please let me know your views on this one. I would really love to made the required ammendments to the behaviour.
Waiting for your reply
Prisha Gupta

The first file in the list is the latest downloaded, the user don't need to find as is on the top of the list.
But, we can change this of course, maybe do the two things, open the folder and change the desktop app to the downloads view as its done today.
But always the last download is on the top. We could add some highlight to it too and/or show the timestamp of the download.
You can improve this view if you want @preeesha and have any ideas.

Thanks for the reply @jeanfbrito.
The idea of opening the download page with a highlighted file with a timestamp sounds pretty cool to me.
I would like to suggest adding an option in the settings to let the user customise this behaviour. We should give user the choice to choose between whether he wants to see the download page or open the folder directly.
What are your views? Is it better this way or am I lacking somewhere?
Also do let me know if I should start working on it?

I think that we can just open the folder and highlight on desktop app without a setting. If someone complain about this new behaviour we add the setting, but I really think that it can be the default behaviour.

Okay @jeanfbrito. I'll making changes to make the notification open the folder and highlight the file in the download page as well. I'll first be adding a timestamp in the downloaded files in a separate PR to avoid the mess.
I'll update you shortly.

could you create the links for the downloaded files (show in folder), like it is realized in this messenger? it's very convenient.
and if you can indicate the download status of the file (downloaded or not), it would be perfect.


Bug in Hearin15 satellite fractions

When I populate two mocks with the Hearin15 model, one with a threshold of 10.25, and the other with a satellite fraction of 11.25, the satellite fractions are both ~0.3.

Also, the number of galaxies plummets for thresholds above 10.25. There are just 3000 galaxies in the 11.25 mock.

The bug also occurs for the Leauthaud11 model, but not for the Zheng07 model.


Incorrect sample size reported in sushie.cv.tsv

Hello,
I encountered an issue with the cross-validation output, specifically regarding the reported sample size. It appears that the sample size reported is always that of the last ancestry processed.
You can reproduce the problem using the following test data:
sushie finemap
	--pheno EUR.pheno
	        AFR.pheno
	--plink plink/EUR
	        plink/AFR
	--covar EUR.covar
	        AFR.covar
	--cv
	--her
	--output ./test_result

The test_result.sushie.cv.tsv output looks like this:

ancestry
rsq
p_value
N
trait

1
0.4932215908291845
4.133847921724767e-74
639
Trait

2
0.4743709425200131
3.0193789659893506e-91
639
Trait

As shown above, both ancestries have the same reported sample size of 639. However, based on the input files, I would expect the EUR ancestry to have 489 samples.
Xinyu

Sorry, I didn't see this until now.
Nice catch! Will fix it in the next version. I probably get it fixed by the end of the coming week.
Thank you so much! For future immediate questions, please email me as I usually do not watch the issue section every day!
Thank you!
Best,
Zeyun


Update draw area info dialog text and use onResume() event to show the dialog.

Fixes #2311

Updates text for draw area info. Uses onResume() event to trigger the info dialog, since the setMenuVisibility() is deprecated in newer versions of Android and was not reliable for determining the task's visibility state overall.

[x] Updates text to match the mocks.
[x] Use onResume() event + isVisible to definitively determine the trigger to show the info dialog.
[x] Verified the performance of SharedPreference to be acceptable for multiple rapid-fire calls to onResume().
[x] Standardized the dialog color.
[x] Removed unnecessary StylizedText, since fontSize already existed.

[x] Existing unit tests pass.
[x] Locally by removing the setter to always trigger the dialog and determinine that the

@gino-m @shobhitagarwal1612 ?

Lgtm! Is this working for Drop a pin and Capture location as well?

Testing now.

Capture location doesn't have a dialog.
Drop a pin seems to be bound to the hint icon. I think we'd need to refactor it to match the mocks.

I'm happy to perform the refactor!


docs: update docker-compose commands to include --build

Changes

#1741  👈 (View in Graphite)
main

How to use the Graphite Merge Queue
Add the label merge-queue to this PR to add it to the merge queue.
You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has required the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.


Few remarks/questions about nixvim

hi,
I contribute regularly to nix+neovim issues and while I dont use nixvim (I prefer a more laid back approach)m I have a few changes in mind I would like to apply to the nixpkgs neovim wrapper. I had a (quick) look at nixvim code to see how it could impact it and I have a few questions/remarks

toLuaObject could be replaced by lib.generators.toLua
if you really want to go hardcore and generate nix code for options, there is https://github.com/neovim/neovim/blob/master/src/nvim/options.lua
I was surprised nix run github:nix-community/nixvim wouldn't showcase some example config ?
do you check the generated config ? aka start nvim and see if it launches errors ? I would like to have this (optionnally) in nixpkgs ?
does a nixvim generated executable read ~/.config ? I would like to make it easier to generate the hybrid neovim that has a nix base but reads from XDG config and a hardened pure nix config as requested in https://github.com/NixOS/nixpkgs/issues/ (maybe using NVIM_APPNAME)

We could use lib.generators.toLua, but I'm not sure it support mixed table & lists (i.e { foo, bar, key = baz}
True, we already do that generation for some of our plugins (like rust-analyzer or efmls-configs)
We do have an example.nix that we could plug to nix run
By check you mean check for errors? We launch a headless neovim instance and we check that stdout is empty, you can check the implementation
I don't really remember the exact details on how we generate the configurations, I would need to look into it, as we support standalone flakes, a HM module & a NixOS module

does a nixvim generated executable read ~/.config ? I would like to make it easier to generate the hybrid neovim that has a nix base but reads from XDG config and a hardened pure nix config as requested in https://github.com/NixOS/nixpkgs/issues/ (maybe using NVIM_APPNAME)

No it's not reading ~/.config as far as I know


ros2 bag filter usage is incorrect

the filter command does not work as explained in the readme and --help message:
The help explains included topics are passed as a list to argument -i:
-i INCLUDE [INCLUDE ...], --include INCLUDE [INCLUDE ...]
Topics to include.
This is consistent with the readme example:
ros2 bag filter -o rosbag2_filtered/ rosbag2_merged/ -i "/system/emergency/turn_signal_cmd" "/autoware/driving_capability"
However this seems not to be how the tool works. On my machine the command:
$ ros2 bag filter /data/universe/rosbag2_2022_05_30-16_03_21 -o /data/universe/rosbag2_2022_05_30-16_03_21_filtered2 -i "/pacmod/*" "/sensing/lidar/top/velodyne_packets"

produces a rosbag with only /sensing/lidar/top/velodyne_packets:
$ ros2 bag info /data/universe/rosbag2_2022_05_30-16_03_21_filtered2

Files:             rosbag2_2022_05_30-16_03_21_filtered2_0.db3
Bag size:          398.5 MiB
Storage id:        sqlite3
Duration:          188.681s
Start:             May 30 2022 07:03:23.370<PHONE_NUMBER>.370)
End:               May 30 2022 07:06:32.51<PHONE_NUMBER>.51)
Messages:          1888
Topic information: Topic: /sensing/lidar/top/velodyne_packets | Type: velodyne_msgs/msg/VelodyneScan | Count: 1888 | Serialization Format: cdr

My bad, it was just a regex thing  /pacmod/* -> /pacmod/.*


Flux field?

TauFactor version: 1.0.0
Python version: 3.10
Operating System: MacOS Monterey 12.6.7

Hi there, I was wondering if there was a way to pull out the flux field through a 2 phase system to visualize it similar to the total flux map .tif file from the Matlab version of TauFactor.  Or even just the 3d array for the total flux that I could then convert myself to a .tif or visualize it with some other method.  It looks like you have potentially done this already based on the graphic included in the description for the Python version.
Describe what you were trying to get done.
Tell us what happened, what went wrong, and what you expected to happen.
I can see that flux is calculated via the concentration gradient as part of the calculation process but I am not sure where to go from there.  My code to calculate tau, d_eff, etc is working well.
Thanks.

Hi Amir,
Thanks for the effort in this module.
I used the code above and it creates a Tensor Object.
May you please advise how to convert this into a file that is suitable for visualization in Paraview?
How does one convert a Tensor object to a 3D tiff or VTK?

Hi @andtoni,
Thanks for reaching out. There are several packages that can handle .tif files. I like to use tifffile.
You first need to convert the Tensor object into numpy and also to the cpu, so if your Tensor object is test, the way to save the file as .tif is
tifffile.imsave("test.tif", test.to("cpu").numpy())

It might be useful to just have a function that saves the flux field as a .tif file #97.

#97 closed this, you can call s.calc_vertical_flux()


Add taxonomy retrieval

Added two functions (ncbi_taxonomy and ncbi_parse_taxonomy_xml) to pull taxonomy from the NCBI Taxonomy database for a set of GenBank records queried from gb_fetch_from_id_list

Awesome, thanks for your contribution!


Fix issue #1986 - sometimes PRCA cannot find changes in a file

This does not happen very often so in the short term we'll ignore those comments. In the long term we are looking at using a higher level API to post comments that should circumvent this problem.

LGTM

LGTM


Possible Development #1

We might be working on a GUI model for the DCSS. Sketches are yet to be released!
Any suggestions that would help in the development of a GUI for The DCSS are very much welcome.

Development has resumed for the GUI and we are now preparing for a rough model of a GUI for all currently available commands. Currently, our GUI model is based on Python 3.x, so please make sure you have downloaded and installed that. Libraries used in the development of the beta GUI model will soon be announced.

Release date: Hopefully today!

this project is now abandoned. development has permanently halted.


Add panic statement support

Add the panic statement support to the new parser.  You can find the syntax in the language specification.
https://ballerina.io/spec/lang/2020R1/#section_7.24

Added with  #22220


Make Scope work with Proteus

Repo: https://github.com/kinvolk/scope/tree/alban/proteus
Current problems:

[ ] report/generated.pb.go:535: cannot convert nil to type Metric
[ ] report/generated.pb.go:545: cannot convert nil to type Metric
[ ] report/generated.pb.go:1057: cannot convert nil to type Node
[ ] report/generated.pb.go:1067: cannot convert nil to type Node
[ ] report/generated.pb.go:1085: cannot convert nil to type Control
[ ] report/generated.pb.go:1095: cannot convert nil to type Control
[ ] report/generated.pb.go:1113: cannot convert nil to type MetadataTemplate
[ ] report/generated.pb.go:1123: cannot convert nil to type MetadataTemplate
[ ] report/generated.pb.go:1141: cannot convert nil to type MetricTemplate
[ ] report/generated.pb.go:1151: cannot convert nil to type MetricTemplate

@Serabe Thanks for looking at this!
Upstream repo: https://github.com/weaveworks/scope/
Scope issue about trying Proteus: https://github.com/weaveworks/scope/issues/2433
/cc @2opremio @schu @iaguis

Updated text and removed the EPIC label since they are all the same problem.

@alban I submitted this morning a PR to alban/proteus https://github.com/kinvolk/scope/pull/5
Basically, I fixed all the problems I found and made a new release. Then, I did a make clean to make sure everything was removed properly and tried again. I also added some files from gogo/protobuf that are really needed (those can be found in the PR).
Thank you!


Unkown number of domains

Hi,
The tutorial and paper make it seem like SpaGCN can guess an optimal resolution without knowing the real number of domains in a dataset.

If the number of domains in the tissue is known ( ...). Otherwise, we vary the resolution parameter from 0.2 to 1.0 and select the resolution that gives the highest Silhouette score

So, running clf.train without the res parameter looks like this:
 clf.train(adata,adj,init_spa=True,init="louvain", tol=5e-3, lr=0.05, max_epochs=200)
Initializing cluster centers with louvain, resolution =  0.4
Epoch  0
Epoch  10
Epoch  20
delta_label  0.00487028191439543 < tol  0.005
Reach tolerance threshold. Stopping training.
Total epoch: 25

Is the output of this function corresponding to my quote of the paper? It seems to only try a single resolution (0.4) and does not seem to compare Silhouette scores.
Kind regards,
Ricardo

SpaGCN uses Louvain's clustering for initialization, which takes a resolution to determine the number of clusters as I explained here #5.
If you know the number of clusters, there is a step in the tutorial to search for a suitable resolution to achieve the number of clusters. SpaGCN itself does not contain the Silhouette scores calculation since it is only used for method evaluation. For real data analysis purposes, you can either set the number of clusters as the tutorial did or just try a few resolutions and pick the one you like.  I would recommend trying 0.2, 0.4, 0.6. Generally speaking, a higher resolution will result in more domains.

Thank you, keep up the great work!


rasa x command error

Rasa version:
1.10.0
Rasa SDK version (if used & relevant):
Rasa X version (if used & relevant):
0.22
Python version:
3.6
Operating system (windows, osx, ...):
Mac OS
Issue:
2020-05-08 19:30:27 ERROR    sanic.root  - Unable to start server
Traceback (most recent call last):
File "/opt/anaconda3/envs/rasa/lib/python3.6/site-packages/sanic/server.py", line 860, in serve
http_server = loop.run_until_complete(server_coroutine)
File "uvloop/loop.pyx", line 1456, in uvloop.loop.Loop.run_until_complete
File "uvloop/loop.pyx", line 1727, in create_server
OSError: [Errno 48] error while attempting to bind on address ('<IP_ADDRESS>', 5002): address already in use
Traceback (most recent call last):
File "", line 1, in
File "/opt/anaconda3/envs/rasa/lib/python3.6/multiprocessing/spawn.py", line 105, in spawn_main
exitcode = _main(fd)
File "/opt/anaconda3/envs/rasa/lib/python3.6/multiprocessing/spawn.py", line 115, in _main
self = reduction.pickle.load(from_parent)
File "/opt/anaconda3/envs/rasa/lib/python3.6/multiprocessing/synchronize.py", line 110, in setstate
self._semlock = _multiprocessing.SemLock._rebuild(*state)
FileNotFoundError: [Errno 2] No such file or directory
Error (including full traceback):

Command or request that led to error:
rasa x

Content of configuration file (config.yml) (if relevant):

Content of domain file (domain.yml) (if relevant):

if I restarted  and run  the command

rasa x
and train a model the error pops up
Training Core model...
2020-05-08 19:39:09 ERROR    rasax.community.api.blueprints.models  - 500, message='Internal Server Error', url=URL('http://localhost:5005/model/train')

is that. a port problem or should I change any code

Thanks for raising this issue, @erohmensing will get back to you about it soon✨
Please also check out the docs and the forum in case your issue was raised there too 🤗

Hey there @sheggamharshith, Rasa 1.10 is incompatible with Rasa X 0.22. Please see the compatiblity matrix here: https://rasa.com/docs/rasa-x/changelog/compatibility-matrix/
Can I ask why you decided to install Rasa X locally instead of via one of our recommended deployment methods?

@erohmensing  thanks for the compatibility matrix i have resolved the issue  mam i was just checking it


Encountered an error

Hi,Ye
   I encountered the following problem while conducting HIC data simulation and have been unable to solve it. I would like to ask for your advice. Is it my dependency version that is causing the problem?

Thanks,
Wang

Hello Wang,
The error you're encountering indicates a problem during the compilation of a Python package that involves native extensions, requiring the gcc compiler. The specific files mentioned in the error message, /lib64/libpthread.so.0 and /usr/lib64/libpthread_nonshared.a, are part of the POSIX thread (pthread) libraries, which are essential for supporting multi-threading in C and C++ programs. These libraries are required by the gcc compiler to link the threading support into the native extensions being compiled. The absence of these files suggests an issue with the development environment setup on your system, particularly related to the threading libraries and development tools. You may consider install libc6-dev and glibc-devel.
Thanks,
Ye


Incorrect indentation after string literals containing escaped characters

Steps to reproduce:

Type string with '\n' in it, press Enter.

a = '\n'

Same for double quotes.
Expected behaviour
a = '\n'
<--- cursor should be here

Actual behaviour
a = '\n'
    <--- cursor is here

Environment data

VS Code version: 1.30.2
Extension version (available under the Extensions sidebar): 2019.1.0
OS and version: Windows 10
Python version (& distribution if applicable, e.g. Anaconda): 3.7
Type of virtual environment used: N/A
Relevant/affected Python packages and their versions: none

Logs
Console:
Starting Jedi Python language engine.

Linter 'pylint' is not installed. Please install it or select another linter".
Error: Module 'pylint' not installed.

Yeah, this is really annoying. It seems like this was introduced by the "fix" for #3284.
If I had to choose between having line continuation backslashes work properly, or backslash escapes work properly, I would choose backslash escapes in a heartbeat. Some people probably never use backslash for line continuation, while most other people probably use it very sparingly, since PEP 8 encourages implicit line continuation wherever it can be sensibly applied.
And even if you like backslash line continuation, (1) presumably you're not going to have large sections of code riddled with them, since long lines are discouraged anyway, and (2) you have reasonable alternatives for achieving what you need. Whereas there are plenty of situations where you could be using a lot of backslash escapes (strings, regular expressions), and there is no reasonable alternative.

I am not familiar with the code, but it may be this string:
https://github.com/Microsoft/vscode-python/blob/c23603c9b7a3dbb805e8339a2d7cf01bb7327b34/src/client/extension.ts#L176
since regex doesn't include end of line.

I'm pretty sure you've hit the nail on the head.
It seems like such a simple and easy fix (see my comment on #3915). If we are wrong about this, and it's actually more complicated, then I wish they would come out and explain why.

Prescribed solution

Try the fix mentioned in  comment on #5821

I've verified that the following indent/dedent properly:
a = '\n'
# cursor here

a = 1 + \
    # cursor here


Create Wiki pages or any accessible docs

The purpose of this issue is to provide a Wiki documentation that cannot be written down in the README.
We could add a How to section to explain how to handles indexes, synonyms, and other settings even if it's not the first purpose of this package.
(Following this discussion on #45)

Maybe you can be inspired by Algolia's docs.

You can have a look to the wiki, I have added two possible way of handling indexes settings.

Awesome! 🚀


Remove the extra packages in the vendor

Signed-off-by: zhouhao<EMAIL_ADDRESS>

@opencontainers/image-tools-maintainers PTAL

LGTM

LGTM


Add new text rendering capabilities

Attempts to address #6

Clawing this back for now, as it needs a bit more work
It appears golangs freetype lib does not take into account font descents when calculating a glyphs bounding box, which results in some multiline text is rendering badly


opencpn: 5.6.2 -> 5.8.4

Description of changes
opencpn is currently failing: https://hydra.nixos.org/build/246770144. This update fixes the build.
https://github.com/opencpn/opencpn/compare/Release_5.6.2...Release_5.8.4
All added packages are from looking through the configurePhase output.

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 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 281450 run on aarch64-darwin 1

1 package built:

opencpn

@ofborg build opencpn opencpn.passthru.tests

@wegank, it looks like it worked: https://logs.ofborg.org/?key=nixos/nixpkgs.281450&attempt_id=450c3659-add1-494e-a34e-3a3f4334a0f6

Ping on this: I don't think I have more work to do, and the build is currently broken.

Thanks @wegank!


affected/package: build error | service/service_layer.go:38:34: internal compiler error: assertion failed

this part i can execute
	switch d := h.helper.(type) {
	case Debugger:
		if d.Debug() {
			cmd, err := http2curl.GetCurlCommand(request)
			fmt.Println("curl_request", cmd.String(), "err", err)
		}
	}

	// if debugger, found := h.helper.(Debugger); found && debugger.Debug() {
	// 	cmd, err := http2curl.GetCurlCommand(request)
	// 	fmt.Println("curl_request", cmd.String(), "err", err)
	// }

this i can't

What version of Go are you using (go version)?

$ go version 1.18.4

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?

What did you expect to see?
What did you see instead?

please include a full reproduction case (eg playground)

Also, 1.18.4 is not the latest release.


Ko naming / similar project

Just noting this project with similar ambitions but is now somewhat dormant: https://github.com/kocircuit/kocircuit
CC @petar the creator

Interestingly these were hatched at similar times. I think they're different enough not to cause confusion (language vs image builder).
https://github.com/kocircuit/kocircuit/commit/3faeb8f46b5831a2dcda61fd52e6bd757f39f184
https://github.com/google/go-containerregistry/issues/80

Interestingly these were hatched at similar times. I think they're different enough not to cause confusion (language vs image builder).
https://github.com/kocircuit/kocircuit/commit/3faeb8f46b5831a2dcda61fd52e6bd757f39f184
https://github.com/google/go-containerregistry/issues/80

Agree!

Perhaps the term was in the air due to https://en.wikipedia.org/wiki/AlphaGo 😉


Question about Scheme and/or ColorPalette behavior

Consider the following code:
import 'package:flutter/material.dart';
import 'package:material_color_utilities/material_color_utilities.dart';

void main() {
  const color = Colors.blue;
  final scheme = Scheme.light(color.value);
}

Should color.value be equal to scheme.primary? Right now these two values are different.
I can see that Scheme.light calls CorePalette.of(color) and then assign corePalette.primary.get(40) as the primary color. Maybe another question would be should corePalette.primary.get(40) be equal to the color that was provided initially?
I was also reading the color system page, and seems like the primary color should have a tone of 40. So I'm just wondering what's the expected behavior when using Scheme.light and/or CorePlatte.of?

Should color.value be equal to scheme.primary? Right now these two values are different.

I believe so, but only if your input color is of tone 40, for a light scheme. In this case Colors.blue is Colors.blue.shade500 which has a tone of 50.

This is by design and guarantees the accessibility of the system, e.g. that the onPrimary color will be fully legible, no matter the color.

The side effect is that most of the time, your input color isn't found exactly in the output scheme.

I see thanks for the clarification!


1 of many... moving to the new projects types

Don't have time for a massive transition in one PR. And it will be too heavy to review. So here you go - first PR in a series of PRs on moving towards new projects types and easier engineering.

@SergeyKanzhelev check build failures.


MAC : Brackets extensions are failing to install after installing 4-5 extensions.

NOTE:
This issue is not observed on win.
Tried with mac 10.15 and 10.13
This issue is also observed in Brackets 1.13
Steps to reproduce:
Step 1: Launch Bracket.
Step 2: Navigate to File menu and click on "Extension Manager".
Step 3: Start installing Brackets extensions by clicking on "Install" button.
Step 4: Observe the behavior after installing few Extensions.
Actual Result:
After installing 5-6 extensions, "Installation failed" error message is shown while installing other extensions.
Expected Result:
It should install all the extensions without any failure.


performSwipe stoped to work with new uiautomator2

After updating uiautomator2 to version 2.31.3 performSwipe stoped to work
Seems the issue in changes of this file https://github.com/appium/appium-uiautomator2-driver/blob/master/lib/commands/actions.js
"codeceptjs": "^3.5.4",
Appium configs:
let Appium = {
app: 'your apk path',
platform: 'Android',
device: 'device_id',
appiumV2: true,
desiredCapabilities: {
automationName: 'UiAutomator2',
'appium:platformName': 'Android',
autoGrantPermissions: true,
platformVersion: 'your android version',
newCommandTimeout: 4000,
timeoutSeconds: 4,
adbExecTimeout: 600000,
androidInstallTimeout: 600000,
appWaitDuration: 60000,
nativeWebTap: true,
networkSpeed: 'full',
noReset: true,
fullReset: false,
allowTestPackages: true,
appWaitActivity: "com.ddits.login.LoginActivity,com.ddits.feature.main.MainActivity"
},
timeouts: {
pageLoad: 15000
},
waitForTimeout: 5000
};
Error:
unknown method: Not implemented
at getErrorFromResponseBody (file:///Users/project_folder/node_modules/webdriver/build/utils.js:194:12)
at NodeJSRequest._request (file:///Users/project_folder/node_modules/webdriver/build/request/index.js:164:23)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Browser.wrapCommandFn (file:///Users/project_folder/node_modules/@wdio/utils/build/shim.js:81:29)
at async Appium.performSwipe (/Users/project_folder/node_modules/codeceptjs/lib/helper/Appium.js:1083:5)
at async swipeElement (/Users/project_folder/test/core/core_steps.js:841:9)
at async /Users/project_folder/test/core/core_steps.js:662:9
at async runSteps (/Users/project_folder/node_modules/codeceptjs/lib/interfaces/gherkin.js:77:9)

Hello,
can you provide more details like your codecept.conf.js and other stuffs that will help us to reproduce the issue?

It's not related to configs but I added Appium config and Error trace


Add Full Stack Open course

I noticed there is no course specialized in web development. Therefore, I suggest to add this great MOOC which is made open by University of Helsinki, and that covers modern web technologies.

The course is worth 5-13 credits, and the content is the same as in the Full stack course held at the Department of Computer Science at the University of Helsinki in Spring 2020. There is also an associated project that is worth 1-10 credits.

https://fullstackopen.com/en/about
Features:

It is an open source course: https://github.com/fullstack-hy2020/fullstack-hy2020.github.io
It is annually updated
It has a built-in assignment submission system based on GitHub
Large community of students

I added it to extra, under Application section

This course is already recommended under final project in the main curriculum: https://github.com/ossu/computer-science#final-project


Create melange.itermcolors

This is the Iterm variant I made.
It is slightly different from the alacrity one because I think there are some issues there with the bright variants.
I used https://terminal.sexy/ to make it.

Thanks!
And thanks for reminding me of the Alacritty colors. You're right, I forgot to update them and they're out of sync.


Cleaning up usage stats page table

Unsure if this is the right way to show this information on the usage stats downloads info. I think being able to download a two-column text file of date + download count would be preferred, especially as the number of days becomes larger.

Alter table to report sums from all time. Maybe in the future serve as a two column file so people (like Jens) can make a plot themselves.


Kibana UI cannot be accessed

After installing the latest Kibana 4.5.3 package from universe with:
dcos package install kibana

the Kibana tasks started successfully.
$ dcos marathon task list | awk '{print $5}' | grep kibana | head -n1 | xargs dcos marathon task show
{
  "appId": "/kibana",
  "host": "<IP_ADDRESS>",
  "id": "kibana.41f21ef2-c1ef-11e6-98b2-4ee48a083375",
  "ipAddresses": [
    {
      "ipAddress": "<IP_ADDRESS>",
      "protocol": "IPv4"
    }
  ],
  "ports": [
    5601
  ],
  "servicePorts": [
    5601
  ],
  "slaveId": "cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1",
  "stagedAt": "2016-12-14T11:20:02.911Z",
  "startedAt": "2016-12-14T11:20:03.788Z",
  "state": "TASK_RUNNING",
  "version": "2016-12-14T11:20:02.882Z"
}

Also, the Kibana log files are reporting that it has been started successfully:
--container="mesos-cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1.9cfd386c-ea07-4e03-a8aa-9e5210e0b7e9" --docker="docker" --docker_socket="/var/run/docker.sock" --help="false" --initialize_driver_logging="true" --launcher_dir="/opt/mesosphere/packages/mesos--253f5cb0a96e2e3574293ddfecf5c63358527377/libexec/mesos" --logbufsecs="0" --logging_level="INFO" --mapped_directory="/mnt/mesos/sandbox" --quiet="false" --sandbox_directory="/var/lib/mesos/slave/slaves/cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1/frameworks/cb77bbc5-7a93-4eb0-a8d6-150729a210d8-0000/executors/kibana.41f21ef2-c1ef-11e6-98b2-4ee48a083375/runs/9cfd386c-ea07-4e03-a8aa-9e5210e0b7e9" --stop_timeout="20secs"
--container="mesos-cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1.9cfd386c-ea07-4e03-a8aa-9e5210e0b7e9" --docker="docker" --docker_socket="/var/run/docker.sock" --help="false" --initialize_driver_logging="true" --launcher_dir="/opt/mesosphere/packages/mesos--253f5cb0a96e2e3574293ddfecf5c63358527377/libexec/mesos" --logbufsecs="0" --logging_level="INFO" --mapped_directory="/mnt/mesos/sandbox" --quiet="false" --sandbox_directory="/var/lib/mesos/slave/slaves/cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1/frameworks/cb77bbc5-7a93-4eb0-a8d6-150729a210d8-0000/executors/kibana.41f21ef2-c1ef-11e6-98b2-4ee48a083375/runs/9cfd386c-ea07-4e03-a8aa-9e5210e0b7e9" --stop_timeout="20secs"
Registered docker executor on <IP_ADDRESS>
Starting task kibana.41f21ef2-c1ef-11e6-98b2-4ee48a083375
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:kibana","info"],"pid":13,"name":"plugin:kibana","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:elasticsearch","info"],"pid":13,"name":"plugin:elasticsearch","state":"yellow","message":"Status changed from uninitialized to yellow - Waiting for Elasticsearch","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:kbn_vislib_vis_types","info"],"pid":13,"name":"plugin:kbn_vislib_vis_types","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:markdown_vis","info"],"pid":13,"name":"plugin:markdown_vis","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:metric_vis","info"],"pid":13,"name":"plugin:metric_vis","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:spyModes","info"],"pid":13,"name":"plugin:spyModes","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:statusPage","info"],"pid":13,"name":"plugin:statusPage","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:table_vis","info"],"pid":13,"name":"plugin:table_vis","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["listening","info"],"pid":13,"message":"Server running at http://<IP_ADDRESS>:5601"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:elasticsearch","info"],"pid":13,"name":"plugin:elasticsearch","state":"green","message":"Status changed from yellow to green - Kibana index ready","prevState":"yellow","prevMsg":"Waiting for Elasticsearch"}
{"type":"response","@timestamp":"2016-12-14T11:20:07+00:00","tags":[],"pid":13,"method":"get","statusCode":200,"req":{"url":"/","method":"get","headers":{"host":"<IP_ADDRESS>:5601","user-agent":"spray-can/1.3.3"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>"},"res":{"statusCode":200,"responseTime":78,"contentLength":9},"message":"GET / 200 78ms - 9.0B"}
{"type":"response","@timestamp":"2016-12-14T11:20:37+00:00","tags":[],"pid":13,"method":"get","statusCode":200,"req":{"url":"/","method":"get","headers":{"host":"<IP_ADDRESS>:5601","user-agent":"spray-can/1.3.3"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>"},"res":{"statusCode":200,"responseTime":6,"contentLength":9},"message":"GET / 200 6ms - 9.0B"}
{"type":"response","@timestamp":"2016-12-14T11:21:07+00:00","tags":[],"pid":13,"method":"get","statusCode":200,"req":{"url":"/","method":"get","headers":{"host":"<IP_ADDRESS>:5601","user-agent":"spray-can/1.3.3"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>"},"res":{"statusCode":200,"responseTime":4,"contentLength":9},"message":"GET / 200 4ms - 9.0B"}

However, accessing Kibana on http://dcos-cluster/app/kibana returns a 404.
Contacting Kibana directly on the Mesos agent IP address returns a 200:
ubuntu@ip-10-0-4-19:~$ curl -v <IP_ADDRESS>:5601
* Rebuilt URL to: <IP_ADDRESS>:5601/
*   Trying <IP_ADDRESS>...
* connect to <IP_ADDRESS> port 5601 failed: Connection refused
* Failed to connect to <IP_ADDRESS> port 5601: Connection refused
* Closing connection 0
curl: (7) Failed to connect to <IP_ADDRESS> port 5601: Connection refused
ubuntu@ip-10-0-4-19:~$ curl -v <IP_ADDRESS>:5601
* Rebuilt URL to: <IP_ADDRESS>:5601/
*   Trying <IP_ADDRESS>...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 5601 (#0)
> GET / HTTP/1.1
> Host: <IP_ADDRESS>:5601
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< kbn-name: kibana
< kbn-version: 4.5.3
< cache-control: no-cache
< content-type: text/html
< content-length: 217
< accept-ranges: bytes
< Date: Wed, 14 Dec 2016 11:23:13 GMT
< Connection: keep-alive
<
<script>var hashRoute = '/app/kibana';
var defaultRoute = '/app/kibana';

var hash = window.location.hash;
if (hash.length) {
  window.location = hashRoute + hash;
} else {
  window.location = defaultRoute;
* Connection #0 to host <IP_ADDRESS> left intact
}

So it seems that the routing does not work. Any idea how to solve this?

Have you tried accessing it through marathon-lb?
On Dec 14, 2016 6:25 AM, "Markus Jura"<EMAIL_ADDRESS>wrote:

After installing the latest Kibana 4.5.3 package from universe with:
dcos package install kibana
the Kibana tasks started successfully.
$ dcos marathon task list | awk '{print $5}' | grep kibana | head -n1 | xargs dcos marathon task show
{
"appId": "/kibana",
"host": "<IP_ADDRESS>",
"id": "kibana.41f21ef2-c1ef-11e6-98b2-4ee48a083375",
"ipAddresses": [
{
"ipAddress": "<IP_ADDRESS>",
"protocol": "IPv4"
}
],
"ports": [
5601
],
"servicePorts": [
5601
],
"slaveId": "cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1",
"stagedAt": "2016-12-14T11:20:02.911Z",
"startedAt": "2016-12-14T11:20:03.788Z",
"state": "TASK_RUNNING",
"version": "2016-12-14T11:20:02.882Z"
}
Also, the Kibana log files are reporting that it has been started
successfully:
--container="mesos-cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1.9cfd386c-ea07-4e03-a8aa-9e5210e0b7e9" --docker="docker" --docker_socket="/var/run/docker.sock" --help="false" --initialize_driver_logging="true" --launcher_dir="/opt/mesosphere/packages/mesos--253f5cb0a96e2e3574293ddfecf5c63358527377/libexec/mesos" --logbufsecs="0" --logging_level="INFO" --mapped_directory="/mnt/mesos/sandbox" --quiet="false" --sandbox_directory="/var/lib/mesos/slave/slaves/cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1/frameworks/cb77bbc5-7a93-4eb0-a8d6-150729a210d8-0000/executors/kibana.41f21ef2-c1ef-11e6-98b2-4ee48a083375/runs/9cfd386c-ea07-4e03-a8aa-9e5210e0b7e9" --stop_timeout="20secs"
--container="mesos-cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1.9cfd386c-ea07-4e03-a8aa-9e5210e0b7e9" --docker="docker" --docker_socket="/var/run/docker.sock" --help="false" --initialize_driver_logging="true" --launcher_dir="/opt/mesosphere/packages/mesos--253f5cb0a96e2e3574293ddfecf5c63358527377/libexec/mesos" --logbufsecs="0" --logging_level="INFO" --mapped_directory="/mnt/mesos/sandbox" --quiet="false" --sandbox_directory="/var/lib/mesos/slave/slaves/cb77bbc5-7a93-4eb0-a8d6-150729a210d8-S1/frameworks/cb77bbc5-7a93-4eb0-a8d6-150729a210d8-0000/executors/kibana.41f21ef2-c1ef-11e6-98b2-4ee48a083375/runs/9cfd386c-ea07-4e03-a8aa-9e5210e0b7e9" --stop_timeout="20secs"
Registered docker executor on <IP_ADDRESS>
Starting task kibana.41f21ef2-c1ef-11e6-98b2-4ee48a083375
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:kibana","info"],"pid":13,"name":"plugin:kibana","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:elasticsearch","info"],"pid":13,"name":"plugin:elasticsearch","state":"yellow","message":"Status changed from uninitialized to yellow - Waiting for Elasticsearch","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:kbn_vislib_vis_types","info"],"pid":13,"name":"plugin:kbn_vislib_vis_types","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:markdown_vis","info"],"pid":13,"name":"plugin:markdown_vis","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:metric_vis","info"],"pid":13,"name":"plugin:metric_vis","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:spyModes","info"],"pid":13,"name":"plugin:spyModes","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:statusPage","info"],"pid":13,"name":"plugin:statusPage","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:table_vis","info"],"pid":13,"name":"plugin:table_vis","state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["listening","info"],"pid":13,"message":"Server running at http://<IP_ADDRESS>:5601"}
{"type":"log","@timestamp":"2016-12-14T11:20:05+00:00","tags":["status","plugin:elasticsearch","info"],"pid":13,"name":"plugin:elasticsearch","state":"green","message":"Status changed from yellow to green - Kibana index ready","prevState":"yellow","prevMsg":"Waiting for Elasticsearch"}
{"type":"response","@timestamp":"2016-12-14T11:20:07+00:00","tags":[],"pid":13,"method":"get","statusCode":200,"req":{"url":"/","method":"get","headers":{"host":"<IP_ADDRESS>:5601","user-agent":"spray-can/1.3.3"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>"},"res":{"statusCode":200,"responseTime":78,"contentLength":9},"message":"GET / 200 78ms - 9.0B"}
{"type":"response","@timestamp":"2016-12-14T11:20:37+00:00","tags":[],"pid":13,"method":"get","statusCode":200,"req":{"url":"/","method":"get","headers":{"host":"<IP_ADDRESS>:5601","user-agent":"spray-can/1.3.3"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>"},"res":{"statusCode":200,"responseTime":6,"contentLength":9},"message":"GET / 200 6ms - 9.0B"}
{"type":"response","@timestamp":"2016-12-14T11:21:07+00:00","tags":[],"pid":13,"method":"get","statusCode":200,"req":{"url":"/","method":"get","headers":{"host":"<IP_ADDRESS>:5601","user-agent":"spray-can/1.3.3"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>"},"res":{"statusCode":200,"responseTime":4,"contentLength":9},"message":"GET / 200 4ms - 9.0B"}
However, accessing Kibana on http://dcos-cluster/app/kibana returns a 404.
Contacting Kibana directly on the Mesos agent IP address returns a 200:
ubuntu@ip-10-0-4-19:~$ curl -v <IP_ADDRESS>:5601

Rebuilt URL to: <IP_ADDRESS>:5601/
Trying <IP_ADDRESS>...
connect to <IP_ADDRESS> port 5601 failed: Connection refused
Failed to connect to <IP_ADDRESS> port 5601: Connection refused
Closing connection 0
curl: (7) Failed to connect to <IP_ADDRESS> port 5601: Connection refused
ubuntu@ip-10-0-4-19:~$ curl -v <IP_ADDRESS>:5601
Rebuilt URL to: <IP_ADDRESS>:5601/
Trying <IP_ADDRESS>...

In order to access it through Marathon-LB, open the Marathon-LB admin
interface at:
http://$PUBLIC_NODE_IP_ADDRESS:9090/haproxy?stats
This should show you a graphical interface similar to this:
[image: Inline image 1]
Apps published in Marathon-LB will appear here with the labels:
APPNAME_port
Now, in order to publish an app in Marathon-LB, like Kibana, you should
edit the app in the Services tab, go to "Labels" and add the label:
'HAPROXY_GROUP' with Label Value 'external'
The app will restart. You should then be able to open the Marathon LB admin
interface again and see the app there:
[image: Inline image 2]
In my example, kibana is running on port 5601. I can open it in the public
node's IP address, on port 5601:
[image: Inline image 3]
(in this case I don't have Elasticsearch running on my cluster so the
status is Red).
References:
https://mesosphere.com/blog/2015/12/04/dcos-marathon-lb/
https://docs.mesosphere.com/1.8/usage/service-discovery/marathon-lb/
On Wed, Jan 25, 2017 at 8:26 PM, Saurya Das<EMAIL_ADDRESS>wrote:

i have marathon lb running and i still get the 404 error. what am i doing
wrong?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mesosphere/universe/issues/871#issuecomment-275284873,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEEZTvNM3sOim-rQINYV30wRCvDuUJVNks5rV_ZFgaJpZM4LM0EQ
.

--
Fernando Sanchez
Sales Engineer
Mesosphere

Thanks .. that worked...

No, I haven't tried using the marathon LB. I would expect that Kibana is available on http://dcos-cluster/app/kibana or http://dcos-cluster/service/kibana because this is the URI that is linked in the DCOS UI Kibana services page.

I'd expect when clicking on the Open Service link that I then get redirected to the Kibana UI as with other services.

That does not seem to be functional today -- you should look at the
marathon-LB option:
In order to access it through Marathon-LB, open the Marathon-LB admin
interface at:
http://$PUBLIC_NODE_IP_ADDRESS:9090/haproxy?stats
This should show you a graphical interface similar to this:
[image: Inline image 1]
Apps published in Marathon-LB will appear here with the labels:
APPNAME_port
Now, in order to publish an app in Marathon-LB, like Kibana, you should
edit the app in the Services tab, go to "Labels" and add the label:
'HAPROXY_GROUP' with Label Value 'external'
The app will restart. You should then be able to open the Marathon LB admin
interface again and see the app there:
[image: Inline image 2]
In my example, kibana is running on port 5601. I can open it in the public
node's IP address, on port 5601:
[image: Inline image 3]
(in this case I don't have Elasticsearch running on my cluster so the
status is Red).
References:
https://mesosphere.com/blog/2015/12/04/dcos-marathon-lb/
https://docs.mesosphere.com/1.8/usage/service-discovery/marathon-lb/
On Mon, Jan 30, 2017 at 10:33 AM, Markus Jura<EMAIL_ADDRESS>wrote:

[image: screen shot 2017-01-30 at 8 31 26 am]
https://cloud.githubusercontent.com/assets/1832216/22429059/9bc17f60-e6c6-11e6-8b6f-870dbee43cc4.png
I'd expect when clicking on the Open Service link that I then get
redirected to the Kibana UI as with other services.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mesosphere/universe/issues/871#issuecomment-276093877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEEZTnCpNZeuzIBEJJVr0QAq08uniOBFks5rXgKzgaJpZM4LM0EQ
.

--
Fernando Sanchez
Sales Engineer
Mesosphere

Thanks for the workaround.
In order that the  http://dcos-cluster/app/kibana redirects to the Kibana UI correctly, is a change in https://github.com/mesosphere/universe/tree/version-3.x/repo/packages/K/kibana necessary or in another repository?
I am asking to know if this issue is addressed at the correct repository.

I believe that the current version of the DCOS "Admin Router" component
does not allow for applications to change their root paths.
So when kibana changes the default URL "http://$DCOS_IP/service/kibana" to
"http://$DCOS_IP/app/kibana" or anything different, Admin Router will block
the traffic and it won't work.
On Mon, Jan 30, 2017 at 12:34 PM, Markus Jura<EMAIL_ADDRESS>wrote:

Thanks for the workaround.
In order that the http://dcos-cluster/app/kibana redirects to the Kibana
UI correctly, is a change in https://github.com/mesosphere/
universe/tree/version-3.x/repo/packages/K/kibana necessary or in another
repository?
I am asking to know if this issue is addressed at the correct repository.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mesosphere/universe/issues/871#issuecomment-276129924,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEEZTkLcIaUURGTym4KxktC7pV0Ts1tPks5rXh8RgaJpZM4LM0EQ
.

--
Fernando Sanchez
Sales Engineer
Mesosphere

This is was a known issues with "community supported" version(4.5.3) of Kibana package and does not impact the now official supported kibana packages. Hence closing this out

I have DCOS 1.10.2 running and just installed kibana.
However I am unable to access the UI. Clicking the link in the ui gives me 404 not found after being redirected like so:
http://<IP_ADDRESS>:21576/service/kibana/app/kibana
Going directly to /app/kibana gives me this:
Kibana did not load properly. Check the server output for more information.
And the following log entries:
{"type":"response","@timestamp":"2017-12-04T20:23:30Z","tags":[],"pid":16,"method":"get","statusCode":503,"req":{"url":"/app/kibana","method":"get","headers":{"host":"<IP_ADDRESS>:21576","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8","accept-language":"en-US,en;q=0.5","accept-encoding":"gzip, deflate","connection":"keep-alive","upgrade-insecure-requests":"1","pragma":"no-cache","cache-control":"no-cache"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>"},"res":{"statusCode":503,"responseTime":25,"contentLength":9},"message":"GET /app/kibana 503 25ms - 9.0B"}
{"type":"response","@timestamp":"2017-12-04T20:23:31Z","tags":[],"pid":16,"method":"get","statusCode":404,"req":{"url":"/service/kibana/ui/fonts/open_sans/open_sans_v13_latin_300.woff2","method":"get","headers":{"host":"<IP_ADDRESS>:21576","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0","accept":"application/font-woff2;q=1.0,application/font-woff;q=0.9,*/*;q=0.8","accept-language":"en-US,en;q=0.5","accept-encoding":"identity","referer":"http://<IP_ADDRESS>:21576/app/kibana","connection":"keep-alive","pragma":"no-cache","cache-control":"no-cache"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:21576/app/kibana"},"res":{"statusCode":404,"responseTime":1,"contentLength":9},"message":"GET /service/kibana/ui/fonts/open_sans/open_sans_v13_latin_300.woff2 404 1ms - 9.0B"}
{"type":"response","@timestamp":"2017-12-04T20:23:31Z","tags":[],"pid":16,"method":"get","statusCode":404,"req":{"url":"/service/kibana/ui/fonts/open_sans/open_sans_v13_latin_300.woff","method":"get","headers":{"host":"<IP_ADDRESS>:21576","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0","accept":"application/font-woff2;q=1.0,application/font-woff;q=0.9,*/*;q=0.8","accept-language":"en-US,en;q=0.5","accept-encoding":"identity","referer":"http://<IP_ADDRESS>:21576/app/kibana","connection":"keep-alive","pragma":"no-cache","cache-control":"no-cache"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:21576/app/kibana"},"res":{"statusCode":404,"responseTime":1,"contentLength":9},"message":"GET /service/kibana/ui/fonts/open_sans/open_sans_v13_latin_300.woff 404 1ms - 9.0B"}
{"type":"response","@timestamp":"2017-12-04T20:23:31Z","tags":[],"pid":16,"method":"get","statusCode":404,"req":{"url":"/service/kibana/ui/fonts/open_sans/open_sans_v13_latin_300.ttf","method":"get","headers":{"host":"<IP_ADDRESS>:21576","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0","accept":"application/font-woff2;q=1.0,application/font-woff;q=0.9,*/*;q=0.8","accept-language":"en-US,en;q=0.5","accept-encoding":"gzip, deflate","referer":"http://<IP_ADDRESS>:21576/app/kibana","connection":"keep-alive","pragma":"no-cache","cache-control":"no-cache"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:21576/app/kibana"},"res":{"statusCode":404,"responseTime":2,"contentLength":9},"message":"GET /service/kibana/ui/fonts/open_sans/open_sans_v13_latin_300.ttf 404 2ms - 9.0B"}
{"type":"response","@timestamp":"2017-12-04T20:23:31Z","tags":[],"pid":16,"method":"get","statusCode":404,"req":{"url":"/service/kibana/bundles/commons.style.css?v=15543","method":"get","headers":{"host":"<IP_ADDRESS>:21576","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0","accept":"text/css,*/*;q=0.1","accept-language":"en-US,en;q=0.5","accept-encoding":"gzip, deflate","referer":"http://<IP_ADDRESS>:21576/app/kibana","connection":"keep-alive","pragma":"no-cache","cache-control":"no-cache"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:21576/app/kibana"},"res":{"statusCode":404,"responseTime":1,"contentLength":9},"message":"GET /service/kibana/bundles/commons.style.css?v=15543 404 1ms - 9.0B"}
{"type":"response","@timestamp":"2017-12-04T20:23:31Z","tags":[],"pid":16,"method":"get","statusCode":404,"req":{"url":"/service/kibana/bundles/status_page.style.css?v=15543","method":"get","headers":{"host":"<IP_ADDRESS>:21576","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0","accept":"text/css,*/*;q=0.1","accept-language":"en-US,en;q=0.5","accept-encoding":"gzip, deflate","referer":"http://<IP_ADDRESS>:21576/app/kibana","connection":"keep-alive","pragma":"no-cache","cache-control":"no-cache"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:21576/app/kibana"},"res":{"statusCode":404,"responseTime":1,"contentLength":9},"message":"GET /service/kibana/bundles/status_page.style.css?v=15543 404 1ms - 9.0B"}
{"type":"response","@timestamp":"2017-12-04T20:23:31Z","tags":[],"pid":16,"method":"get","statusCode":404,"req":{"url":"/service/kibana/bundles/commons.bundle.js?v=15543","method":"get","headers":{"host":"<IP_ADDRESS>:21576","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0","accept":"*/*","accept-language":"en-US,en;q=0.5","accept-encoding":"gzip, deflate","referer":"http://<IP_ADDRESS>:21576/app/kibana","connection":"keep-alive","pragma":"no-cache","cache-control":"no-cache"},"remoteAddress":"<IP_ADDRESS>","userAgent":"<IP_ADDRESS>","referer":"http://<IP_ADDRESS>:21576/app/kibana"},"res":{"statusCode":404,"responseTime":1,"contentLength":9},"message":"GET /service/kibana/bundles/commons.bundle.js?v=15543 404 1ms - 9.0B"}

These are the packages I have installed:
[devops@dcospoc-boot ~]$ dcos package list
NAME      VERSION      APP               COMMAND  DESCRIPTION
elastic   2.1.0-5.6.2  /staging-elastic  ---      Elasticsearch 5, and optionally X-Pack
kibana    2.1.0-5.6.2  /kibana           ---      Kibana 5, and optionally X-Pack
How am I supposed to access it? Is there another way I'm supposed to access the UI?

Do you find an issue for this problem please ?


Search result page: occurences frequency (not) displayed?

In the prototype, the occurence frequencies were displayed, which some found useful.


Window Buttons: kdecorations missing

Describe the bug

Steps To Reproduce
Steps to reproduce the behavior:

Install libsForQt5.applet-window-buttons
Try to apply them

Additional context
I get the same issue, when I download the variant from the build in KDE Store (Get new widgets)
The library in question is this one.
Notify maintainers
@dotlambda

Metadata

system: "x86_64-linux"
host os: Linux 6.1.57, NixOS, 23.05 (Stoat), 23.05.4335.898cb2064b6e
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.13.5
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

How is https://github.com/KDE/kdecoration related to this issue?

I think this is, how appletdecoration is implemented.
P.S: I do get the same error with the version from the KDE widget store (the inbuild one from Plasma itself, that you reach with the "Get new Stuff" button)

@dotlambda There is a fix: https://github.com/psifidotos/applet-window-buttons/issues/193


latest grunt-connect-proxy broken

I'm seeing this:
Loading "connect_proxy.js" tasks...ERROR
>> TypeError: Cannot read property 'prototype' of undefined

Found this grunt-connect-proxy bug.
I resolved by manually:
rm -rf node_modules/grunt-connect-proxy
npm install<EMAIL_ADDRESS>npm install grunt-connect-proxy

Thanks for your issue, can you confirm it's fixed in master? :)

Please reopen if it's still the same with the latest master :)

It is not fixed in master.  I ran into this setting up a project on a new machine with npm install.
Please reopen and fix properly.

(to be clear - it looks this is a bug in grunt-connect-proxy, and 0.2.0 doesn't fix that)

Will try to reproduce than fix.

@thomasvs Can you confirm you're using the right version of eventemitter?
-> % cat node_modules/eventemitter3/package.json | grep version
  "version": "0.1.6",


fix(): Java SDK for Match 360 in CPD4.0.3

:tada: This PR is included in version 1.0.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


NF: add function Repo.restore()

The function restores all committed changes, e.g. if user responds with "no" to promt when asked if assets should be updated.
Close #258

Codecov Report
Base: 90.07% // Head: 90.00% // Decreases project coverage by -0.08% :warning:

Coverage data is based on head (fc0563d) compared to base (c2aefcf).
Patch coverage: 53.84% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #271      +/-   ##
==========================================
- Coverage   90.07%   90.00%   -0.08%
==========================================
  Files          21       21
  Lines        1461     1460       -1
  Branches      321      313       -8
==========================================
- Hits         1316     1314       -2
+ Misses        114      113       -1
- Partials       31       33       +2

Impacted Files
Coverage Δ

onyo/commands/set.py
86.48% <33.33%> (-0.36%)
:arrow_down:

onyo/commands/unset.py
86.48% <33.33%> (-0.36%)
:arrow_down:

onyo/lib/onyo.py
92.01% <66.66%> (+0.02%)
:arrow_up:

onyo/commands/edit.py
93.93% <100.00%> (-1.59%)
:arrow_down:

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

IMO, some of these situations should not do a restore (for example dry-run). However, that conversation is independent of this change, which does improve upon the status quo. I agree that Repo.restore() is useful.
Given that this is a public method, I would really prefer to see a few tests.


Detect comments

I know that comments are not defined in json standard, but many parsers do support them, and I find them useful.
the patch is activated by a preprocessor macro and the original behavior can be restored by commenting its definition.

Automated message from Dropbox CLA bot
@capitalaslash, thanks for the pull request! It looks like you haven't yet signed the Dropbox CLA. Please sign it here and update the thread so we can consider merging your code.

+1

CLA signed

A few design-level points for discussion:

I like that this behavior is optional (so nobody is surprised) but I wonder if it could be a run-time rather than a compile-time option.  It only affects Json::parse, so it would be pretty easy to add an extra argument for configuration, flags, etc.
I don't have experience with other parsers to know if there's a general agreement on comment style here.  The style you chose matches C/C++, Java, and Javascript.  I'd likely have picked '#' as a comment character to match Python, Perl, YAML, etc. but that's just me.  What other parsers have you compared to to determine this is the most likely expected behavior.

I'll make a few inline comments on individual lines too.  I wonder what @j4cbo might think of this too.

Oh, also, welcome, and thanks for your contribution!  Forgot to say that in my diving straight into business. :)

cumulative reply to your points:

I went for compile-time activation so that it would not affect performances at all when not needed. no problem on my side to have it run-time activated.
as json comes from javascript it feels natural to have javascript-style comments. even the python json module parses c-style comments.
I wll go for the loop instead of recursion, patch coming.
more tests coming.

I went for a bool argument with the default set to false, that is quite opaque.
We can go for a properly named bit-flag if you think it would be better.

I added a few more inline comments, primarily about some issues with size checks which I didn't see on my first look.
I agree with your concern about the opacity of a boolean argument.  One approach I've used to avoid that in the past is an enum.  You can declare an enum with values like JsonParse::STANDARD and JsonParse::COMMENTS, and pass one or the other instead of the boolean, to make the intent explicit.  That approach also can eventually grow to allow enum values to be combined like bitfields, but I wouldn't worry too much about supporting that preemptively.

should have addressed all your concerns.
the enum works great for this.

Looks good.  Just one off-by-one check to point out.

ok, fixed.

Thanks!  Merging.


Force user logout before token expiry

If a horizon user's token expires during long running operations, those
operations can fail. This occured during long running heat operations
(eg multiple stack deletions). We address this by setting the
TOKEN_TIMEOUT_MARGIN to 10 minutes. This will log the user out 10
minutes before the token expires.
We also set the horizon session timeout to 50 minutes for clarity.
The newtoken code was previously added under the assumption that the
token could be extended. This is incorrect and that code has been
removed.
Partial-Bug: 1797186
Signed-off-by: David Sullivan<EMAIL_ADDRESS>

I think we could revert these settings in settings.py to upstream and put the customizations in our local setting file here (https://github.com/openstack/stx-upstream/blob/master/openstack/python-horizon/centos/files/local_settings.py), like we do with our other changes.  Not sure why we modified this file initially.
Also there's a typo in the comment "user"

That sounds like a much better option, I was wondering why we would do that here. Let me try that fix and I'll update this PR.

It's specific to stx as we aren't using the TOKEN_TIMEOUT_MARGIN parameter (which was introduced in pike).

LGTM
Thanks David

OK it should be good to go now. I've added another commit to remove the changes from settings.py. Those changes will be made in local_settings.py in stx-upstream. Please squash the commits when you merge the PR.

Looks good, thanks for changing