Pin dependencies

This PR contains the following updates:

Package
Type
Update
Change

@quasar/vite-plugin (source)
devDependencies
pin
^1.3.0 -> 1.3.0

@rushstack/eslint-patch (source)
devDependencies
pin
^1.1.4 -> 1.2.0

@tsconfig/node16
devDependencies
pin
^1.0.3 -> 1.0.3

@types/express (source)
devDependencies
pin
^4.17.15 -> 4.17.15

@types/jest (source)
devDependencies
pin
^29.0.0 -> 29.2.6

@types/jsdom (source)
devDependencies
pin
^21.0.0 -> 21.1.0

@types/node (source)
devDependencies
pin
^18.11.18 -> 18.11.18

@types/react-test-renderer (source)
devDependencies
pin
^18.0.0 -> 18.0.0

@types/supertest (source)
devDependencies
pin
^2.0.11 -> 2.0.12

@typescript-eslint/eslint-plugin
devDependencies
pin
^5.0.0 -> 5.50.0

@typescript-eslint/eslint-plugin
devDependencies
pin
^5.48.2 -> 5.48.2

@typescript-eslint/parser
devDependencies
pin
^5.48.2 -> 5.48.2

@vitejs/plugin-vue (source)
devDependencies
pin
^4.0.0 -> 4.0.0

@vitest/coverage-c8
devDependencies
pin
^0.28.0 -> 0.28.1

@vue/eslint-config-prettier
devDependencies
pin
^7.0.0 -> 7.0.0

@vue/eslint-config-typescript
devDependencies
pin
^11.0.0 -> 11.0.2

@vue/test-utils
devDependencies
pin
^2.2.7 -> 2.2.7

@vue/tsconfig
devDependencies
pin
^0.1.3 -> 0.1.3

autoprefixer
devDependencies
pin
^10.4.13 -> 10.4.13

eslint (source)
devDependencies
pin
^8.32.0 -> 8.32.0

eslint (source)
devDependencies
pin
^8.24.0 -> 8.33.0

eslint-config-airbnb-base
devDependencies
pin
^15.0.0 -> 15.0.0

eslint-config-prettier
devDependencies
pin
^8.6.0 -> 8.6.0

eslint-config-standard
devDependencies
pin
^17.0.0 -> 17.0.0

eslint-config-standard-with-typescript
devDependencies
pin
^34.0.0 -> 34.0.0

eslint-plugin-cypress
devDependencies
pin
^2.12.1 -> 2.12.1

eslint-plugin-import
devDependencies
pin
^2.27.5 -> 2.27.5

eslint-plugin-jsdoc
devDependencies
pin
^40.0.0 -> 40.0.0

eslint-plugin-n
devDependencies
pin
^15.0.0 -> 15.6.1

eslint-plugin-node
devDependencies
pin
^11.1.0 -> 11.1.0

eslint-plugin-prettier
devDependencies
pin
^4.2.1 -> 4.2.1

eslint-plugin-promise
devDependencies
pin
^6.0.0 -> 6.1.1

eslint-plugin-react
devDependencies
pin
^7.31.8 -> 7.32.2

eslint-plugin-vue (source)
devDependencies
pin
^9.9.0 -> 9.9.0

istanbul-badges-readme
devDependencies
pin
^1.8.4 -> 1.8.4

jest (source)
devDependencies
pin
^29.0.0 -> 29.3.1

jest-badges
devDependencies
pin
^0.1.3 -> 0.1.3

jest-sonar-reporter
devDependencies
pin
^2.0.0 -> 2.0.0

jsdom
devDependencies
pin
^21.0.0 -> 21.0.0

lint-staged
devDependencies
pin
^13.1.0 -> 13.1.0

npm-run-all
devDependencies
pin
^4.1.5 -> 4.1.5

playwright-webkit (source)
devDependencies
pin
^1.27.1 -> 1.30.0

postcss (source)
devDependencies
pin
^8.4.21 -> 8.4.21

prettier (source)
devDependencies
pin
^2.8.3 -> 2.8.3

sass
devDependencies
pin
^1.57.1 -> 1.57.1

source-map-support
devDependencies
pin
^0.5.20 -> 0.5.21

supertest
devDependencies
pin
^6.3.3 -> 6.3.3

tailwindcss (source)
devDependencies
pin
^3.2.4 -> 3.2.4

ts-jest (source)
devDependencies
pin
^29.0.5 -> 29.0.5

ts-loader
devDependencies
pin
^9.4.2 -> 9.4.2

ts-node (source)
devDependencies
pin
^10.3.0 -> 10.9.1

tsconfig-paths
devDependencies
pin
^4.1.2 -> 4.1.2

typescript (source)
devDependencies
pin
~4.9.4 -> 4.9.4

vite (source)
devDependencies
pin
^4.0.0 -> 4.0.4

vitest
devDependencies
pin
^0.28.0 -> 0.28.1

vue-tsc
devDependencies
pin
^1.0.24 -> 1.0.24

Add the preset :preserveSemverRanges to your config if you don't want to pin your dependencies.

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: frontend/package-lock.json
curl: (18) transfer closed with 23476584 bytes remaining to read
Download failed: https://nodejs.org/dist/v18.14.2/node-v18.14.2-linux-x64.tar.xz
bash: npm: command not found


Update es.json

translate english to spanish
Related Issues

Closes #
Short Description and Why It's Useful

Screenshots of Visual Changes before/after (If There Are Any)

IMPORTANT NOTICE - Remember to add changelog entry
Contribution and Currently Important Rules Acceptance

[ ] I read and followed contribution rules

Closing as handled in https://github.com/hotwax/fulfillment-pwa/pull/333


NTI: Truthiness check discards unknown-ness

function f(x) {
  if (!x) return null;
  return /** @type {number} */ (x);
}

input0:3: WARNING - invalid cast - the types do not have a common subtype
from: truthy
to  : number
  return /** @type {number} */ (x);
                               ^

https://closure-compiler-debugger.appspot.com/#input0%3Dfunction%2520f(x)%2520%257B%250A%2520%2520if%2520(!x)%2520return%2520null%253B%250A%2520%2520return%2520%252F**%2520%2540type%2520%257Bnumber%257D%2520*%252F%2520(x)%253B%250A%257D%26input1%26conformanceConfig%26externs%26refasterjs-template%26includeDefaultExterns%3D1%26CHECK_SYMBOLS%3D1%26CHECK_TYPES%3D1%26CHECK_TYPES_NEW_INFERENCE%3D1%26CLOSURE_PASS%3D1%26LANG_IN_IS_ES6%3D1%26MISSING_PROPERTIES%3D1%26PRESERVE_TYPE_ANNOTATIONS%3D1%26PRETTY_PRINT%3D1%26TRANSPILE%3D1
The if() check that narrows it to truthy discards the possibility of any other type.
You ought to narrow it to a "non-falsy unknown" type.

This is still broken for instanceof:
function f(x) {
  if (!x) return null;
  return x instanceof Array;
}

javascript/apps/fava/debug/debugservice.js:80: ERROR - Invalid type(s) for operator INSTANCEOF.
Expected : an object or a union type that includes an object
Found    : truthy

  return x instanceof Array;
         ^

(from a build that includes the fix)

And for method type inference:
function f(x) {
  if (!x) return null;
  forEach(x, y => {});
}

/**
 * @param {!Array<T>} arr
 * @param {function(T)} cb
 * @template T
 */
function forEach(arr, cb) {}

ERROR - Could not instantiate type Array<T> with truthy.
  forEach(x, y => {});
          ^

Closed by https://github.com/google/closure-compiler/commit/cdf064187bd660fad4b5b65b12be5e2a043779eb


FreeBSD has the Puppet major version in the package name

The non-versioned package is the deleted Puppet 3 gem so this as a bug.


Impl serde::{Deserialize, Serialize} for StrInner

Signed-off-by: Jiahao XU<EMAIL_ADDRESS>

It's not 100% clear if it serializes that as a string or as an array of bytes. I think it should be the former, but can we confirm by having an explicit test, maybe by storing to JSON and then loading it back?

        let s = Deref::deref(self);
        s.serialize(serializer)

s there is &str, I can add an explicit annotation to it.

@vorner I've fixed the serialization code and the style issue.

Thanks for the changes.
It's clearer it's string now, but I'd still like to have a round-trip test. I can add it if you prefer that.
Should I release the other thing or should I wait for this one first?

Should I release the other thing or should I wait for this one first?

I'm not in rush

Codecov Report

Merging #5 (71ca3ed) into main (8c7d384) will decrease coverage by 0.05%.
The diff coverage is 0.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main       #5      +/-   ##
==========================================
- Coverage   85.53%   85.47%   -0.06%
==========================================
  Files           2        3       +1
  Lines         546      544       -2
==========================================
- Hits          467      465       -2
  Misses         79       79

Impacted Files
Coverage Δ

src/string/mod.rs
79.93% <ø> (ø)

src/string/serde_impl.rs
0.00% <0.00%> (ø)

It's clearer it's string now, but I'd still like to have a round-trip test. I can add it if you prefer that.

I will add unit tests using serde_test

@vorner I've added basic unit tests for Str and StrMut.

Thanks. I'm going to release it now.


Ember Simple Auth

Hey!
Ember simple auth sends a request with these headers, but according to the docs it wont work:
**Authorization:**Token token="Q1AyBcNUNEv65djHyYFu", uid="765611.........."
Any way we can get support for this type of request (token="") in the gem?
Thanks.

I think the preferred way is to customize the ember-simple-auth plugin. I will look into that the next days.

