Any unhandled error causes acceptance tests to fail, making it impossible to test error states

Hi!
In our app, we catch errors in order to display flash messages to the user, letting them be aware of an error and offering a chance to retry.
We choose to re-throw the error after displaying the flash message. This is because we want the error to be caught by an error tracking service such as Sentry, Bugsnag, TrackJS, Raygun, etc.
The problem is that QUnit tests would crash on any uncaught error, making it impossible to test error reporting.
There are two userland workarounds from this issue:

Choose not to re-throw an error. I don't like this approach because it would require adding manual error tracking commands into every catch block.
Re-throwing conditionally, only in non-test environment. This is more or less OK, but I don't feel comfortable adding exceptions for tests. I believe, it's a slippery slope.

Previously, it was possible to override Ember.Test.adapter.exception and prevent tests from failing on uncaught assertions. The best part is that you could check for a condition (e. g. a certain error code or message) and re-throw an error if it was not the one you were expecting.
But according to ember-qunit source, it is no longer possible in modern Ember:
// Ember 2.17 and higher do not require the test adapter to have an `exception`
// method When `exception` is not present, the unhandled rejection is
// automatically re-thrown and will therefore hit QUnit's own global error
// handler (therefore appropriately causing test failure)

How do I prevent QUnit from crashing on unhandled errors? What is the modern replacement for overriding Ember.Test.adapter.exception?

Note that this is not a problem for ember-mocha. Mocha-driven tests do not crash when Ember Data rejects a promise.

Here's what I figured out:

QUnit is designed to fail tests on all errors, including unhandled rejected promises. Mocha won't do that unless you use an assertion against a rejected promise.

QUnit does not have an API to squelch those errors, making a test pass. There is assert.throws, but:

It can't be used with Cucumber-style tests, which execute a linear list of steps, and steps can't be nested.
It seems to be synchronous. If I get it right, you can't use it with async code and instead have to catch the failing promise.
But there is no access to Ember Data promises from an acceptance test.

Ember.onerror is an old and quite poorly documented feature of Ember:

It is mentioned once in the guides as a simple hook for Sentry/Bugsnag.
It's never mentioned in the API docs.
It does not have an export.
It does not offer pub/sub, meaning two addons can't use it.

I had an impression that Ember.onerror is a candidate for deprecation and should be avoided. @amk221 kindly helped me understand that it has special behavior in ember-qunit: catching an error in Ember.onerror would prevent QUnit from failing a test!

At the same time, QUnit would ensure Ember.onerror is not catching all errors. In case it does, you should see a failing test case. To avoid this, you need to re-throw errors after catching them in Ember.onerror.

@amk221 pointed out that Ember.onerror only catches errors that are thrown within the Ember runloop.
The solution is to wrap it with run from '@ember/runloop'. This is the first time I've had to use run in app code.

Now I have control over errors in tests again, which I lost after Ember.Test.adapter.exception was removed.
Big thanks to @amk221 for taking time and effort to help me figure this out.

Though my immediate problem is resolved, I'm gonna leave this issue open because:

Ember.onerror behavior in tests needs to be documented.
I would like to start a discussion over the future of Ember.onerror. We probably need an RFC to introduce a tool that can be imported and allows pub/sub, so that it can be used without overwriting other uses.

Just to follow up on the conversation @lolmaus and I had on discord
The pseudo code that helped was:
Ember.onerror = () => {
  if (i want to ignore this error) {
    return;                                 // 1
  }

  if (Ember.testing) {
    throw error;                            // 2
  }
}

Be able to test error states in the test suite
Satisfy validateErrorHandler

FWIW, setupOnerror (from @ember/test-helpers) is specifically attempting to make that one off setup easier.

To specifically answer the original question:

How do I prevent QUnit from crashing on unhandled errors? What is the modern replacement for overriding Ember.Test.adapter.exception?

You would do something akin to:
import { setupOnerror } from '@ember/test-helpers';

test('....', async function(assert) {
  setupOnerror((error) => {
    // do nothing, throw, whatever you want
  });

  await visit('/whatever');
  // ...more stuff...
});

@rwjblue Thanks, that works great, but only if you use RSVP. Here is a basic example demonstrating the problem.
Imagine you have an app that used to have:
actions: {
  doSomethingAsync() {
    return this.service.doSomething().then(() => {
      this.flash.add('done');
    }).catch(error => {
      this.flash.add('failed');
      throw error;
    });
  }
}

...but now you want to modernise to use async/await...
@action
async doSomethingAsync() {
  try {
    await this.service.doSomething();
    this.flash.add('done');
  } catch(error) {
    this.flash.add('failed');
    throw error;
  }
}

setupOnerror is never called, so the opportunity to squelch the thrown error never happens.

I think it fully depends on the actual test in question. Generally speaking, there is no magic bullet for handling native promise rejections. The fact that it is possible in RSVP has been a convenient crutch for us for a while, but just doesn't match our future reality.

there is no magic bullet for handling native promise rejections

Please let me reiterate as I'm struggling to understand. Point out where I make a mistake or a false assumption.
The problem is that QUnit chooses to crash tests on all unhandled promise rejections (with exceptions mentioned above).
Given that QUnit is part of Ember apps by default (and the only real alternative, ember-mocha, is falling behind and not quite usable), we need a solution for this.
If the case of failed tests on unhandled native promises "works as intended, then we need guidelines how to deal with unhadled promises. E. g. should the developer always take care of catching all promises that they spawn?
It's not that obvious, because some async methods are hooks which are handled by Ember internals (sometimes too aggressively — you might not see the error at all, or it might be caught and rethrown elsewhere with an entirely irrelevant stack trace), but others like an action in @amk221's example are not handled automatically.
So two points here:

A typical Ember developer does not have a habit of catching promises because Ember guides never state that they should, and it works in most cases until it suddenly doesn't, and it's absolutely frustrating.
If promises must never be left uncaught, guides need to be updated to develop this habit in Ember users.
How do we even handle promises? Take @amk221's example. What can be done to resolve the problem? The only thing I can think of is replacing throw error with something like this.metrics.trackError(error). Is that what we're supposed to do?

PS Thank you for looking into this matter.

@lolmaus - I'll try to reply to the various sections independently (as there are a few separate points you are making).

The problem is that QUnit chooses to crash tests on all unhandled promise rejections (with exceptions mentioned above).

FWIW, I think this is the correct stance for QUnit to take (and IIRC I implemented it waaaaaaay back in 2017 https://github.com/qunitjs/qunit/pull/1241). Unhandled exceptions (and unhandled promise rejections) are bad, and in most circumstances point to an actual problem in the application.

If the case of failed tests on unhandled native promises "works as intended", then we need guidelines how to deal with unhandled promises

I totally agree with you here! We absolutely should document how to handle situations like @amk221's.

It's not that obvious, because some async methods are hooks which are handled by Ember internals (sometimes too aggressively — you might not see the error at all, or it might be caught and rethrown elsewhere with an entirely irrelevant stack trace), but others like an action in @amk221's example are not handled automatically.

I agree that it is unclear how Ember's internals handle unhandled rejections. I think we should update the documentation for all async route hooks to explicitly say what happens when an exception occurs. For example, if an exception occurs during model and you have an error substate or error action that rejection is automatically handled for you (this is why you don't commonly see the problem you are reporting for that category of code). I also think that doing that documentation will significantly help folks think about how exceptions / rejections are handled by the system (and therefore how they should be handled by their own code).

A typical Ember developer does not have a habit of catching promises because Ember guides never state that they should, and it works in most cases until it suddenly doesn't, and it's absolutely frustrating.

To reiterate, I agree with you. We should increase both API and guide documentation for exceptions/rejections and how application developers should handle those situations. FWIW, I do not think the answer is "never leave them uncaught" (as sometimes you really do intend for an error / rejection to bubble all the way up loudly).

How do we even handle promises? Take @amk221's example. What can be done to resolve the problem? The only thing I can think of is replacing throw error with something like this.metrics.trackError(error). Is that what we're supposed to do?

I am totally on board with the idea that we should identify specific use case / scenarios, and solve for them. That will help us know what to document (and where). Unfortunately, the example doesn't have enough information. What is triggering this action? What does the test look like? What kind of test? etc.

Ultimately, I think we should (mostly in order):

attempt to summarize the cases that we are trying to work through (no, the general "unhandled rejections" bucket is not good enough 😝 )
ensure that they are all possible to test
determine what changes are needed (either here in ember-qunit, in @ember/test-helpers, ember-source, etc) to make those tests a tad less onerous (IMHO the tests making it clear that an unhandled rejection will be happening is totally fine)
once we understand the scenarios, create detailed issues (or PRs :wink:) for the API docs and guides that we think we need

Oh, also, I wanted to point out that this bit (from the original issue text) just isn't a factor here:

Previously, it was possible to override Ember.Test.adapter.exception and prevent tests from failing on uncaught assertions. The best part is that you could check for a condition (e. g. a certain error code or message) and re-throw an error if it was not the one you were expecting.

Anything that Ember.Test.adapter.exception would have caught is handleable (IMHO in a better way) with setupOnerror from @ember/test-helpers.

Thanks!

the example doesn't have enough information

