Update requirements

Closes #206.
Set version lofts for Python dependencies.

Unless there is a specific reason not to accept rdflib5.0.0 and up I still think we should allow that.
The more restrictive we are the higher chance of not being compatible with other packages for no good reason.

Under normal circumstances I'd agree, but since these releases are only a couple of months apart, I don't think there will be a huge difference. Also, there are no releases between version 5.0.0 and 6.0.0.
Furthermore, if we allowed version 5.0.0, the issue mentioned in #206 would not be resolved.

5.0.0 resolves the issue206, it is 4.x.x that makes that error as far as I understand. If there is little difference between 5.0.0 and 6.0.0 there is even less reason to be restrictive.
Francesca

From: Casper Welzel Andersen @.>
Sent: Wednesday, September 15, 2021 11:11:51 PM
To: emmo-repo/EMMO-python @.>
Cc: Francesca Lønstad Bleken @.>; Review requested @.>
Subject: Re: [emmo-repo/EMMO-python] Update requirements (#212)
Unless there is a specific reason not to accept rdflib5.0.0 and up I still think we should allow that.
The more restrictive we are the higher chance of not being compatible with other packages for no good reason.
Under normal circumstances I'd agree, but since these releases are only a couple of months apart, I don't think there will be a huge difference. Also, there are no releases between version 5.0.0 and 6.0.0.
Furthermore, if we allowed version 5.0.0, the issue mentioned in #206https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femmo-repo%2FEMMO-python%2Fissues%2F206&data=04|01|francesca.l.bleken%40sintef.no|3333a90ab45e47eeeb4a08d9788d70cc|e1f00f39604145b0b309e0210d8b32af|1|0|637673371152625207|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Nzdfoz3zr4jvZofIUH2R6hvvNDQip2ms5JRV7tZGTps%3D&reserved=0 would not be resolved.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femmo-repo%2FEMMO-python%2Fpull%2F212%23issuecomment-920379135&data=04|01|francesca.l.bleken%40sintef.no|3333a90ab45e47eeeb4a08d9788d70cc|e1f00f39604145b0b309e0210d8b32af|1|0|637673371152635163|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=qcvVhk661b1OP%2BB23r2C5J91Xew2nXfUZyGdCrjJALg%3D&reserved=0, or unsubscribehttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALPGAD4MEG7P4ZZJABLKBMTUCEDZPANCNFSM5ECTBRRQ&data=04|01|francesca.l.bleken%40sintef.no|3333a90ab45e47eeeb4a08d9788d70cc|e1f00f39604145b0b309e0210d8b32af|1|0|637673371152635163|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=tsJLjZEzmRzztqXJv0eguGPETXQuTyBrEzfLgnvkUcE%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|francesca.l.bleken%40sintef.no|3333a90ab45e47eeeb4a08d9788d70cc|e1f00f39604145b0b309e0210d8b32af|1|0|637673371152645131|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=qRNXHLrwO5dCh2OdjrU1iBsyFW7CAfqv2dia59WsUmo%3D&reserved=0 or Androidhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|francesca.l.bleken%40sintef.no|3333a90ab45e47eeeb4a08d9788d70cc|e1f00f39604145b0b309e0210d8b32af|1|0|637673371152645131|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=VhZ0SdQ3dpZujXArXNjwysKjNoY4tpqTecM6m2GuPEg%3D&reserved=0.

5.0.0 resolves the issue206, it is 4.x.x that makes that error as far as I understand. If there is little difference between 5.0.0 and 6.0.0 there is even less reason to be restrictive.

Again, as far as I read the rdflib changelog, this is not the case.
Changelog: https://github.com/RDFLib/rdflib/blob/master/CHANGELOG.md
The issue from the RDFLib repository in question (referenced in the "Known issues" list in the EMMO-python readme): RDFLib/rdflib#1043.
It seems from the changelog that this was fixed by PR RDFLib/rdflib#1054, which was merged after 5.0.0 and only included in 6.0.0.
This also matches up with the "Known issues" text that "This issue was fixed after the release of rdflib 5.0.0".

Ok, then I am wrong. Agree with keeping 6.x.x then.
Francesca

From: Casper Welzel Andersen @.>
Sent: Thursday, September 16, 2021 11:44:17 AM
To: emmo-repo/EMMO-python @.>
Cc: Francesca Lønstad Bleken @.>; Review requested @.>
Subject: Re: [emmo-repo/EMMO-python] Update requirements (#212)
5.0.0 resolves the issue206, it is 4.x.x that makes that error as far as I understand. If there is little difference between 5.0.0 and 6.0.0 there is even less reason to be restrictive.
Again, as far as I read the rdflib changelog, this is not the case.
Changelog: https://github.com/RDFLib/rdflib/blob/master/CHANGELOG.mdhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FRDFLib%2Frdflib%2Fblob%2Fmaster%2FCHANGELOG.md&data=04|01|francesca.l.bleken%40sintef.no|84d0ace8e5bd47bdca0e08d978f68ddd|e1f00f39604145b0b309e0210d8b32af|1|0|637673822629772160|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=UrASeC8IzBigLpjgeXnKN0BAiCUlLK1PHdzBqkB5SGc%3D&reserved=0
The issue from the RDFLib repository in question (referenced in the "Known issues" list in the EMMO-python readme): RDFLib/rdflib#1043https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FRDFLib%2Frdflib%2Fissues%2F1043&data=04|01|francesca.l.bleken%40sintef.no|84d0ace8e5bd47bdca0e08d978f68ddd|e1f00f39604145b0b309e0210d8b32af|1|0|637673822629782117|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=d0jjEpkonA0UuiD3sjetPE%2BaWXwt8nwudbUYGGSSyP4%3D&reserved=0.
It seems from the changelog that this was fixed by PR RDFLib/rdflib#1054https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FRDFLib%2Frdflib%2Fpull%2F1054&data=04|01|francesca.l.bleken%40sintef.no|84d0ace8e5bd47bdca0e08d978f68ddd|e1f00f39604145b0b309e0210d8b32af|1|0|637673822629782117|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=XUuwrlPRUAGog7JUrUe7mLWSHG2l3LsFstT8GzFJEhs%3D&reserved=0, which was merged after 5.0.0 and only included in 6.0.0.
This also matches up with the "Known issues" text that "This issue was fixed after the release of rdflib 5.0.0".
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femmo-repo%2FEMMO-python%2Fpull%2F212%23issuecomment-920750433&data=04|01|francesca.l.bleken%40sintef.no|84d0ace8e5bd47bdca0e08d978f68ddd|e1f00f39604145b0b309e0210d8b32af|1|0|637673822629792072|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=w8YC8AO7AMJ8mU9vYQzesAa9ciiYwf50nn4%2FwNTvXY8%3D&reserved=0, or unsubscribehttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALPGAD4VM6PUEA7CI2TTATDUCG37DANCNFSM5ECTBRRQ&data=04|01|francesca.l.bleken%40sintef.no|84d0ace8e5bd47bdca0e08d978f68ddd|e1f00f39604145b0b309e0210d8b32af|1|0|637673822629792072|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=6dRxLR3MfQWEGcVNRLtg05nVBls8GRyD%2FX%2BC9HsT6PI%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|francesca.l.bleken%40sintef.no|84d0ace8e5bd47bdca0e08d978f68ddd|e1f00f39604145b0b309e0210d8b32af|1|0|637673822629802029|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Knf0u5jJHx4N9lvyHKlqYewsCW7bNvAe4VRlrvKP7po%3D&reserved=0 or Androidhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|francesca.l.bleken%40sintef.no|84d0ace8e5bd47bdca0e08d978f68ddd|e1f00f39604145b0b309e0210d8b32af|1|0|637673822629802029|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=dH5yazk9Qtq4H9SHLDJTC53BQBtgAk011DNHpPREDs4%3D&reserved=0.

Concerning the difference between 5.0.0 and 6.0.0, from the changelog it seems there are many vital improvements. I don't see why we should support an older version with several bugs that have already been fixed in a newer version while also considering that the number of repositories that only support version 5.0.0 and not 6.0.0 have only had a 2 month window to do so.
The only thing that might be "dangerous" is that version 6.0.0 drops Python 2 and Python 3 < 3.7 support. I.e., this repository should also drop Python 3.6 support if the minimum rdflib version should be 6.0.0.

I think that rdflib has provided the features we use since v2.0 or maybe v3.0. Most linux distributions do not provide rdflib v6. Fedora 33 (which was released this spring) is e.g. on version 4.2.1. Requiring a higher version of rdflib that we actually use may unnecessary enforce people to use a virtual environment instead of the version of rdflib that comes with their distribution.
I am not sure we want to go down this road - Emmontopy is after all a fairly simple package.

I think that rdflib has provided the features we use since v2.0 or maybe v3.0. Most linux distributions do not provide rdflib v6. Fedora 33 (which was released this spring) is e.g. on version 4.2.1. Requiring a higher version of rdflib that we actually use may unnecessary enforce people to use a virtual environment instead of the version of rdflib that comes with their distribution.

Ah - excellent point.
I'll add back the support for earlier versions 👍
We'll keep the issue open then, and I'll try to add some version-aware code around the functionality that's affected by issue #206.

I have added some sanity checks for having rdflib be version 6.0.0 or higher if one wants to output Turtle files using the ontoconvert CLI tools and connected utility Python functions.
I don't know if this is the desired result, or if it should instead be a warning and then continue?

I think that rdflib has provided the features we use since v2.0 or maybe v3.0. Most linux distributions do not provide rdflib v6. Fedora 33 (which was released this spring) is e.g. on version 4.2.1. Requiring a higher version of rdflib that we actually use may unnecessary enforce people to use a virtual environment instead of the version of rdflib that comes with their distribution.
I am not sure we want to go down this road - Emmontopy is after all a fairly simple package.

As a further note to this though, I'd always recommend installing Python packages in virtual environments - but I think it's good to support this use case.

This has been superseded by #216


Update together.ipynb

Description
Requesting to update the title and name, and add a link to the list of available models.
Fixes # (issue)
Type of Change
Please delete options that are not relevant.

[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Suggested Checklist:

@coco66 did you want to update the embedding notebook as well? docs/examples/embeddings/together.jpynb

Ph that's another PR, OK!


Uncaught TypeError: this.persistenceAdapter.saveDatabase when using jQuery Sync Adapter

I've been trying to use the jQuery Sync Adapter with the following code:
var options = {
  ajaxLib: 'jquery',
  save: {
    url: 'http://requestb.in/1i6am5u1'
  },
  load: {
    url: 'http://requestb.in/1i6am5u1'
  }
};

var jqueryAdapter = new lokiJquerySyncAdapter(options);
var db = new loki('users', {adapter: jqueryAdapter});
var users = db.addCollection('users');

for (var i = 0; i < 5; i++) {
  users.insert({_id: i, name: 'user-' + i});
}

console.log(users);
db.saveDatabase();

but I'm getting the following error:
Uncaught TypeError: this.persistenceAdapter.saveDatabase is not a function

I'm unable to save the Loki database to a remote RequestBin.
Any ideas or suggestions on what is causing the bug?
Note: the code above assumes that the typo in the jquery-sync-adapter has been fixed, see issue #243

Not sure this was ever tested fully so thanks for reporting.  @techfort wrote it a long time ago so normally I would let him fix but he may be out for a while, so I went ahead and did it.
Let me know if that works out for you.


Generate config for INTEROP tests on 4.18

https://issues.redhat.com/browse/SRVCOM-3401

Configuration for a candidate release of OpenShift now has to be specified explicitly. Previously, we generated them automatically by taking the highest version of OpenShift in config, bumping the minor version, and creating the config for the candidate release. Now, we need to be able to specify which custom configs will be run for each version of OpenShift - including this candidate version.
Add tests for candidate OCP 4.18 explicitly for all repositories, but only for the latest version Serverless 1.36.
Add INTEROP config for OpenShift 4.18. This is supposed to replace manual changes like in this PR: https://github.com/openshift/release/pull/57252 (it's error prone and requires multiple reviews from our team).
Remove older interop tests for OCP <=4.17

When merging this PR, the following config will be generated: https://github.com/openshift/release/pull/58680

@ReToCode Could you take a look? Thanks


Add data parameter to _publishEvent function

This will give users the ability to receive the banner_id (branchViewId) in the listener callback when journeys events are published.

👍


Add License

Hi,
Is it ok for me to use your quake styled player movement script for my game?
Also, if anyone else stumbles upon this and if they could use this repo, it would be a good idea to add a license.

Just added an MIT license. Feel free to use!


Added Studio docs for email sign up and custom Gitlab server support

Main pages to review
Changed:

https://dvc-org-studio-accounts-vedlrg.herokuapp.com/doc/studio/get-started
https://dvc-org-studio-accounts-vedlrg.herokuapp.com/doc/studio/user-guide/views/create-view
https://dvc-org-studio-accounts-vedlrg.herokuapp.com/doc/studio/user-guide/teams
https://dvc-org-studio-accounts-vedlrg.herokuapp.com/doc/studio/user-guide/account-management

New:

https://dvc-org-studio-accounts-vedlrg.herokuapp.com/doc/studio/user-guide/connect-custom-gitlab-server

This PR is ready for review. But I've marked it as Draft so that we don't merge it before the corresponding changes in the Studio application are shipped.

I made an initial review. Thank you @tapadipti

Thank you @iesahin . I've addressed your comments above.

Is this still a draft or ready for final review? Thanks

Is this still a draft or ready for final review? Thanks

@jorgeorpinel It's ready for review. I've marked it as Draft so that we don't accidentally merge it before the corresponding changes in the Studio application are shipped.

@iesahin could you pls review and let me know if any more changes are needed? Merging this is blocked until you approve.

I've marked it as Draft so that we don't accidentally merge it before the corresponding changes in the Studio application are shipped

For the record we use the status: wait-core-merge label for that 🙂 (drafts can be merged accidentally anyway).
And thanks! Great stuff as usual

@jorgeorpinel I've made your suggested changes in a new PR: https://github.com/iterative/dvc.org/pull/3497 And for suggestions that I've not implemented, pls see the comment replies above. Let me know if more changes are needed.


Removing products from the cart doesn't work.

Description
To trigger an error:

Add product to the basket

Go to another page that doesn't have products, e.g. Home page then this error appears in the sidebar

Try to remove the product from the basket using the sidebar

Hey @joanna-gil
this is a known error and should already be fixed.
The fix was merged yesterday, could you please update to the lastet master it try if the fix solves your bug?
Kind regards
Jonas

Thanks, it actually works. I downloaded Shopware yesterday afternoon and didn't check if something new came out, thank you for fixing the bug!


Update VariadicBind.h

Remove warning: expression result unused [-Wunused-value]
https://stackoverflow.com/questions/14370043/can-operators-be-overloaded-for-initializer-list-literals

Coverage remained the same at 96.36% when pulling b28058720456d9b5226d6f2cc292670076157068 on JakubFornadel:patch-1 into 8465f05e7e86b1365c21f81bba10281b7809c9f7 on SRombauts:master.

Thanks


Question re. user/data migration of older NAV on prem to Business Central

Hi guys,
I would like to know if we have any guidelines to start with for projects where existing on prem customers want to transition to Business Central.
I would like to see the best answers/guidelines around these questions (which I am sure are blogged about but I want some verified answers):

recommended process to migrate data? We cannot do what we used to do (sql database backup restore and convert/data migration), would Config Packages be the way to go and would ledger entries need to be re-created through journals?
* I assume the above has to be backed by transitioning any customization to extensions
could we transfer the user's specific data as well? how would that be done, is it as easy as mapping the users to the Azure AD through the domain provider?
from a licensing perspective: if a customer just subscribes to Office 365, maps his domain to the Azure AD, creates his users and buys the BC license, would he need to buy any other O365 licensing or just flick the switch for BC on each user and they would be able to use the service?

Cheers,
Rob

Please see:
https://github.com/Microsoft/AL/issues/2476
https://github.com/Microsoft/AL/issues/1689
Perhaps @jenolson has an update on this topic as well

@StanislawStempin
Your answers only lead to requests and questions that have already been closed, but that have not been answered either. There is still a need for an answer as to how a customer can be transferred to the new Azure world with an existing OnPrem solution and when or whether Microsoft plans to provide the appropriate tools.

This repository no longer handles general questions and is only dedicated to bug reports and feature suggestions for AL compiler and developer tools
To get help please use one of the following resources:
Business Central Community
mibuso forum
Dynamics User Group


[ci skip] adding user @remi-kazeroni

Hi! This is the friendly automated conda-forge-webservice.
I've added user @remi-kazeroni as instructed in #54.
Merge this PR to add the user. Please do not rerender this PR or change it in any way. It has [ci skip] in the commit message to avoid pushing a new build and so the build configuration in the feedstock should not be changed.
Please contact conda-forge/core to have this PR merged, if the maintainer is unresponsive.
Fixes #54

@schlunma we got us a failed test from the ICON cmorizer - could you remind me if we fixed this, please? Nay bother too much, this PR is not rebuilding/redeploying the package, and it is at v2.7.1 so we may have fixed that ages ago - but just making sure, better safe than Tory :+1:

We changed the test grid file in https://github.com/ESMValGroup/ESMValCore/pull/1664, which causes the older tests to fail now. This is fixed in the current main :+1:

brilliant, cheers, Manu! :beer:


shading dependencies in pulsar client

Minimizing the number of dependencies in Pulsar client by shading them

retest this please

retest this please

retest this please

retest this please


Frapi development is dead?

Hi guys, is frapi development dead? :(

Hi, yes(

Why can't the maintainers simply remove dead projects, this is the 5th dead project i find today while looking for simple small PHP REST API frameworks.


[RFC] pkg/kvstore: start watchers only when etcd is connected

There's no point in trying to watch for a resource is etcd is not
connected so we should start watching for a resource when cilium has
etcd connectivity.
Signed-off-by: André Martins<EMAIL_ADDRESS>Depends on #7447
NOTE: Even with this patch I've noticed "Starting to watch allocation changes" message always shows that etcd is not connected, I think we should also wait until we have connectivity with the kvstore before reporting any status for etcd.

This change is

@aanm Is there a particular reason why you marked this as RFC? This seems straight-forward to me.

@tgraf  Mostly because of this:
NOTE: Even with this patch I've noticed "Starting to watch allocation changes" message always shows that etcd is not connected, I think we should also wait until we have connectivity with the kvstore before reporting any status for etcd.


Add support for rate limiting producers

Initial work on rate limiting producers. I think that this is the right direction, butI might be wrong so let me know :) Some questions:

we should probably limit the size of the buffer where we store messages. Should we have :buffer_keep and :buffer_size like GenStage has?

right now, the rate limiting is per producer. At work, we need rate limiting per pipeline, that is, the total number of messages consumed needs to be under a certain rate. A solution can be to just have each producer have a rate limit of total_rate_limit / number_of_producers per second. This practically works but might not be optimal because if a producer can produce a lot while another producer is slow, the fast producer will be penalized by its own rate limiting instead of sharing the rate limiting and improving throughput. Another thought is that Broadway doesn't have correlation between producers and processors, so I don't know if rate limiting per producer is every useful rather than rate limiting globally. What are your thoughts on this?

I think we should go ahead and implement the shared counter. We can implement it with ETS:

On every operation, we bump the ETS counter using update_counter. Everything that is above the rate limiting limit, is queued.

We have a separate process that is clearing the ets row every X seconds. This process will issue a select_replace. If the value we read is greater than or equal to the limit, we send a message to all producers telling them they can go back to emit items.

amazing!!! :heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:


Hash contents of cm instead of using resource version

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 17 (0.0%)  changed or added relevant lines in 2 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.04%) to 25.419%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

controllers/sriovnetworknodepolicy_controller.go
0
1
0.0%

pkg/utils/utils.go
0
16
0.0%

Files with Coverage Reduction
New Missed Lines
%

controllers/sriovibnetwork_controller.go
2
70.45%

Totals

Change from base Build<PHONE_NUMBER>:
0.04%

Covered Lines:
2334

Relevant Lines:
9182

💛  - Coveralls

LGTM

@adrianchiris @SchSeba @zeeke @wizhaoredhat @zshi-redhat @e0ne PTAL we are trying to expedite getting this backported for a cu issue.

can you say what exactly the issue is in the commit msg and why this change is needed ??

can you say what exactly the issue is in the commit msg and why this change is needed ?

About why this change is needed:
Short version: It was suggested by our API team that we should not use ResourceVersion of configmap objects to track its content change since the ResourceVersion may change for various reasons (e.g. etcd key rotation, metadata field update etc), not that we assumed it will only change when sriov policy changes.
Long version: We observed that the ResourceVersion of some k8s objects (e.g. configmap, secret) changes as a consequence of etcd key rotation (because apiserver updates these encrypted k8s objects upon etcd key rotation). In sriov operator case, the ResourceVersion of device-plugin-config configmap changes when etcd key rotates, which results in sriovNetworkNodeState generation update, it then causes unnecessary reconcilication of sriov node state in sriov-config-daemon. Given that nodeStateSyncHandler always restarts sriov-device-plugin pod and the etcd key rotation may happen anytime depending on it's rotating intervals, we have seen customer issue that their pods cannot be started due to unexpected admission error from sriov-device-plugin while it gets restarted.

@e0ne PTAL

My concern is that the hash of the data doesn't really go with a parameter named DpConfigVersion. I don't think changing the name of the parameter is an option here. So, could you please add a docstring for this parameter in the api to explain what the content of this parameter will be? This way the custom resource will have a description for this parameter.
Also, please add a body to the commit explaining why this change is needed.

I've added a commit message. @mlguerrero12  PTAL

Have you thought about setting an empty string for this parameter? What's the purpose of it? Is it to have a quick way to know if networknodestate objects and the DP config map are in sync?

Have you thought about setting an empty string for this parameter? What's the purpose of it? Is it to have a quick way to know if networknodestate objects and the DP config map are in sync? A hash wouldn't be something to use as a quick comparison I think. Hence, we could stop using it.

An empty string is a perfectly valid thing to hash. It will be used when the cm data field is empty.
The effort I'm pushing for breaks down into two pieces.

Let's focus on fixing the issue at hand (which we will backport to earlier versions) which is "the way we use resource version is incorrect".
We can rewrite parts of operator to finally get rid of the separate CM altogether.

This PR addresses only number 1.

LGTM

after this change gets deployed, will sriov network operator sync sriov network node states and update DpConfigVersion with the new hash ?if so this will cause config-daemon to reconcile once.

LGTM. My only concern is upgrades to sriov-network-operator to this new cksum calculation will cause DpConfigVersion to change. Consequently a reboot of the device plugin and possibly a drain of the node.

LGTM

after this change gets deployed, will sriov network operator sync sriov network node states and update DpConfigVersion with the new hash ?if so this will cause config-daemon to reconcile once. (which will restart device plugins ?)

It will not forcefully update it during an upgrade. However, if there is any change to the resource version after that, there will be one final restart to update the dp version to the hash.

It will not forcefully update it during an upgrade. However, if there is any change to the resource version after that, there will be one final restart to update the dp version to the hash.

please confirm you have tested it.

I confirm I have swapped out the image of my cluster with this new version and I've seen the hash change when the cm was reconciled.

did device plugin restart after that ?

I confirm I have swapped out the image of my cluster with this new version and I've seen the hash change when the cm was reconciled.

did device plugin restart after that ?

yes, there was 1 more final restart for the dp.

yes, there was 1 more final restart for the dp.

personally im OK with it so LGTM,
id like to get confirmation from @SchSeba / @zeeke  that they are ok with it.
@wizhaoredhat i assume that a device plugin restart is tolerable after upgrade ?

LGTM


Repetition of categories in corresponding vocab files

I searched for the category "coordinateSpace" and found it 3-times in the categories file. Maybe introduce with the update of the namespace, @Raphael-Gazzotti?

I may be misunderstanding the issue, but it seems "coordinateSpace" appears only once per version (latest, v4.0, v3.0).

Yeah, I'm sorry. I forgot about that 😆 I think I have been working too much with the properties and just assumed similar structures which obviously does not make any sense.


Create _goodbye.siml

May or may not conflict with !ai goodbye. I don't know what I'm doing.

@Thielak Am I doing it right? Updated my file.

Aye aye


Conversation restart doesn't work

Channel: Skype
nupkg v: alpha-m3.1
I have a long-running operation my bot kicks off. As such, I send to my endpoint a serialized version of ConversationReference like so:
await _client.PostAsync([my endpoint],
    new StringContent(JsonConvert.SerializeObject(
        new
        {
            callback = new
            {
                url = @"http://mybot.azurewebsites.net/api/callback",
                conversation = TurnContext.GetConversationReference(turn.Activity)
            }
        }),
    Encoding.Default, @"application/json"));

and I've added another controller to my bot like so:
[Route("api/Callback")]
public class CallbackController : Controller
{
    private readonly IConfiguration _config;
    private readonly TelemetryClient _logger = new TelemetryClient();

    private static BotFrameworkAdapter _adapter = null;

    public CallbackController(IConfiguration configuration)
    {
        _config = configuration;

        if (_adapter == null)
        {
            _adapter = new BotFrameworkAdapter(new ConfigurationCredentialProvider(configuration));
        }
    }

For my POST handler, I have the following:
[HttpPost]
public IActionResult Post()
{
    dynamic request = JToken.ReadFrom(new JsonTextReader(new StreamReader(this.Request.Body)));

    var activity = Activity.CreateMessageActivity() as Activity;

    var reference = ((JObject)request.reference).ToObject<ConversationReference>();
    TurnContext.ApplyConversationReference(activity, reference);

    new TurnContext(_adapter, activity)
        .SendActivity(@"All done!");

    return NoContent();
}

but, despite no exceptions in deserializing back in to a ConversationReference and all the properties populated successfully, no message is sent back to my user on Skype.

I also tried this:
            var reference = ((JObject)request.reference).ToObject<ConversationReference>();
            _adapter.ContinueConversation(reference, HandlerAsync);

            return NoContent();
        }

        private async Task HandlerAsync(ITurnContext turn)
        {
            await turn.SendActivity(@"All done!");
        }

with the same results

Oh you're doing proactive, there's a known bug (#314) there right now that's fixed in #461.

I've decoupled this fix from the other work in #461, now the PR we're waiting for is #468.

@brandonh-msft #468 was merged in earlier this morning. There are no packages published for it, but if you build locally and reference the local packages you can try out the fix and see if it's working for you now. At bare minimum I know that specific NullReferenceException will be gone. I was also able to get a contrived test scenario working locally against the emulator in which I was able to send a proactive message back using ContinueConversation from a ConversationReference much like you laid out above. I would definitely suggest using the direct _adapter.ContinueConversation approach though, it doesn't make sense for you to spin up your activity + TurnContext for this scenario.

Doesn't fix the problem. I built the latest master source, published the packages to a VSTS instance, and pulled them down. I use them, ship the bot to Azure, and get a proactive message. At the point where I do turn.SendActivity() it blows up with:
Microsoft.Bot.Connector.Authentication.MicrosoftAppCredentials.OAuthException
  HResult=0x80131500
  Message=Unauthorized
  Source=<Cannot evaluate the exception source>
  StackTrace:
   at Microsoft.Bot.Connector.Authentication.MicrosoftAppCredentials.<RefreshTokenAsync>d__30.MoveNext() in D:\Github\Microsoft\botbuilder-dotnet\libraries\Microsoft.Bot.Connector\Authentication\MicrosoftAppCredentials.cs:line 203
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

Inner Exception 1:
HttpRequestException: Response status code does not indicate success: 401 (Unauthorized).

@brandonh-msft Thanks for the bug report, and the detailed analyis. I'll look into removing the problematic overload completly. I want to sync with @Stevenic to make sure we mirror that behavior in Node.

Fixed / Merged in PR #483

Removing the overload does not seem like the correct solution to this and has now regressed #314. The default overload of BotAdapter::ContinueConversation needs to be overridden in BotFrameworkAdapter or else it won't have a chance to inject the services into the TurnContext that it relies on later.  So, while I understand I used the wrong value in the implementation (bot id vs bot app id), we need to overload it to support the scenario from #314 where the caller is in the midst of a turn and decides they want to do something proactive:
Imagine MyBot.cs...
public Task OnTurn(ITurnContext turnContext)
{
    // received some activity that triggers some proactive conversation
    await turnContext.Adapter.ContinueConversation(
        someConversationReference,
        continuedTurnContext =>
        {
             await continuedTurnContext.SendActivity("hello from proactive");
        });
}

Let's consider what's happening here: a dev has written a bot that's supposedly agnostic of the adapter it's hosted in and thus, by design, TurnContext::Adapter is of type BotAdapter. Given that, the only overload the developer would ever have available to them would be the base overload that does not take the botAppId.
Now, they could obviously cast the Adapter to BotFramworkAdapter and then call the overload with botAppId, but, for this specific scenario, I would argue that in the case above we could assume that whatever "app" was in place in the original turn is the one they want to use to make the proactive calls and that would be a reasonable default the majority of the time not requiring people to go that extra step further. I can definitely solve that problem and make it work based on the "current" app identity, but I'd love some confirmation of my thinking here before submitting a new PR. If this doesn't make sense, then it's possible the entire abstraction is flawed and needs to be revisited.
Ok, so... that's not even @brandonh-msft's scenario, right? In his case he actually is working with the BotFrameworkAdapter directly, so he absolutely could call the overload directly, though he does have to discover this himself. The fact is, I don't actually think he (or any developer) needs to be doing this themselves. This is what PR #461 is about enabling. It would allow devs to submit event activities from "the outside" to which the bot can could react and it already allows passing the botAppId via an HTTP header or on the querystring and the developer would not even need to be concerned with the adapter instance at all.

The adapter / bot has been heavily refactored a couple of times since this thread was active.
We think you should be able to achieve what you want to with the current factoring. Possibly there are some patterns that will emerge and we will want to first class in the core framework. However, for this version we are locking down.


[SPARK-35735][SQL]  Take into account day-time interval fields in cast

What changes were proposed in this pull request?
Support take into account day-time interval field in cast
Why are the changes needed?
Support take into account day-time interval field in cast
Does this PR introduce any user-facing change?
user can use cast(str, DayTimeInterval(DAY, HOUR)) etc
How was this patch tested?
Added UT

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44433/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44433/

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

Ping @MaxGekk

Test build #139935 has started for PR 32943 at commit fe7b616.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44462/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44462/

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

Test build #139935 has finished for PR 32943 at commit fe7b616.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

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

retest this please

Test build #139954 has started for PR 32943 at commit fe7b616.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44481/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44481/

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

Test build #139954 has finished for PR 32943 at commit fe7b616.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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

Test build #140255 has started for PR 32943 at commit 7ad0ff9.

Kubernetes integration test unable to build dist.
exiting with code: 1
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44784/

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

Test build #140255 has finished for PR 32943 at commit 7ad0ff9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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

Test build #140269 has started for PR 32943 at commit 3f615f1.

Test build #140269 has finished for PR 32943 at commit 3f615f1.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

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

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44800/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44800/

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

retest this please

Test build #140275 has started for PR 32943 at commit 3f615f1.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44806/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44806/

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

Test build #140275 has finished for PR 32943 at commit 3f615f1.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

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

Test build #140289 has started for PR 32943 at commit cdb0c9c.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44820/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44820/

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

ping @MaxGekk @cloud-fan

Test build #140289 has finished for PR 32943 at commit cdb0c9c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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

ping @MaxGekk  Can help to re-trigger the jenkins test?

retest this please.

Hmm, Jenkins seems down today.

@AngersZhuuuu You can re-trigger yourself by making an empty commit:
git commit --allow-empty -m "Trigger build"

Test build #140371 has started for PR 32943 at commit 7dfa4f8.

Test build #140371 has finished for PR 32943 at commit 7dfa4f8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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

@AngersZhuuuu You can re-trigger yourself by making an empty commit:
git commit --allow-empty -m "Trigger build"

Can work now, any more suggestion?

+1, LGTM. Merging to master.
Thank you, @AngersZhuuuu and @sarutak for review.


Some profiling information

I have been playing around a little bit with my profiler to check the performance of AI. Some interesting things came up, which I would like to share. Please realize that at this point performance is not our greatest concern. (reliability and functionality is much more important, the tactics PC is quite strong). Also realize that the results may be different on other OS'es or other devices.
tl;dr

Decouple the interface and/or make it more efficient for max. 50% performance increase
remove the maps from constants.cpp and make the either macro's or static constrexpr loose variables etc. those lookups can be done at compile time. this increases performance with approx. 5-10%
remove the old world for an approx. 10% performance increase
merge #802 for a 20% performance increase
doing the above should result in the fact that running halt strategy does not take more than 5% CPU time anymore.

how did i profile?

OS: macOS 10.15 "catalina"

Device: macbook pro 13" retina

CPU (2,4 GHz Dual-Core Intel Core i5)

RAM: 8 GB 1600 MHz DDR3

GPU: Intel Iris 1536 MB

All RTT libraries compiled with -O3 except for AI, which is compiled to -g -O0.

start profiler after initial boot of rtt AI. ran usually around 3 minutes. (1 minute halt, 1 minute formation, 1 minute normal play)

What is the biggest performance hit?
It is by far the QT interface, which takes more than 50% of the CPU time, even during normal play. At least, this is the case on MacOS. Not sure what this percentage is on other devices, macOS is known for heavily prioritizing graphics. Still, the interface is very heavy. The most heavy parts are the graph widget and the visualization widget.
on development, 20% of the CPU time went to the behaviour trees (this includes updating world) and 10% to smaller things (like protobuffers etc.). So where did the other 20% go?  It was IOManager. and more interestingly, on my branch (#802 Cleanup IOmanager) this was NOT the case. I suspect this is the price you pay for updating the world anytime a message comes in: you have to lock mutexes, wait a lot for them, and probably some cache misses because of switching threads etc. etc. -> on my device PR #802 shows a huge performance improvement of almost 20%! (I thought game analyzer was the bad guy here, but that only took about 1 percent)
Updating the world
The new world updates quite a bit faster. it does the same calculations in about 70% of the time. Half of that time is looking up constants from constants.cpp, which are the maps for working geneva and working dribbler. These things are quick wins of course by removing the map. (maybe on O3 this would be optimized out, but i tested on -g O0)
Note that at this point the performance gain of the new world is not there, since the old one is still present.
Other insights

The calculations are very nicely spread over 4 cores.
percentages are sometimes vague.
roboteam utils, roboteam proto and roboteam_world perform really good performance-wise

I would argue that profiling at -O0 is pretty much meaningless for AI. Function inlining, vectorization and other things affect performance heavily. Roboteam_World literally becomes almost 100-1000 times faster on my machine going from O0 to O3

I did it on -O0 specifically because at the robocup we ran at O0 as well, so that we could catch mistakes more quickly would they occur.  Besides, although it is not entirely accurate, it definitely does give a representation of what is fast and what is not.


port to stdpp 1.6.0 and later

Minor changes to make upgrade to later Coq version possible.

@traiansf so do we want to merge this today? I think it's a good idea since it's more compatible than before ("stdpp 1.6.0 or later")


implement findAll to allow fluent assertions against all elements that match selector

Purpose
Hello there 👋,
I believe that, at the moment, the way to make assertions against multiple matches is done through $assertElement->contains() and $assertElement->doesntContain() methods.
The limitation of these approaches is that the contains() doesn't allow us to write an assertion that ensures all elements under a given selector respect a specific set of rules.
For example:
"Assert all images being rendered have an 'alt' attribute"
->assertElementExists(fn(AssertElement $viewRendered) => viewRendered
    ->doesntContain('img', [???]) // Without alt attribute

I believe we cannot perform this assertion with the existing resources.  Let me know if I'm mistaken.
My proposed solution is the following:

The reasoning behind this proposal is two-fold:

It allows us to make sweeping assertions about what must be enforced for all elements in the selection.

It allows us to continue making fluent assertions over all elements in the selection

It resembles the ->has->each() API that exists in the FluentJSON assertion

I hope this doesn't go against the philosophy of the package.
I'm looking forward to any feedback or suggestions.

Thanks for the PR!
I love the idea, but perhaps just name it each like with AssertableJson. That would make it much easier to remember :)

I love it, sounds good
Thanks for the PR! I love the idea, but perhaps just name it each like with AssertableJson. That would make it much easier to remember :)

Awesome 🎉! I'm glad you liked it!
Good point! Naming it each() makes it more descriptive.

@sinnbeck While I was updating the readme, I noticed there was a section of it using contains() with a callback being passed as an argument:

I think this is probably from an older version of the API. At the moment the contains does not take callbacks.
I included a quick tweak to this section to this instead:

But let me know if you would prefer me to revert this change. This is in the HEAD commit of the PR, I could just remove it.

Oh nice catch! Normally I would prefer it in a separate PR but I will just release it as part of the same version :) Ill draft a new release right away


Plans to switch to .NET core instead of Mono?

Are there any plans to switch to .Net core (which is platform independent) instead of Mono?

I don't want to be rude but,
please don't waste the devs time by such issues just join the reddit.
Read this: Why hasn't Godot used DotNet Core, as opposed to Mono?
It clearly says that .Net core is not ready yet and thus doesn't make it into priority and it's only about a couple of months old so such a issue doesn't make any sense.

Duplicate of #10612 and maybe #17010.

This is very problematic for many of us who are .NET developers and use .NET Core. Many libraries are no longer available in "Framework" flavour (for example, SadConsole) and only available in .NET Core. This means we won't be able to integrate them with .NET in the foreseeable future.
.NET Core DLLs can call .NET Framework DLLs, so switching to .NET Core is actually more compatible. However, I understand and accept (to some degree) the argument that .NET Core does not (yet) run on mobile, and Godot does run on mobile today.

I think they plan on consolidating all of the .Net's (and Mono) in .Net 5, so it wouldn't make sense to change anything until that happens and any issues have been ironed out.
https://devblogs.microsoft.com/dotnet/introducing-net-5/

I think they plan on consolidating all of the .Net's (and Mono) in .Net 5, so it wouldn't make sense to change anything until that happens and any issues have been ironed out.
https://devblogs.microsoft.com/dotnet/introducing-net-5/

Yeah that is a good idea, as .net 3 is not released yet. only in preview and has a lot of changes between 2 and 3
.net 5 essential - you should just need to change the project type and it should work.

3.0 is out now! :)

Also a .NET Standard 2.0 library an be called from mono!


anyof keyword is not converted appropreately

Description
OpenAPI schema
"SchemaX": {
  "anyOf" : [SchemaA, SchemaB]
}

is converted to
type SchemaX = Partial<SchemaA & SchemaB>

, but I think it shoud be converted to
type SchemaX = SchemaA | SchemaB

.
Maybe its source code is arround https://github.com/aspida/openapi2aspida/blob/main/src/builderUtils/props2String.ts#L37-L40 .
Environment

Package version:
v0.19.0
OS:

[x] Linux
[ ] Windows
[ ] macOS

Node.js version:
v18.2.0
npm version:
8.9.0

Additional context
Thanks for developing this awesome library!

From the description on this site, it seems that the implementation of anyOf is incomplete but not wrong.
https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/

For the example of the page, schemas of PetByAge and PetByType are represented in Typescript as
type PetByAge = {
  age: number
  nickname?: string
}

type PetByType = {
  pet_type: 'Cat' | 'Dog'
  hunts?: boolean
}

, and considering two types below,
type SchemaX = Partial<PetByAge & PetByType>
type SchemaY = PetByAge | PetByType

I think a union type represents more precisely the schema as documented.
Because the schema of anyof PetByAge and PetByType should reject
{
  "nickname": "Mr. Paws",
  "hunts": false
}

, but SchemaX accepts it and SchemaY reject.
const x: SchemaX = {"nickname": "Mr. Paws",  "hunts": false}  // assignable :(
const y: SchemaY = {"nickname": "Mr. Paws",  "hunts": false}  // error, not assignable :)

And also Schema Y accepts all objects that the schema accepts
const y: SchemaY = { "age": 1 }
const y: SchemaY = { "pet_type": "Cat", "hunts": true }
const y: SchemaY = { "nickname": "Fido", "pet_type": "Dog", "age": 4}

And I found other wrong case.
Considering the case below,
components:
  schemas:
    schemaA:
      type: object
      properties:
        id:
          type: integer
      required:
        - id

    schemaB:
      type: object
      properties:
        id:
          type: string
      required:
        - id

    schemaX:
      anyof:
        - $ref: '#/components/schemas/schemaA'
        - $ref: '#/components/schemas/schemaB'

schemaA and schemaB will be converted to
type SchemaA = { id: number }

type SchemaB = { id: string }

and schemaX should accept { id: string } or { id: number }.
However, schemaX is converted to
type SchemaX = Partial<schemaA & schemaB>
// = {id?: undefined}

with current implementation because schemaA & schemaB is { id: never }.
On the otherhand, if with union type implementation, SchemaX will be converted to
type SchemaX = SchemaA | SchemaB
// = {id: string | integer}

.

@solufa
Is there any chance this feature request will be accepted?
If needed, I am able to create PR.

Fixed in v0.23.0


[SPARK-14804][Spark][Graphx] Fix checkpointing of VertexRDD/EdgeRDD

What changes were proposed in this pull request?
EdgeRDD/VertexRDD overrides checkpoint() and isCheckpointed() to forward these to the internal partitionRDD. So when checkpoint() is called on them, its the partitionRDD that actually gets checkpointed. However since isCheckpointed() also overridden to call partitionRDD.isCheckpointed, EdgeRDD/VertexRDD.isCheckpointed returns true even though this RDD is actually not checkpointed.
This would have been fine except the RDD's internal logic for computing the RDD depends on isCheckpointed(). So for VertexRDD/EdgeRDD, since isCheckpointed is true, when computing Spark tries to read checkpoint data of VertexRDD/EdgeRDD even though they are not actually checkpointed. Through a crazy sequence of call forwarding, it reads checkpoint data of partitionsRDD and tries to cast it to types in Vertex/EdgeRDD. This leads to ClassCastException.
The minimal fix that does not change any public behavior is to modify RDD internal to not use public override-able API for internal logic.
How was this patch tested?
New unit tests.

Test build #66538 has started for PR 15396 at commit 22d16b4.

I'm no expert on checkpointing, but the tests look fine to me.  You could eliminated duplicated code in the tests by putting the shared code in a helper method.
Tested locally to confirm unit tests fail before the fix.

Test build #66538 has finished for PR 15396 at commit 22d16b4.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

Can you reference the earlier pull requests here too?

Looks good. I left a suggestion that I think will make the code cleaner.

Any update on this? Would love to see it in an upcoming release.

Test build #72002 has started for PR 15396 at commit 9878c9f.

Test build #72002 has finished for PR 15396 at commit 9878c9f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

I am merging this to master and 2.1


legacy.js import from cdn fails

I am trying this in ff/win, and it all goes well for awhile until this happens:

this // causes the url to 404, I think?
For chromium the situation is different, but it won't load any way:

To quote SO,

I believe this is the bug affecting you: https://bugs.chromium.org/p/chromium/issues/detail?id=108055
There's been discussion about it from 2011-2016, and is ongoing. Basically Chrome can't handle a very large number of requests in a short period of time.

So when you say here that people could import BabylonJS entirely using:
import * as BABYLON from "@babylonjs/core/Legacy/legacy";

perhaps mention that it only works at compile time with a bundler 😅

I ll update the doc ASAP thanks a lot.
cc @RaananW to double check when he ll be back from vacation.

I will be happy to mention the browser error, but we as a framework expect it to work :-)


Multinomial Naive Bayes Improvements

Changelog:

Removed classes property and ordinal_encode from fit.
Updated docstring to specify that targets should be between 0 and num_classes - 1.
Some refactoring, e.g. used Nx.logsumexp, moved argument validation inside fit, etc.
Fixes #242.

Another thing is that Nx.logsumexp/2 should be pulled out of nx.ex file. I might create a separate issue for that.

Another thing is that Nx.logsumexp/2 should be pulled out of nx.ex file. I might create a separate issue for that.

Why?

Another thing is that Nx.logsumexp/2 should be pulled out of nx.ex file. I might create a separate issue for that.

Why?

@polvalente Yeah, I should have written the reason. :)
It's because the maximum value that is subtracted from the exponentials should be treated as constant during differentiation as done in Axon and JAX. Correct me if I'm wrong - this cannot be done for functions in nx.ex file?
Alternative would be to have separate implementations in Scholar and Axon, but I would prefer to have it in Nx because I consider the function fundamental.