Hi there @ghost   ,
In an effort to cleanup this project and prioritize a bit, we're marking issues that haven't had any activity in a while with a "close-in-7-days" label. If we don't hear from you in about a week, we'll be closing this issue. Obviously feel free to re-open it at any time if it's the right time or this was done in error!
If you are still having the issue (especially if it's a bug report) please refer to our new Issue Template to provide some more details to help us solve it.
Hope all is well.


Investigate weirdness with assessment import

All of the other file importers output a nice progress bar in the remote logs, but not the X2 assessment importer. Not sure why, need to investigate.

Assessment import working fine, just the progress bar missing. My guess: caused by all the Error R14 (Memory quota exceeded) warnings being printed by Heroku. Let's see if fixing #11 fixes this.

Closing for now, will re-open if issue persists after fixing the memory warnings.


Add /bored command using boredapi

Command Name
/bored
Public API Resource
https://www.boredapi.com/api/activity/
Description
a command to generate a random activity to kill boredom , just type /bored and the bot will reply with a message suggesting what to do
Implementation Details

Add a new javascript file in the commands folder
Implement a API request with the help of axios to your public API
Format the data in a readable way and send it to the user
Use the discord.js docs to get started

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hey ! I'd like to work on this one, can you assign me ?

I want to be assigned to work on this , for hacktoberfest 😄

@MoncefME Sure, go ahead :)
@Irjean Since MoncefME created this issue, I'll assign him, but you can open your own issue.

@thieleju I did a pull request , the command worked for me , can you please confirm if there is no problem , I edited the Readme.md file ( added the command )

@MoncefME Well done!
I reviewed your pr #77 and labeled it with the hacktoberfest-accepted label.
Thanks for contributing ❤

thanks dude  I hope I can contribute more , I love this project < I found it interesting since I'm new to discordjs> , should I wait to be approved by hacktoberfest?

@MoncefME Thank you ❤
But unfortunately for the duration of hacktober, this repository is only 1 pr/issue per person.
I think the site needs a little more time since I did all 3 things 😄

Great , this is my first PR so I don't know that I should wait 7 days , I will keep woking on other projects , thanks you so much mate, have a nice day 🥇


unit of velocity

Hello!!
your AR drone code is really awesome
i just wonder what unit of velocity of drone?
and also roll, yaw and pitch
thank you!!!

Hi !
The unit of velocities which returned by ARDrone::getVelocity() is [m/s].
Moreover, the unit of roll, pitch and yaw angles is [rad].
If you would like to use them in degrees, please use RAD_TO_DEG.
// Convert angles from [rad] to [deg]
double roll  = ardrone.getRoll()  * RAD_TO_DEG;
double pitch = ardrone.gerPitch() * RAD_TO_DEG;
double yaw   = ardrone.gerYaw()   * RAD_TO_DEG;

Regards,
puku

really appreciate!! thanks


Refactor hardcore

This whole repo should be redone and fit into a fitting js framework.
We need some slickness.
Call a new amazing nodejs web framework.


[Roadmap] Improvements to Human Evaluation and Annotation View

The current human evaluation and annotation view has several limitations that need to be addressed to improve user experience and functionality:

Feedback Types: Currently, only one feedback type (a score on a scale of 0 to 100) is allowed for single evaluations. We should support multiple feedback types and scores to capture a wider range of evaluation metrics.
Comparing Multiple Evaluations: The current view does not allow for comparing multiple evaluations, neither is the table view as comprehensive as the one in evaluation.
Annotating Test Sets: Currently, the ability to annotate test sets and save the changes made during human evaluation is not supported.
Flexible Column Requirements: Currently, users are required to use the column name "correct_answer" for annotations. We should allow users to use different column names and provide more flexibility in column requirements.
Progress Tracking: The current view does not provide a way to track the progress of annotations. Implementing a progress tracking feature would show how much of an annotation is completed and what is left. We also do not allow users to return to the previous part of the annotation.

[ ] #1295 (point 1 and 4)
[ ] #1296 (point 3)
[ ] #1232
[x] #1198
[ ] Improve human evaluation dashboard view

@aakrem @bekossy Some notes about the current solution

Menus

Having an AWS like menu would simplify things in this case

Feedback modal for adding new question (in this order)

Name: Should be without spaces.
Question Title:
Description: Will be shown later as a tooltip in the evaluation view.
A multi-select with the following question types:

Text Question
Rating Questions
Label

When the user selects one of these options, the rest of the form dynamically changes to show the following:

Text Question: Nothing.
Rating Questions: A dynamic Form Item to add allowed scores (link). The current solution of allowing users to provide a number from 0 to hundreds does not make sense. Usually, you would have either good or bad, or maybe a maximum of 5 scores.
Label Question: A dynamic Form Item to add allowed labels (e.g., true, false) (link). The current solution of allowing users to provide a number from 0 to hundreds does not make sense. Usually, you would have either good or bad, or maybe a maximum of 5 scores. Two columns in this form, one about the name of the

The "invite users" section should not be here.
Please refer to this link for inspiration on questions and rendering.

Dashboard view

One possibility would be to have everything in the same table and add a "Configuration" column, which shows the configuration (the ones existing per default are Single Model Eval and A/B Testing). This way, the user would be able to filter to an evaluation type and then compare the results.

New evaluation modal (modify name to new annotation)

The user can only select multiple variants if they have selected a configuration of A/B testing in the annotation type (which I think we should call annotation configuration).
Right next to the "create" button, we add the "invite" button, which allows the user to invite multiple users to do the annotation.
After clicking on "Create", the user jumps directly to the evaluation view.

The evaluation card view should render the questions that were provided in the modal when configuring the annotation.

Open questions:

What happens when the user invites multiple users to do an annotation? Do we create one annotation job for each? Do they all see these annotation jobs in the evaluation, or do they only see their own?

One possibility is to have an annotator role in which they only see annotation jobs that are for them


Screen Hangs and locked when clicked on Outlook Send Email Connector