I'll try and explain a bit more... I use the errors for flow control 🙈, e.g.
@action
attempt() {
  return this.validate()
   .then(() => this.save())
   .then(() => this.modal.close(();
}

this.validate throws, so that this.save never happens. It is that that is causing me grief. I realise it's frowned upon to use errors for flow control, so I could stop doing that.

Gotcha. Where are you calling this.attempt() from? What kind of test is this?

I've also come across this issue today, where setupOnerror couldn't catch the exception. It slipped through QUnit and caused the test to fail. Good thing is I'm quite clear on what I did and what's my temporary fix.
The "expected behavior": I do abort a transition under a specific condition transition.abort().
Original Tests:
    const lock = confirmService.lockCurrentRoute();
    await visit('/route-b');
    assert.equal(currentURL(), '/route-a');

(I'm trying to visit route-b which is blocked). This resulted in:

Which then I wanted to test with:
    setupOnerror(function (error) {
        assert.ok(error); // or even more precise: assert.equal(error.name, 'TransitionAborted');
    });
    const lock = confirmService.lockCurrentRoute();
    await visit('/route-b');
    assert.equal(currentURL(), '/route-a');
    setupOnerror();

Here is the actual workaround:
    const lock = confirmService.lockCurrentRoute();
    try {
      await visit('/route-b');
    } catch (error) {
      console.log(error);
    }
    assert.equal(currentURL(), '/route-a');

Hope this brings some insights.

Would you mind making a repo with a small demo?

Sure: https://github.com/amk221/-ember-error-flow-control

Just encountered the same issue while upgrading ember-qunit from 4.6.0 to 5.1.3

Same here, is this planned to be fixed/updated by any chance?

I run into another case of errors, which aren't going through Ember.onerror and therefore can not be handled with setupOnerror in tests: Event listeners assigned with {{on}} modifier.
Assume we have this template-only component:
<button {{on "click" @onClick}} type="button">
  click me
</button>

Now we want to write a test for it, that it does not silently catch errors thrown by function passed to @onClick argument. My first attempt would look like this:
test('it does not catch errors thrown by @onClick handler', async function (assert) {
  const expectedError = new Error();

  setupOnerror((error) => {
    assert.step('error is thrown');
    assert.equal(error, expectedError);
  });

  this.set('clickHandler', () => {
    throw expectedError;
  });
  await render(hbs`<Button @onClick={{this.clickHandler}} />`);
  await click('button');

  assert.verifySteps(['error is thrown']);
});

But the error is not handled by Ember.onerror. Therefore setupOnerror is not working. Without monkey-patching QUnit's internals it is impossible to test this.
Please find a reproduction here: https://github.com/jelhan/reproduce-component-event-handler-throws-testing-issues/compare/b95001721b9b027c444926db168975ed846fdac3...master It also contains a very hacky work-a-round, which requires monkey-patching QUnit.
This is driven by a real-world use case in Ember Bootstrap. A component provided by Ember Bootstrap silently catches errors of the event handler. This is considered a bug. Fixing the bug is easy. Adding tests for it is way more challenging. And even worse: Other existing tests, which tests behavior in case event handler rejects, are affected by that bug fix as well. So fixing the bug without adding tests is not an option. It would require even to disable existing tests. :sob:

Hi @rwjblue !
Any progress on this one?

Ran into this problem again with a test that intentionally returns HTTP 500 from a mocked API endpoint. QUnit chooses to crash a test on a rejected promise.
setupOnerror is not doing anything for this case.
An HTTP 500 error should be not an unexpected case, and this is how it is handled gracefully:
{{#if this.submitTask.isRunning}}
  Submitting...
{{else if this.subitTask.last.isError}}
  Something wrong happened:
  {{format-error this.submitTask.last.error}}
{{/if}}

I was able to resolve it like this.
Before (simplified):
<button {{on "click" (perform this.submitTask)}}>Submit<button>

After:
<button {{on "click" (this.submit)}}>Submit<button>

  @action
  async submit(): Promise<void> {
    try {
      await this.submitTask.perform();
    } catch(e) {
      // We don't want tests to unconditionally crash when this happens.
      // The error will be handled by `submitTask.last.isError`
    }
  }

So this action only exists to wrap the Ember Concurrency task with a do-nothing try-catch block.
Apparently, the {{perform}} helper of Ember Concurrency should be considered faulty because it won't catch failed or cancelled tasks, causing tests to fail.  🤷♂
I don't think that rejected promises should crash tests. Handling it requries too much runtime boilerplate that is absolutely unnecessary for production and only exists to please QUnit.
As for failed transitions, I don't even know how to wrap them.
CC @simonihmig

https://github.com/snewcomer/ember-stateful-promise/blob/f151a254f1ad7a060e474abd551e686e83723b8f/tests/integration/components/playground-test.js#L13
This is what I did for a very specific use case of purposefully rejecting promises in the library.

@snewcomer I came here to say https://api.qunitjs.com/extension/QUnit.onUncaughtException/, which is available and public API as of<EMAIL_ADDRESS>works nicely.
FWIW, I've opened https://github.com/DefinitelyTyped/DefinitelyTyped/pull/57770 to update the qunit types to include this hook.

I've started a PR to finally fix this: ember-test-helpers#1194. I would appreciate your thoughts!

I am getting issue with if(Ember.testing ) { throw error} condition -
I have added the Ember.onerror in my App.js route, also there is one component in node-module where there is Ember.onerror is use with if(Ember.testing ) { throw error}. So when I generate the error it goes to inside the node-module component, whereas i expected it will trigger my App.js route.
Please can someone help me how to keep my App.js onerror function to trigger instead of the node-module component?

There are some techniques / platform APIs to catch errors: https://github.com/emberjs/ember-test-helpers/issues/1128#issuecomment-1920196763
I don't know the timing of QUnit.onUncaughtException and the browser-based unhandledrejection event (what the above explores), but given that both these tools now exist, I think we can close this issue (as the problem isn't really anything wrong with ember-qunit, per se (feel free to disagree tho! :sweat_smile: I can be convinced!)).
There is a desire among a good few (many?) to have setupOnerror also listen to this type of error event, so maybe there is a PR in someone's future to add that capability? 🥳

It seems to be like setupOnerror is a poor mans try-catch. Why can't we do this:
test('something we know will fail', function() {
  assert.expect(1);

  try {
    await visit('/');
  } catch(error) {
    // squelch, since we are testing an error scenario
  }
});

What we should target for:
await assert.rejects(
  visit('/')
);

assert.rejects(
  click('button')
);

But I fear there are architectural limitations in Ember.js itself, which prevents it for most use cases...
Last time I tried working around the limitations with QUnit.onUncaughtException and unhandlerejection browser event, I run into many issue. And it was breaking over time with upgrades of Ember, QUnit, and other libraries. Maybe it got better. But it's still far away from a good testing story for error cases.

Why can't we do this

This is actually how you test beforeModel transitions aborts :sweat_smile:
See: https://github.com/emberjs/ember-test-helpers/issues/332


Add description flag to tod task create

Here are the docs for create task on the Todoist API https://developer.todoist.com/rest/v2/#create-a-new-task
Add a description flag to the tod task create command. There is no default.

Closing duplicate


Support for HTML attachments

Bounty
See the Contribution guidelines for how to claim this bounty.
Bounty: $100 USD
Timeframe: 7 days
Requirements
Improve the HTML importer by adding support for attachments

[ ] Add support for attachments (images, video, audio)
[ ] Follow the user's setting for Default location for new attachments
[ ] Use Obsidian-style embed links ![[image.png]]
[ ] Avoid importing icons/logos that are not part of the content of the page

I might be interested. I have plugins in the community plugins and the requirements are simple enough, so I believe I could do this one.
But where would one ask for clarification of requirements though? Like I am wonderimg whether "maintain folder structure" means I need to create subfolders under the attachment folder or a flat structure would do. Also, should we work from the master branch or some other branch like html-import?

Right, I think I understand now. Thank you.
On Tue, Jul 25, 2023 at 10:51 PM Stephan Ango @.***>
wrote:

@polyipseity https://github.com/polyipseity You can ask questions about
the requirements here.
Like I am wonderimg whether "maintain folder structure" means I need to
create subfolders under the attachment folder or a flat structure would do
There is a user setting called Default location for new attachments with
several options under Obsidian Settings → Files and links. The attachments
location should respect the user's setting.
Also, should we work from the master branch or some other branch like
html-import?
See the guide
https://github.com/obsidianmd/obsidian-importer/edit/master/CONTRIBUTING.md.
You would fork the repo and PR from there.
—
Reply to this email directly, view it on GitHub
https://github.com/obsidianmd/obsidian-importer/issues/28#issuecomment-1649992659,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEGXX6VR4SE7PYHPSVWG3V3XR7MM7ANCNFSM6AAAAAA2WB5PPU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Yes, you can apply. See contribution guidelines.

Yea, I confirm that I am applying.
(I must be bad at language or something, I thought my intention to apply is
already clear. 😅)
On Wed, Jul 26, 2023 at 8:39 AM Stephan Ango @.***>
wrote:

Yes, you can apply. See contribution guidelines.
https://github.com/obsidianmd/obsidian-importer/blob/master/CONTRIBUTING.md
—
Reply to this email directly, view it on GitHub
https://github.com/obsidianmd/obsidian-importer/issues/28#issuecomment-1650782758,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEGXX6UK2XPICQ5WBZEKEDLXSBRLDANCNFSM6AAAAAA2WB5PPU
.
You are receiving this because you were mentioned.Message ID:
@.***>

To apply please provide the following. We will wait a few days to see if other developers are interested.

1-2 sentences about why you would be a good fit
1-2 sentences about how you would approach the requirements
Links to code samples, e.g. Obsidian community contributions

I think that I have probably spent enough time with the Obsidian API to know what and how API methods and classes should be used.
(Two sentences is a bit short, but I will try to shorten the sentences.)

Load files and call htmlToMarkdown. (currently implemented)
Identify external embeds ![alt](link).
Filter links either by extension in the URL (no request needed, but could be inaccurate or unavailable) or returned content type (requires a request; filter by checking whether the type starts with image/, audio/, or video/). This filter could be user-configurable in the import dialog. If configurable, filtering by file extension is more understandable to end users than content type.
Collect all the links and deduplicate them (embeds pointing to the same URL).
Download them using requestUrl and put them into the user-configured (Default location for new attachments) attachment folder. If filenames collide, add an increasing number to distinguish them (File 1.png, File 2.png, File 3.png...). Ideally, there should be a separate count for successful, failed, and skipped (filtered) attachment downloads in the results.
Replace external embed links with either wikilinks or Markdown links according to the setting Files & Links > Use [[Wikilinks]]. Embeds with failed downloads are unchanged.
The steps from ii to v should run concurrently (async) with i and vi so that the downloads start when the first link in the first file is identified instead of waiting for all the links in all files to be identified.
The current implementation reads, processes, and saves each HTML file one by one in  a for loop (file reads and writes are comparatively slow compared to code execution), which can be improved by using Promise.allSettled instead: https://github.com/obsidianmd/obsidian-importer/blob/77155aef1576bd5c5b9b8b460d8e7e8be14ae0cf/formats/html.ts#L31-L42

A plugin is a lot of code sample to go through, so I will link the PR instead: https://github.com/obsidianmd/obsidian-releases/pull/1472. There are also 2 ongoing PRs: https://github.com/obsidianmd/obsidian-releases/pull/2189, https://github.com/obsidianmd/obsidian-releases/pull/2197

Since Node APIs are used anyway, we can convert local file paths to and from file URLs using pathToFileURL and fileURLToPath. Then if the protocol of the URL is file:, read the file directly instead of going through requestUrl and copy the file to the vault.
For resolving local relative paths URLs, the URL constructor has a base second argument, so doing new URL(linkPath, pathToFileURL(htmlPath)) will correctly resolve them.

Something I have been wondering about is how to make sure we only import the attachments that are related to the content of the article. Many web pages have logos/icons embedded in the HTML but we probably should only import the images/etc that are in the content of the page.

Perhaps image size could be used. If the image is within 64 px x 64 px (or user configured size), then it is considered an icon or logo. The external embed link could be removed if it is an icon or logo.

@polyipseity You are assigned! Please make sure to submit your PR by end of day (GMT) on August 4th, 2023. Thanks!
Join the #plugin-dev/importer channel if you have any questions: https://discord.gg/obsidianmd

We are increasing the bounty reward to $300 since this was a bigger project than anticipated.


Don't run enable_ca_trust on EL7

update-ca-trust ignores all arguments on EL7 so update-ca-trust enable and even update-ca-trust check (from the unless parameter)
actually perform an update.
Fixes #GH-38
I've converted the spec tests for that class to use rspec-puppet-facts.

Thanks for working through this one - we're not a big RHEL shop so this one was low on the list even though it looks pretty important.


Disable Add for a specific Model

Is this possible?

you can do that with css hack to now showing the add button for now

How would I do that for just one of the entities?

return ''. $this->returnView();


Fix break in package build

PR Summary
Pin ffi to 1.12 to fix break in package build
PR Context
https://github.com/jordansissel/fpm/pull/1709
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[x] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

@TravisEz13 Can you reframe the title to include ffi version pinning in it?

@PoshChan please retry static

@adityapatwardhan, successfully started retry of PowerShell-CI-static-analysis


frontend run error

Build and run frontend on windows.  Receive window is not defined error
npm: 10.2.0

<EMAIL_ADDRESS>dev
next dev

(node:17772) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
(node:25200) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
ready - started server on <IP_ADDRESS>:3000, url: http://localhost:3000
Browserslist: caniuse-lite is outdated. Please run:
npx update-browserslist-db@latest
Why you should do it regularly: https://github.com/browserslist/update-db#readme
event - compiled client and server successfully in 5.9s (273 modules)
wait  - compiling...
event - compiled successfully in 411 ms (235 modules)
wait  - compiling / (client and server)...
wait  - compiling /_error (client and server)...
event - compiled client and server successfully in 23.9s (20964 modules)
warn  - Fast Refresh had to perform a full reload due to a runtime error.
error - ReferenceError: window is not defined
at detect (C:\proj\llm\openagents\github\OpenAgents\frontend\node_modules\echarts\dist\echarts.js:123:54)
at C:\proj\llm\openagents\github\OpenAgents\frontend\node_modules\echarts\dist\echarts.js:97:9
at C:\proj\llm\openagents\github\OpenAgents\frontend\node_modules\echarts\dist\echarts.js:22:68
at Object. (C:\proj\llm\openagents\github\OpenAgents\frontend\node_modules\echarts\dist\echarts.js:25:2)
at Module._compile (node:internal/modules/cjs/loader:1376:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
at Module.load (node:internal/modules/cjs/loader:1207:32)
at Module._load (node:internal/modules/cjs/loader:1023:12)
at Module.require (node:internal/modules/cjs/loader:1235:19)
at require (node:internal/modules/helpers:176:18)
at Object.echarts (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:1391:18)
at webpack_require (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:33:42)
at eval (webpack-internal:///./components/Datatype/Chart/Echart.tsx:9:65)
at ./components/Datatype/Chart/Echart.tsx (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:491:1)
at webpack_require (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:33:42)
at eval (webpack-internal:///./components/Chat/ChatRichContentItem.tsx:15:91)
at webpack_require.a (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:97:13)
at eval (webpack-internal:///./components/Chat/ChatRichContentItem.tsx:1:21)
at ./components/Chat/ChatRichContentItem.tsx (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:293:1)
at webpack_require (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:33:42)
at eval (webpack-internal:///./components/Chat/ChatMessage.tsx:16:94)
at webpack_require.a (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:97:13)
at eval (webpack-internal:///./components/Chat/ChatMessage.tsx:1:21)
at ./components/Chat/ChatMessage.tsx (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:282:1)
at webpack_require (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:33:42)
at eval (webpack-internal:///./components/Chat/Chat.tsx:18:70)
at webpack_require.a (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:97:13)
at eval (webpack-internal:///./components/Chat/Chat.tsx:1:21)
at ./components/Chat/Chat.tsx (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:249:1)
at webpack_require (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:33:42)
at eval (webpack-internal:///./pages/api/home/home.tsx:41:80)
at webpack_require.a (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:97:13)
at eval (webpack-internal:///./pages/api/home/home.tsx:1:21)
at ./pages/api/home/home.tsx (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:722:1)
at webpack_require (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:33:42)
at eval (webpack-internal:///./pages/api/home/index.ts:7:63)
at webpack_require.a (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:97:13)
at eval (webpack-internal:///./pages/api/home/index.ts:1:21)
at ./pages/api/home/index.ts (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:733:1)
at webpack_require (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:33:42)
at eval (webpack-internal:///./pages/index.tsx:7:67)
at webpack_require.a (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:97:13)
at eval (webpack-internal:///./pages/index.tsx:1:21)
at ./pages/index.tsx (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:744:1)
at webpack_require (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\webpack-runtime.js:33:42)
at webpack_exec (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:1764:39)
at C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:1765:28
at Object. (C:\proj\llm\openagents\github\OpenAgents\frontend.next\server\pages\index.js:1768:3)
at Module._compile (node:internal/modules/cjs/loader:1376:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1435:10) {
page: '/'
}

Hi, sorry we haven't thorough test on windows yet. Could you try the docker deployment because it is os-agnostic? Or you might check the node and npm versions. The node 18.7.0, npm 8.15.0 or node 21.0.0 + npm 10.2.0 pair work for now.

I have the same problem with macos, npm 10.2.3, node 21.2.0.

Btw, it seems to be a known issue for node 21.0, please refer to this issue https://github.com/apache/echarts/issues/19233

Please refer to #42 that solves this issue by down-grading npm and node.


Remove annoying popup after minimizing to system tray

My Setup

Operating System: Windows 10
App Version: 3.0 +
Installation type: exe

[x] I have tested with the latest version
[ ] I can simulate the issue easily

Description
Same as in title, please do something about it quickly, thanks.
Current Behavior
When minimizing app to system tray the popup is displayed informing about the app is still running, when you click it, the app is restoring itself back to view, and now You can minimize it again and popup is shown again, and you can minimize it ......
It is stupid, please remove this popup, as I think when user is minimizing the app, it knows that it runs in background.
Expected Behavior
Nothing at all, app should minimize and run in background as it was before update to version 3.0.

Duplicate of #1749


address hanging process on SASS syntax error

Problem: A syntactic error in a SASS file may lead to a hanging process due to a known issue in node-sass (https://github.com/sass/node-sass/issues/1048).
Solution: Invoke sass.renderSync instead of sass.render.
Discussion:

The issue occurs, for instance, when running the plugin within grunt-postcss (e.g. when compiling test/sass-error.css in this PR). Any SASS syntax error appears to lead to a hanging process.
The PR adds a test case to verify a clean exit on encountering a SASS syntax error (sass-error.css). As part of the tape test suite, this test succeeds with the original postcss-sass code. I am not sure how to explain this fact; the internal logic of a tape test in npm may account for it.
The suggested solution in https://github.com/sass/node-sass/issues/1048 does not appear to address the issue when running in grunt.
My proposal is to invoke sass.renderSync and catch any error it may emit.
As a side-effect of invoking sass.renderSync instead of sass.render, the existing test of import functionality (test/imports.css) now triggers the (appropriate) deprecation warning "Including .css files with @import is non-standard behaviour which will be removed in future versions of LibSass" (see, for instance, https://github.com/sass/node-sass/issues/2362). (This message could be suppressed by adding the .css extension to @import statements in test/import.css, but then  the test imports:postcss would fail.)

Jonathan, thank you for your work on this plugin!
Best wishes,
M.

Is this still an issue in Sass? This is a very clever work around that I’m not entirely opposed to adding, but I’d prefer it were resolved on Sass’ side, of course.

Your 3.0.0 commit (with many version updates) seems to take care of the issue.
Many thanks!


fix(cdk/schematics): fix resolving modules in ng update

Closes #21160

@crisbeto The material schematics tests runs into a memory issue. I suspect this is due to the migration now correctly resolving all related files, but I cannot say for certain. Do you have an idea on how this could be fixed?

Even if it is resolving more files than before, we'd have to try really hard to get it to run out of memory. Could it be hitting an infinite loop somewhere? Also does this happen if you run the tests locally?

Yes, I'm trying to investigate it right now. I need to setup the bazel debugging...

I have currently narrowed it down to the material-imports.spec.ts and the hammer-migration-v9.spec.ts. I'm currently debugging it, to see what is happening.

Ok, the problem seems to be, that getDir in the HostTree treats a non-existent file path as a potential directory. This means getDir cannot be used to assert a path being a directory (and is also does not expose the isDirectory of its nested host).
I'll see if there is an alternative solution.

@crisbeto I have refactored the directory check to query, if the parent directory has the given directory as a subdir. Please have another look.

No problem, thank you for the quick response. 😃
Do you think a release with this fix is possible this week or is that unlikely?
Depending on this we will wait for the release or try to provide a workaround internally in our company.

Since this is only schematics code, it can be merged in quicker, but I can't guarantee when it'll be released.

Ok, that's not a problem.
The workaround is to simply run ng update package --migrateOnly --from=10 --to=11, so we can live with that.

@crisbeto I tested this with a few real life projects from our company and discovered an additional problem. When projects import package.json, typescript checks potential entry points (e.g /package.json/package.json and /package.json/index.ts) which would result in a failure with getDir. To avoid this I added a check to verify that the parent "directory" is not an existing file.


modify function: normalizeCounts(), normalizeLogProbs()

replaced the sweep() by mvMult() and mvAdd() within the normalizeCounts() and normalizeLogProbs()

@Irisapo Several unit tests failed with this code (see the Travis build output for more details). Can you make sure that these tests pass on your computer, and add any new code to make them pass to this pull request?


Can someone push the latest image to hub.docker ?

As in subject. Latest on github is .43, latest on hub is 39.
I'm building them locally now and then hosting those, but would rather have it done automagically, which means I can play whenever I want before checking if versions match :)

You are looking on the wrong repo. The latest is 0.17.43 over here https://hub.docker.com/r/factoriotools/factorio/tags


Unification issue

Hey so i was looking through REI when i noticed that all of the default assembler recipes got removed.
The normal amount should be 311 recipes while REI only shows 22 recipes with the material.js enabled. It looks like it's the AOF unification script that seems to be causing it because when i disable the unification script all of the default assembler recipes appears.

This seems to be an MI issue, which has been fixed in the latest beta. will try

Fixed by updating Modern Industrialization


support for volume labels

Volume labels were recently added to docker. See https://github.com/docker/docker/pull/21270
Creating  a label via docker to swarm.
docker volume create -d flocker --label owner=ryan --name test4 -o size=75G

Output
$ docker volume inspect test4
[
    {
        "Name": "test4",
        "Driver": "flocker",
        "Mountpoint": "",
        "Labels": null
    }
]

Expected response
$ docker volume inspect test4
[
    {
        "Name": "test4",
        "Driver": "flocker",
        "Mountpoint": "",
        "Labels": {
            "owner": "ryan"
        }
    }
]

The only way to see the label is to SSH to the node and run inspect on the local docker daemon.
docker-machine ssh mha-demo1
root@mha-demo1:~# docker volume inspect test4
[
    {
        "Name": "test4",
        "Driver": "flocker",
        "Mountpoint": "/flocker/8c22e40c-2519-4db6-9e9b-904bbbb6ea98",
        "Labels": {
            "owner": "ryan"
        }
    }
]

docker version to swarm from client
Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Wed Apr 27 00:34:20 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      swarm/1.2.2
 API version:  1.22
 Go version:   go1.5.4
 Git commit:   34e3da3
 Built:        Mon May  9 17:03:22 UTC 2016
 OS/Arch:      linux/amd64

docker version from a docker host in the swarm cluster.
docker version
Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:30:23 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:30:23 2016
 OS/Arch:      linux/amd64

I reproduced this issue.
Actually I think this is an issue of Docker Engine.
@wallnerryan @nishanttotla
As I call <IP_ADDRESS>:2376/volumes against docker engine with no labels:
{
  "Volumes": [
    {
      "Name": "allen",
      "Driver": "local",
      "Mountpoint": "/var/lib/docker/volumes/allen/_data",
      "Labels": null
    },
    {
      "Name": "test5",
      "Driver": "local",
      "Mountpoint": "/var/lib/docker/volumes/test5/_data",
      "Labels": null
    }
  ],
  "Warnings": null
}

while calling <IP_ADDRESS>:2376/volumes/test5 has label details:
{
  "Name": "test5",
  "Driver": "local",
  "Mountpoint": "/var/lib/docker/volumes/test5/_data",
  "Labels": {
    "owner": "ryan"
  }
}

I will try t report this in docker/docker.

An appropriate bump in the engine-api vendoring should fix this by properly vendoring a newer version of the types.Volume struct which includes the Labels field.
Speficially, the engine-api vendor of swarm needs to include the following two commits in order to support labels for volumes and networks:
https://github.com/docker/engine-api/commit/37d4a7ad84d56164b127b12d1c720ad430143973
https://github.com/docker/engine-api/commit/95cfeb66ab637e09d14fab3a8eeae7da052697f4

@allencloud This work is tracked under #2253.

@dongluochen
I am afraid more work needs to be done ranther than https://github.com/docker/swarm/issues/2253.
Because docker engine's api did not provide labels in /volumes/{*name}, while this has no relationship with engine-api's docker client.
More infomation :
https://github.com/docker/docker/issues/22838
https://github.com/docker/docker/pull/22077

@dongluochen @allencloud I believe this issue has surfaced two separate problems:

GET /volumes/id does not return the labels for a specific volume, even though the engine does so. I believe that's what the engine-api bump would resolve in this case but feel free to correct me if that's not the case
GET /volumes does not return the labels for any volume, and the engine fails to do so either

@wallnerryan This should work if you use a recent CLI and Docker Engine with Docker Swarm, as confirmed by @alexmavr. We'll close the issue today, please comment if you're unable to get it to work.

thanks @nishanttotla will try this out soon !


Remove stats access for users before launch

also, existing pre-launch stats should be deleted, so that tests do not influence the results


[YUNIKORN-964] upgrade image base to 1.21.4-alpine

Fix vulnerabilities in the base image by moving to later version.
What is this PR for?
Upgrade the docker base image to fix OS vulnerabilities.
What type of PR is it?

[X ] - Bug Fix

What is the Jira issue?
https://issues.apache.org/jira/browse/YUNIKORN-964
How should this be tested?
any build and deploy will use the new image
Screenshots (if appropriate)
Questions:
NA

CI is failing with the error:
Node.js version v12.14.1 detected.
The Angular CLI requires a minimum Node.js version of either v12.20, v14.15, or v16.10.

Not sure where 12.14.1 in the above message came from. But the node version in the base image is 12.13.1, which needs to be bumped up

The 12.14.1 comes from the github action. The real make image build runs from the Dockerfile only. We need to update both of them. We should never have been out of sync between the github action and the Dockerfile. I will correct that too.


How to disable logging in embedded ETCD?

I want to use the embedded ETCD for integration tests. The tests become quite noisy with the output and I'd like to disable this.
I noticed a LogPkgLevels key in embed.Config but I'm not sure what i need to enter here for it to have some effect. Looking through I see capnslog is used. My best guess so far looks something like this but has no effect (source):
package main

import (
	"log"
	"time"

	"github.com/coreos/etcd/embed"
)

func main() {
	cfg := embed.NewConfig()
	cfg.Dir = "default.etcd"
+	cfg.LogPkgLevels = "github.com/coreos/etcd/embed=E"
	e, err := embed.StartEtcd(cfg)
	if err != nil {
		log.Fatal(err)
	}
	defer e.Close()
	select {
	case <-e.Server.ReadyNotify():
		log.Printf("Server is ready!")
	case <-time.After(60 * time.Second):
		e.Server.Stop() // trigger a shutdown
		log.Printf("Server took too long to start!")
	}
	log.Fatal(<-e.Err())
}

Output:
$ go run main.go
2017-08-13 15:30:10.952639 I | embed: listening for peers on http://localhost:2380
2017-08-13 15:30:10.954746 I | embed: listening for client requests on localhost:2379
SET LOG LEVEL github.com/coreos/etcd/embed=E
must equal [http://localhost:2380] [http://localhost:2380]
-> default http://localhost:2380
2017-08-13 15:30:10.955688 I | etcdserver: name = default
2017-08-13 15:30:10.955696 I | etcdserver: data dir = default.etcd
2017-08-13 15:30:10.955699 I | etcdserver: member dir = default.etcd/member
2017-08-13 15:30:10.955702 I | etcdserver: heartbeat = 100ms
2017-08-13 15:30:10.955704 I | etcdserver: election = 1000ms
...

Expected:
Only show error output

It will only set log level in embed package. Try specifying all the packages you need silence, or try capnslog.SetGlobalLogLevel(capnslog.CRITICAL)?

Ah, of course. I would need to set the level for each package for this to work.
However, capnslog.SetGlobalLogLevel(capnslog.CRITICAL) does exactly what i need and is even easier. Thanks!

I'll add that you can do
cfg.LogPkgLevels = "*=E"


Handle array if integer

https://github.com/raybellwaves/xskillscore/issues/52

Thanks @ahuang11 !


Fixed missing UI URL in localcluster-deployment.md

Fixed missing URL to access UI at the end of the documentation as per https://github.com/kubeflow/website/issues/2209  and added an alternative method as a note to access K3s from WSL2.
Fixes #2209

/assign @8bitmp3

Thanks @alfsuse. I'm going through it and will send a PR, having tested the file with a Markdown linter.
To run kubectl in Windows Terminal, can you still test the installation with kubectl version --client?

@8bitmp3 this looks great to me

Thanks @alfsuse. I'm going through it and will send a PR, having tested the file with a Markdown linter.

cool! wait for it

To run kubectl in Windows Terminal, can you still test the installation with kubectl version --client?
Yep just checked.

/cc @8bitmp3 @Bobgy  This looks good to me now I think we may merge it so we may close also https://github.com/kubeflow/website/issues/2209 ?

thank you @alfsuse !
cc @joeliedtke  @Bobgy @IronPan @neuromage @Ark-kun @numerology please take a look, thank you!
(OWNERS from https://github.com/kubeflow/website/blob/master/content/en/docs/pipelines/OWNERS)
/ok-to-test

/assign @joeliedtke @Bobgy @IronPan @neuromage @Ark-kun @numerology @8bitmp3

Thank you for the contribution!
Would you mind resolving the conflicts?

@Bobgy   @8bitmp3  fixed as per suggestion.
I would say that /lgtm to me

/approve
/Lgtm
Thank you!


Build problem in Ubuntu18.04

Because apt can't install libopen3d-dev on Ubuntu18.04, I have build and install open3d from source.
Here is my steps:
git clone https://github.com/isl-org/Open3D
cd Open3D
mkdir build
cd build
cmake .. -DBUILD_PYTHON_MODULE=OFF  -DBUILD_CUDA_MODULE=ON
make
sudo make install

Then, I run ./build.sh in Open3DGen, some errors occur like:
fatal error: Open3D/Open3D.h: No such file or directory
I replace #include<Open3D/Open3D.h> with #include<open3d/Open3D.h> , more error like error: ‘registration’ is not a member of ‘stitcher3d::o3d’ occur.
How can I fix this?
By the way, is there a proper way to install Open3D in ubuntu18.04?

I tried also on ubuntu22.04, also the same problem as 'fatal error: Open3D/Open3D.h: No such file or directory', it seemed that
related with libopen3d-dev, others versions are 0.9.0 or 0.10.0. but on ubuntu22.04 there

I tried on ubuntu22.04, also the same problem as 'fatal error: Open3D/Open3D.h: No such file or directory', it seemed that related with libopen3d-dev . I tried to change the path in the<Open3DGen-main/src/surface_mesh.h> .h or main.cpp files, but still report :Open3DGen-main/src/constants.h:130:89: error: ‘registration’ is not a member of ‘stitcher3d::o3d’ 130 | typedef std::tuple<std::shared_ptro3d::geometry::PointCloud, std::shared_ptro3d::registration::Feature> down_fpfh; There might be a lot of work to deal with Open3D versions. Open3DGen compile with Open3D in Older versions like 0.9.0 or 0.10.0 may work fine. But on ubuntu22.04 can only find 0.14.1 version. I tried to install 0.9.0 by deb but met dependency problems. Then I'm trying ubuntu21.10, which can install libopen3d-dev_0.9.0+ds-5build2 by default.

I tried on ubuntu22.04, also the same problem as 'fatal error: Open3D/Open3D.h: No such file or directory', it seemed that related with libopen3d-dev . I tried to change the path in the<Open3DGen-main/src/surface_mesh.h> .h or main.cpp files, but still report :Open3DGen-main/src/constants.h:130:89: error: ‘registration’ is not a member of ‘stitcher3d::o3d’ 130 | typedef std::tuple<std::shared_ptro3d::geometry::PointCloud, std::shared_ptro3d::registration::Feature> down_fpfh; There might be a lot of work to deal with Open3D versions. Open3DGen compile with Open3D in Older versions like 0.9.0 or 0.10.0 may work fine. But on ubuntu22.04 can only find 0.14.1 version. I tried to install 0.9.0 by deb but met dependency problems. Then I'm trying ubuntu21.10, which can install libopen3d-dev_0.9.0+ds-5build2 by default.


Comments

Comments are important issue in migration.
Can you attach the grammar for comments?

A new grammar that parses comments has been added


Documentation

Could you please add a section in your readme that covers how to import the package. Cheers

I haven't maintained this project since I first wrote it in 2012. I'm flattered at how many people have played with it over the years though!
Anyways, I never did package for Maven, etc -- but apparently years ago I found a neat little service that will dynamically do it for you (I really don't recall doing this, but it's linked to my profile lol) and added a page on using that service to package it up for use in a Maven project.
Give it a whirl here, hopefully it still works: https://jitpack.io/p/bane73/firebase4j
😄

I am assuming my suggestion worked for you, @jessebridge so I am closing this issue.


Update pdbbind.py

change _protein_obabel_reduce.pdb to
_protein_processed.pdb.
align with the zenodo file.

Sorry, we only accept significant contributions to this repo from external people.


Force text output on login, version, status and util accesstoken get commands

When we changed the default output mode to use JSON, certain commands wrap the command output in quotes, which is unnecessary.
For example, login, version and status return an output which is wrapped, it would be nice if these commands would force text output mode to remove the quotes.

The util accesstoken get command also wraps the access token response in quotes

Thoughts @pnp/cli-for-microsoft-365-maintainers ?

Good point Garry! While we would sacrifice being consistent a bit, I do feel these commands have a special status in the CLI, I'd not mind having a different default output for these.
The same flies for the util accesstoken get command by the way.

Good catch on the access token command @martinlingstuyl, I've updated the issue.

Second, I wonder if it won't end up confusing when used in a script

Now you've got me doubting as well. 🤷♂

TBH for me it's kinda ok the way it is now 😉. I mean I am totally open for any improvement, but I see no risk/issue also with what we have currently 🤔.
@garrytrinder did you have some specific use case when for example the returned quotes were problematic?

TBH for me it's kinda ok the way it is now 😉. I mean I am totally open for any improvement, but I see no risk/issue also with what we have currently 🤔. @garrytrinder did you have some specific use case when for example the returned quotes were problematic?

No use case, it just always bothered me that the output was wrapped in quotes since we changed the default output. 😄

First of all, changing this output mode would be a breaking change, so let's label it as such to ensure that we don't just include it in a minor version.

@waldekmastykarz agreed, these are breaking changes.

Second, I wonder if it won't end up confusing when used in a script: imagine you configure CLI to output json, because you need to use the information in a script. If suddenly some commands output strings that can be parsed by JSON parsers but others don't, that might be inconvenient because will need to memorize which commands produce output that needs parsing and which are the exception.

In the case of login the initial output, the string that contains the link to the device login and the code, is always going to be text, this isn't something that you would script against as the login flow is interactive, however one thing that I've realised is that we don't actually return anything when you successfully login.
It would be nice if the login command could return an output similar to the below. This is something that the Azure CLI does when you login to Azure, and could provide useful information for re-use in scripts.
{
    "tenantId": "bf805346-44e7-43f7-8e60-c5e24aefe49c",
    "user": {
      "name"<EMAIL_ADDRESS>      "type": "user"
    }
}

I've also noticed that the status command, returns a JSON object when you are connected, but returns a string when you are not, this is inconsistent.

You cannot parse the current output as a string is not valid JSON, see example from pwsh below, so would lead to confusion.

This would be the same for version and accestoken, unless of course the user explicitly adds the --output option to set the command to return a response in text or changes the global output to text.
In summary, rather than forcing text output, I think the better approach would be to provide JSON outputs for these commands instead, if we default to JSON then every command should return valid parsable JSON output.

I agree with you here @garrytrinder, we should be more consistent.
One small thing is that the output with quotes can in fact be converted in PowerShell just fine. The string contains quotes, like this:
$test = '"this is some parsable string"'
You can convert that just fine. But other than that I'd not really call it a json object and I agree with you that it would be better to update the output to a proper object in json mode.

ok totally clear now. +1 here as well 👍

@garrytrinder I like your suggestion to return the account information upon successful login. That's an enhancement, so we could add it already.

In the case of login the initial output, the string that contains the link to the device login and the code, is always going to be text, this isn't something that you would script against as the login flow is interactive

Correct, but that's just one case when you use --authType deviceCode. It might be different in other auth modes, and it would definitely be confusing if we use different output modes depending on which options you use.

@garrytrinder, I think we can convert this issue to an epic and create a new issues for all the things we want to change.

@martinlingstuyl isn't the only change showing the same information as in m365 status after signing in? If that's the case, we might as well close this issue and create a new one without an epic.

I think there's a couple of enhancements that are coming out of this discussion @waldekmastykarz, correct me if I'm wrong @garrytrinder :

The m365 login command does not return anything. It should have an output object similar to m365 status.
The m365 status currently returns a JSON object when you are connected, but returns a string (with quotes) when you are not, this is inconsistent. We should enhance it to return a JSON output object in both cases.
The m365 util accesstoken get currently returns a string (with quotes) in JSON mode. It would be awesome if we could return a JSON object here in JSON mode.
Same for m365 version: Return a proper JSON object in json mode.

Correct, thanks for summarising @martinlingstuyl 👍🏻

@martinlingstuyl The string in quotes for m365 status makes it a valid JSON object that you can parse. That's exactly why the string is in extra quotes. Same goes for other commands. We could wrap them in an extra object, but what's the added value of it if we're returning just one property?

You're correct that it's valid JSON and you can parse it fine. However, I do feel like its confusing. You have to look twice before you know what's going on. Certainly if you are not very proficient in JSON.
I think that would be reason enough to move to real JSON objects.

I think that would be reason enough to move to real JSON objects.

That would however introduce additional complexity if you're building a script and want to get the user's name. Rather than being able to do -o text, you'll now either use --query or pass the output to jq/parse JSON in PowerShell.
I wonder if we really need these commands to be JSON objects with a single property merely for the sake of consistency with other commands that retrieve data from M365.

Rather than being able to do -o text

Hmmm... I'd not thought of that. That's correct.
What do you think @garrytrinder?

Things have moved on a little since I raised this, m365 status has been enhanced and now returns extra information:
{
  "connectedAs"<EMAIL_ADDRESS>  "authType": "DeviceCode",
  "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
  "appTenant": "common"
}

Using m365 status --query 'connectedAs' -o text you can access the connectedAs property value, which is a typical approach as it strips the wrapped quotes so I don't think adds extra complexity.
I think we should go further with the m365 status command and include a new property to this output called isConnected which has a boolean value which is always returned no matter what the connected status is, this will make the output consistent for both scenarios and make it more explicit i.e. m365 status --query 'isConnected' -o text will return true or false as apposed to m365 status --query 'connectedAs' -o text returning a value or null. I expect this will also make it easier when parsing output using pwsh.
m365 status when connected
{
  "isConnected": true,
  "connectedAs"<EMAIL_ADDRESS>  "authType": "DeviceCode",
  "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
  "appTenant": "common"
}

m365 status when disconnected
{
  "isConnected": false
}

When we introduce the support for multiple identities, isConnected and connectedAs will still have their place. At that point, we'll need to make a distinction between signed in and connected, where connected represents the account that's currently active. We'll need to keep the word connected for at least v6, but could consider renaming it to something clearer like active or currentlyUsed.

Got it. So If understand it correctly, once we have multiple identities in place, output of m365 status may be something like below, right?
[
    {
        "isConnected": true,
        "connectedAs"<EMAIL_ADDRESS>        "authType": "DeviceCode",
        "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
        "appTenant": "common"
    },
    {
        "isConnected": false,
        "connectedAs"<EMAIL_ADDRESS>        "authType": "DeviceCode",
        "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
        "appTenant": "common"
    }
]

The above could be the case during v6. Then for V7, we may have something like below, is that right?
[
    {
        "currentlyUsed": true,
        "connectedAs"<EMAIL_ADDRESS>        "authType": "DeviceCode",
        "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
        "appTenant": "common"
    },
    {
        "currentlyUsed": false,
        "connectedAs"<EMAIL_ADDRESS>        "authType": "DeviceCode",
        "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
        "appTenant": "common"
    }
]

To make it easier to use it, I'd say we'll keep one top-level set of properties that describe the current status, and then add a new property with an array of the logged in identities, something like:
{
  "isConnected": true,
  "connectedAs"<EMAIL_ADDRESS>  "authType": "DeviceCode",
  "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
  "appTenant": "common",
  "signedInIdentities": [
    {
        "id": 0,
        "userName"<EMAIL_ADDRESS>        "authType": "DeviceCode",
        "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
        "appTenant": "common"
    },
    {
        "id": 1,
        "userName"<EMAIL_ADDRESS>        "authType": "DeviceCode",
        "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
        "appTenant": "common"
    }
  ]
}

If we could introduce breaking changes, we could simplify it to:
{
  "isConnected": true,
  "connectedAs": 0,
  "signedInIdentities": [
    {
        "id": 0,
        "userName"<EMAIL_ADDRESS>        "authType": "DeviceCode",
        "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
        "appTenant": "common"
    },
    {
        "id": 1,
        "userName"<EMAIL_ADDRESS>        "authType": "DeviceCode",
        "appId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
        "appTenant": "common"
    }
  ]
}

where connectedAs points to the ID of one of the signed in identities.

Hey folks, let's try to conclude next steps for this issue to prevent it from becoming stale. Based on the discussion above, I think we're not in favor of forcing text output on the mentioned commands, right? If that's the case, let's close this issue and open separate issues for other refactorings so that we can spec and track them accordingly.

Totally Waldek. We will be going ahead without any changes in the output.
Based on the discussion, following are the enhancements / modifications we have to build.
This is based on @martinlingstuyl 's summary as per this conversation. and @garrytrinder 's comment as per this conversation, following would be the enhancement we have to to create.

[ ] The m365 login command does not return anything. It should have an output object similar to m365 status. Make the login's output similar to what is explained as per this conversation
[ ] The m365 status currently returns a JSON object when you are connected, but returns a string (with quotes) when you are not, this is inconsistent. We should enhance it to return a JSON output object in both cases. m365 status already has connected information
[ ] The m365 util accesstoken get currently returns a string (with quotes) in JSON mode. It would be awesome if we could return a JSON object here in JSON mode. No changes to the current behavior
[ ] Same for m365 version: Return a proper JSON object in json mode. No changes to the current behavior

Am I missing any other points apart from above? Please feel free to append.

Sounds good to me

Pardon me for not taking the action on that @waldekmastykarz and thanks for creating the issue. There were lot of catching up and this was lost in that.
No excuse whatsoever though.


Env selector (#4614)

Pull request opened by the merge tool on behalf of #4614

Merged in 18f84015c361275ce44af258e60c195dfbbc9df1


[HybridApp] Android status icons hidden in status bar

Problem
Android status bar icons can't be seen. They are displayed in dark mode, despite the OS being set to light mode (ie, clock, battery indicator, etc). They show in NewDot standalone app.
Raised here in Slack.

Solution
Unknown.

FYI @AndrewGable, it is added to project

Cc @war-in @mateuuszzzzz @staszekscp

Yeah, can SWM pick this one up if Jules is focusing on #47868 which is a blocker?

Hi 👋 I'm Marcin from Software Mansion and I'd like to work on this one

Excellent, thanks!


Computed backlink in query results in edgedb error: ProtocolEncodingError: object data size does not match its shape

EdgeDB Version: 3.2+44862ed
EdgeDB CLI Version: 3.4.0+4d95a2c
OS Version: macOS 13.4.1

Steps to Reproduce:

Run this query against the schema below:

select Person {name, descendants := .<ancestors[is Person]};

Schema:
module default {
  type Person {
    required name: str;
    multi ancestors: Person;
  }
}

select schema::Type {name, refs := .<target[is schema::Pointer]};

hits it with an empty schema
The issue seems to be that the injected typename isn't getting reported in the type descriptor sent to the client.
This is a 3.x regression, it worked in 2.16. Probably introduced by the big refactors to sertypes.py

Oh, actually, looks like it was introduced by some of the backlink link properties stuff


Reimplement CLI with click to improve instantiation time.

@dglowe could you review the corresponding branch and see if the change makes sense? As best I can tell there's not really a performance gain, but click is definitely more extensible/modular so I tend to say let's make the switch.

Agreed. Wouldn't say a performance gain, but - after reviewing code and using - from dev and user standpoint, seems an overall better experience. I think make the switch.

@mcferrill Didn't mean to close with comment. I see the corresponding branch is one commit behind master. I think if there are no conflicts after catching up with master, it's ready to merge. Want me to do that so your time can be otherwise used?

Sounds good
On Tue, Jun 14, 2022 at 2:28 PM Daniel Lowe @.***>
wrote:

@mcferrill https://github.com/mcferrill Didn't mean to close with
comment. I see the corresponding branch is one commit behind master. I
think if there are no conflicts after catching up with master, it's ready
to merge. Want me to do that so your time can be otherwise used?
—
Reply to this email directly, view it on GitHub
https://github.com/atac/c10-tools/issues/22#issuecomment-1155629393, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYYJUJDP33KW5Q6FZY6MNDVPDMNDANCNFSM5T2EBYXA
.
 If so I have something weird happening with my environment.  Else I can work on getting tests to pass. Just trying to lock in on next action to take.

Did you 'pdm install' before testing?
On Tue, Jun 14, 2022 at 5:14 PM Daniel Lowe @.***>
wrote:

Question - when you run pytest on 09fde99
https://github.com/atac/c10-tools/commit/09fde994d6afb1a45c40fa309e1286168553db8c
'remove docopt', do your tests pass? If so I have something weird happening
with my environment. Else I can work on getting tests to pass. Just trying
to lock in on next action to take.
—
Reply to this email directly, view it on GitHub
https://github.com/atac/c10-tools/issues/22#issuecomment-1155763441, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYYJUMSKTS3SVONEL3IHJDVPD753ANCNFSM5T2EBYXA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Micah

I did.


Notification priority is undefined

Hi!
I'm trying to show heads-up notifications on an Android device and it seems to require the notification priority for SDK < 26.
I am setting the priority with the OptionsBuilder, but when I receive the notification in frontend, the _priority attribute is set to undefined.
I'm not sure if the problem is with laravel-fcm or if something happens between the moment my notification is sent to FCM and the moment I log it in my application.
Here's my code:
public function send($notifiable, Notification $notification): void
{
    $this->notifiable = $notifiable;
    $this->notification = $notification;
    $this->data = $this->getData();

    $tryCount = 0;
    $notification = $this->buildNotification();
    $topic = $this->buildTopic();
    $options = $this->buildOptions();

    do {
        $tryCount++;
       $response = FCM::sendToTopic($topic, $options, $notification, null);
    } while ($response->shouldRetry() && $tryCount <= 5);
}

protected function buildOptions(): Options
{
    return (new OptionsBuilder())
        ->setPriority(OptionsPriorities::high)
        ->build();
}

Am I missing something?
Thank you!

I hope you already found the answer.
$optionBuilder->setPriority('high');  is how you set priority

@jeremiahsherrill Actually, it's already what I'm doing. OptionsPriorities::high returns the string high. Unfortunately, it is not working for some reason...


fix(logging): update log level to trace to reduce noise

Which issue(s) this PR fixes:

Issue longhorn/longhorn#9011
What this PR does / why we need it:
Reduce logging noise. See https://github.com/longhorn/longhorn/issues/9011#issuecomment-2233714842.
Special notes for your reviewer:
None
Additional documentation or context
Side-effect from https://github.com/longhorn/longhorn-manager/pull/1946.

@mergify backport v1.7.x v1.6.x


Bata India UI Clone created

Description 📜
Bata India UI Clone created
Fixes #1161

Type of change 📝
Please delete options that are not relevant. In order to tick the check box just put x inside them for example [x] like this

[X] Add a new project
[ ] Modified or enhanced the existing projects
[ ] Improve the readme of any project

Domain of Contribution 📊
Please delete options that are not relevant. In order to tick the check box just put x inside them for example [x] like this

[ ] Project using only HTML & CSS
[X] Project using HTML, CSS & JS
[ ] Project using ReactJs

Checklist ✅
Please delete options that are not relevant. In order to tick the check box just put x inside them for example [x] like this

[X] I have performed a self-review of my own code or work.
[X] I have commented on my code, particularly in hard-to-understand areas.
[X] My changes generate no new warnings.
[X] I'm GSSoC'22 contributor

Screenshots / Gif (Recommended) 📸

@gurjeetsinghvirdee Pls review this PR


Building from source won't work with "complex" system locales

What you were trying to do
Build from source!
What actually happened
On one of my machines the system locale is a two-parter, en_UA (English language, Ukrainian region). Unfortunately, Java expects a two-letter locale (just the language). So this leads to a cascade of errors:
14:21:56.939 [main] WARN  o.t.e.c.f.c.LocaleConstraint - Locale en_UA should be one of [,nn,ar,bg,kea,nds,zu,am,fr,ti,bo, ... many other 2 letter codes ...]

14:21:56.942 [main] ERROR o.t.g.u.r.SimpleClassFactory - Failed to instantiate class: class org.terasology.engine.config.SystemConfig
...
Caused by: java.lang.IllegalArgumentException: The default value must be a valid value. Check the logs for more information.

14:21:57.024 [main] ERROR o.t.engine.core.TerasologyEngine - Failed to initialise Terasology
java.lang.NullPointerException: null

How to reproduce
Build from source on a similar machine. I'll have a fix for this soon though!

@rzats interestingly, I cannot even find the en_UA locale for installing and enabling it 🤔
maybe the error is not generally related to locales of format xx_XX but to this specific locale?

@rzats the idea behind locale is different to my knowledge. en_UA would mean that ukraine has a different english variant, so with maybe different words, grammar, etc. that variant of english seems to be not standardized, as @jdrueckert remarks. the region you live in is set in different variables, here an example from romania, some english variant is set, american, or british for example, and the others are set to region romania:
https://www.baeldung.com/linux/locale-environment-variables
what does ```public static Locale.Category[] values()````return for you?
see:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Locale.Category.html


Report all used plugin parameters

Currently, not all plugin parameters are given out, including the ones that are used for the actual computation but are not task specific, such as CI and PUE.
They should be listed in the HTML and TXT summary output.

And the plugin version!

Addressed in https://github.com/nextflow-io/nf-co2footprint/pull/89


Testing for travis errors

(do not merge)

When need to handle QSignal in a Node is it possible to have QSignal with object.
I propose:
BaseNode(object)
Node(BaseNode, QObjetc)
NodeWidget(BaseNode, QWidget)

Are there any nodes that emit signals?
In the past I have handled it like this:
class MyClass(object):
    # Only used for emitting signals:
    class SignalProxyObject(QtCore.QObject):
        my_signal = QtCore.Signal()

    def __init__(self):
        self.__sig_proxy = MyClass.SignalProxyObject()
        self.my_signal = self.__sigProxy.my_signal

Yes there are some nodes in all PR I made. I will have a look.
I finally propose:
Node(object)
QNode(Node, QObject)
QWidgetNode(Node, QWidget)
So each can inherits what it needs.

If the only purpose of QNode is to introduce QObject as a superclass, then why not just do that for the subclasses that require it?
Instead of this:
Node(object)
QNode(Node, QObject)
MyQNode(QNode)

Why not this:
Node(object)
MyQNode(Node, QObject)

I would like at least QWidgetNode because close is more tricky (2 meaning :  QWidget.close and Node.close).

Agreed.

OK so I mergel this patch in my samuel.garcia:device-pyaudio
And pull it in all my branches to see what append.
OK ?

+1


Usage of :be_delayed with ActionMailer

Hi!
I can't seem to figure out how the be_delayed matcher from master is supposed to be used with ActionMailer classes. Since ActionMailer does some funky stuff with instance and class methods I can't use the matchers as documented.
expect(MyMailer.method :notification).to be_delayed('Hello')

fails with a NameError: undefined method.
I can work around that with a fake Method object like this:
expect(OpenStruct.new(receiver: MyMailer, name: :notification)).to be_delayed('Hello')

but that doesn't feel right at all.
Any hints on how the matcher is supposed to be used in this case are greatly appreciated.

Pull request #63 has been merged into develop now and will be released with v2.1, fixing this issue


Stem not used for yySymType type and yylex1 func.

It always start with yy but the prefix should come from the -p option value.

Closed by mispelled https://github.com/cznic/goyacc/commit/d6e6af4a1ff7ba634de6960ea17be2b74d63664c.


IE Issue with player events

The events for this plug-in does not currently work on IE 10 and 11, and would need some refactoring to sort out.

Fixed and committed


Issue with k8s.io/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/

The below sentence is there towards the end of this page: (If you didn't already try creating a Node.js application and deploying it using a container, you can do that first by following the instructions from the Hello Minikube tutorial).
But the "Hello Minkube" tutorial link has nothing about creating any Node.js application or deploying it.

This is indeed a documentation bug. The v1.4 echoserver uses NGINX without node.js
Good spot, @shanarvs
/kind bug
/language en
/triage accepted
/priority backlog

/assign


Trouble connecting to Kube API server

Issues I'm facing:
Was testing out RBAC, enabled the addon, made some changes in known_tokens.csv (but only added, I didn't remove any pre existing ones) in attempts to get external access to the Kubernetes API from my local network outside the VM , updated the VM and restarted because it was acting sluggish when I did microk8s stop microk8s start . Restarted and now I'm receiving The connection to the server <IP_ADDRESS>:16443 was refused - did you specify the right host or port? . I didn't change anything in the kubectl config so that should be ok, and didn't change anything in /var/snap/microk8s/current/args/kube-apiserver  .  If I do ps aux | grep microk8s it looks like microk8s is running in the background but actively refusing my connection. If I attempt to disable RBAC with microk8s disable RBAC I receive the following error:
The error
Traceback (most recent call last):   File "/snap/microk8s/2488/scripts/wrappers/disable.py", line 43, in <module>     disable(prog_name="microk8s disable")   File "/snap/microk8s/2488/usr/lib/python3/dist-packages/click/core.py", line 722, in __call__     return self.main(*args, **kwargs)   File "/snap/microk8s/2488/usr/lib/python3/dist-packages/click/core.py", line 697, in main     rv = self.invoke(ctx)   File "/snap/microk8s/2488/usr/lib/python3/dist-packages/click/core.py", line 895, in invoke     return ctx.invoke(self.callback, **ctx.params)   File "/snap/microk8s/2488/usr/lib/python3/dist-packages/click/core.py", line 535, in invoke     return callback(*args, **kwargs)   File "/snap/microk8s/2488/scripts/wrappers/disable.py", line 36, in disable     _, disabled_addons = get_status(get_available_addons(get_current_arch()), True)   File "/snap/microk8s/2488/scripts/wrappers/status.py", line 157, in get_status     kube_output = kubectl_get("all")   File "/snap/microk8s/2488/scripts/wrappers/common/utils.py", line 169, in kubectl_get     return run("kubectl", kubeconfig, "get", cmd, "--all-namespaces", die=False)   File "/snap/microk8s/2488/scripts/wrappers/common/utils.py", line 39, in run     result.check_returncode()   File "/snap/microk8s/2488/usr/lib/python3.6/subprocess.py", line 389, in check_returncode     self.stderr) subprocess.CalledProcessError: Command '('kubectl', '--kubeconfig=/var/snap/microk8s/2488/credentials/client.config', 'get', 'all', '--all-namespaces')' returned non-zero exit status 1.
Details
I'm running:
Ubuntu 20.04.3 LTS
kubectl Client Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.2-3+a4bd0397e1cb5e", GitCommit:"a4bd0397e1cb5e638a6a6464f759114ee2250ea1", GitTreeState:"clean", BuildDate:"2021-09-16T00:05:14Z", GoVersion:"go1.16.7", Compiler:"gc", Platform:"linux/amd64"}
I apologize if this is something RBAC user error related on my part, but figured if its spitting out a stack trace it might not be expected behavior.
inspection-report-20211022_140152.tar.gz
.

@jbhf the token file follows what's required by kubernetes static token file.
https://kubernetes.io/docs/reference/access-authn-authz/authentication/#static-token-file


Tranquility should be able to push events to replicated beam if one of the partitioned replica is unreachable

We faced an issue in our metrics cluster, where one of the druid workers (1 partition out of 30) was unreachable via network but the task status was running, tranquility kept trying to send messages to the unreachable task and kept getting exceptions -
2015-06-11 14:20:17,692 WARN  [finagle/netty3-3] com.metamx.tranquility.finagle.FutureRetry$ - Transient error, will try again in 29007 ms
java.io.IOException: Unable to push events to task: index_realtime_mmx_metrics_2015-06-11T14:00:00.000Z_10_0 (status = TaskRunning)
	at com.metamx.tranquility.druid.DruidBeam$$anonfun$4$$anonfun$apply$4$$anonfun$apply$6$$anonfun$apply$7$$anonfun$apply$3$$anonfun$applyOrElse$2.apply(DruidBeam.scala:160)
	at com.metamx.tranquility.druid.DruidBeam$$anonfun$4$$anonfun$apply$4$$anonfun$apply$6$$anonfun$apply$7$$anonfun$apply$3$$anonfun$applyOrElse$2.apply(DruidBeam.scala:146)
	at com.twitter.util.Future$$anonfun$map$1$$anonfun$apply$6.apply(Future.scala:863)
	at com.twitter.util.Try$.apply(Try.scala:13)
	at com.twitter.util.Future$.apply(Future.scala:90)
	at com.twitter.util.Future$$anonfun$map$1.apply(Future.scala:863)
	at com.twitter.util.Future$$anonfun$map$1.apply(Future.scala:863)
	at com.twitter.util.Future$$anonfun$flatMap$1.apply(Future.scala:824)

However, the replica task and other partitions were running fine, things were restored to normal on forcefully terminating the worker.
Tranquility should be able to handle such a scenario and instead of getting stuck it can blacklist the unreachable partition and keep sending data to only the replica.

Did the task eventually fail? The idea is that tasks that are broken should fail, and then tranquility will see the failure and stop trying to send them data. So, IMO this should be addressed in the indexing service.

 It will stop pushing data when the task fails, though.
I think that if you want dead tasks to drop out of the cluster faster, you could reduce the RTR grace period from the 15 minute default.

Closing as I don't think there is much better tranquility can do here.


Please use a cache to retrieve llvm tarballs

We, LLVM, have a few issues with people downloading llvm or clang every run of the CI.
See http://lists.llvm.org/pipermail/llvm-dev/2016-May/100303.html
or http://lists.llvm.org/pipermail/llvm-dev/2017-May/113269.html
I know you are not using apt.llvm.org but this still has an important impact to download 216mo at each run of the CI
Done here:
https://github.com/rust-lang-nursery/rust-bindgen/blob/master/ci/before_install.sh#L13

Sure, happy to, thanks for the heads-up.
I'll try to make it work using https://docs.travis-ci.com/user/caching/#Arbitrary-directories, but let me know if there's any repo I could look at to verify it works.


[Identity] Making MSAL extensions an unlisted dependency

@azure/msal-node-extensions has some very inconvenient requirements for our developers and for our community. It requires (besides Python in the three environments):

On Linux, to have installed libsecret and build-essentials.
On OSX, to have XCode configured.
On Windows: To have Visual Studio Code installed with C++.

While we move this dependency (and KeyTar) to a new package, this PR makes it so the dependency is "unlisted": If users try to use this feature, we will throw an error asking them to install the dependency. Tests that use this feature get skipped if the dependency is not present, and run if the dependency is present.
I will add more clarity in the docs as part of this other PR: https://github.com/Azure/azure-sdk-for-js/pull/14405

Is there value in using optionalDependencies in the interim?

@ellismg not for our case since Rush installs optional dependencies automatically.


Allow to create new empty notebook from the command line

It would be great to be able to create an empty notebook from the command line, e.g.:
code stuff.ipynb

which would open a new Jupyter notebook in the same way that "Create New Blank Jupyter Notebook" does from the Command Palette. Currently, when you do this it only opens a blank text file.

Adding @lramos15 who is looking into this for custom editors et al

This isn't really a feature request. If the user has their editor associations set correctly then the untitled file will be passed to the custom editor / notebook. It is up to that specific editor what to do then. This workflow just works for the Hex Editor for example as I have handled untitled file URIs. Once https://github.com/microsoft/vscode/issues/115631 gets finalized there will be a better implementation path for all notebooks and custom editors to handle untitled files. Whether or not we want to add an additional command line argument to specify the editor type via an editor id is another thing that could be discussed @jrieken. That way the user wouldn't need their editor associations set correctly.

@lramos15
I don't understand your comment. The editor associations are set the way as you describe and what happens is that you attempt to open the (previously nonexistent) file with the .ipynb suffix and it opens the file, but it doesn't automatically create a notebook with a single empty cell to start off with. It just creates a blank text file. And if you try to save, it's still just a text file.

Ah thank you for the clarification. This is actually a notebook bug with notebooks not respecting editor associations for untitled files. This feature works for custom editors just not notebooks.

This might be another thing for the custom editor drama/debt. I don't think notebook should be doing anything special for this and it should be handling with the "normal" code for open a file with the notebook editor type

@lramos15 Is there anything I need to do here or do notebooks get this for free?

@jrieken In theory once all the debt is worked out notebooks should receive this for free. If not I can take care of ensuring it works for both.

I think supporting overrides in openEditors too makes sense to me. I don't think code should be duplicated but reused.

After discussion with @jrieken this seems to be blocked by the amount of open editor debt that still exists between custom editors and notebooks. Ideally we want to unify those and remove a lot of the complexity as right now it's like 100+ lines just for notebooks to figure out what input they want to use and there are some issues in that logic preventing this from moving forward.

@bpasero I think this is actually blocked on the fact that we do not await the extension host activation and therefore none of the contributions are registered at this time. That's the conclusion @rebornix and I came to, but I'm not sure if you have any suggestions or ideas.

We do not really need to await the extension host activation but rather the contributed custom editors, no? Isn't it sufficient to know which extension contributes a pattern for custom editor to do the right thing? Do we need to wait for extension activation?

@bpasero I think this is actually blocked on the fact that we do not await the extension host activation and therefore none of the contributions are registered at this time.

A common workaround/trick is to remember that there was an extension that handles this kind of editor and than optimistically proceed with that assumption

@bpasero The code you gave me seemed to do the trick. Feel free to check the commit if it's the wrong place for it.

@lramos15 I think we cannot ship that change though, let me try to explain: we are typically very concerned how fast VSCode opens it's window, showing a text editor and a blinking cursor to the user, we call that the critical startup path and all our performance measurements measure against that goal because it is our goal to offer the fastest time from starting VSCode to blinking cursor in the editor.
Now, openEditors is on that startup path:
https://github.com/microsoft/vscode/blob/e1727abb4114388c7b126f22348b4c4149cf9a2b/src/vs/workbench/browser/layout.ts#L700-L700
Looking at the perf output (Startup Performance Editor), it seems like the extensions registration code triggers a lot later than the editor restore phase:

That means with this change, the code/didRestoreEditors would only now fire after code/didLoadExtensions.
@jrieken please correct me if I am wrong, but I think the whenInstalledExtensionsRegistered only fires from here:
https://github.com/microsoft/vscode/blob/73c85159e72069f69db46fad178f37b5d015f5bc/src/vs/workbench/services/extensions/common/abstractExtensionService.ts#L431-L431

I think this is confirmed now by the perf bot result from today:

I've reverted this and will try @jrieken's approach of caching if there was an override for a specific resource type and then only waiting on the ext host for registrations in that case.

I tried this in the insiders build and it works! Thanks to all of you!


Refactor DDS dashboard to live entirely under /dash

To comply with #4603, requests for iiif.wellcomecollection.org/dash are routed to dashboard.
Which means it can't have any content that isn't under this path.

This is working but it has resulted in some ugly /dash/dash/ URLs which we can fix over time.

Deployed to staging environment. E.g. the following are the same paths (.test. has yet to be updated).

https://iiif-stage.wellcomecollection.org/dash/Queue
https://iiif-test.wellcomecollection.org/dash/dash/Queue


"Error: The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256."

This happens when I use s3-cli sync. Any ideas?

@gazsp did you solve this?

@KsenijaGogic
Nope. Switched to using s3cmd.

You can specify a region by doing the following
s3-cli sync --region=ca-central-1 /dist s3://my-bucket/

Thanks, adding the signature version to the config file did the job! Still I wonder whats the char after s3 = ?

Also make sure you add your region = [region] to your conf file if you run into signing issues

@biosthezerg Thanks, I've updated my post just in case people don't scroll down far enough to read about the indentation.


Fixes #2041 Constantly creating processes while checking packages

Fixes #2041 Constantly creating processes while checking packages
Checks whether the file change is a Python source or compiled file before retriggering package scan.

👍


convert from launching with sky_tool to the flutter tool

Convert from launching with sky_tool to the flutter tool.


Move ResourceClaim ignore filters from Application to an ArgoCD object

This PR adds ResourceClaims jqPathExpressions filters on the ArgoCD object as a part of global Argo configuration,
instead of defining that on the level of specific Application .

PR https://github.com/rht-labs/lodestar-deployment/pull/452 fixed this issue, so closing this PR as no longer needed


Large Depth Error

Hi, and thanks for the great work!
I have reproduced the experiments in Table 1, and for the most part the metrics are very similar to reported in the paper. The only inconsistency I found was the Depth metric.
Paper:

Reproduced:

I was wondering if this type of behavior is expected between different runs?

Hi @codyreading, that's interesting. How do the depth maps look qualitatively? Does that also look incorrect?

Depth Maps look quite good qualitatively, I've uploaded some of the results here of nerfacto-visibility-cube:
If you could upload your depth maps, I'd love to compare them to visually see any differences.

Hi @codyreading, I requested access to your link. When you compute the metrics, do you clip the depth from 0 to 2? We do that in our evaluation here.

The depth maps you have look correct as far as I can tell. One more thing to double check is that you are using median depth instead of expected depth when rendering.

Okay let me check these out, thanks!

Hey @ethanweber! Apologies for the delay, but just checked that we clipped the depth from 0-2 and also used median depth, I kept all the defaults.
I can rerun this to see if this type of behaviour is reoccuring.

Closing for now, I don't need to reproduce the depth metrics any longer


[SPARK-6196] [BUILD] Remove MapR profiles in favor of hadoop-provided

Follow up to https://github.com/apache/spark/pull/7047
@pwendell mentioned that MapR should use hadoop-provided now, and indeed the new build script does not produce mapr3/mapr4 artifacts anymore. Hence the action seems to be to remove the profiles, which are now not used.
CC @trystanleftwich

Merged build triggered.

Merged build started.

Test build #41319 has started for   PR 8338 at commit 14bcab4.

Test build #41319 timed out     for PR 8338 at commit 14bcab4     after a configured wait of 175m.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/41319/
Test FAILed.

Merged build finished. Test FAILed.

Test build #1675 has started for   PR 8338 at commit 14bcab4.

Test build #1675 timed out     for PR 8338 at commit 14bcab4     after a configured wait of 175m.

I will let @pwendell respond to this when he comes back from vacation.

@rxin yeah that's fine, there's no emergency, although these profiles are already unused; the release script for 1.5 will not produce artifacts that use these. On the other PR Patrick indicated, I think, that he intends these to be removed in favor of hadoop-provided

Yes this LGTM - these are outdated and I don't even think MapR is advising their customers to use these.  They are asking people to use hadoop-provided, which was created to simplify using Spark with different versions.

Nice, I do agree with that, and think it will be a better experience for all. The vendor <repository> declarations can stay as a convenience. I'd be inclined to do something similar for the cdh4 profile. I can see that it functions as a sort of generic hadoop-2.0.0 build but would not mind zapping it.


[Feature] Support SDXL 1.0

SDXL 1.0 is update,can support SDXL 1.0 ?

looking forward that.

Any updates on this? Roadmap / plan? @lllyasviel

I remember Emad saying a month ago that SDXL was ready for ComfyUI and ready for controlnet...what is the problem?

use HuggingFace Diffuser's training script https://github.com/huggingface/diffusers/blob/main/examples/controlnet/README_sdxl.md

duplicate: https://github.com/lllyasviel/ControlNet/issues/461

complete


Validate that EC2 instances only have one security group attached

This handles part of #58 to ensure only one security group is attached and adds unit tests

fyi @boranx I've been running your code out in the wild and found some low hanging fruit to add to this instance validation when we found a cluster that was alerting because there were additional security groups attached by the customer :D


Code refactoring

This a draft PR to track the codebase's refactoring. The goal is to follow Python's PEP 8 coding style guide and produce more readable and consistent code.

You also have to replace all the old constans with new constants. I think you're approach is very error prone because you're overwriting all the old constant names without actually replacing any of them.

You need to replace the constant names first before you start reordering them

I figured out a regex replace to do this easily

I'm in the process of uploading the updates files with all of the constants updated. Please refrain from merging your changes.

I updated all the constants to the format OW[1-2](_[A-Z]+)+

I did a scan and it looks fine. Gonna have to see if it compiles though

I think we use this PR just for capitalizing constants, then submit another PR for other types of refactoring.

I confirmed that the compiled output is identical.


fix PublishedPort allocate logic

In the code if p.PulishedPort does not meed condition p.PublishedPort >= dynamicPortStart && p.PublishedPort <= dynamicPortEnd, when GetSpecificID fails, I think swarmkit still needs to Release it.
This pr did:

move defer func() outer to release more cases.

Signed-off-by: allencloud<EMAIL_ADDRESS>

Current coverage is 53.70% (diff: 100%)

Merging #1534 into master will not change coverage

@@             master      #1534   diff @@
==========================================
  Files            82         82
  Lines         13414      13414
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           7204       7204
- Misses         5224       5228     +4
+ Partials        986        982     -4

Powered by Codecov. Last update ae7991c...0cb342e

I think I misunderstood the code. Really sorry about that, Closing it.