Another thing is that Nx.logsumexp/2 should be pulled out of nx.ex file. I might create a separate issue for that.

Why?

@polvalente Yeah, I should have written the reason. :)
It's because the maximum value that is subtracted from the exponentials should be treated as constant during differentiation as done in Axon and JAX. Correct me if I'm wrong - this cannot be done for functions in nx.ex file?
Alternative would be to have separate implementations in Scholar and Axon, but I would prefer to have it in Nx because I consider the function fundamental.

Ah, we can probably fix this by setting stop_grad there :)

Another thing is that Nx.logsumexp/2 should be pulled out of nx.ex file. I might create a separate issue for that.

Why?

@polvalente Yeah, I should have written the reason. :)
It's because the maximum value that is subtracted from the exponentials should be treated as constant during differentiation as done in Axon and JAX. Correct me if I'm wrong - this cannot be done for functions in nx.ex file?
Alternative would be to have separate implementations in Scholar and Axon, but I would prefer to have it in Nx because I consider the function fundamental.

Ah, we can probably fix this by setting stop_grad there :)

I thought I tried it but it didn't work. Probably a mistake by me. :)

Another thing is that Nx.logsumexp/2 should be pulled out of nx.ex file. I might create a separate issue for that.

Why?

@polvalente Yeah, I should have written the reason. :)
It's because the maximum value that is subtracted from the exponentials should be treated as constant during differentiation as done in Axon and JAX. Correct me if I'm wrong - this cannot be done for functions in nx.ex file?
Alternative would be to have separate implementations in Scholar and Axon, but I would prefer to have it in Nx because I consider the function fundamental.

Ah, we can probably fix this by setting stop_grad there :)

I thought I tried it but it didn't work. Probably a mistake by me. :)

I'll check this out in a few min!

https://github.com/elixir-nx/nx/pull/1470 @krstopro


Implement 'lxc image copy'

Signed-off-by: Serge Hallyn<EMAIL_ADDRESS>

I'm not sure getRaw was the best name, open to another name.  But otherwise I thnk this pull request should be ready.

Sorry, one other thing, can we update the lxc help image output to not list the target image name if it can't be used?
getRaw is fine with me.


Doc: In documentation section System overview link is broken

In the Documentation section of README.md file the System overview(System overview) link is broken.
┆Issue is synchronized with this Jira Task by Unito

Thank you for that! Are you interesting in fixing that?