Describe the Bug with repro steps
1- Open a crowded standart logic app workflow in designer mode.
2 - Click Outlook Send Email action to see the details
3 - Screen hangs and give an error after a while. (Page Unresponsive : Kill browser or Wait popup shown)
What type of Logic App Is this happening in?
Standard (Portal)
Are you using Preview Designer or GA Designer
Preview
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON
No response
Screenshots or Videos
No response
Browser
Chrome - Version 111.0.5563.111 (Official Build) (64-bit)
Additional context
Session ID: 266ba8e6d7f74c5a904259e0f1f9861b
Version: <IP_ADDRESS> (v<IP_ADDRESS>#285ff1b64d.230607-0457) Signed
Composition time: 1.13s
Experiments: Toggle bread crumb
Experiments: Custom scrollbars
Accessibility: Toggle text spacing
Accessibility: Toggle tab highlighting
User settings: Dump | Save | Clear
Telemetry: Flush
Portal services: Dump
Enabled features: 187 | Details
Loaded extensions: 2 | Details
Loaded asset types: 835 | Open blade
Debug Hub: Open Debug Hub
HubsExtension: 84ms | Version: <IP_ADDRESS>.210.0.1285164.230607-0457
Microsoft_Azure_EMA: 16ms | Version: 2.30529.1.8
AB#24289857

Can you send me some more information about your workflow? If you'd rather keep it private you can send it to<EMAIL_ADDRESS>Without more info however, there isn't much I can do to debug this.

Hey @hartra344, tried to provide as much as information with the original post.
If you could guide me about the further information you need, happy to provide.
in the new designer, in a crowded logic app workflow, try to click "Send an email (V2)" action in order to replicate the scenario.
Browser and the mouse just hangs, it couldnt open the right hand pane for the connector properties screen.
Its just like running a js infinite loop, doesnt allow to do any action on the screen.
It forces me either refresh the page, or close the tab to reopen.
Our workflow contains a try-catch block, and the send email connector is under the catch block.
Please let me know what else do you need.

@kipergil-wb we don't have a concept of try catch built into logic apps. What structure are you using to do this? If it's a switch node then I likely know what is causing this and we have a fix ready in our next deployment.


[modify] Enhance task query in Lua m_taskwarrior_d init file

Added report parameter to task execution command
Improved task processing with new hierarchy and visited condition checks
Updated task_query_pattern to include potential report parameter

close #31


events function not compatible

Hi, I want to implement livewire-calendar within my laravel project which it already leverages and livewire for other functions.
I am following the readme and in the LivewireCalendar class I have inserted the events () function as indicated in the guide.
My Visual Studio Code is reporting error to me because it says the events () method is not compatible with 'Asantibanez \ LivewireCalendar \ LivewireCalendar :: events ()
In the guide it is not specified but before the main component class I inserted this line to invoke the package
use Asantibanez \ LivewireCalendar \ LivewireCalendar;
What am I doing wrong?
Thanks to those who want to answer.
See you soon

@fragmadev I had a similar issue. I was able to move past by including:
use Illuminate\Support\Collection;


ARROW-1677: [Blog] Post on ray and arrow serialization

This doesn't seem to be showing up on the Arrow blog. https://arrow.apache.org/blog/

There seems to be some problem with the ASF git mirror and publishing toolchain. I think it's because the arrow-site repo is getting big. You can see I pushed the blog here https://git-wip-us.apache.org/repos/asf?p=arrow-site.git;a=shortlog;h=refs/heads/asf-site. We will need to bug ASF Infra about what's going on

I opened https://issues.apache.org/jira/browse/INFRA-15293 to investigate this


Include JavaScript in Code Coverage

Include Javascript coverage in code coverage.
To be done when we figure how how to test DOM.

Since DOM should be tested with End To End testing #142 I think I'll close this issue, since the JS is tested (Just not uploaded to codecov)


manage PIDP WEBAPP and PIDP SERVICE in DEV

added 2 modules:

service account roles:  tracks the service account's roles.
scope mappings: tracks the realm & client level scope mappings


JSON de-serialization not working - Reactive approach using Spring cloud function

Issue Description:
In spring cloud stream, json is not getting de-serialized into POJOs when the function receives it. No exception but fields are with null values. I am using solace binder.
Issue occurs when:
	Dependencies and version details as follows:
		spring-cloud-starter-stream-solace:2.1.1
		spring-cloud-stream: 3.0.9.RELEASE
		spring-cloud-starter-config: 2.2.6.RELEASE
		spring-boot-starter-actuator: 2.3.7.RELEASE
		spring-boot-starter-webflux: 2.3.7.RELEASE

Issue not happening when:
	Dependencies and version details as follows:
		spring-cloud-starter-stream-solace:2.1.1
		spring-cloud-stream: 3.0.9.RELEASE

Issue not happening when:
	Dependencies and version details as follows:
		spring-cloud-starter-stream-solace:2.1.1
		spring-cloud-stream: 3.0.6.RELEASE
		spring-cloud-starter-config: 2.2.3.RELEASE
		spring-boot-starter-actuator: 2.3.2.RELEASE
		spring-boot-starter-webflux: 2.3.2.RELEASE

Some more findings:
Issue occurs only when I have this version of dependency spring-cloud-function-context:3.0.11.RELEASE. And same works fine with spring-cloud-function-context:3.0.10.RELEASE. But, I can't downgrade the function context dependency as some properties related to error handling doesn't work without latest.
Suspected Class is: SimpleFunctionRegistry.java in line number: 833 in spring-cloud-function-context:3.0.11.RELEASE

I need to have the spring cloud config client and actuator endpoint exposed using webflux. Please help me to resolve the same.

Given that application/json is the default content type, there are hundreds of tests serializing and deserializing to/from JSON. Basically what I am saying is that we can't reproduce it, so you need to provide a test case or sample project that we can run and reproduce the issue.

Given that application/json is the default content type, there are hundreds of tests serializing and deserializing to/from JSON. Basically what I am saying is that we can't reproduce it, so you need to provide a test case or sample project that we can run and reproduce the issue.

Any feedback or follow up on this? As I mentioned, I can't reproduce it so please provide a small project wit bare minimum which demonstrates the issue

Any feedback or follow up on this? As I mentioned, I can't reproduce it so please provide a small project wit bare minimum which demonstrates the issue

Hi @olegz , Apologies for coming back to bit late as I was bit tided-up. I will try to create a sample project to reproduce the same, as quick as possible.
Thanks!

@karthikaiselvan are you still planning to provide a sample to reproduce?

Hi @olegz, I had created one and I couldn't upload the same due to company policy. I have to create it again using my own PC, which I will try to create in the coming weeks. Since I am preparing for few tech exams, ETA is mostly likely the end of April.

I am not able to reproduce the same in the latest versions. So, it item can be closed.
Thanks!


[Auth] No response for google and facebook login

I downloaded the source from the github, and tested.
I have made no change but...

facebook ID update in config.xml of app module and auth module
google-services.json has been inserted

Login with email works very well.  The problem is...

the app, onActivityResult in com.firebase.uidemo.auth.AuthUiActivity, gets no result when I tried google login or facebook login.

As I said I didn't change the gradle file and the information I used is like below...

Android device: LG-F700L
Android OS version: 7.0
Google Play Services version: ??? [When should I refer to get the information?]
Firebase/Play Services SDK version: 11.8.0
FirebaseUI version: 3.2.1

Please teach me how to handle this problem.  Any advice or tip would be highly appreciated.
Also, it would be appreciated if you could teach me how to add label to issue.
I referred https://help.github.com/articles/applying-labels-to-issues-and-pull-requests/
but, I couldn't find the checkbox which the page mentions in the third step.

I believe i am having the same problem.
I am using phone auth. The phone number gets verified, and the verification activity closes. The calling activity either does not get called, or is not getting the same supplied request code.
We faced this issue in prod on an Android 7.0 device (Samsung galaxy S7). I'll leave this info here, and meanwhile try to get my hands on a device with matching configs to test.

@eldi059 do you get a response when you do email authentication or phone authentication?
(Also you can't label issues as an outside contributor so that's why you can't see the box)

@samtstern
Thanks for reply. I don't get response when trying phone authentication, and I do for email authentication.
I am developing the module not based on the example app in this repository but based on firebase documentation.  And just a minute ago I succeeded to login via google account.  Actually the documentation is quite good and it is easy to follow.
I will close the issue.
Thanks again.
(How can I become a contributor? I am a kind of novice in adroid app development, but want to contribute to this site. ;))

@eldi059 thanks for letting us know you figured it out, I will close this issue.
We love to have contributors!  The best thing to do is to read issues and join the discussion, proposing solutions that may work.  FirebaseUI-Android may not be the best place to start if you're a beginner since it's an advanced codebase but you're always welcome to try and contribute to any Firebase repository.


Updates on Storage and Event Hubs kinds

Clarify requirements for Private Endpoint support for Storage Accounts and Event Hubs.

@juanandmsft : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi Juan, thanks for the suggestions, we have a workstream to update the complete list with special considerations as a separate column, our preference is to wait for the complete list to be released shortly, we have many other resources with similar considerations

@malopMSFT - if you're going to make this update in a different PR (in the private repo perhaps), can you add #please-close and this PR will be closed. If this PR is going to be used for something else, then it can remain open. thanks.

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Resolving the merge conflict resolved the issue that's addressed in the pull request, so we'll close the PR. Thanks.


Make sure uploading big things isn't possible

Someone might have uploaded their home directory with intellij. This shouldn't be possible.

I think given the tests that this isn't a problem any more.


Fix geolocation clobbers

The background location wrapper was accessing $window.plugins.backgroundGeolocation which is not defined anymore on the latest version. Changed to $window.BackgroundGeolocation.

Can you point me to the github repo of the version you're referring to?

Sure, it's this one: https://github.com/christocracy/cordova-plugin-background-geolocation/tree/0.3.7

One issue with using that is that it's a Premium plugin; and that doesn't jive with people using it in an open-source project (or expecting to be able to use these plugins for free).

Maybe that's just what we have available now =(
I'm just PR'ing because I tried to use the plugin as is and got this error inside a ngCordova file.

@VicMota I thank you for your PR; but we'll have to put this into a premium branch to have it work; we can't break everyone else by pulling this in. An alternative would be you to fork the project and create a custom wrapper like I did for https://github.com/Jewelbots/ng-cordova-bluetoothle and just use that separately for your needs.  It's less than optimal, I know; but backwards capability is key.

I understand. This can be closed.


Update futures-timer to 3.0.2

I didn't check before creating a PR. Another PR for this is already open https://github.com/async-rs/async-std/pull/738


questions about the WaveletPacket function

shouldn't the Wavelet packet decomposition function-WaveletPackt contain a parameter about sample frequency？ otherwise the wavelet coefficients' length of each level  will be vary along with the input length. But no matter what the input length is, as long as the sample frequency is fixed，should the wavelet coefficient length not change?

We can discuss this in the thread you started on the mailing list:
https://groups.google.com/forum/#!topic/pywavelets/aeZmmySgOas
It is not a bug in PyWavelets, so I will close the issue here


Version incompatibilities?

I can't seem to load the qiime2R package. I've successfully installed it, but when I try to load it, I get this error:

library(qiime2R)
Error: package or namespace load failed for ‘qiime2R’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/Users/.../Library/R/3.6/library/Rhdf5lib/libs/Rhdf5lib.so':
dlopen(/Users/.../Library/R/3.6/library/Rhdf5lib/libs/Rhdf5lib.so, 6): Library not loaded: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libR.dylib
Referenced from: /Users/.../Library/R/3.6/library/Rhdf5lib/libs/Rhdf5lib.so
Reason: image not found

My best (somewhat inexperienced) guess is version incompatibilities? Any insight would be appreciated!

I checked this on my OS X mojave machine and I did not have this issue with 3.6.0. I am wondering if uninstalling or updating your Rhdf5lib might help BiocManager::install("Rhdf5lib"). I am thinking something funny happened in your update from 3.5 to 3.6.

Unfortunately I get the exact same error (described above) on two different OSX machines, so it's not just an update error on one machine. I tried running BiocManager::install("Rhdf5lib") and get this:
Warning message:
package ‘Rdhf5lib’ is not available (for R version 3.6.0)

Hmm, I checked this on two more macs, a second mojave, and a high sierra and I can't replicate the error. Given that you got the error that Rdhf5lib isn't available, I wonder if you need to update your BiocManager as well. I currently have BiocManager_1.30.4 and Rhdf5lib_1.6.0. Please let me know what happens.
Jordan

Got it! I had to update BiocManager and THEN Rhdf5lib, both at the System level (not the user level). Thank you!


[SPARK-23786][SQL] Checking column names of csv headers

What changes were proposed in this pull request?
Currently column names of headers in CSV files are not checked against provided schema of CSV data. It could cause errors like showed in the SPARK-23786 and https://github.com/apache/spark/pull/20894#issuecomment-375957777. I introduced new CSV option - enforceSchema. If it is enabled (by default true), Spark forcibly applies provided or inferred schema to CSV files. In that case, CSV headers are ignored and not checked against the schema. If enforceSchema is set to false, additional checks can be performed. For example, if column in CSV header and in the schema have different ordering, the following exception is thrown:
java.lang.IllegalArgumentException: CSV file header does not contain the expected fields
 Header: depth, temperature
 Schema: temperature, depth
CSV file: marina.csv

How was this patch tested?
The changes were tested by existing tests of CSVSuite and by 2 new tests.

Can one of the admins verify this patch?

Test build #88551 has started for PR 20894 at commit 811df6f.

Test build #88551 has finished for PR 20894 at commit 811df6f.

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/88551/
Test PASSed.

@HyukjinKwon

I think we are fine to just document this like saying them to better use select or renaming it after the load

The problem occurs during loading. Could you, please, explain how select or renaming of the columns could solve the issue which I described above. Spark just loads data silently. And some partitions have wrong data.
Please, do this experiment:
Create two files 1.csv and 2.csv in the same folder
$ cat 1.csv
temperature, depth
10.0, 5.0

$ cat 2.csv
depth, temperature
1234, 4.1

Read the files by Spark:
val data = spark.read.option("header", "true").csv("folder/*.csv")
data.select("temperature").show

I as an user would expect either:
+-----------+
|temperature|
+-----------+
|       10.0|
|        4.1|
+-----------+

or an error but not this output:
+-----------+
|temperature|
+-----------+
|       10.0|
|       1234|
+-----------+

Yea, I got the point. So, the case is when some files have different header.  I was thinking of a case when all files have the same header but the user provided a wrong order of schema (comparing to those all headers).

Test build #88571 has started for PR 20894 at commit d6d370d.

I just checked the JIRA https://issues.apache.org/jira/browse/SPARK-23786, I think CSV should follow the other format (e.g., parquet), right?

@gatorsmile For example, Spark is case sensitive for jsons:
cat ./case_sesitive.json
{"FIELD1": 1}

If schema is specified with field name "field1":
val schema=new StructType().add("field1", IntegerType)
spark.read.schema(schema).json("case_sesitive.json").show

it cannot match field:
+------+
|field1|
+------+
|  null|
+------+

but if schema's field and actual json field in the same case:
val schema=new StructType().add("FIELD1", IntegerType)
spark.read.schema(schema).json("case_sesitive.json").show

+------+
|FIELD1|
+------+
|     1|
+------+

Test build #88571 has finished for PR 20894 at commit d6d370d.

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/88571/
Test PASSed.

Test build #88791 has started for PR 20894 at commit 0904daf.

Test build #88791 has finished for PR 20894 at commit 0904daf.

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

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

Merged build finished. Test FAILed.

Test build #88792 has finished for PR 20894 at commit 191b415.

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/88792/
Test PASSed.

Regarding https://github.com/apache/spark/pull/20894#issuecomment-375992103 , does our name resolution in Parquet respect our SQLConf spark.sql.caseSensitive?  If the column orders are different, should we do the auto column order adjustment?

Test build #89337 has started for PR 20894 at commit 714c66d.

@gatorsmile Parquet (and json) datasource doesn't respect spark.sql.caseSensitive. Should it do?

If the column orders are different, should we do the auto column order adjustment?

StructType is aware of field ordering by definition: https://github.com/apache/spark/blob/b304e07e0671faf96530f9d8f49c55a83b07fa15/sql/catalyst/src/main/scala/org/apache/spark/sql/types/StructType.scala#L99
The auto column order adjustment should be under an option or CSV rows should be mapped to something different from StructType which is agnostic to field ordering, IMHO.

Actually the spark.sql.caseSensitive flag is checked during schema inferring : https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/csv/CSVDataSource.scala#L162
I think we have to respect it when we check header against inferred schema

Test build #89337 has finished for PR 20894 at commit 714c66d.

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/89337/
Test PASSed.

Test build #89360 has started for PR 20894 at commit b43a7c7.

Test build #89360 has finished for PR 20894 at commit b43a7c7.

This patch fails from timeout after a configured wait of `300m`.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

jenkins, retest this, please

Test build #89365 has started for PR 20894 at commit b43a7c7.

jenkins, retest this, please

Test build #89496 has started for PR 20894 at commit a5f2916.

Test build #89496 has finished for PR 20894 at commit a5f2916.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #89497 has started for PR 20894 at commit 9b2d403.

Test build #89497 has finished for PR 20894 at commit 9b2d403.

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

Merged build finished. Test FAILed.

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

jenkins, retest this, please

Test build #89501 has started for PR 20894 at commit 9b2d403.

Test build #89501 has finished for PR 20894 at commit 9b2d403.

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

@gatorsmile @HyukjinKwon Could you look at the PR again, please.

Test build #89940 has started for PR 20894 at commit 1fffc16.

Test build #89940 has finished for PR 20894 at commit 1fffc16.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class Reverse(child: Expression) extends UnaryExpression with ImplicitCastInputTypes
case class ArrayJoin(
case class ArrayPosition(left: Expression, right: Expression)
case class ElementAt(left: Expression, right: Expression) extends GetMapValueUtil
case class Concat(children: Seq[Expression]) extends Expression
case class Flatten(child: Expression) extends UnaryExpression
abstract class GetMapValueUtil extends BinaryExpression with ImplicitCastInputTypes
case class GetMapValue(child: Expression, key: Expression)
case class MonthsBetween(
trait QueryPlanConstraints extends ConstraintHelper
trait ConstraintHelper
case class CachedRDDBuilder(
case class InMemoryRelation(
case class WriteToContinuousDataSource(
case class WriteToContinuousDataSourceExec(writer: StreamWriter, query: SparkPlan)

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

Merged build finished. Test PASSed.

cc @gengliangwang Could you review this CSV PR?

Test build #90011 has started for PR 20894 at commit ad6cda4.

Test build #90011 has finished for PR 20894 at commit ad6cda4.

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

Merged build finished. Test FAILed.

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

Some questions here:

The case exists in all data source format, right?
If user didn't provide schema, should we check the header among CSV files?
Users should be responsible for the specifying data schema.  The proposed behavior can only help users to avoid manually checking the CSV headers.

jenkins, retest this, please

Test build #90049 has started for PR 20894 at commit ad6cda4.

Test build #90049 has finished for PR 20894 at commit ad6cda4.

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

Merged build finished. Test FAILed.

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

jenkins, retest this, please

Test build #90215 has started for PR 20894 at commit ad6cda4.

Test build #90215 has finished for PR 20894 at commit ad6cda4.

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/90215/
Test PASSed.

@HyukjinKwon @gengliangwang @gatorsmile Please, have a look at it again.

I understood the rationale, problem and the approach and I don't feel strongly - I am less sure since 1. this option is specific to CSV about columns. It sounds adding complexity. 2. however, I doubt if the severity of the issue is worth enough adding an option and that amount of change.
I believe I usually have been staying against in most of such cases in particular in JIRA level (probably worth enough checking Won't fix JIRAs).
For clarification, please proceed if you guys feel it's needed and don't block on me.

For example, there are so many options that can be potentially added (other univocity parser options).

You are right, so many things can be added but in this particular case we are trying to solve a problem related to correctness. This is the issue to which our customers faced in real life, and lost a few days to restore their data only because Spark produces wrong result silently.
Any solution which checks CSV header against schema will require an option or global parameter to disable it for keeping backward compatibility. @HyukjinKwon What kind of solution would be appropriate  for this problem from your point of view?

I don't have a particularly better solution for now. Documentation might be one option in such case given past discussions and suggestions from other committers and reviewers.

Test build #90581 has started for PR 20894 at commit 2bd2713.

Test build #90581 has finished for PR 20894 at commit 2bd2713.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #90589 has started for PR 20894 at commit 21f8b10.

@HyukjinKwon we are one of the Spark users experiencing this problem in the real world: dealing with dirty data produced by a variety of third party systems. Documentation doesn't solve anything here: it simply punts a complicated series of traversals and manual header checks. We've had to implement them to address the issue in the absence of this capability.
I agree that there are (too) many reader (and writer) options in Spark. That's fundamentally a side effect of architecture choices: Spark offers no user-accessible lifecycle hooks for custom loading/validation (or saving, for that matter). This is a fundamental limitation, something I've discussed with @rxin and @marmbrus in the past. (For example, at Swoop, we've had to completely re-implement DataFrameWriter as OpenDataFrameWriter to expose options & the data being written so that the API can be extended via implicits.) Let's not blame this PR based a Spark architecture choice. In the absence of the abovementioned hooks, the only way to meaningfully extend Spark's loading behavior is by jamming more code into data sources and adding more options to control it. Given that (1) this is the Spark 2.x approach to data sources, (2) the issue this PR addresses can lead to silent correctness problems and (3) users have no easy way, within Spark, to identify and correct the issue, I believe this PR serves a very useful purpose in the Spark ecosystem.
By analogy, consider SQL's UNION, which can cause problems because columns are combined not by name but by position, hence, (x: Int, y: Int) can be happily UNIONed with (y: Int, x: Int) to create, very likely, gobbledygook. The difference in this case is that (a) the SQL UNION behavior is standardized, (b) it has been well-documented for decades and (c) the operands' schema can be easily inspected via Spark. This is a great situation where users who end up in trouble can be told to RTFM. By contrast, the Spark CSV data source behavior is (a) arbitrary, (b) undocumented and (c) Spark provides no useful tools for users to check whether they'll get in trouble.
Great job, @MaxGekk!

Documentation does solve the problem in a way because we are going to claim what Spark supports and does. How about adding a script or something to find out by reading ahead or another way?
I don't see too much value on it. If you guys think it's worth, please go ahead. I think I said don't block on me. I am okay.

Test build #90589 has finished for PR 20894 at commit 21f8b10.

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

Merged build finished. Test FAILed.

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

jenkins, retest this, please

retest this please

Test build #90598 has started for PR 20894 at commit 21f8b10.

Test build #90598 has finished for PR 20894 at commit 21f8b10.

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/90598/
Test PASSed.

@gengliangwang @gatorsmile May I ask you to look at this PR one more time.

ping @gengliangwang

Can we check if there's any committer positive on this change before going ahead?

Test build #90682 has started for PR 20894 at commit e3b4275.

In this PR, when documenting the option enforceSchema, we need to emphasize the schemas are checked by positions instead of by names.
@ssimeonov UNION is a good example. Many Spark users feel confused about it. In the last release (SPARK 2.3), we added a new Dataset API unionByName.
I think that is why we should also consider this in the follow-up PR. When we fetch the data from the external data sources, we respect the embedded/built-in schema and do the column reordering when building the plan.
In addition, this sounds a pretty general issue for reading/writing from/to the external data sources. We can consider this option in the other built-in data sources and also in the design of data source API v2.

Right, will proceed reviewing this.

I understand the default value of enforceSchema must be true to keep backward compatibility, but shall we suggest users to set it to false to avoid incorrect result in the document?

Test build #90738 has finished for PR 20894 at commit 04199e0.

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/90738/
Test PASSed.

Test build #90756 has started for PR 20894 at commit 795a878.

Test build #90756 has finished for PR 20894 at commit 795a878.

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/90756/
Test PASSed.

Test build #90808 has started for PR 20894 at commit 9606711.

Test build #90809 has started for PR 20894 at commit 11c7591.

Test build #90808 has finished for PR 20894 at commit 9606711.

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

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

Merged build finished. Test FAILed.

Test build #90809 has finished for PR 20894 at commit 11c7591.

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/90809/
Test PASSed.

@gatorsmile @cloud-fan @HyukjinKwon @gengliangwang May I ask you to look at the PR again.

Test build #90993 has started for PR 20894 at commit 7dce1e7.

Test build #90993 has finished for PR 20894 at commit 7dce1e7.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class TaskKilled(
case class KafkaContinuousInputPartition(
trait HasValidationIndicatorCol extends Params
trait DivModLike extends BinaryArithmetic
case class Divide(left: Expression, right: Expression) extends DivModLike
case class Remainder(left: Expression, right: Expression) extends DivModLike
case class ExprCode(var code: Block, var isNull: ExprValue, var value: ExprValue)
trait Block extends JavaCode
 implicit class BlockHelper(val sc: StringContext) extends AnyVal
case class CodeBlock(codeParts: Seq[String], blockInputs: Seq[JavaCode]) extends Block
case class Blocks(blocks: Seq[Block]) extends Block
case class MapEntries(child: Expression) extends UnaryExpression with ExpectsInputTypes
class ReadOnlySQLConf(context: TaskContext) extends SQLConf
class TaskContextConfigProvider(context: TaskContext) extends ConfigProvider
case class RateStreamContinuousInputPartition(
case class ContinuousShuffleReadPartition(index: Int, queueSize: Int) extends Partition
class ContinuousShuffleReadRDD(
trait ContinuousShuffleReader
class MemoryStreamInputPartition(records: Array[UnsafeRow])
class ContinuousMemoryStreamInputPartition(
class RateStreamMicroBatchInputPartition(

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/90993/
Test PASSed.

Test build #91155 has started for PR 20894 at commit 26ae4f9.

Test build #91155 has finished for PR 20894 at commit 26ae4f9.

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/91155/
Test PASSed.

@gatorsmile @cloud-fan @HyukjinKwon @gengliangwang Could you look at the PR one more time.

Test build #91399 has started for PR 20894 at commit 3b37712.

Test build #91399 has finished for PR 20894 at commit 3b37712.

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/91399/
Test PASSed.

LGTM
Thanks! Merged to master


WIP: Linux bridge vlan filter

Passing on build against networkmanager-1.18, somehow failing against master.
https://travis-ci.org/nmstate/nmstate/jobs/560003493

Coverage remained the same at ?% when pulling 30ec53fa803664f8cbc8c3d255ed27ef6ffb3559 on maiqueb:linux_bridge_vlan_filter into 5e802d137bc5b1a6124e2750039dbaf4aab915ce on nmstate:master.

Closing the PR, since the accepted API changed drastically from what's being developed here.
Easier to just open a new one in the future.


Alternate reduce allocations

An alternative to #936, this takes the low hanging fruit but leaves the more controversial diff change in behaviour behind.

How does this reduce the number of objects allocated?
The reasoning in #936 was hard to follow...

How does this reduce the number of objects allocated?
The reasoning in #936 was hard to follow...

The lamba keyword creates a new instance each time, where as assigning it to a constant does not.

LGTM

Thanks @JonRowe, :ship: it


WIP: QMAPS-772 Add category filter at autocomplete

The point is to display a "category" item in autocomplete list when the searched terms are matching a simple regex while waiting a more complex NLP system.

We cancel that MR, this will be resolved in #188


Discuss sphinx extensions suggested in PR #801

PR #801 suggests a couple of sphinx extensions to be added and we should discuss if they are needed. As always, we should not add packages or functionality because it is 'good to have', but with a concrete application.
Those packages are also suggested in the CTAO python template library (see this conf.py).
autosummary
autosummary : generates summary list for long docstrings
automodapi
automodapi
(in the conf.y, these are two modules: sphinx_automodapi.automodapi and sphinx_automodapi.smart_resolver)
Replacement of sphinx.autodoc with some additional functionality.

I should add the note that we do not make use of any functionality of the packages above. Maybe we should not include them for now and only add them when needed?

I should add the note that we do not make use of any functionality of the packages above. Maybe we should not include them for now and only add them when needed?

But they helped us by pointing us to the fact that we were using backslash (`) the wrong way in the documentation, no?
I think we should add them and be in the as same page to the remaining dpps packages as possible. With the code growing (errors growing) it will be more and more difficult to deal with these differences in the future.

I now don't see the warnings when building the docs in main (not even if we add these packages). I am not sure what changed, but I think we do not need those packages anymore.

Closing because we decided not to add these packages as they are not necessary: https://github.com/gammasim/simtools/pull/801


Client login should wait for LoginSuccess

I'm curious as to the reason that it currently waits for PlayerAbilities.  From looking at wiki.vv and my testing with a vanilla server, LoginSuccess seems to be the best early packet to listen for.  Otherwise, some essential packets (such as PlayerAbilities) are unavailable to clients.
I have a commit in my fork if you want an easy fix: NJAldwin/ozelot@479c29c3adfd95683daf75058b95368db85d639d

I don't remember why that is.
Looking at the docs it might be because PlayerAbilities comes at the end of a bunch of packets sent to the client, and I was not interested in those.
If returning control on receival of LoginSuccess works then let's do that.

I went ahead and added your linked commit.
b4993b00cfd598a12d7c48020b28abc8912f7072


Moar flags

Adding three new flags:
-d to "dry" whatever is being set: removes waterlogged states and turns water into air
-s to "soft place" stuff: if the existing and new blocks match, the properties from one are translated into the ones of the other
-g to remove greenery: when relacing air or water, a set number of other blocks are removed too: grass, fern and the tall variants for air, and seagrass and kelp for water. Other stuff (like flowers and coral fans) could be added. Maybe let the suer add them with a config (file) or setting (in-game)?
Also fixed -w because it used to have a bunch of problems. It now converts air into water, properly detects waterlogged blocks and doesn't throw property errors when trying to waterlog stone.
-d is applied before -w, so they can be combined to do stuff like change the water level of a build or whatever you need.
This fixes #21 and fixes #23 .

Well, I went agead an fixed som bugs and it turned out I was doing it in this branch, sorry! copy had a bug where the selection would get inverted and do strage things (never reported), that's fixed. I also fixed one of the bugs in #28, where most brushes and shapes wouldn't behave properly with undo. I was caused by undo expecting positions and not blocks from which to extract positions.

Well, I went agead an fixed som bugs and it turned out I was doing it in this branch, sorry! copy had a bug where the selection would get inverted and do strage things (never reported), that's fixed. I also fixed one of the bugs in #28, where most brushes and shapes wouldn't behave properly with undo. I was caused by undo expecting positions and not blocks from which to extract positions.

And this seems to somehow break the flags suggester? I'll look into that, doesn't occur in master.

And this seems to somehow break the flags suggester? I'll look into that, doesn't occur in master.


Emit decorator list

Fix https://github.com/microsoft/typespec/issues/4031
When we specify the allowed-emit-decorators in emitter, TCGC will help to emit out decoration information for each item (client, property, operation), e.g final-state-var, our .NET input-Model need to contain this information.
This PR will

emit decorators to all kind of models, operations and operations
add reference resolve strategy in TypeSpecInputDecoratorInfoConverter to support parse by reference

API change check
APIView has identified API level changes in this PR and created following API reviews.
@typespec/http-client-csharp

autorest.csharp regen preview PR: https://github.com/Azure/autorest.csharp/pull/4940

Previously I thought it's quite natural to pass decorators to generator. But after seeing the codes, I hesitate, mainly because:

In some cases, we have to process the decorators before passing input json to generator. Do we still need to pass the original data?
Swagger input will be converted to input model first. If a metadata happens to exist in both typespec decorator and swagger x-ms-xxx directive, we definitely don't want to covert swagger directive into typespec decorator. We should go approach 1 above.
It looks quite painful to parse the DecoratorInfo in csharp.

@m-nash @ArcturusZhang your thoughts?

3. It looks quite painful to parse the DecoratorInfo in csharp.

For #1, we only need to pass some special set(which is small) of decorators which may not common, or be special decorators defined in customized emitter. Common decorators we will parse the information to our input model and will not pass to generator
#2, I think the swagger derective (all its corresponds typespec decorator) does not belong to the decorators to emit.
#3  We only need to parse known decorator's information (we know the definition/structure) of the decorator. Not generic parse for all decorators.

Previously I thought it's quite natural to pass decorators to generator. But after seeing the codes, I hesitate, mainly because:

In some cases, we have to process the decorators before passing input json to generator. Do we still need to pass the original data?
Swagger input will be converted to input model first. If a metadata happens to exist in both typespec decorator and swagger x-ms-xxx directive, we definitely don't want to covert swagger directive into typespec decorator. We should go approach 1 above.
It looks quite painful to parse the DecoratorInfo in csharp.

@m-nash @ArcturusZhang your thoughts?

So we could categorize the decorators into two types:
The first type of decorators really changes something on the typespec, such as this. These kind of decorators have done their work in tsp compilation because they changes the type graph, and TCGC does not even feel the existence of them
The second type of the decorators are "flags". They do nothing on the typespec itself, such as the @useSystemTextJsonConverter decorator. For this kind of decorators, it makes sense that we pass through their data to the generator.
I think this should resolve your first concern.
For 2, some extensions will change the spec, for instance some x-ms-format extension changes the type, for this kind of extensions, our code model converter should do their work correctly by convert it to its actual types, and it should never be a decorator in the decorator list. Some other extensions are just flags, these needs to be put into the decorator list.
For 3, you might need to specify. It is always painful when we want to convert an unknown type into C#, it is inevitable.

Previously I thought it's quite natural to pass decorators to generator. But after seeing the codes, I hesitate, mainly because:

In some cases, we have to process the decorators before passing input json to generator. Do we still need to pass the original data?
Swagger input will be converted to input model first. If a metadata happens to exist in both typespec decorator and swagger x-ms-xxx directive, we definitely don't want to covert swagger directive into typespec decorator. We should go approach 1 above.
It looks quite painful to parse the DecoratorInfo in csharp.

@m-nash @ArcturusZhang your thoughts?

So we could categorize the decorators into two types: The first type of decorators really changes something on the typespec, such as this. These kind of decorators have done their work in tsp compilation because they changes the type graph, and TCGC does not even feel the existence of them The second type of the decorators are "flags". They do nothing on the typespec itself, such as the @useSystemTextJsonConverter decorator. For this kind of decorators, it makes sense that we pass through their data to the generator.
I think this should resolve your first concern.
For 2, some extensions will change the spec, for instance some x-ms-format extension changes the type, for this kind of extensions, our code model converter should do their work correctly by convert it to its actual types, and it should never be a decorator in the decorator list. Some other extensions are just flags, these needs to be put into the decorator list.
For 3, you might need to specify. It is always painful when we want to convert an unknown type into C#, it is inevitable.

@ArcturusZhang thanks. For 3, I just found that we could have a TypeSpecInputDecoratorConverter, so in the future we can have concrete type for the decorators we do care in generator. Problem solved.


fix(deps): update gomod

This PR contains the following updates:

Package
Type
Update
Change

github.com/IBM/go-sdk-core/v5
require
patch
v5.13.1 -> v5.13.2

github.com/IBM/platform-services-go-sdk
require
patch
v0.37.3 -> v0.37.4

github.com/gruntwork-io/terratest
require
patch
v0.41.23 -> v0.41.24

Release Notes

IBM/go-sdk-core
v5.13.2
Compare Source
Bug Fixes

deps: bump dependencies to recent versions (#184) (a33f767)

IBM/platform-services-go-sdk
v0.37.4
Compare Source
Bug Fixes

deps: bump various dependencies (#256) (450de25)

gruntwork-io/terratest
v0.41.24
Compare Source

Modules affected

k8s

Description

Added functions for Kubernetes PersistentVolumes

Special thanks

Special thanks to the following users for their contribution!

@kaisoz

Related links

https://github.com/gruntwork-io/terratest/pull/1284

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

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


Basic Flutter package support for Desktop

The dart package supports them all:

sentry_flutter doesn't:

Probably a matter of adding the platforms here: https://github.com/getsentry/sentry-dart/blob/7ca0d10ca4985dbf928958e715bc695bfe1d3045/flutter/pubspec.yaml#L33-L41
To at least explicitly support it. Device context etc can come later.

Ideally this should be done together with #288 to get basic breadcrumb support out of the box.

These plus plugins maintained by flutter community can help to add device or package context info by replacing currently used package_info plugin.

Important: As of January 2021, the Flutter team is no longer accepting non-critical PRs for the original set of plugins in flutter/plugins, and instead they should be submitted in this project. You can read more about this announcement here. as well as in the Flutter 2 announcement blog post.

Links for reference:
https://github.com/flutter/plugins/blob/master/CONTRIBUTING.md#important-note
https://medium.com/flutter/whats-new-in-flutter-2-0-fe8e95ecc65

These plus plugins maintained by flutter community can help to add device or package context info by replacing currently used package_info plugin.

Important: As of January 2021, the Flutter team is no longer accepting non-critical PRs for the original set of plugins in flutter/plugins, and instead they should be submitted in this project. You can read more about this announcement here. as well as in the Flutter 2 announcement blog post.

Yes plus plugins is the way to go.
Particularly on the next major bump, we should make the switch.


failed in cargo build

cargo build

error[E0308]: mismatched types
    --> src/types.rs:1538:45
     |
1538 |         let c_str = unsafe { CStr::from_ptr(&strs[off as usize] as *const u8 as *const i8) };
     |                              -------------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
     |                              |
     |                              arguments to this function are incorrect
     |
     = note: expected raw pointer `*const u8`
                found raw pointer `*const i8`
note: associated function defined here

Hi, How to solve this problem?

Please see if https://github.com/anakryiko/btfdump/pull/4 fixes the issue. Thanks for reporting!


[RUNTIME][VULKAN] Seg fault in WorkspacePool's destructor (#5632)

fixed this issue by changing WorkspacePool's destruction order

https://github.com/apache/incubator-tvm/issues/5632

@tqchen, please review, thank you!


Children are reordered when their keys are numbers.

import Component, {Config} from 'metal-jsx';
import Transition from 'metal-css-transitions';

const styles = {
	padding: '20px'
};

class Test extends Component {
	created() {
		this.addToArray_ = this.addToArray_.bind(this);
	}

	addToArray_() {
		this.state.array_ = this.state.array_.concat([1, 4, 5, 6]);
	}

	render() {
		return (

{'Click to add to Array.'}

					<Transition name="transition-fade-out-slide-up">
						{
							this.state.array_.map(
								i =>
{i}

							)
						}
					</Transition>

		);
	}
}

Test.STATE = {
	array_: Config.value([2, 3, 7, 8])
};

export default Test;

When you click to add to the array, you would expect that the children would be rendered in the same order as the array. Instead, the children are reordered numerically.
This appears to be caused by converting to the children to a keyed object.

Should be fixed by https://github.com/bryceosterhaus/metal-css-transitions/commit/ba8b60ebaaf64a096eca3adb262a69d2d03277e2


topologySpreadConstraints are discarded when minReplicaCount is zero for rabbitmq scaler (and possibly the other scalers too)

When minReplicaCount is zero for a ScaledObject, the topologySpreadConstraints of the scaled pods are discarded.
Expected Behavior
The topologySpreadConstraints should be preserved when the target deployment is scaled above zero.
Actual Behavior
The topologySpreadConstraints does not appear in the pods when they are scaled, leading to improper spreading across the topology key defined by the topologySpreadConstraints.
When minReplicaCount is greater than zero, topologySpreadConstraints is properly preserved.
Steps to Reproduce the Problem

Create a ScaledObject with minReplicaCount=0 for scaling a deployment containing topologySpreadConstraints in the PodSpec.
Trigger scale up of the deployment.
Fetch the deployment spec from kubernetes and observe the missing topologySpreadConstraints.

Specifications

KEDA Version: Using the helm chart version 1.4.2
Platform & Version: AKS, v1.18.2
Kubernetes Version:

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-21T14:51:23Z", GoVersion:"go1.14.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T23:18:00Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}

Scaler(s): RabbitMQ Queue latest version

@zroubalik, I'm sorry to directly tag you like that, but any idea what would cause this? I tried looking into the code, but I'm not knowledgeable enough in Go and on how an operator such as KEDA interacts with the manifests and the Kubernetes API.
Is this even caused by KEDA or is this an issue with the HPA/Kubernetes?
This issue is preventing a deployment scaled up from zero to properly be spread across topology domains. Instead, the replicas are almost all scheduled on the same node which can be inefficient in term of resources utilization and is preventing high availability topology.

@zroubalik I was able to replicate the behavior above in the current version of KEDA. I believe this is due to the fact that the topologySpreadConstraints was introduced in k8s version 1.16 and the client go library being used did not yet account for that portion of the spec. I tried out the same deployment using KEDA v2 which has a newer client go library and the pods contained the additional topologySpreadConstraints so v2 will fix this issue,

@tbickford thanks a lot for the confirmation! For v2 we have changed the scaling 1 <-> 0 as well a little bit (using the /scale subresource instead of changing the spec and replicas), so I am glad this is solved.
@mboutet sorry for the delay, I was super busy a last few days, this issue won't likely be solved in the v1, but upcoming v2 should do the job. I hope that's ok for you.

Perfect! Looking forward for the v2 of KEDA 😃 Thank you. Should we wait until the v2 is released to close the issue?

Let's close this one, once it is verified on some release of v2 (beta, etc), there should be a release pretty soon.

It seems similar issue with my case. I have deployment, it has:
topologySpreadConstraints:
- maxSkew: 1
  topologyKey: agentpool
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app.kubernetes.io/name: service-12345

And I have an ScaledObject of KEDA Prometheus. KEDA version 1.5. The weird thing is the topologySpreadConstraints section in the deployment is missing/disappeared in the deployment or pod when I check them on dashboards. It leads to wrong topology of scaling, that is pods are assigned to wrong nodes.
Does v2.0 solve this issue?

Yes, I tested with v2 and it seems to work.

@mboutet thanks for the confirmation. Closing this then.


[5957] let users view and download historic funding information

Context
Users should be able to view and download historic funding - at least for the year prior to the current year.
Suggested changes:

Funding pages rendered on /funding/YYYY/page-name
Funding link in nav defaults to linking to the current year
The breadcrumb on each funding page links to a funding years index
The year index lists years where we have funding information available (expected to be at least 3)

Clicking on the link takes the user to the relevant year's funding pages.
Changes proposed in this pull request

adds funding index page /funding
redirects to latest funding year when clicking on the nav bar funding link
splits the two funding types on the index page Trainee Summary, Payment Schedule

Guidance to review
Ideally should be tested in production data

 Let users view and download historic funding information

As I commented on the ticket yesterday. I like Ed’s implementation with the “Payment schedules” and “Trainee summary” data for each year on the two tabs.
From your comments earlier @d-a-v-e , I now understand that for some years we don't have both sets of data so that's why the new design has a list of years for each data type which in some instances points to the same view.
An alternative solution could be to have a singular list of years that direct to the same view with the two tabs but have some explanatory content on any tabs for which data is not available. I'll approve this review and we can bear this in mind for a future improvement.


Try/except fetch cifar dataset

In order to avoid Travis issues when cifar provider is not reachable, we could try/except to get the dataset and use a local copy when KO.
See discussion here

Have the same issue in some #205 deploy

I think that is a good idea.

Same for titanic dataset!

@arthurPignet I add this one to you, same theme you've been working on to improve the dataset loading part.

After digging a bit into keras, it already stores cifar10 locally, so keras downloads the dataset only if it did not find cifar in the cache. For me there is two solutions, catch the error raised by the URLerror and HTTPerror, and maybe retry 3 or 5 times or put the dataset into the repo (which is quite heavy)


Setup Contentful

Set this up so all page content and images can be edited

@kpierduta Is contentful all set?


capture_body makes requests hangs / validation error

Describe the bug:
When using CAPTURE_BODY:

"all" - you get "validation error: error: context: request: 'body': validation rule 'types(string;map[string]interface)' violated "
"errors" - sending httpx request to unreachable address, the client gets stuck and no repsonse is returned to the client

To Reproduce

Create FastAPI.
do any request using  httpx.AsyncClient to unknown request (ex: localhost: 5050)
if your CAPTURE_BODY is set to all, you will get validation error
if your CAPTURE_BODY is set to errors, the requests will hang forever

Environment (please complete the following information)

OS: [e.g. Linux]: Docker python:3.8.2-slim-buster
Python version: 3.8.2
Framework and version [e.g. Django 2.1]: FastAPI 63.0
APM Server version: 7.10.2
Agent version: 5.10.1

Additional context
Add any other context about the problem here.

Agent config options

Click to expand
apm_config = {
    "SERVICE_NAME": "map",
    "ENABLED": True,
    "SERVER_URL": "http://**********:8200",
    "CAPTURE_HEADERS": True,
    "CAPTURE_BODY": "all",
}

requirements.txt:

Click to expand
aiofiles
aredis
async-timeout
asyncpg
authlib
certifi
cffi
chardet
click
cryptography
debugpy
python-dateutil
ecdsa<0.15
elastic-apm
fastapi
gunicorn
h11
h2
hiredis
hpack
hstspreload
httpcore
httptools
httpx
hyperframe
idna
loguru
orjson
pyasn1
pycparser
pydantic
python-jose
python-multipart
rfc3986
rsa
six
sniffio
starlette==0.13.6
ujson
uvicorn
uvloop
websockets
# yappi

After debugging a little, it's related to the body payload, it seems flat body like: [10,20] will make it not work

After debugging a little, it's related to the body payload, it seems flat body like: [10,20] will make it not work

@Syniex To clarify, using a flat body like that will make the request hang? Does it hang even without the agent present? If the agent makes the application hang for any reason, we consider that a bug.

without the agent the application doesn't hangs.

I will provide code tomorrow, and dig deeper to it.

Thank you. This sounds like something we would like to fix.

`python
from typing import List
import httpx
import uvicorn
from elasticapm.contrib.starlette import ElasticAPM, make_apm_client
from fastapi import FastAPI
from pydantic import BaseModel
class Point(BaseModel):
coordinates: List[float]
app = FastAPI()
apm_config = {
"SERVICE_NAME": "testing",
"ENABLED": True,
"SERVER_URL": "http://localhost:8200",
"CAPTURE_HEADERS": True,
"CAPTURE_BODY": "error",
# "CAPTURE_BODY": "all",
}
apm = make_apm_client(apm_config)
app.add_middleware(ElasticAPM, client=apm)
class RandomError(BaseException):
pass
@app.post("/working")
async def working_fine():
#Example of working endpoint when no body is provided
async with httpx.AsyncClient() as client:
response = await client.get("http://notexisthost/")
return response.json()
@app.post("/not/working/1")
async def not_working(point: Point):
# This won't work when using "CAPTURE_BODY": "errors" and will hang the request forever
async with httpx.AsyncClient() as client:
response = await client.get("http://notexisthost/")
return response.json()
@app.post("/not/working/2")
async def not_working_2(coordinates: List[float]):
# "CAPTURE_BODY": "all" will make elasticsearch says "body": validation error
async with httpx.AsyncClient() as client:
response = await client.get("http://notexisthost/")
return response.json()
if name == "main":
uvicorn.run(app, host="<IP_ADDRESS>")
`

@basepi I checked the commit and the application doesn't hangs anymore.
but the Validation error is still there.
from typing import List

import uvicorn
from elasticapm.contrib.starlette import ElasticAPM, make_apm_client
from fastapi import FastAPI

app = FastAPI()
apm_config = {
    "SERVICE_NAME": "testing",
    "ENABLED": True,
    "SERVER_URL": "http://localhost:8200",
    "CAPTURE_HEADERS": True,
    "CAPTURE_BODY": "all",
}
apm = make_apm_client(apm_config)
app.add_middleware(ElasticAPM, client=apm)

@app.post("/validation/error")
async def working_fine(coordinates: List[float]):
    # Example of working endpoint when no body is provided
    return "Done"

if __name__ == "__main__":
    uvicorn.run(app, host="<IP_ADDRESS>", debug=False)

Oh, right, sorry, I got so hung up on the hang (which was definitely the biggest problem) that I forgot to look at the validation issues. Thanks for attaching an example error, that will be helpful.


[142] the test hook fails to save test-reports (4-2-stable)

why does removing the copytree command satisfy saving the test-reports?

test-reports folder never gets created and we already have test_output.log and we don't need it.

okay, please #


Trunk

Coverage decreased (-0.7%) to 25.336% when pulling 6f00dd16a6cac49bd90bf6d690e1e7c2bfe07a15 on trunk into 50187c41338a561ad397c21a8212cf4a69120f10 on master.


⚠ Cioos Pacific CKAN Sitemap has degraded performance

In 4ed2dc2, Cioos Pacific CKAN Sitemap (https://catalogue.cioospacific.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 14186 ms

Resolved: Cioos Pacific CKAN Sitemap performance has improved in 52f6925 after 10 minutes.


Install FFmpeg from source to support decoding with cuda

What is the current behavior?
we install ffmpeg from dnf, which does not include cuda support

What is the new behavior?
install ffmpeg from source which supports cuda from linux/amd64

Have tests been run against this PR?

Have appropriate comments and documentation been made on this PR?

Related changes in other repos (link commit/PR here)

Other information:

closed


Profile Human Phenotype

Requester information

Name-
Eric Torstenson

Affiliations-
VUMC/Anvil

Request Details

Purpose-
Profiling these will permit us to clarify the purpose and the code system's that one can expect to be used. It also will clarify our usage of values and interpretation to indicate presence/absence of the specified phenotype.

Who it benefits-
Any group that captures information regarding the presence or absence of HPOs or other phenotypic traits.

Use case-
A patient may have one or more phenotypes that have been observed to be either present or absent. These can be annotated currently using Observations, but using a HumanPhenotype profile, there will be an added level of clarity as to what those entries represent.

Fields:

Code stores the phenotype code
Value stores assertions about finding present or absent
Interpretation also indicates the positive and negative

We should investigate value sets and bindings for the Value and Interpretation fields.


'Commit changes' has no reaction when clicked

I have completed the 'Setup with existing project' step, but when I import the interface file(such as: https://github.com/postmanlabs/newman/blob/2a57036bc96c6e06289238cb4ef3fe70c1f9f338/test/integration/whatwg-url.postman_collection.json), I execute 'Commit changes' and nothing happens.

There might be a Problem with exporting your project. Do you see any Errors in the Console when clicking "Commit changes"?

Could you provide me with logs from Insomnia's Browser-Console / Dev-Tools? You can open them using Ctrl + Alt + I.

I have followed your instructions and opened the console, and there is an error message.

Sorry for the wait, I had some work / personal stuff to do, but I found the problem and hopefully fixed your issue.
There seems to be a Problem with the Metadata for a folder not existing. This also happens with Metadata for other Items like Requests. I'm not entirely sure why this happens, Insomnia sometimes just doesn't create the Metadata.
The folder metadata only contains the information whether the folder is collapsed, so as a workaround, the plugin will now create the metadata if it couldn't be found. Be sure to install version 0.5.4 of the plugin.

That's great, thanks for fixing it.


after reloadDataEvent() the previous page is displayed

for example after change to night mode or changing font size reader jumped on previous page
can anyone help ?

@hrishikesh-kadam


Add test case for duplicate assets (#107)

The problem happens when referencing the same image multiple times, with
a different query string. (For example when using image transforms --
https://docs.netlify.com/large-media/transform-images/.)
The build plugin strips the query string, so several different URLs
become duplicates.

@Munter I don't think I can push to https://github.com/Munter/netlify-plugin-hashfiles/pull/128, but here's a new PR with a test case.


OPTIMADE v1.2 release planning

Following from @merkys's comment on the mailing list, we should begin preparations for a v1.2 release.
I think I also foolishly "volunteered" to manage this release a while ago, but please help out if you want to. As part of this process, I've been doing a bit of issue triaging -- please re-open any issues that I closed that you think are still valid. In particular, I've also been clearing up the v1.2 milestone https://github.com/Materials-Consortia/OPTIMADE/milestone/3 which should now reflect what I write below.
We can use the comments here to have some async discussion that can perhaps be finalized at the final meeting this year.
Summary
As far as I see it, we need to decide:

Whether to release v1.2 before the paper
Whether to release and wait for providers to implement v1.2 before the paper
Whether to write or merge any more PRs before releasing v1.2

My suggestion would be to finalize any PRs/issues we know we want in before the next meeting, then make a release candidate before Christmas. We can write the paper based on that release candidate and hopefully servers will start picking up the changes too (we can certainly get most of it into optimade-python-tools in January). We can submit the paper whenever with references to the release candidate, ready to be updated with the real release version in time for its (hopeful) publication.
Proposed changelog (updated 22/06)
I've just made a draft v1.2.0 release on GitHub (that everyone in the organization should be able to see) --- we could also convert this into a proper release candidate sooner rather than later v1.2.0-rc1, if desired. This draft has the following abridged (removed typo/testing PRs) changelog:

Allow provider-specific nested properties within OPTIMADE properties. by @JPBergsma in https://github.com/Materials-Consortia/OPTIMADE/pull/401
Space group additions: space_group_hall and space_group_it_number by @merkys in https://github.com/Materials-Consortia/OPTIMADE/pull/405
Allow boolean values in queries by @merkys in https://github.com/Materials-Consortia/OPTIMADE/pull/348
Files endpoint by @merkys in https://github.com/Materials-Consortia/OPTIMADE/pull/360
Property definitions by @rartino in https://github.com/Materials-Consortia/OPTIMADE/pull/376 (plus several associated tweaks and fixes)
Support fuzzy comparison lists by @merkys in https://github.com/Materials-Consortia/OPTIMADE/pull/415
Backoff time by @merkys in https://github.com/Materials-Consortia/OPTIMADE/pull/411
Means to specify database license by @merkys in https://github.com/Materials-Consortia/OPTIMADE/pull/414
Means to provide partial entries and pagination mechanism through properties @rartino  https://github.com/Materials-Consortia/OPTIMADE/pull/467
Per entry and per property metadata by @JPBergsma https://github.com/Materials-Consortia/OPTIMADE/pull/463
Update to JSON:API v1.1 by @rartino https://github.com/Materials-Consortia/OPTIMADE/pull/461
Adding type and id to entry info endpoints by @ml-evs https://github.com/Materials-Consortia/OPTIMADE/pull/472
Adding database describing fields to meta by @ml-evs https://github.com/Materials-Consortia/OPTIMADE/pull/424

Outstanding PRs/issues
PRs we may want to finish and merge before release:

#377
#452
#460
#445
#473
#464
#206

PRs that seem to required more time in the oven (and perhaps another round of in-person discussion):

#386
#396 / #400
#392 & #398 are both mature PRs with a lot of discussion that would probably benefit from being included in a pre-release so that we can begin implementing them in our servers (and other associated SMILES PRs #436).
#456
#455

There are also some potentially blocking issues to address:

#416 - plenty of good discussion, but needs quite an extensive PR adjusting the merged space group functionality after #405. The current proposal also adds a definition of fractional site positions.
#102 - although #414 was merged, there is ongoing discussion about per-entry licensing. It seems the consensus is that this should be added to the free text license info for the overall database, but we should confirm this at the next meeting.
#410 c.f. #206
#469 and #479

Thanks for putting this together @ml-evs. Many of the features included in the current manuscript have been added post-v1.1, thus I think releasing v1.2 before publication would be a good idea.
#416 seems to be a real blocker. @rartino did a great job by summarizing the consensus, but it may take some time to convert that to a PR and merge it since a lot of new properties are proposed to be added.
#102 probably can be left out for this release (@blokhin, will you be able to support v1.2 with a per-database license file?)
#392 and #398 may be too far from reaching consensus at the moment. I am drafting an alternative proposal to implement #368, but I do not think it will be accepted any sooner.

@merkys per-database license file should be no problem! In general, I'd like to support the new release at the MPDS as early as possible.

The changes in #414 are actually somewhat breaking, as we are introducing a new mandatory info field license. Are we happy that this is introduced in a minor version release?

The changes in #414 are actually somewhat breaking, as we are introducing a new mandatory info field license. Are we happy that this is introduced in a minor version release?

Oh, right. To stick to minor version we probably need to demote license to an optional field and define a default behavior ("check the website" as before, I assume?).

(I vaguely remember a discussion of an implicit CC-BY if the license was not provided in this field)

I think it is safer to say "do not assume anything if not given". This seems backwards-compatible to me :)

Well, the property definitions PR definitely introduces many breaking changes to /info/<entry> too. We might need to discuss whether this is really already OPTIMADE 2 :)

Did we not agree to interpret SemVer for communication protocols to say that a backwards-breaking protocol change is one that breaks clients written to the older specification, but not one that requires change of the server code to conform to the newer version?
In that case, is adding a new mandatory field breaking? I suppose that, yes, very strictly speaking because we never explicitly say that a client MUST NOT crash on unrecognized non-database-specific fields. Still, I thought we agreed that this is just an omission we should just add as a clarification at some point.
I don't think the property definitions PR is backwards breaking (but I have not checked very carefully yet). In defining type in the info endpoint for OPTIMADE v1.1, I specifically insisted on inserting the following to make it possible to add this feature without being backwards-breaking: "For the purpose of compatibility with future versions of this specification, a client MUST accept values that are not string values specifying any of the OPTIMADE Data types, but MUST then also disregard the type field." I think that addresses the most clear place where the change could have been breaking.

Did we not agree to interpret SemVer for communication protocols to say that a backwards-breaking protocol change is one that breaks clients written to the older specification, but not one that requires change of the server code to conform to the newer version?

Sure (and we should write this up as I end up requesting to re-litigate this point every time...), but  pragmatically, each of the providers will have a non-zero amount of work to do to support v1.2. I'm going through that process now for optimade-python-tools and could potentially have something ready for our next meeting on the 22nd.

In that case, is adding a new mandatory field breaking? I suppose that, yes, very strictly speaking because we never explicitly say that a client MUST NOT crash on unrecognized non-database-specific fields. Still, I thought we agreed that this is just an omission we should just add as a clarification at some point.

I don't think the property definitions PR is backwards breaking (but I have not checked very carefully yet). In defining type in the info endpoint for OPTIMADE v1.1, I specifically insisted on inserting the following to make it possible to add this feature without being backwards-breaking: "For the purpose of compatibility with future versions of this specification, a client MUST accept values that are not string values specifying any of the OPTIMADE Data types, but MUST then also disregard the type field." I think that addresses the most clear place where the change could have been breaking.

Thanks for pointing out that note, I hadn't spotted it. Maybe that digs us out of the hole on a technicality, but I'll still need to update the validator and client behaviour in optimade-python-tools to work with any new 1.2 databases. This does lead to a bit of an explosion of work in terms of supporting multiple v1 versions simultaneously, but perhaps that is unavoidable. As I said above, I'll try to present the work it required to support "v1.2" in optimade-python-tools and can make an informed decision then.

In that case, I don't think the key question is if the next version number is v1.2 or v2.0, but whether we need to go through the new features merged into develop and see if there are features that require so much work that we rather omit them from this release (saving them for the next release).
On the other hand, doesn't the new features mostly amount to optional features and a few new required fields? I get the point that to fully validate the info endpoint properties field is significant work (and lets then not talk about /trajectories if we merge that before the release...), but does the validator have to handle this before the release? Can't the validator just be changed to ignore the new mandatory fields under properties and type if it is unrecognized?

In that case, I don't think the key question is if the next version number is v1.2 or v2.0, but whether we need to go through the new features merged into develop and see if there are features that require so much work that we rather omit them from this release (saving them for the next release).

Agreed, in my comment I was also conflating the issue of who will actually have time to implement these features before we talk about them in the paper! We can see if anyone has any objections to the changeset outlined in the OP at the next meeting, and to vaguely cross-post my answer from there, I guess we are looking at January-February for a specification release now anyway.

but does the validator have to handle this before the release? Can't the validator just be changed to ignore the new mandatory fields under properties and type if it is unrecognized?

Yes, I'm fine with this, although the knock-on effect will be that the fuzzy query aspect of the validator will not be able to run -- assuming that providing properties in the old style is no longer supported (which seemed to be the case from last reading of the spec?).

Suggestion is now to have release candidate 2 out by next week, at which point we can write the paper etc and hopefully find anything that breaks during implementations.

The consensus in today's meeting now seemed to shift back to delaying the release for several months until all of the PRs listed above are merged, and the paper will be written in such a way that assumes they will be merged, with the intermediate time being for initial implementations.
It's not entirely clear to me that this opinion is unanimous so please comment here if you disagree!

Hmm, yes, this closed automatically...


Improve visualization

[ ] Start 3d plot from a good position
[ ] Ability to color individual boxes
[ ] Quickly switch between multiple boxsets (Change rga algorithm to return list of boxsets for each depth?)

For the coloring, a good way maybe is to have some colormap as (optional) argument. So we can define a custom mapping from scalar values of boxes to a fixed RGBA value. This way we can easily e.g. display the invariant measure either with some Red-Green color map or with different opacity values as suggested in #20.

Ok, but why not just do
plot(boxset; colors = colormap.(measure))

?

I have to admit I did not have a close look at the plotting code. If this works, of course, this is what I meant.

This does not currently work. My suggestion was to add a "colors" argument instead of a "colormap" argument.

I see. Depends on what is easier to implement I guess, but colormaps seem to be more standard, while the colors way is more flexible. Don't really have an opinion on that yet.

Well. At the end, the renderer will take a Vector{GLBox{2}} or  Vector{GLBox{3}} where
struct GLBox{N}
    center::SVector{N,Float32}
    radius::SVector{N,Float32}
    color::SVector{4,Float32}
end
We can have any number of functions that put the arguments into this format.

This might be more of a medium-to-long-term goal, but working with some Jupyter notebooks, I noticed that it might be helpful if a call to plot(BoxSet) did not open a new Julia-window, but return a suitable plot object, so that the plot can be viewed in a notebook or the plotting plane of Juno etc. I have to admit though that I have no idea how difficult this would be (or if it maybe even works already and I'm simply using it wrong).

This requires a new backend like https://github.com/JuliaPlots/WGLMakie.jl


Automatically disconnect old peers after network upgrade activation

Is your feature request related to a problem? Please describe.
zcashd implements automatic disconnection from old peers after a network upgrade activates.
Zebra manually increments the CURRENT_VERSION and MIN_NETWORK_UPGRADE version after each network upgrade activation, but that's not an ideal solution, because it:

causes node failures after a network upgrade activation, until the CURRENT_VERSION is incremented
keeps connecting to old Testnet peers, until both networks have activated the same MIN_NETWORK_UPGRADE

Describe the solution you'd like
Increment the network protocol version when network upgrade features are complete:

[ ] Increment the CURRENT_VERSION after all network-upgrade specific tasks are done for testnet
[ ] Increment the CURRENT_VERSION after all network-upgrade specific tasks are done for mainnet

Make sure we double-check these versions right before every network upgrade activation on Mainnet and Testnet.

Automatically reject older peers after network upgrade activation:

[ ] Replace MIN_NETWORK_UPGRADE with a min_peer_version function, which changes at each network upgrade activation, based on the best tip height

the state can use a watch channel to broadcast the best (non-finalized or finalized) tip height

[ ] Add a MIN_ACTIVE_NETWORK_UPGRADE constant, which can be used to calculate the minimum network protocol version we'll accept during the initial sync
[ ] Reject new connections from outdated peers based on min_peer_version
[ ] Close any open connections from outdated peers when the min_peer_version changes

[ ] security: rate-limit these connection closes to 1 per second, to avoid connection floods and temporary starvation

[ ] Make sure we allow connections to outdated peers if the chain is rolled back past network upgrade activation

Describe alternatives you've considered
Just keep manually incrementing MIN_NETWORK_UPGRADE. That will cause Zebra to fail after each network upgrade.
Additional context
A previous PR that incremented these constants is #1333.
Related Issues
#706 evicting old peers in the days before a network upgrade
#337 ZIP-200: Network Upgrade Mechanism
Follow-Up Tasks
Re-deploy the Foundation DNS seeders
Re-deploy any other long-running Foundation Zebra nodes

Rather than implementing any special network upgrade disconnection logic, I think it would be much cleaner to (1) decline to connect to peers speaking the old protocol and (2) ensure that all network connections are short-lived by churning peer connections.  This is better because it avoids introducing extra modes into our network code.

xref https://github.com/ZcashFoundation/zebra/issues/706 with discussion on the above point

Assigning this ticket to sprint 7, because it's required for testnet activation.

Closed by #2519.


At the first task function, the module is not imported

from rapidfire import task
import requests

@task(next_action='hg_up_branch')
def branch():
    release_branches_url = XXX
    api_key = XXX
    r = requests.get("{}&key={}".format(release_branches_url, api_key))

(py3.5) (git) ⭠ [master] ⮀[wan] ~/Work/rapidfire
% rap branch
name 'requests' is not defined

https://github.com/wanshot/RapidFire/pull/8