⚠ Bofrost.lu has degraded performance

In e944fd8, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2331 ms

Resolved: Bofrost.lu performance has improved in b3df052 after 9 minutes.


chore: bump model-viewer and transpile via babel

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR type

[x] Bugfix
[ ] Feature
[ ] Refactoring

What's new?

[x] PR closes #2852
[x] bump model-viewer and transpile via babel to make sure future versions can be loaded correctly

Before submitting Pull Request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[ ] I've posted a screenshot of demonstrated change in this PR

Optional

[ ] I've tested it at </rmrk/collection/26902bc2f7c20c546a-1FVG7>
[ ] I've tested PR on mobile and everything seems works
[ ] I found edge cases
[ ] I've written some unit tests 🧪

Had issue bounty label?

[x] Fill up your KSM address: Payout

Community participation

[ ] Are you at KodaDot Discord?

Screenshot

[ ] My fix has changed something on UI; a screenshot is best to understand changes for others.

pay 50

😍 Perfect, I’ve sent the payout
💵 $50 @ 174 USD/KSM ~ 0.287 $KSM
🧗 EqdyzrzVmeHwMdMwvPeCMnNdbuQDbD3YrjY93xq9Ln3jUGW
🔗 0x9bb7e9f6c7f4a0cb270528cdf66cc8395451b21c890de0800d15089d388d6fcd
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


mocha 4 doesn't exit unlike mocha 3

Prerequisites

[x ] Checked that your issue isn't already filed by cross referencing issues with the common mistake label
[x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
[ x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
[ x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with:
node node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend avoiding the use of globally installed Mocha.

Description
I have been running specific set of tests for few years now and have been always upgrading to the latest mocha and everything was ok.
With mocha 4 suddenly all tests are passing but it doesn't end as if the --no-exit is automatically added although I never added it.
Steps to Reproduce
Expected behavior:
After all tests end, the process should stop even if there are timeoutes or sockets that prevent the process from existing.
Actual behavior:
Mocha 4 process waits forever like mocha 3 with --no-exit flag
Reproduces how often:
With our tests always. I have 700 tests so it is hard to pinpoint which one casuses the issue or if maybe it is in our codebase.
Versions
mocha 4.0.0 fails. before that everything works good.

I am seeing the exact same problem.   Tests will pass and then mocha just hangs.  See my Travis CI:
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109
I also noticed this same problem on video-dev/hls.js - mocha just hangs after passing tests:
https://travis-ci.org/video-dev/hls.js/builds/282590422

Did you guys read the release notes? https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

Thanks. tok bad the mocha website is not updated with this breaking change. The cli args there do not mention it.

Other than providing a quick fix (use --exit), I do agree they left the core issue of finding the faulty tests to the user. I'm struggling with that myself now, but when upgrading major versions, I make sure to read the release notes and not blindly upgrade

The release notes suggest using why-is-node-running except it doesn't work due to https://github.com/mafintosh/why-is-node-running/issues/7

Hit by this too. I understand the reasoning behind the change to the default, and thank you for incrementing the major version, but given that why-is-node-running is abandoned and broken, this may not be the most user-friendly change.

Hi all,
First off, I want to apologize for the rough upgrade path on this point -- we definitely agree that Mocha ought to tell the user what's keeping the tests running (and then it wouldn't even need to keep the process open; it could just be a reason to return failure after they're done), but haven't found an entirely satisfactory way to do so yet. Version 4 didn't get the amount of time we wanted to put into it, as it was prompted by our CI failing due to changes in PhantomJS 1.x's installer (package-lock.json probably would have prevented this if we'd had it set up beforehand, but we still can't get it working). why-is-node-running was the one tool we found to help, but we don't think we can integrate it (between the requirement of --expose-internals and lack of a good way to programmatically get its output); I have found that it does work if you follow a couple steps:

run Mocha with --expose-internals
make your first test file (e.g. listed in mocha.opts) contain (or at least begin with) after(require('why-is-node-running'))

...so it's better than nothing (although I'll see if I can update the release notes to describe this in more detail), but if anyone knows a better option please let us know!
Also sorry about missing the site documentation -- we'll get it updated as soon as possible. (Once #2987 is done we can even make it an automatic part of our version/publish scripting!)

@ScottFreeCode
borisov@glossy:~/test/mocha $ ./node_modules/.bin/mocha --version
4.0.0

borisov@glossy:~/test/mocha $ ./node_modules/.bin/mocha --expose-internals test.spec.js
  error: unknown option `--expose-internals'

Right, sorry I wasn't clear about that -- --expose-internals is a Node option that can be used by running node --expose-internals ./node_modules/mocha/bin/_mocha instead of ./node_modules/.bin/mocha. That's also something we can fix, since Mocha passes certain flags on to Node and we can add --expose-internals to those flags.

Created mochajs/mochajs.github.io#81 and #3045 to track updating the documentation and Mocha's Node flags, respectively. Will keep this issue open at least till the documentation is updated.

@ScottFreeCode you may want to mention that --expose-internals only works for node <= 6. Hopefully people can downgrade to node 6 temporarily so they can see what timer needs to be cancelled or unref'ed, or sockets needing to be unref'ed.
In any event, I appreciate the help, and thanks for Mocha!

you may want to mention that  --expose-internals  only works for node <= 6.

Are you sure? I tested with Node 8.6.0. Albeit not on all OSes, so I guess I should fire up every box I have and triple-check...

Here's a Gist with a rough guide to work around this for the time being.

Are you sure? I tested with Node 8.6.0. Albeit not on all OSes, so I guess I should fire up every box I have and triple-check...

This "works" in that it triggers the output from the module, but it doesn't actually give me much information, regardless of the version of Node.js.
I'm going to add some updates to the site, but please see my forthcoming comments on #3045.

This "works" in that it triggers the output from the module, but it doesn't actually give me much information, regardless of the version of Node.js.

It gives a useful stacktrace for setTimeout and setImmediate, but no real info at all for other things such as a listening server (as I just recently found out while trying to understand how it's doing what it's doing). The "async-dump" example in the gist has a real advantage in terms of working for everything (and not requiring --expose-internals), even though it's only useable on newer versions of Node.

I suppose my general advice would be "if pulling your hair out, just add --exit and relax".  Then don't use it for your next project :wink:

...and here are the docs

Sorry to comment on the closed PR again, but there might a user-friendly solution here:
One could log a warning about the changed behavior after the runner has finished for 3s or so, but the process didn't exit.
Would just need to add a setTimeout() after the runner finished and call timeout.unref() to make sure this timeout doesn't prevent the process from exiting. If the timeout gets executed it's time for a warning 😉

I’ve considered that but I’m wary that it will cause other problems with reporters or other integrations... I can’t prove it won’t.

If you're still having problems and why-is-node-running doesn't work right, check out wtfnode.
That package worked much better for me.

I can see how having existing tests suddenly stop exiting can be disconcerting (to say the least). I do see a mention about the new behavior in the release notes.
I discovered the change accidentally myself with new tests that forced me to ensure I called redis.quit() in an after() function and I am definitely pleased with the new behavior, which seems correct and appropriate to me.
I didn't need to use [this gist] this time, but as already mentioned by @boneskull, it looks like it could be really useful when it's not clear which async tasks haven't completed and are holding up the process from exiting.

I must admit that I don't quite understand the issues in the referenced tickets that lay behind this new behavioural change.
AFAICT, it has something to do with unhandled Promise rejections. But pardon me, if you don't resolve a Promise given to a Mocha test, then Mocha will neither succeed nor continue from that test, right? So it must be some poorly implemented nested Promise which doesn't have a rejection handler, but the containing code must be resolving anyway.
If this is the case, I don't see how it's Mocha's job to detect those issues. And if implementing some magic to detect those issues, which may make current (correctly-written) tests hang indefinitely, then that magic should be and opt-in behaviour, not an opt-out one — i.e. --no-exit rather than --exit.
I'm looking at all of my tests using the official node-mongodb-native driver hanging because that driver pools connections and don't close them all on .close(), seemingly be design. My tests are behaving properly, but a dependency is not (or is it? I don't know necessarily for a fact that it's bad behaviour to have lingering sockets or file descriptors until a script is exited elsewhere — do you?). So what am I testing here? My code, or someone else's? I thought I was testing my own, but apparently not.
Sure, I can add the --exit flag, but the next guy might not, and either way, it just seems wrong that I can write perfectly fine tests with perfectly fine code being tested, and still have some random dependency cause my tests to hang indefinitely.
If I add a process.exit() in a final after() hook, my tests won't hang, but then it'll break horribly with --watch (possibly other features), not only preventing me from watching for changes, but ejecting me into a cursorless shell.
It may very well be that I'm the clueless one here (certainly there's a lot I'm not getting, and a lot of people have been involved, so I would tend to think so :) ), I just feel like this whole thing is not quite... right...?
Cheers :)

@DanielSmedegaardBuus TL;DR on the solution: put --exit in the mocha.opts file. (This is typically the solution for anything that needs to always be set when Mocha is run, as a more general tip.) More detailed clarification of what this change is about: below.
#2640 is about promise rejections, isn't intended to do anything but make them consistent with synchronous exceptions thrown from non-promise asynchronous test code, and hasn't been implemented yet.
This is about tests setting up resources, listeners or ongoing work and not cleaning it up, regardless of whether promises are used in their implementation and/or in the test. For example:
I have a test for an API based on websockets, which includes opening and closing connections. This API was buggy and was not closing the connections right, but passed my tests since the tests didn't really have a way to assert that the underlying connection was treated correctly. (If I had strictly tested only my own code, I could have verified it's using the dependency in what I mistakenly thought was the right way; I was testing with the real websocket precisely to catch issues with usage correctness in the first place however -- integration tests to complement the unit tests.) I caught that error when I switched to the --no-exit behavior (of Mocha 3; now the default in Mocha 4) and discovered that if I ran those tests Node would not close because the websocket connection is still listening.
(It's true it's possible that the error lies in a dependency rather than in your own code, but even then, there can be value in knowing that before you ship with a given version of that dependency -- as alluded-to above, this is more applicable for integration tests in the first place than for unit tests, but ideally a project has both of those.)
This isn't always necessary, of course -- in some cases, a resource of this nature might be meant to be left alive till the process is killed, or might keep Node alive even though no other cleanup of the resource really matters, or might be part of a resource pool that reuses individual members and doesn't need to clean up the pool as a whole -- in such cases --exit would be correct. The reason for the change of the default behavior was to raise the visibility of such issues: before, you would probably never know to try --no-exit and check for these kinds of errors, now you'll run into them by default and can --exit if you determine that the behavior is correct (or at least not worth worrying about).
There is, of course, something of an issue with the "fix" that just hanging when this happens isn't very informative. We've still got to figure out if we can integrate some way of actually programmatically checking for things still running (so a proper warning or error can be given) that will work on all supported versions of Node without interfering with anything that might still be cleaning up or closing when Mocha reaches the end.

I'm sorry, but this was very frustrating. I was just trying to find out why mocha won't exit. https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit links to why-is-node-running, so now I have gone, tried to use that module, seen a cryptic message "Error: Cannot find module 'internal/linkedlist' ... (stack trace)", and after following the rabbit hole trying to find out why --expose-internals doesn't work, I wind up at https://github.com/mochajs/mocha/issues/3045 to find a supposed solution, but why-is-node-running tells me that there is 1 known handle keeping it open, and a few unknown handles, but doesn't list anything.
This might not be the right place to bring this up, but mocha's docs shouldn't be recommending solutions that require this much googling and issue diving to get to work. I was trying taking things out and adding them in, with very inconsistent behavior. For the sake of future users and my sanity:
package.json:
"scripts": {
    "test": "mocha --exit"
}

That's the best I can do.

@jeffvandyke I understand your frustration and went through the same issues--but if you've got any assertions behind promises, you may appreciate this change.
I had a number of specs that had flaky async behavior. Depending on the run order of my specs, uncaught promise rejection errors would be logged to the console and then be scrolled out of sight by hundreds of other tests that passed, or the node instance would shut down before the rejection happened.
After removing the --exit from my mocha.opts, the rejected promises would reliably log errors, and highlight those bugs.

I know, lots of shared pain :) Mocha's documented behavior actually sounds correct to me, but even though my 5 tests seem simple enough, just using node-fetch to test an api, I'm still unsure why mocha doesn't exit, even though they all pass successfully (yes, they are able to fail too). I could spend more time trying to figure out why why-is-node-running isn't working, but I'm tired of monkeying about other people's code, so I think I'll give myself a break for now.
I'll probably keep playing with it, and if I can get something reproducible, I might open a new issue, no promises though.

would recommend the new node inspector’s debugger... it has good async traces.

Yay! Turns out wtfnode is much better at shedding light on this. I found out that when using node-fetch, I have to call result.text() or .json() or the connection stays open. Running wtfnode ./node_modules/.bin/_mocha and pressing Ctrl-C revealed the open connections.
I think it would have been easier if the docs recommended this package rather than why-is-node-running.
Another suggestion: I really like @andywer's idea of having some kind of warning if mocha dosn't exit. It would be sweet if mocha could even use wtfnode somehow to list active handles keeping node alive after some time has passed.
Whatever the right thing should be, I think it's garbage that I had to look this far to figure out why mocha wouldn't exit. Anyway, I've given my suggestions :)

Hi guys,
I think this feature might still be not working properly, this is the most basic test I could think of and mocha still fails to exit by itself. --no-exit is an excellent default option and I am all for it, but either I'm failing at understanding what I am doing wrong or something is intrinsically wrong with mocha and it's preventing to close even the simpler of the tests.
describe('describe', function() { 	it('it', function(done) { done();     }); });
summary: --exit does work, --no-exit never closes any test.

In my case I'm using a Koa application, and testing with Mocha 4 + Supertest.
I had to just close server together with done call following release notes "To avoid false positives and encourage better testing practices".
Before:
request(app.listen())
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, done)

After:
const server = app.listen()

request(server)
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, () => {
    server.close()
    done()
  })

Hope it helps somenoe.

I'm doing some bootstrapping for mocha before every test. Basically starting a little HTTP server in the same process.
Is there an event I can hook into to shut it down after Mocha stops running? I just want to shut it down, but just at that time.
I love the idea behind this feature btw.. it's a good test for seeing if you have dangling requests.

@evert  Doesn't it work closing server in after?

Is there a global 'after everything' that runs after mocha is done? I may have missed that! Couldn't find it in the docs.

Yes, there is global after hook.

https://mochajs.org/#root-level-hooks

Thank you! I missed that, sorry :/ didn't know the terms to ctrl-f for.

wtfnode didn't really work for me. All I could see was that some PID started by mocha was hanging.
On the other hand, @boneskull gist worked: https://github.com/mochajs/mocha/issues/3044#issuecomment-351299745. Thank you!

wtfnode needs to be run against _mocha, not mocha.

Thanks for the --exit. It fixed it for me.

enter this script in package.json:
"scripts": {
"test": "mocha --exit"
}

I tried various remedies mentioned in this thread:

why-is-node-running produces no output
wtfnode produces output but not enough to determine where the File descriptors/Sockets/Servers/Timers are created in the code
async_hooks debug method errors
adding –exit to mocha cmd line flag results in exit

So follow @ProfJigsaw and use –exit, that’s what I am doing. Would be great if there was an improvement by mocha though, at least a way to figure out where issues are and how to resolve them.

That's what a debugger's for, IMO.  How would you debug your own scripts if they never exited?
https://github.com/GoogleChromeLabs/ndb is a cool project.

Off-topic: I love this ticket, just for the information on troubleshooting tools it keeps on giving! :)

@borisovg Imagine how great this ticket would be if it actually provided a solution! :)
@boneskull Is there some "list File descriptors/Sockets/Servers/Timer" debugger feature that I am not aware of?

@borisovg Thanks for your really super example. In my case wtfnode shows there is a mongo connection open, but all mongo connections in my my-shitty-code.js have been closed, so the problem is from somewhere else, and wtfnode doesn't give enough info as to where it is from.

If wtfnode indicates that a mongo db connection is open, then it's open. Why would you assume it's wrong?

@evert I think you might have misinterpreted what I wrote
Minimal examples are great for illustration, and it's actually useful to see similar output to what you are seeing, but in real code that has been written over many years these connections aren't so easy to find. It's good to know that there are mongo connections still open, but to actually find them is non-trivial. I eventually found some open connections, but they were much much deeper in the code than the surface level where all connections had been verifiably closed, wtfnode didn't help in identifying where they were only that they existed by listing the mongoose module path. I still have some to track down, based only on port number, but I am hopeful.

I ran into this very issue writing a Serverless function that communicated with Firebase. Turns out their admin SDK maintains an open handle indefinitely. Because of this change (and the subsequent suggestion to use wtfnode, I was able to identify that fact and save myself a ton of headache (and costs) down the road.
In my opinion, it would be very helpful to include some sort of "if it hangs for X long and doesn't have any output throw some text to stdout" logic. I'm unsure how feasible that is or how much bandwidth is available to produce such an improvement, but I think that might help alleviate some initial frustration of "wtf is going on with my mocha!"

var timers = sinon.useFakeTimers({
    now: new Date().getTime(),
    shouldAdvanceTime: true,
});

If I forget timers.restore(); the process hangs forever.

Based on the documentation @pgilad sent here, to me there is a cleaner solution. As the documentaion says:

To avoid false positives and encourage better testing practices, Mocha will no longer automatically kill itself via process.exit() when it thinks it should be done running.

A cleaner solution then it would be to create a global after function (an after outside any describe function), I would recommend in a separate file like exit-mocha.js or exit-mocha if you will. The callback sent to after you can force a gracefully node process exit which is going to exit without any error. The file can be sent to mocha cli as if it was another test file (it could simulate an --exit flag)
exit-mocha.js or exit-mocha.js
after('Exit mocha gracefully after finishing all tests execution'. function () {
  // Exit node process
  process.exit();
});

Then you can execute mocha tests like:
mocha exit-mocha test/**/*.spec.js
or
mocha exit-mocha.js test/**/*.spec.js
It is important that if you are using wildcards for the name of the tests files like I did with test/**/*.spec.js that the name of the exit-mocha file does NOT match the wildcard pattern, otherwise, it will not be possible for you to use it as a "flag"

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit" worked for me. Indeed the --exit is a very good workaround. I use the version 5.2.0 in my project.

Is there a way to get the equivalent effect of using the --exit flag when using mocha "programmatically?" I don't see a documented option for the exit, or a general way to pass in a flag while using the NodeJS API.

Other than providing a quick fix (use --exit), I do agree they left the core issue of finding the faulty tests to the user. I'm struggling with that myself now, but when upgrading major versions, I make sure to read the release notes and not blindly upgrade

How  exactly do you pass it ? This is my package.json script
"scripts": {     "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ "   }  and it's not working

Other than providing a quick fix (use --exit), I do agree they left the core issue of finding the faulty tests to the user. I'm struggling with that myself now, but when upgrading major versions, I make sure to read the release notes and not blindly upgrade

How exactly do you pass it ? This is my package.json script
"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } and it's not working

Had the same issue and I think I am not the only one. I just had to move --exit at the end.
This did not work:
istanbul cover ./node_modules/mocha/bin/_mocha  --exit -- test/.test.js
This did work me:
istanbul cover ./node_modules/mocha/bin/_mocha -- test/.test.js --exit

exit does nothing when running Mocha programmatically, fwiw. the process is force-exited by the CLI wrapper, not Mocha-the-library.


Cannot install latest version on RHEL7

Hi,
I've followed multiples issues to try to install the latest RPM for RHEL7 without any luck.
So, when I run:
sudo yum localinstall mod_auth_openidc-2.3.9-1.el7.x86_64.rpm
I've got a dependency issue with cjose.
Following the instructions to install the release I've then downloaded https://github.com/zmartzone/mod_auth_openidc/releases/download/v2.3.0/cjose-0.5.1-1.el7.centos.x86_64.rpm and run:
sudo yum localinstall cjose-0.5.1-1.el7.centos.x86_64.rpm
But YUM says it requires jansson >= 2.3.
yum info jansson tells me the 2.10 package is already installed.
Following this issue: https://github.com/zmartzone/mod_auth_openidc/issues/354#issuecomment-385439379 I've removed jansson and re run sudo yum localinstall cjose-0.5.1-1.el7.centos.x86_64.rpm but I still have the same error regarding the jansson dependency. yum localinstall is not able to resolve it by itself.
What am I missing? How can I install this RPM on a RHEL7 system? The package in the officiel repo is the 1.8.8, way to old for our needs.

your package management is mixed up: do [1] and if that does not help do [2]
[1]
yum remove jansson
wget http://mirror.centos.org/centos/7/os/x86_64/Packages/jansson-2.10-1.el7.x86_64.rpm
yum localinstall -y ~/jansson-2.10-1.el7.x86_64.rpm
wget http://mirror.centos.org/centos/7/os/x86_64/Packages/jansson-devel-2.10-1.el7.x86_64.rpm
yum localinstall -y ~/jansson-devel-2.10-1.el7.x86_64.rpm
wget https://github.com/zmartzone/mod_auth_openidc/releases/download/v2.3.0/cjose-0.5.1-1.el7.centos.x86_64.rpm
yum localinstall -y ~/cjose-0.5.1-1.el7.centos.x86_64.rpm
wget https://github.com/zmartzone/mod_auth_openidc/releases/download/v2.3.9/mod_auth_openidc-2.3.9-1.el7.x86_64.rpm
yum localinstall -y ~/mod_auth_openidc-2.3.9-1.el7.x86_64.rpm

[2]
rpm -iv ~/cjose-0.5.1-1.el7.centos.x86_64.rpm --nodeps
rpm -iv ~/mod_auth_openidc-2.3.9-1.el7.x86_64.rpm --nodeps

The problem is that the error message is misleading.
It reads:
Requires: pkgconfig(jansson) >= 2.3
but what is actually meant is that jansson-devel is missing...

The problem is that the error message is misleading. It reads: Requires: pkgconfig(jansson) >= 2.3 but what is actually meant is that jansson-devel is missing...

and that in its turn was a longstanding RPM packaging problem in the cjose libraries provided as part of the Releases of this project; that is fixed now


platformShowToastEvent mock is missing export

lwc-recipes use the ShowToastEventName variable to create event listeners for testing toasts. The export is missing from the mock implementation in lwc-jest.
https://github.com/salesforce/lwc-jest/blob/master/src/lightning-stubs/platformShowToastEvent/platformShowToastEvent.js
Additionally, the event name lightning__showtoast seems to generate a LWC warning:
    console.warn node_modules/@lwc/engine/dist/commonjs/es2017/engine.js:208
      [LWC warning]: Invalid event type "lightning__showtoast" dispatched in element <c-toaster>. Event name should only contain
lowercase alphanumeric characters.

lwc-recipes actually overrides the platformShowToastEvent stub to use their own that exports the ShowToastEventName value: https://github.com/trailheadapps/lwc-recipes/blob/master/force-app/test/jest-mocks/lightning/platformShowToastEvent.js#L7
The reason we don't export that value for the default stub here is because the real implementation of platformShowToastEvent does not export it. The purpose of these stubs is to mimic the API of the real base components/libraries and provide some shell implementation, but leave the ability to override the defaults.


Only return entries for local service_id

AAP-27844
This will avoid pulling entries for periodic resource sync if they are not marked as belonging to the resource server. I'm still unsure if this behavior is desirable.

I pushed another change, because I'm concerned about a scenario where we want all records. It is very unlikely that it would be practical to get the service_id of something aside from the resource server or the local server. So I want to allow ?service_id= in order to not do any service-specific filter. Whether we use this or not I'm cool, I just want to have this option in case things go badly we have this option to fix it.


Support For RXSwift 5.x

Please can you update to support RXSWIFT 5

look this https://github.com/CainLuo/RxMapKit @yawboafo


Mismatched parameters

Pulled master today and ran into an error during incremental reconstruction:
[DEBUG]   running PYTHONPATH=/home/dmb2/db-odm/SuperBuild/install/lib/python2.7/dist-packages /home/dmb2/db-odm/SuperBuild/src/opensfm/bin/opensfm reconstruct /home/dmb2/ODMProjects/toledo/opensfm
2018-01-10 14:21:03,709 INFO: Starting incremental reconstruction
2018-01-10 14:21:25,876 INFO: Starting reconstruction with DJI_0066.JPG and DJI_0075.JPG
2018-01-10 14:21:26,049 INFO: Two-view reconstruction inliers: 2200 / 2203
2018-01-10 14:21:26,636 INFO: Triangulated: 2202
Traceback (most recent call last):
  File "/home/dmb2/db-odm/SuperBuild/src/opensfm/bin/opensfm", line 34, in <module>
    command.run(args)
  File "/home/dmb2/db-odm/SuperBuild/src/opensfm/opensfm/commands/reconstruct.py", line 21, in run
    report = reconstruction.incremental_reconstruction(data)
  File "/home/dmb2/db-odm/SuperBuild/src/opensfm/opensfm/reconstruction.py", line 1095, in incremental_reconstruction
    data, graph, im1, im2, p1, p2)
  File "/home/dmb2/db-odm/SuperBuild/src/opensfm/opensfm/reconstruction.py", line 669, in bootstrap_reconstruction
    bundle_single_view(graph, reconstruction, im2, data.config)
  File "/home/dmb2/db-odm/SuperBuild/src/opensfm/opensfm/reconstruction.py", line 218, in bundle_single_view
    config['radial_distorsion_k3_sd'])
Boost.Python.ArgumentError: Python argument types in
    BundleAdjuster.set_internal_parameters_prior_sd(BundleAdjuster, float, float, float, float, float, float, float)
did not match C++ signature:
    set_internal_parameters_prior_sd(BundleAdjuster {lvalue}, double, double, double)
Traceback (most recent call last):
  File "/home/dmb2/db-odm/run.py", line 47, in <module>
    plasm.execute(niter=1)
  File "/home/dmb2/db-odm/scripts/run_opensfm.py", line 124, in process
    (context.pyopencv_path, context.opensfm_path, tree.opensfm))
  File "/home/dmb2/db-odm/opendm/system.py", line 34, in run
    raise Exception("Child returned {}".format(retcode))
Exception: Child returned 1

I have boost v 1.58 installed. It looks like these code changes were implemented in the last month with the Brown camera addition.

No answer for a while, closing.


Comparison of union types should error

TypeScript Version:  v4.0.2

Search Terms: union type comparison
Code
function compare(a: number | string, b: number | string): boolean {
  return a < b; // <- Fails to error
}
compare(1, "a");
1 < "a"; // Correctly errors: Operator '<' cannot be applied to types 'number' and 'string'.

This is a simplified example taken from an error found in code review. The function's type signature should really be: function compare<T extends number | string>(a: T, b: T): boolean and I would have expected TypeScript to error for the uncorrected type signature.
Expected behavior:
Typescript should catch the error comparing union types within the function as Flow (v0.136.0) does: flow.org/try example.
Actual behavior:
Typescript does not catch the error for a < b.
Playground Link: example in typescriptlang.org/play.
Related Issues:

Was there an undetected regression? The end of https://github.com/microsoft/TypeScript/issues/5156 implies this was fixed.

Are you actually talking about the generic case or the non-generic case? I'm inclined to agree about the non-generic case but I think erroring on the generic version would be a bridge too far for a lot of users.

For the unbounded generic case in https://github.com/microsoft/TypeScript/issues/5156#issuecomment-231660972, I feel the most ergonomic outcome would be to defer the type checking of the unbounded generic function until concrete types are known.
function compare<T>(a: T, b: T): boolean {
  return a < b;  // <- checking deferred as unknown if T is comparable.
}
compare(1, 2); // <- Passes appropriately.
compare(1, "a"); // <- Fails appropriately: Argument of type 'string' is not assignable to parameter of type 'number'.

null < null; // Fails appropriately: Object is possibly 'null'.
compare(null, null); // Passes inappropriately, should fail with: Object is possibly 'null'.

#5156 also mentioned non-primitive comparisons which are currently allowed. For objects, I think it only makes sense to allow relational comparison of objects with a [Symbol.toPrimitive] method or a valueOf method returning a primitive. The toString method would be ignored since Object.prototype.toString() returns '[object Object]'.
({} < {}); // <- Passes inappropriately, should fail.
new Date() < new Date(); // <- Passes appropriately since Date.prototype.valueOf() returns a number.

TypeScript generics aren't C++ templates that get instantiated in-place; you can't use that kind of reasoning. The function body isn't visible when the function originates in a .d.ts file, for example.

There is IMHO some inconsistency between different operators, for example TS doesn't throw when comparing incompatible types, but it does so when using +:
declare const foo: object|number;

foo > 5; // I'd expect "Operator '>' cannot be applied to types 'number | object' and 'number'.(2365)" error
foo + 5; // Fails correctly with "Operator '+' cannot be applied to types 'number | object' and 'number'.(2365)"

https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEYD2A7AzgF3gMwFzyQCMArcDAHxQFcBbQkGAbgChnt4A+eAVhfYGoeLVkA

objOrNum > 5 is considered OK because this only produces true when the LHS is a number

Not true
const compare = (objOrNum: object | number) => objOrNum > 5;

compare(new Date()); // true

Unless by LHS you mean the value after implicit type conversion, this happens in the runtime though, and isn't TYPEScript about TYPES?
https://github.com/microsoft/TypeScript/issues/16895#issuecomment-320423188 "explains" why using + operator on incompatible types (string and number) is fine:

This is because + is overloaded as both "arithmetic addition" and "string concatenation"

So is > i'd think. But maybe I'm wrong:

(╯°□°)╯︵ ┻━┻
It also suggested using eslint, but why would we use linter or any other external tools for detecting usage of operators on incompatible TYPES? Isn't what TYPEScript is for?

The same can't be said of + since it produces NaN

Not true
({}) + 5; // [object Object]5

Moreover, it produces the same result as ({}) + '5', but:

Dividing by 0 produces NaN. Does TS complain about it?
declare const zero: 0;

5/zero; // no error

Could it be because TYPEScript only checks for TYPES and not the runtime result?
But even if object + number produced NaN I don't feel like it should be justification for not allowing it. Yes, it should throw an error, not because of the runtime behaviour though but because TYPEScript should not allow using an operator on incompatible TYPES.
And that's the point - it's not about the result of operation being OK or not, TYPEScript is about TYPES, isn't it? Comparing values having types that are not really comparable is equally wrong as adding or multiplicating them, regardless of the result the operation produces in the runtime.
OK, enough ranting, hopefully noone is offended :) If people like to compare unknown values that may happen to be numbers with numbers then let it be, but wouldn't it be reasonable to introduce some "very strict" setting to detect this kind of problems?

I didn't say it was unreasonable, just that the current behavior was motivated from real use cases 🤷♂

+1
I just found a bug in my code that should have been caught by the type system.
Here's a simplified version of my use case:
/**
 * A point in time (timestamp).
 *
 * Either ISO date string (UTC), Unix timestamp as seconds, Date object or an
 * object with date properties (UTC).
 */
export type Moment =
  | string
  | number
  | Date
  | {
      year: number;
      month: number;
      day?: number;
      hour?: number;
      minute?: number;
      second?: number;
    };

someFunction({ moment1: "2023-01-01", moment2:<PHONE_NUMBER> });

function someFunction(params: { moment1: Moment; moment2: Moment }) {
  const moment1 = params.moment1;
  const moment2 = toTimestamp(params.moment2);

  // I thought I had converted both moments to numbers (Unix timestamps), so I
  // can compare the precedence of these timestamps. Compiler should have warned
  // that number can't be compared to Moment.
  if (moment1 < moment2) {
    // Unexpected things happening
  }
}

function toTimestamp(input: Moment): number {
  // ...
}

This does not make sense to me:
(a: number, b: string) => a > b; // error, string and number not comparable
(a: number, b: string | object) => a > b; // error, none of the union members are comparable with number
(a: number, b: string | object | number) => a > b; // this is fine, b might be comparable with number

Type safety should work like 'they must be compatible', not like 'they might be compatible'


Add kroxylicious-app module with opinionated logging config

Type of change

Enhancement / new feature

Description
When you start up the jar currently emitted by the kroxylicious module with the dist profile, nothing is logged. We currently do not have an slf4j implementation supplied. This is nice if users wanted to embed Kroxylicious. But we usually want logging if we are running kroxylicious in a container etc. So this commit introduces a module which configures default logging with sl4fj and provides the picocli integration.
The default log level is WARN except for some specific loggers which are enabled by user configuration. Users could set the log4j2.configurationFile system prop to override the classpath configuration, or set the env var KROXYLICIOUS_ROOT_LOG_LEVEL to change the default log level (eg KROXYLICIOUS_ROOT_LOG_LEVEL=DEBUG java -jar ...).
Note that the existing picocli classes haven't been cleaned out of kroxylicious yet so we can move performance tests over before removing the responsibilities from the other module.
Checklist
Please go through this checklist and make sure all applicable tasks have been done

[ ] Write tests
[ ] Make sure all tests pass
[ ] Review performance test results. Ensure that any degradations to performance numbers are understood and justified.
[ ] Make sure all Sonar-Lint warnings are addressed or are justifiably ignored.
[ ] Update documentation
[ ] Reference relevant issue(s) and close them after merging
[ ] For user facing changes, update CHANGELOG.md (remember to include changes affecting the API of the test artefacts too).

Sam asked in standup, Why move picocli code here too? I see kroxylicious-app as the being the command-line tool that runs Kroxylicious, so the CLI glue is also a concern of kroxylicious-app along with the logging config. Other users might want to embed Kroxylicious (like our test code does), they will be able to run:
Configuration config = new ConfigParser().parseConfiguration(stream);
KafkaProxy kafkaProxy = new KafkaProxy(config)
kafkaProxy.startup();

to embed Kroxylicious without needing to pull in the command line tooling and slf4j implementation.

I guess the mvn command in the Dockerfile will need to change.

Decided to remove the old picocli app and other duplicated things, this avoids Sonar complaints about duplication and we don't really need the fuss of splitting it into two PRs


Using a Karate standalone error is produced when trying to use internal java class

When executing karate standalone as a mock server error is produced when trying to load internal Java class:
Caused by: com.intuit.karate.KarateException: js failed:
>>>>
01: Java.type('example.QueueUtils')
<<<<
org.graalvm.polyglot.PolyglotException: TypeError: Access to host class example.QueueUtils is not allowed or does not exist.
- <js>.:program(Unnamed:1)

mock.feature:4

This is on latest Karate version 1.1.0.
I am reporting it after trying to use the suggested solution from @ptrthomas :
https://stackoverflow.com/questions/58398742/unable-to-use-readclasspath-when-running-tests-with-standalone-karate-jar/58398958#58398958 and still receiving the same error.
Execution command from inside 'example' folder: java -cp karate.jar:. com.intuit.karate.Main "$@" -m mock.feature
I am adding reproducible example for the behavior (the Karate jar file is not include so the size of the archive can stay low).
example.zip

@ChavdarEmilovPagoNxt you are trying to mix 2 very different things. if you want java classes to load they should be on the classpath. just putting . here does not work for getting what your maven project has compiled (I think it goes into target/test-classes) onto the classpath.
please assume this is not supported by Karate and figure this out on your own if needed. one way is for you to generate a JAR yourself and then add it to the classpath and I've already linked to other stack overflow answers for that

@ChavdarEmilovPagoNxt and I just figured out that this will actually work, if you have made sure to run mvn test-compile once. as I said, this may not be the right way to do it, and you should probably explore how you can create a JAR that you can "add" to the karate.jar, if you already using a maven project structure my recommendation is please don't use the standalone option
java -cp karate.jar:target/test-classes com.intuit.karate.Main -m src/test/java/example/mock.feature

@ptrthomas Thank you for the fast feedback and for the solution. I tried it but and it do worked but I am now receiving  java.net.BindException: Address already in use which I have to investigate. I will try to figured this in first place and when have some time in the future will investigate how to create a jar that will work with Karate as already tried it before creating the thread but without success. Regarding your recomendación first want to say that really appreciate it but unfortunately I am not sure I can apply it. I have a working maven infrastructure for test that is working fine. Apart of that I have been asked to provide a standalone multi mock server for development. That is for what the jar is used as from the https://github.com/intuit/karate/tree/master/karate-netty I through this is the way to do it. Due to your comment I am rechecking if it can be done from inside maven.

@ChavdarEmilovPagoNxt it gets complicated when you mix java, that's all. many teams are using karate mocks without maven because normally you need only one or two text files. I suggest work with someone who knows Java and Maven well. it is possible to even start karate mocks on a common server for everyone to use, but figuring out how to do that is up to you. maybe Docker is something else you should consider.

@ChavdarEmilovPagoNxt I wanted to mention that "jbang" is a very interesting option if you want to create an executable that pulls in some Java libraries via maven and give you the flexibility to refer to some custom code at the same time.
https://github.com/intuit/karate#jbang
cc @peterquiel since this may be a good candidate for a blog post

@ptrthomas thank you! I maybe check it in the future but it is not necessary for the project at this time and there are other priorities...


ReferenceError: SVGPathElement is not defined

I'm trying to use svg-to-geojson as an npm dependency for a rest application, I'm able to install it using npm install, but when I try to use it using this require:
var svgtogeojson = require('svg-to-geojson');
I get the following error when I try to run the server:
ReferenceError: SVGPathElement is not defined
    at e.svgtogeojson (path/to/geojson-rest/node_modules/svg-to-geojson/dist/svg-to-geojson.min.js:1:23679)
    at Object. (path/to/geojson-rest/node_modules/svg-to-geojson/dist/svg-to-geojson.min.js:2:22430)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)

It seems to be an issue related to path-to-polyfill, but I can't figure out how to resolve this.

same issue for me

same issue for me


Plugin won't show zigbee devices, tabs shows only loading...

Issue description
No devices show-up , nor groups, nor plugin config... all tabs shows only "Loading...".
Additional information
Zigbee2MQTT version:  1.25.1 commit: 3f6a137
Python version: 3.9.2
Domoticz version: 2022.1 (build 14341) , Build Hash: d479d6cb8 Compile Date: 2022-05-23 01:01:38
dzVents Version: 3.1.8
Plugin version: 3.1.0-beta , basically git clone: commit 3ca1419 - 2022-04-30 17:33 CEST
Logs
 2022-05-26 18:49:22.073 Status: Domoticz V2022.1 (build 14341) (c)2012-2022 GizMoCuz
2022-05-26 18:49:22.073 Status: Build Hash: d479d6cb8, Date: 2022-05-23 01:01:38
2022-05-26 18:49:22.073 Status: Startup Path: /--edited--/domoticz/
2022-05-26 18:49:22.143 Status: PluginSystem: Started, Python version '3.9.2', 1 plugin definitions loaded.
2022-05-26 18:49:22.156 Status: WebServer(HTTP) started on address: :: with port 8080
2022-05-26 18:49:22.162 Status: WebServer(SSL) started on address: :: with port 8443
2022-05-26 18:49:22.169 Status: TCPServer: shared server started...
2022-05-26 18:49:22.169 Status: RxQueue: queue worker started...
2022-05-26 18:49:24.175 Status: zigbee2mqtt: Started.
2022-05-26 18:49:24.173 Status: zigbee2mqtt: Entering work loop.
2022-05-26 18:49:24.176 Status: EventSystem: reset all events...
2022-05-26 18:49:24.176 Status: NotificationSystem: thread started...
2022-05-26 18:49:24.178 Status: EventSystem: reset all device statuses...
2022-05-26 18:49:24.398 Status: Python EventSystem: Initializing event module.
2022-05-26 18:49:24.402 Status: EventSystem: Started
2022-05-26 18:49:24.402 Status: EventSystem: Queue thread started...
2022-05-26 18:49:24.571 Status: zigbee2mqtt: Initialized version 3.1.0-beta
2022-05-26 18:49:24.598 Status: PluginSystem: 1 plugins started.
2022-05-26 18:49:25.173 Status: MQTT CliGW LAN: Connecting to 192.--edited--:1883
2022-05-26 18:49:25.375 Status: MQTT CliGW LAN: connected to: 192.--edited--:1883
2022-05-26 18:51:57.008 zigbee2mqtt: Zigbee2mqtt bridge is offline
2022-05-26 18:52:32.237 zigbee2mqtt: Zigbee2mqtt bridge is online
2022-05-26 18:52:32.391 zigbee2mqtt: Received available devices list from bridge
2022-05-26 18:52:32.805 zigbee2mqtt: Received available devices groups from bridge
2022-05-26 18:52:32.818 zigbee2mqtt: Zigbee2mqtt bridge is online

I restarted z2m around 18:51..18:52
What I figured out so far, that z2m changed it's "api" , it won't support anymore bridge/devices/get - which is used to get device-list. Z2M keep devices in json array in topic bridge/devices with RETAINED flag.
I'll create issue regarding that too 😃

Oh hell, I'm so blind , I did not registered that in README.md was added ( commit db397ad ) in Install instructions the 5th point that talks about adding device api_transport 😳 :face_palm:
That's the result of updating only via git pull 😅 and hitting restart 😅


WebClient - Editor

Create a web client for editing topics, gambits and replies

This has been moved to github.com/silentrob/superscript-editor


Created Romanian translation for the freeCodeCamp README.MD file.

Created Romanian translation for the freeCodeCamp README.MD file.

[ ] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the master branch of freeCodeCamp.
[ ] None of my changes are plagiarized from another source without proper attribution.
[ ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

@QuincyLarson Sorry for the confusion. At the time when I was trying to push my PR after a long time trying to do so and talking with @raisedadead we figured it out that GitHub was down and that's why I couldn't see my PRs after committing. After a day GitHub was up again and all my commits started to show. The PRs should be all the same. Please use which one works best for you. Thank you again for everything.

@lindakovacs Thanks for your patience. Yes - this sort of thing happens all the time and is a natural byproduct of having a project as active as freeCodeCamp is - no need to apologize!
I recommend looking at the current Romanian translation on Master, then editing that to further improve it. In the process, you will create a new pull request. Then just @-mention me and I can help QA and merge it.
As always, thank you for all your translation expertise and help!


[core] no metrics listed in metadata.csv file

The integrations-core/agent_metrics/metadata.csv file has no metrics listed in it. Noticed when trying to view documentation on default metrics exposed by the Datadog agent.

Hallo @callafeucht, thanks for letting us know.
That page is of a deprecated feature about collecting metrics about the agent itself. As the page mentions on a note, to collect Agent metrics for Agent v6+, use the Go-expvar check with the agent_stats.yaml configuration file packaged with the Agent.
If you need to collect metrics about the agent itself for agent 5, please contact our support team and they'll be happy to help you.


irccloud's own pastes

Try pasting this in a channel:
https://www.irccloud.com/pastebin/rKxEE05g

The resulting paste hase ace_ classes. Good thing we have Twilight styles for these :yum:

Actually that link works standalone too.

I'm not seeing ace_ classes:

Strange, I have ACE right there, no syntax though.

Anyways, I'll add ACE twilight, won't hurt.

Set the paste to CSS, now syntax works too:

My Chrome shows the same classes as yours. Probably feature detection gone wrong on IRCClouds side or something. We should style both.

My theory is that because I'm the author of that paste, I get ACE. I was able to edit it after all.


fix(RedisProxy multi) handle failing to start a multi transaction

we don't want to stay in multi state if starting multi failed

do we still need this @paulmhh ?

move to main branch (or drop)


HADOOP-17028. ViewFS should initialize mounted target filesystems lazily

2260

 Quality gate: Failed
2 Issues

 2 Code issues

Details


Show informative error for "You are not registered as an Apple Developer"

Stumbled upon https://github.com/KrauseFx/xcode-install/issues/202 but I couldn't find an open/closed PR for this.
Force pushed: I took back the JSON pretty formatting for spec/fixtures/yolo.json.

❤

Nice catch, thanks, also thanks for adding tests ❤


sty file: fix version number

The version number and date are changed automatically from the Makefile. So there is no need to change it the style file, thanks anyway. I will prepare an CTAN upload.


[image_picker] How to detect if an image is vertical or horizontal

Hello everyone
I am making an App in Flutter in which I use image_picker and I would like to know how to know the orientation of an image, if an image is vertical or horizontal.
Is there any way to do it?

This is probably better suited for stack overflow

Hi @adriancsbna
You need to get EXIF data of your picked image, it stores the image's metadata that has such details
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community for resources and asking questions like this, you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you


Feature/expected cycles per layer

Add analysis pass to return a dictionary with node as key and expected cycles for set folding as value. Add for each HLSCustomOp a function that returns the expected cycles, integrate testing into existing unit tests for the HLSCustomOps.

Is it a requirement to use str(node) as a key in the output dictionary? The node.name would be much easier to parse and understand.

I agree, assuming you mean this:
cycle_dict[str(node)] = inst.get_exp_cycles()
This was put in place since nodes have no guaranteed unique name by default, whereas we could use the string representation of it as a hashable dict key. But we can guarantee that all nodes have unique names by calling GiveUniqueNodeNames -- I'll update this and add a comment.


Support screen readers

Currently support for screen readers is non-existent.

Duplicate https://github.com/sourcelair/xterm.js/issues/731


Add missing field in customer attributes

Adding the field 'urls' in CustomerAttributes, according to the official documentation.
https://docs.lemonsqueezy.com/api/customers#the-customer-object

Mapping this field into a "map[string]string" seemed to me to be the best option (shorter and more readable + only one field in the sub-object for the moment). If it's preferable, I can create another structure to parse the field "urls" returned by the lemonsqueezy API.

Thank you for your feedback, I replaced the field with an inline struct.


fix: data spreadsheet object drag drop

Closes # https://github.com/carbon-design-system/ibm-products/issues/5799
What did you change?
I added a check for if the type of header is an object and to check for specific key property set to true headerKey to pick up this text value as the header value otherwise in depth json.stringify does not work properly
How did you test and verify your work?
Storybook
https://github.com/user-attachments/assets/4c2f8abe-d3c2-48c4-878a-c4a9b1eb6523

Thanks, I will address the comments today

Hi @matthewgallo is there any update on this? Thanks!

With provided feedback. Also noting column_name is not required. I don't see anywhere in code to really mention this as even things like placement or sticky on the columns properties aren't fully defined somewhere so I think implementation for this is ok.
I also added safety net so if user didn't define column_name but the header is an object, we will use the getNodeTextContent function.

We have 1 more week for our deadline on our project, would love to be able to get these in and a version released with them if possible. That way we can implement them on our UI as soon as possible, thanks!

Hi @annawen1 can you review when you get the chance? Thanks!

@davidmenendez can you add this back to merge queue please? Thanks!

Is there anything left for this? Thanks!

Not sure why tests are failing, they passed before and nothing major changed :(

We're adding support for visual regression testing that isn't fully configured yet. Everything looks good here, we can merge this now. Thanks for you patience with this one Austin!

Thanks!


[Debugger] Add support for quoted identifiers

Purpose
This PR updates debugger variable implementation and the expression evaluation implementation to support recent changes introduced to quoted identifiers.
Fixes https://github.com/ballerina-platform/ballerina-lang/issues/25731
Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[x] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

@NipunaRanasinghe shall we add some test with quoted identifiers.

@hevayo I was planning to add tests in a separate PR, but can do in here too. +1


fix(material/core): align ripple animation parameters with spec

Aligns the ripple timings with the numbers from MDC.

Repeating here our discussion from Slack (because I can't upload webm videos on GitHub) for transparency:
It looks like this value isn't applied directly to scale, but is instead used for an intermediate calculation:
https://github.com/material-components/material-components-web/blob/master/packages/mdc-ripple/foundation.ts#L530-L531

I've reverted the change to the initial scale.


getLedgerEntries should be update to the new design

Currently, we only have the ability to paste a string. We need to add the ability to paste an XDR string or use ledger entry keys.
Updated designs here.
Jane:

Once you put in the XDR, it just parses into the form below and populate the form and you can edit the form and add more fields or the DR directly

I think we need to reiterate on the design somewhat

I think this figma design use Shadcn UI framework...
Currently, project progress?

@jeesunikim I think @charles-sdf and I have finalized the getLedgerEntries design

Yeah, I checked the figma design. and now I mean, will develop the Frontend based on UI/UX

@dev0614 We may need the assignee to work on this. We will consider opening bounties in the future so that you could contribute to our many codebases. Thank you for your interest :)

Do I need to make new repo?
or will you make new repo?

We are making this changes, thank you

If that is ready for development, let me know that.
Thank you for your update.

getLedgerEntries only takes in keys not xdr. Its response returns xdr. Why are we accepting xdr? @janewang

@jeesunikim and @charles-sdf let's connect on this today so we are aligned


Can't change Netlify identity URL given on first run

Running Netlify CMS with Gatsby, I went to http://localhost:9000/admin/#/ and clicked "Login with Netlify Identity." I pasted my site url at the prompt, including the http:// portion. Now the CMS is trying to hit https://http://my-site-url.netlify.com/.netlify/identity and (of course) failing.
I can't find a way to change this. After rebuilding and serving the site, I keep getting the same 'Failed to load' modal, with a 'forgot password' button.
How can I point the CMS to the right URL?

Got it, thanks!

@tech4him1 I'm not sure if I should file a separate issue for this, but I keep getting the "Failed to load settings from https://mywebsite.com/.netlify/identity" when I try to use the widget during local development. Is there something I'm doing wrong?

@renschler Did you enable Netlify Identity and Git Gateway?

I don't have git gateway enabled (afaik), but this is just for the gatsby-hello-world example, i'm not using netlify-cms (so maybe this thread is misplaced - i apologize).
I do have netlify identity enabled, and it seems to work fine in production, it just doesn't work locally.

Update: I develop in Brave Browser, and I had shields down, but things weren't working. They did work when I visited the production site though (even with shields up).
When I tested in Chrome things worked fine for local dev.
So I'm not sure what is causing the issue with Brave local development but this is the error in my console:
localhost/:1 Access to fetch at 'https://smartscalesync.com/.netlify/identity/settings' from origin 'http://localhost:8000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.

ok no worries thanks

Currently, you need to run localStorage.removeItem("netlifySiteURL") in the console to reset the URL, and then reload the page. This is an upstream issue that is in the process of being fixed: netlify/netlify-identity-widget#148.

I'm sorry, but can anyone provide more step on how to run the localStorage.removeItem("netlifySiteURL")  in the console?
I started up netlify-cms locally and entered the wrong Netlify identify URL and now I'm stuck on the error page.
After some googling, found out what you meant by localStorage(of the browser) and (developer)console(of the browser)...:
https://github.com/netlify/netlify-identity-widget/pull/70/files

I can modify the localStorage, but I can't get the repository URL to change under Identity > Git Gateway. I still need help.


org.cloudfoundry.identity:cloudfoundry-identity-common:2.x is missing on maven central

Hi,
within SAP we noticed that org.cloudfoundry.identity:cloudfoundry-identity-common:2.x is missing on maven-central.
Only version 1.4.3 is available: http://search.maven.org/#artifactdetails|org.cloudfoundry.identity|cloudfoundry-identity-common|1.4.3|jar
Can you please provide org.cloudfoundry.identity:cloudfoundry-identity-common:2.x also?
Best Regards
Matthias

Will this suffice?
http://repo.spring.io/webapp/search/artifact/?1&q=cloudfoundry-identity-common-2.0.3

Sadly it will not, since the http://repo.spring.io repository is continuously breaking the rules of immutable artifacts too often in the past we don't have access to spring.io anymore in our enterprise. with maven-central it is much easier cause artifacts deployed there are in fact immutable. Which is a must for build reproducibility.

Let's us see what we can do, we've run into immutability problems too with other libraries, but not as of lately. We will explore the possibility of publishing to Sonatype's OSS repo and from there it should be mirrored to maven central

We will start publishing releases on Maven Central from here on.
http://search.maven.org/#search|ga|1|org.cloudfoundry.identity
We still have some issues to work out internally on how to use our CI/publish system with the branch flow that we prefer. but the release is available and will be available for future releases.


Wr/parking orbit2

"parking orbits" the sfdx-plugin-lwc-test plugin, which means bumping dependencies to their latest major versions, specifically: @salesforce/command, @salesforce/core, and oclif libraries.
It also applies the latest @salesforce/dev-scripts and @salesforce/dev-config standard to the plugin, which brings it line with other sfdx plugins.
sfdx force:lightning:lwc:test:run now works on windows
added NUTs (not unit tests) to better test at the integration level
@W-10743909@

QA Notes
lwc:test:create

force:lightning:lwc:test:create --filepath=/Users/smit.dagli/dreamhouse-lwc/force-app/main/default/lwc/propertyMap/propertyMap.js
🟢 Output matches here: ERROR running force:lightning:lwc:test:create:  Test file already exists: '/Users/smit.dagli/dreamhouse-lwc/force-app/main/default/lwc/propertyMap/__tests__/propertyMap.test.js'.

force:lightning:lwc:test:create --filepath=/Users/smit.dagli/dreamhouse-lwc/force-app/main/default/lwc/propertyMap/thisDoesNotExist.js
🟢 Output matches here: File not found: '/Users/smit.dagli/dreamhouse-lwc/force-app/main/default/lwc/propertyMap/thisDoesNotExist.js'.

force:lightning:lwc:test:create --json
🟡 Different outputs for the "stack" attribute of the json object, the "Context" attribute missing in the sfdx version but present in the local version

lwc:test:setup

force:lightning:lwc:test:setup
🟢 Was able to setup and run tests both locally and on sfdx

force:lightning:lwc:test:setup --json
🟢 Same output for both local and sfdx

lwc:test:run

force:lightning:lwc:test:run
🟢 Same output for both, same tests passing for each run (Note: I got this error error Invalid sourceApiVersion found in sfdx-project.json. Expected 53.0, found 55.0 both locally and on sfdx)

force:lightning:lwc:test:run --json
🟡 Different outputs for the "stack" attribute of the json object, the "Context" attribute missing in the sfdx version but present in the local version

force:lightning:lwc:test:run --watch
🟢 Same output for both, same tests passing for each run (chose the run all tests option)


The example in Readme is incorrect

Currentlly  under example it shows
Example
from aidbox.resource.appointment import Appointment, Appointment_Participant
_from aidbox.resource import Patient, Practitioner_
from aidbox.base import Reference, HumanName

I this should be replaced with as this resource available in the packages within the resources
----
from aidbox.resource.patient import Patient
from aidbox.resource.practitioner import Practitioner
----

Could you please update the readme ?

Thanks! We missed this piece


[FLOC-1789] Change docker image name

Fixes https://clusterhq.atlassian.net/browse/FLOC-1789

Thanks @adamtheturtle this is correct as far as this image name goes, it is now just redis - can you confirm that you've tested this new app and deployment config as per the GSG? And that this is the only place in our docs we refer to dockerfile/ image names?

I have tested this and followed the GSG successfully. Good to merge.


Software device pipeline

Added a C# wrapper for the software_device.add_to(context) function.
This enables the software device to create its own pipeline, as suggested in #3947

Thanks @stephen-systemfriend !


Manually added non-Steam games covers don't update

I have non-steam games added manually and covers selected in SteamGridDB aren't updated in Steam.
SteamGridDB seems to add images but with wrong filenames.
Covers of games from others launchers are imported and work well.
Filename in config\grid of image added manually

Filenames in config\grid of image added with SteamGridDB

Comparaison of files added in config\grid :

log.log

Same issue.
If I decide to add the artwork manualy it's then added with a different id/filename than the one SteamGridDB is giving.

Same issue.
If I decide to add the artwork manualy it's then added with a different id/filename than the one SteamGridDB is giving.

@lucasfads I found a way to fix the problem and describe it in the original post.
I publish a built version with my fix if you want to install it.

Same issue.
If I decide to add the artwork manualy it's then added with a different id/filename than the one SteamGridDB is giving.

@lucasfads I found a way to fix the problem and describe it in the original post.
I publish a built version with my fix if you want to install it.

AMAZING! It seems to be working just fine.
Thank you and congratulations for the great work @SantaHey!

@CorporalPig22 It didn't gave you this in the downloadable version ?
Because I didn't touch the search function.

@SantaHey
(I'm using google translator, I'm from Brazil) Thanks man, your version is working perfectly, it also fixed the problem of not being able to change the logos, again thank you very much


Ability to support protobufs

Hi,
Actually this is a feature request but did not find a category for the same. Can this project be please extended to identify and use PROTOBUF messages - would be great to use in mobile app automation testing to mock requests from the app?
Thanks,
Sathish

duplicate of #682


Enums are generated incorrectly

Describe the bug
Graphql Enums have keys and values. Seems graphql-codegen uses only keys for generaring enums in typescript.
See example below:
// Such GQL enum
new GraphQLEnumType({
	name: 'FvFormFillerServiceControlTypes',
	values: {
		Text1: {
			value: 'lala'
		}
	}
})

// will be converted into such typescript enum:

export enum GQLFvFormFillerServiceControlTypes {
  Text1 = 'Text1',
}

// Expected typescript enum is:
export enum GQLFvFormFillerServiceControlTypes {
  Text1 = 'lala',
}

in this case you will have to map your enum values in your codegen.yml file, field
generates:
  schema.ts:
    plugins:
      - typescript
    config:
      enumValues:
        FvFormFillerServiceControlTypes:
          Text1: lala

This is obviously incorrect behavior. GraphQL has in its enum key and value. Typescript has in its enum key and value. It seems logically correct to map key to key and value to value. Codegen should generate code rather than make me insert manually such enums :)
I believe I can even create pull for that:)

I didn't read the code, but my guess would be that they work with the resulting generated .graphql file or just consider not using the defined values to cover for frontend users, who doesn't have information about internal enum mapping in the server and will be consuming the graphql only with the plain values.
Maybe there should be an option to chose between using the internal values in enum or not

Maybe there should be an option to chose between using the internal values in enum or not
As an non-breaking feature - definitely

@deser You can use enumValues for internal mapping.
https://graphql-code-generator.com/docs/plugins/typescript#enumvalues-enumvaluesmap

This was suggested above and I described why this doesn't match :)

Currently GraphQL Codegen uses definitions only in the visitor implementations of all plugins. It doesn't respect the actual GraphQLNamedTypes like GraphQLEnumType as in your example. It introspects the schema and parses again to make sure it has a valid astNode to make the visitors work correctly.
I pushed some changes on GraphQL Toolkit to keep actual GraphQLSchema object by fixing its astNode to make it work properly with the visitors instead of printing and reparsing.
https://github.com/ardatan/graphql-toolkit/commit/4d94736a02498d267724e0e461dddcb719e84247
I also did some changes on TypeScript visitor to use existing enum values if there is any defined in GraphQLEnumType.
https://github.com/dotansimha/graphql-code-generator/pull/3147
When all those come together, we will directly use your GraphQLSchema object with your GraphQLNamedTypes but we will fix it automatically inside GraphQL Toolkit if there is any problem with this GraphQLSchema object.
It might be better to call it as an enhancement than a bug because every single type in typescript package is generated to be used as typings not actual code.
I'll keep you posted when the PR is ready to test :)

every single type in typescript package is generated to be used as typings not actual code.
that may be the tricky part, since enums will be compiled to actual objects which may be used for for code

@BigsonLvrocha Could you try with the following version?
1.9.2-alpha-1455536b.55+1455536b

@ardatan ,
Firstly - thanks a lot :)
Secondly - yes, I'll try 1.9.2-alpha-1455536b.55+1455536b. Will respond soon

Updated:
"@graphql-codegen/cli": "1.9.2-alpha-1455536b.55",
"@graphql-codegen/typescript": "1.9.2-alpha-1455536b.55",

Seeing errors:
 Unable to download schema from remote: Unknown operation named "introspection".
        Error: Unable to download schema from remote: Unknown operation named "introspection".

@deser I fixed the introspection query in URL loader but I don't think it is possible to get enum values from the schema's introspection because it is not part of schema definition/SDL. Could you try with the actual code file that exports schema?

Last time I tried I failed to do it. We define schema in old school way (literally constructing new GraphQLObjectType ) and writing script which requires that schema as a module and generates graphql types failed. Therefore the only way I found working is introspection schema :)
Let me try again maybe something has changed from the last time.
Should I install 1.9.2-alpha-1455536b.55 again?

You can try it with 1.9.2-alpha-74dff252.63+74dff252. I added tests for your case.

ok thx

Doesnt work with introspection schema. Will try to work with schema directly

@deser I fixed the introspection query in URL loader but I don't think it is possible to get enum values from the schema's introspection because it is not part of schema definition/SDL. Could you try with the actual code file that exports schema?

@deser It will never work with introspection and SDL because enum values are not part of the schema definition. You should try the exported schema as I said above.

Sure, I'm trying that. Thank you

It works. Thanks a lot!

Found a possible issue:
config:
            declarationKind: 'interface'
            typesPrefix: GQL
            skipTypename: true
            addUnderscoreToArgsType: true
            maybeValue: T

With this config it generates incorrect types:

Found a possible issue:
config:
            declarationKind: 'interface'
            typesPrefix: GQL
            skipTypename: true
            addUnderscoreToArgsType: true
            maybeValue: T

With this config it generates incorrect types:

Previously it was ok:

And adding enumPrefix: GQL doesn't help. Seems bug

I think it should be fixed in v1.10.0.
@deser let me know if it needs to be reopened and fixed again.

Ok thx a lot!


python312Packages.django-q: fix build

This fixes mailmanPackages.hyperkitty.

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@mweinelt The preprocess-cancellation patch dropped in b7b24b5141011be77636d42cee4d2a39624cb012 was not obsolete. WIthout it, setuptools can't find the metadata. But using poetry-core works.

Also see https://github.com/NixOS/nixpkgs/pull/363754

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 364654

x86_64-linux

:fast_forward: 4 packages marked as broken and skipped:

python311Packages.django-q
python311Packages.django-q.dist
python312Packages.django-q
python312Packages.django-q.dist

:white_check_mark: 7 packages built:

mailman-web
mailman-web.dist
moonraker
python311Packages.preprocess-cancellation
python311Packages.preprocess-cancellation.dist
python312Packages.preprocess-cancellation
python312Packages.preprocess-cancellation.dist


Shortened purge check algorithm

Your implementation did not work:

Adding +1 to the limit didn't actually have any effect on the messages purged.
Sending the return embed via ctx.channel.send rather than ctx.send resulted in the defer never ending.
The lambda check didn't seem to actually do anything.

I've removed the unnecessary lambda, set the before to only purge messages before the command was invoked, migrated the messages string into the embed, reduced some of the bulk, and turned some of the short if-statements into one liners.

Update to my last PR:

Fixed the plurality string displaying inverted.
Removed the reason field from the embed if it wasn't specified as it's not being stored in the database and is mostly useless information otherwise.


Jakarta first refactor

I think for forward development we should take a Jakarta first approach.
Since 0.9.2 was my first release as lead on this project I wanted to have at least one release were we could transition from Java EE to Jakarta EE.
Going forward I am fine dropping Java EE support.

[ ] All integrations tests (sample-apps/) should be converted to Jakarta except the everything-app.
[ ] Stabilize the everything-app to depend on microshed-testing-core:0.9.2
[ ] Copy source code from microshed-testing-core to microshed-testing-core-jakarta
[ ] Manually transform it to Jakarta namespace
[ ] Delete microshed-testing-core

Great decision, will de my best to help with this!

@KyleAure as mentioned earlier. I would like to convert the core to the Jakarta namespace and drop the newly created core-Jakarta module. Modules should be based on functionality not on the technical implementation. In this way, core will stay core and from version 0.9.3 will be supporting Jakarta not Javax. Agreed?

Yes I think this will be the best solution.

Hi Kyle, Please alter to tasks to comply to what we've decided on. I've opened a draft PR to show the progress. Happy holidays!

@KyleAure PR is ready for your approval.


test: disable fqdn connectivity test during restart

NOTE: do not merge yet, commit 5a437d7639daba693f3b5325aac8b172fcff298b was added only for testing and should be dropped before merging.
From the focused testing in #13896 it seems that the connectivity test
only fails during restart on kernel 4.9. However, when run as part of
the full test suite, the connectivity check also seems to fail on e.g.
GKE and 4.19. Thus, disable the connectivity test during restart
altogether.
If this turns out to make the test stable in quarantine we could as a
follow-up move the "Restart Cilium validate that FQDN is still working"
test out of quarantine and only restrict the restart connectivity test
to quarantine.
For #11213

test-me-please

retest-gke

Seems to fail on GKE as well: https://jenkins.cilium.io/job/Cilium-PR-K8s-GKE/3103/
Will disable the connectivity test in that case as well.

test-me-please

Unfortunatley it looks like the connectivity test during restart test also fails on 4.19 (https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Kernel/3706/) when running the full test suite on Jenkins. Thus, as discussed out-of-band in the #ci-force channel, I'm going to disable that part of the test altogether.
If the rest of the test proves to run stable in quarantine we could move the full test out of quarantine and re-enable the connectivity test during restart only in quarantine.

test-me-please

Test run passed, dropping commit b055112 which temporaily moved the entire test out of quarantine for easier PR testing. Marking as ready for review.

test-me-please


Warnings on import

We're seeing the following warnings in our terminal on import of wgpu-py on a debian-bookworm docker image:
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
No config found!
No config found!

Does not lead to any errors/exceptions. Minor issue.

False alarm, it happens on some other moment...


In py, the recipe for generating steam from water does not allow for the selection of a fuel-fired boiler.

Problem Description
the recipe for generating steam from water does not allow for the selection of a fuel-fired boiler.
Reproduction
No response

helmod works on this

I used a localized py version in Chinese

I can confirm this problem

Adding the keywords "Oil burner" and "steam-250" to this issue for anyone else experiencing this.

It can be seen to not be an option for steam generation in the preference tab.

Hi, thanks for the reports. Those kinds of boilers are just not supported by the mod, as it needs custom handling. I do however want to add proper support after I sort out fluid temperature stuff, which is hopefully soon.


enable AppVeyor

Anyone willing to have this running on their appveyor account? I have a few too many packages running on mine and would like to avoid making their queue time any worse if possible.

Done (hopefully....)

https://ci.appveyor.com/project/yuyichao/gzip-jl

Do I need to manually add the webhook?

Thanks! I can turn it on if you go to the settings on appveyor and send me the webhook url

Hm. ccall into dup isn't very portable, and neither is shelling out to which. Forgot about #41, maybe we should clean that up.

may as well at least have the right config file...


export CV format txt/html

Users would like to get a list of their papers to copy paste them in word documents.
Example in legacy: http://old.inspirehep.net/search?ln=en&ln=en&p=a+witten&of=hcv&action_search=Search&sf=earliestdate&so=d&rm=&rg=25&sc=0

Add another format in the dropdown menu under LaTeX(US) called 'CV format (html)' in 'Cite' and 'Cite all' that exports a paper in the following format:
For https://inspirehep.net/literature/1781327
Geodesics of the hyperbolically symmetric black hole
L. Herrera, A. Di Prisco, J. Ospino, L. Witten
arXiv:2002.07586 [gr-qc]
10.1103/PhysRevD.101.064071
Phys.Rev. D101 (2020) no.6, 064071
where title, authors, arxiv, doi are links.
The fields should be:
Title
Authors as they appear in the search results with et al.
arxiv id  [arxiv category]
doi
pub note
(jira issue: INSPIR-3635)

In legacy, we have different options for txt and html formats, let's brainstorm on ways we could have them both in 1 option.

We need to add new formats text/html, text/plain, for literature detail and list endpoints, similar to https://github.com/inspirehep/inspirehep/blob/276bd2e2eaca0f576c0cf7398daa67236c2f6c4b/backend/inspirehep/records/config.py#L103-L116
For search endpoints, _source should be specified for the new formats so that only required fields retrieved from elasticsearch.

(Not sure if we want to generate also these formats on index time)

We can use jinja templates serialize records to these formats.
New formats should be added here, so that they are visible on the UI.
This shouldn't prefix application anymore but receive the full mime-type
When the format is text/html, this should use SanitizedHTML instead, which allows only limited number of tags and attributes (similar to Banner.jsx)

To keep track of the issues to fix:

multiple affiliations for authors - 'and' needs spaces
add check for authors existing when there are collaborations but not authors -> https://sentry.inspirebeta.net/inspire-qa/hep/issues/394605/?query=is%3Aunresolved
spacing between records in the cite all
middle dot between collaborations and authors needs space
https://inspirebeta.net/literature/1688995 missing collaboration

LGTM, just one comment to change the title of the dropdown to "CV (html)"


Warning when outside of git directory

I think this warning should be suppressed, for use outside a git directory:
❯ toggl start  "description here"
-Failed to resolve token: Failed to resolve git root
Time entry started
$ [0:00:00]* –  description here

Thank you so much!

Hey you're right this code path should not evaluate unless the active config requires git.
I'll fix it asap.
Thanks!

@0atman do you happen to have a config file as well?
I'm curious what your toggl config is.
I've created a patch to relax the dependency on config in the start command but that was another issue.


Require cgo to work on centOS 7

I am writing a project using xorm on a Mac.
The version of Mac is:
macOS Mojave 10.14.4 (18E226)

Then use the command to cross-compile to Linux.
GOOS=linux GOARCH=amd64 go build

When running on Linux, an error occurs. The error is:
[ERRO] 2019/05/17 02:42 orm failed to initialized table Message: Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub

The source code is:
var Engine *xorm.Engine

func InitDataSource(app *iris.Application) {
	var err error
	Engine, err = xorm.NewEngine("sqlite3", "./message.db")
	if err != nil {
		app.Logger().Errorf("orm failed to initialized: %v", err)
		os.Exit(1)
	}
	iris.RegisterOnInterrupt(func() {
		_ = Engine.Close()
	})
	// init Message table
	err = Engine.Sync2(new(Message))
	if err != nil {
		app.Logger().Errorf("orm failed to initialized table Message: %v", err)
		os.Exit(1)
	}
	// init DeviceInfo table
	err = Engine.Sync2(new(DeviceInfo))
	if err != nil {
		app.Logger().Errorf("orm failed to initialized table DeviceInfo: %v", err)
		os.Exit(1)
	}
}

But it works fine on my mac.
Use the sqlite3 database.
How can I solve this problem, or if I want to install go on Linux?

just use CGO_ENABLED=1

You need some docker images to cross-compile cgo, for example: xgo, or you can take a look of my centos-go image. https://gitea.com/lunny/centos-go, you can use that via:
docker run --rm -v "$PWD":/myrepo -w /myrepo lunny/centos-gop:latest go build

You need some docker images to cross-compile cgo, for example: xgo, or you can take a look of my centos-go image. https://gitea.com/lunny/centos-go, you can use that via:
docker run --rm -v "$PWD":/myrepo -w /myrepo lunny/centos-go:latest go build

Ok, I run it and received an new error:
# nzlong @ nzlongdeiMac in ~/dev/go/src/messages_transfer on git:master o [10:52:26] C:1
$ docker run --rm -v "$PWD":/myrepo -w /myrepo lunny/centos-go:latest go build
jwt.go:4:2: cannot find package "github.com/dgrijalva/jwt-go" in any of:
	/usr/local/go/src/github.com/dgrijalva/jwt-go (from $GOROOT)
	/root/go/src/github.com/dgrijalva/jwt-go (from $GOPATH)
xorm_db.go:4:2: cannot find package "github.com/go-xorm/xorm" in any of:
	/usr/local/go/src/github.com/go-xorm/xorm (from $GOROOT)
	/root/go/src/github.com/go-xorm/xorm (from $GOPATH)
jwt.go:5:2: cannot find package "github.com/iris-contrib/middleware/jwt" in any of:
	/usr/local/go/src/github.com/iris-contrib/middleware/jwt (from $GOROOT)
	/root/go/src/github.com/iris-contrib/middleware/jwt (from $GOPATH)
jwt.go:6:2: cannot find package "github.com/kataras/iris" in any of:
	/usr/local/go/src/github.com/kataras/iris (from $GOROOT)
	/root/go/src/github.com/kataras/iris (from $GOPATH)
devices.go:5:2: cannot find package "github.com/kataras/iris/context" in any of:
	/usr/local/go/src/github.com/kataras/iris/context (from $GOROOT)
	/root/go/src/github.com/kataras/iris/context (from $GOPATH)
message_transfer.go:7:2: cannot find package "github.com/kataras/iris/middleware/logger" in any of:
	/usr/local/go/src/github.com/kataras/iris/middleware/logger (from $GOROOT)
	/root/go/src/github.com/kataras/iris/middleware/logger (from $GOPATH)
xorm_db.go:6:2: cannot find package "github.com/mattn/go-sqlite3" in any of:
	/usr/local/go/src/github.com/mattn/go-sqlite3 (from $GOROOT)
	/root/go/src/github.com/mattn/go-sqlite3 (from $GOPATH)
devices.go:6:2: cannot find package "github.com/rs/xid" in any of:
	/usr/local/go/src/github.com/rs/xid (from $GOROOT)
	/root/go/src/github.com/rs/xid (from $GOPATH)
message_transfer.go:8:2: cannot find package "gopkg.in/go-playground/validator.v9" in any of:
	/usr/local/go/src/gopkg.in/go-playground/validator.v9 (from $GOROOT)
	/root/go/src/gopkg.in/go-playground/validator.v9 (from $GOPATH)

But these packages already exist in the docker container.
This is GOPATH
[root@127fb4e23104 github.com]# ll
total 32
drwxr-xr-x 3 root root 4096 May 18 02:32 dgrijalva
drwxr-xr-x 4 root root 4096 May 18 02:37 go-playground
drwxr-xr-x 5 root root 4096 May 18 02:33 go-xorm
drwxr-xr-x 3 root root 4096 May 18 02:33 iris-contrib
drwxr-xr-x 5 root root 4096 May 18 02:34 kataras
drwxr-xr-x 3 root root 4096 May 18 02:38 leodido
drwxr-xr-x 3 root root 4096 May 18 02:34 mattn
drwxr-xr-x 3 root root 4096 May 18 02:37 rs
[root@127fb4e23104 github.com]# pwd
/root/go/src/github.com

You need to use CGO_ENABLED=1.
Check https://github.com/mattn/go-sqlite3#compilation
Or you can check my Dockerfile

Ok, Use the CGO_ENABLED=1 can not to build too.

It seems that you are not using the vendor mode.

What do you mean? How do I operate, not familiar with docker

@whimthen My centos-go docker image only for build on go mod, but currently it seems you put your repository on $GOPATH. Maybe you can move it out of the $GOPATH and ensure your go version great than 1.11

@lunny go version is go version go1.12.5 linux/amd64. and I move repository out of the $GOPATH is the same error.

@whimthen You may find some articles to know about go mod .

@lunny Thanks very much. Use go mod is working, build successful.
But your Dockerfile is missing git, I ran it successfully after re-creating the image.
Just add RUN yum install -y git.

@whimthen Oh, right. Thank you, I always use go mod -vendor so I haven't install git on that Dockerfile.

Please feel free to reopen it.


Flatpak Version Integration?

Is your feature request related to a problem? Please describe.
I can't install Better Discord with the Flatpak version of Discord installed.
Describe the solution you'd like
I'd like to have integration for the Flatpak version of Discord. A lot of linux apps are already moving to Flatpak, as it is more secure because it is set in its own sandbox.
Describe alternatives you've considered
N/A
Additional context
N/A

betterdiscordctl has you covered.

Hey... I don't see what all the fuss is about and why this has been discussed for years, or even why anyone needs or trusts those "fancy" "betterdiscordctl" or "BetterDiscord-Installer.AppImage" tools anyway. It's literally just 1 little .asar file that needs to be placed in the Discord folder, and one little config edit. No need for all that hassle.
I wrote this oneliner which automatically installs/updates BetterDiscord. It's really that easy, yes. Compare this to the huge, bloated code of the other methods...
FP_CONFIG="$HOME/.var/app/com.discordapp.Discord/config" && BD_ASAR=betterdiscord.asar && mkdir -p "${FP_CONFIG}/BetterDiscord/data" && wget --timestamping -P "${FP_CONFIG}/BetterDiscord/data" -- "https://github.com/BetterDiscord/BetterDiscord/releases/latest/download/${BD_ASAR}" && DISC_VER="$(ls --sort=time --time=creation "${FP_CONFIG}/discord" | grep -E -m 1 '^[0-9]+\.[0-9]+\.[0-9]+$')" && echo -e "require('../../../../BetterDiscord/data/${BD_ASAR}');\nmodule.exports = require('./core.asar');" | tee "${FP_CONFIG}/discord/${DISC_VER}/modules/discord_desktop_core/index.js" && echo -e "\nBetterDiscord installed. Restart Discord if currently running." || echo -e "\nInstallation failed."

Just run that, and it will do the following:

This is only for the Flatpak version, obviously. I don't use Snap.
Automatically downloads the latest BetterDiscord, but only if an update is available. It doesn't download anything at all if there are no updates.
Injects the betterdiscord.asar into Discord's loader script for the latest installed Discord version (version is auto-detected).

That's it. Just save this command somewhere. Run it once. That's it. Run it again when you want to update BetterDiscord. You can run it as many times as you want, since it won't change anything if BetterDiscord is already installed and up-to-date.
You can even make an alias in your ~/.zshrc or ~/.bashrc if you want to easily run this command in your terminal anytime in the future:
alias betterdiscord-update="FP_CONFIG=\"\$HOME/.var/app/com.discordapp.Discord/config\" && BD_ASAR=betterdiscord.asar && mkdir -p \"\${FP_CONFIG}/BetterDiscord/data\" && wget --timestamping -P \"\${FP_CONFIG}/BetterDiscord/data\" -- \"https://github.com/BetterDiscord/BetterDiscord/releases/latest/download/\${BD_ASAR}\" && DISC_VER=\"\$(ls --sort=time --time=creation \"\${FP_CONFIG}/discord\" | grep -E -m 1 '^[0-9]+\.[0-9]+\.[0-9]+\$')\" && echo -e \"require('../../../../BetterDiscord/data/\${BD_ASAR}');\nmodule.exports = require('./core.asar');\" | tee \"\${FP_CONFIG}/discord/\${DISC_VER}/modules/discord_desktop_core/index.js\" && echo -e \"\nBetterDiscord installed. Restart Discord if currently running.\" || echo -e \"\nInstallation failed.\""

Note that GitHub presents oneliners as a very long line. Be sure to copy these correctly, or use the "copy text" button that GitHub provides.
Have fun and I hope this helps someone else who just wants a simply, clean and safe way to install BetterDiscord for Linux Flatpaks.
:cat2:

Hey! Thanks for that! Got BetterDiscord now!

@Peremious Awesome.  That was a quick reply! It's nice to have this clean installation method, so that you don't have to trust 3rd party installers.
With this you're able to install it totally safely, and then the Flatpak Discord sandbox takes care of the rest by ensuring that BetterDiscord and its plugins can't do anything malicious while they're running either.
Flatpak and this little script is really the safest way to install and run BetterDiscord. Sure, I saw the other solution ("betterdiscordctl"), but it relied on running some random person's super messy, over-engineered and self-updating code which I'm never gonna do unless the people behind it are extremely trustworthy. ;)
Anyway, have a great day and take care! :) Remember to join the official discord at https://betterdiscord.app/ if you need help with anything.

how about dont leave an (ironically) bloated response to something with a command that might as well be as unverifiable as betterdiscordctl that youre criticising, and the appimage exists because it's a linux port of the installer (which is what this repo is for in the first place).

Moving all discussion to #157


Error when trying to run the example

My current operational system: Windows 10 10.0.22000.1098
What i tried to run:
$ git clone https://github.com/michal-z/zig-gamedev.git
$ cd zig-gamedev
$ zig build physically_based_rendering_wgpu-run

So then it gives me a error:
Illegal instruction at address 0x7ff76cfd1010
0x7ff73157a106 in OpenFile (build.exe.obj)
        .OBJECT_PATH_NOT_FOUND => return error.FileNotFound

Maybe i miss some step to run this example?

It should work fine. What Zig version do you use? Try to delete zig-cache folder and build again.

Hi, i'm using zig 0.10-dev.

After doing that it gives me new errors:
Illegal instruction at address 0x7ff7305c1630
The following command exited with error code 3 (expected 0):
cd C:\Users\Ukn0w404\Documents\zig-gamedev && C:\Users\Ukn0w404\Documents\zig-gamedev\zig-out\bin\triangle_wgpu.exe
error: UnexpectedExitCode
C:\ProgramData\chocolatey\lib\zig\tools\zig-windows-x86_64-0.10.0\lib\std\build\RunStep.zig:277:17: 0x7ff6f5c0b90f in runCommand (build.exe.obj)
                return error.UnexpectedExitCode;
                ^

Looks very strange, like a corrupted build script.
Could you try official Zig builds from: https://ziglang.org/download/0.10.0/zig-windows-x86_64-0.10.0.zip
Also, try to re-clone the repo.

I've just re-tested with Zig 0.10.0 official build on Windows and all works fine for me.

Ohh, i have sayed Windows 10 but i'm currently in windows 11 tho

i tried to re-install zig on it but doesn't work again

After a time debugging i found this instruction causing the error:

So the error is when calling dawn::native::InstanceBase::InstanceBase

I'm also using Windows 11.
Could you take a look at libs/zgpu/libs/dawn/x86_64-windows-gnu/dawn.lib file? What is the exact size of it?
It should be: 38.5 MB (40,385,442 bytes)

Ok, I know what is happening. Dawn binaries use AVX/AVX2 instruction set and your CPU does not support it. I will upload new binaries that don't require AVX/AVX2.

Thanks!

It should work now, please fetch the latest code and re-build.

It worked!!!! Thanks!


jwt: use pre-computed JWT header

JWT header is unmodifable and can be used as constant.
Signed-off-by: Alexey Markevich<EMAIL_ADDRESS>

@galak added comment to mention base64UrlEncode

This improvement require less memory:
before: sizeof(jwt_header_desc) + sizeof("JWT") + sizeof("ES256") = 32 + 4 + 6 = 42
after: sizeof(jwt_header) = 37
Also new code executed a little bit faster; using nrf9160dk got ~1ms

@galak added comment to mention base64UrlEncode

I guess I was looking for something a bit more detailed that would explain how someone else could generate/reproduce that same encoded value.

I used https://jwt.io/
Put required header into corresponding editbox and have ready to use value from Encoded area (red part, up to first dot)


Step copy file 0.0.3

New Pull Request Checklist
Please mark the points which you did / accept.

[x] I read the Step Development Guideline
[x] I have a test for my Step, which can be run with bitrise run test (in the step's repository)
[x] I did run bitrise run audit-this-step (in the step's repository - note, if you don't have this workflow in your bitrise.yml, you can copy it from the step template.)
[x] I read and accept the Abandoned Step policy

Hi @satyasrikantmantha please create a clean step share for your step, as i mentioned in your previous PR, the step PR should contain only 1 commit:

close this PR
delete step-copy-file-0.0.3 branch from your steplib fork
use our tools to share your step: https://github.com/bitrise-steplib/step-template#share-your-own-step


Rocm miopen deterministic pre rocm 53 test updates

Wheel builds for TF against pre ROCm5.3 are failing due to deterministic tests. This PR filters them out for ROCm5.2 and lower.
Issue
https://github.com/ROCmSoftwarePlatform/frameworks-internal/issues/2834

retest Ubuntu-GPU-single please


You can't enable builds for private projects

Because of GitLab bug https://gitlab.com/gitlab-org/gitlab-ce/issues/27298 you can't use the following config:
my_group/my_project:
  project_settings:
    builds_enabled: true
    visibility_level: 0

because it results in HTTP 400 response from GitLab API:
{
  'project_feature.builds_access_level': [
    'cannot have higher visibility level than repository access level'
  ]
}

This is of the long standing bugs that was one of the reasons we implemented project skipping: https://github.com/egnyte/gitlabform/blob/master/config.yml#L119
But we can no longer skip such projects so I plan to implement a better workaround that will allow skipping only a part of project config (such as project_settings, deploy_keys etc.), even if it is configured on a group level (like we do for files: https://github.com/egnyte/gitlabform/blob/master/config.yml#L117 ).

So as a workaround for this you should skip project_settings for single projects within a group which have this problem, like this:
my_group/my_project:
  project_settings:
    skip: true

gitlabform error output:
gitlabform.gitlab.core.UnexpectedResponseException: Request path='projects/XXX', method=PUT, data='{'public_builds': True, 'visibility_level': 10, 'only_allow_merge_if_all_discussions_are_resolved': False, 'builds_enabled': True, 'only_allow_merge_if_build_succeeds': False}' failed - expected code(s) 200, got code 400 & body: 'b'{"message":{"project_feature.builds_access_level":["cannot have higher visibility level than repository access level"]}}''

This issue is not valid anymore.
Note that the syntax of the config has changedin the mean time.
Please see an example how you should enable builds for a private project here: https://github.com/egnyte/gitlabform/blob/master/gitlabform/gitlabform/test/test_project_settings.py#L24


License?

Hi, I'm part of the Godot Engine XR community.
Thoughts on include a MIT or Apache 2 license that is compatible with Godot Engine?
https://github.com/godotengine/godot/blob/master/LICENSE.txt

Im not sure how can you use a small python app in godot or vsekai, but aure