Better qs-manipulation APIs on BaseURL

The werkzeug.urls APIs are pretty awesome for both low and high-level uses, URL is especially nice for both parsing/manipulating URls and neatly creating them.
The one black mark here is that while extracting a querystring is really well supported (URL.decode_query), resetting one less so, and updating one is especially not-nice:

resetting requires an explicit call to url_encode for serialization, which is OK but a bit verbose:return url_parse(input).replace(query=url_encode(params))

updating can not be performed as an expression as it requires extracting, processing, then re-setting the query:url = url_parse(input)
qs = url.decode_query()
qs[key] = value
return url.replace(query=url_encode(qs))

Every time this feels ugly and frustrating. Since BaseURL already has a bunch of convenience helpers for existing (simpler) use-cases, maybe it could have them for this as well? e.g. set_query(d=None, /, **kw) and update_query(d=None, /, **kw) which could take care of that internally?
The one thing which is a bit unclear, given querystrings have MultiDict semantics, is how to handle key conflicts (for updates, but also potentially for replacements if the method would accept both an optional base mapping and kwargs).
I think replacement semantics would make more sense as default, even though that is not the behaviour of MultiDict.update (and I don't think it has any method to do that as part of its interface?). Though for set at least it could also accept either a (multi)dict or kwargs but not both.

Werkzeug was originally written for Python 2, and used Python's urlparse module. When Python 3 support was added, it instead tried to backport Python 3's urllib.parse module to support both strings and bytes for 2/3 compat. Werkzeug's urls module is mostly not our own code, but a copy of the API from Python's builtin urllib.parse module, with whatever behavior it had at the time.
The history of this makes maintaining it more difficult, as it's hard to dive in and understand the correct behavior, or understand how/why it differs from Python's implementation. My long term goal is to remove as much of this module as possible and go back to using urllib.parse directly. Therefore, I don't plan to change how most of it works any further, including the URL and BytesURL classes.

Werkzeug's urls module is mostly not our own code, but a copy of the API from Python's builtin urllib.parse module, with whatever behavior it had at the time.

That doesn't really jibe with the actual modules, werkzeug.urls has a much better (and more expansive) API than urllib.parse, very much including everything mentioned in this post. As far as I can see (and in my experience) werkzeug.urls is closer to "urllib.parse but good" than "outdated urllib.parse".

It has some other functions, which I won't get rid of, but the vast, vast majority of it was intended to be a compat layer when we were maintaining support for Python 2 and 3, not a separate API.

If the functions in werkzeug.urls were implemented as wrappers around urllib.parse, rather than complete reimplementations, I'd be more open to adding extra behavior. As a maintainer and user, I want to understand what extra behaviors are happening, versus unintended different behavior from divergent implementations.
I'm not opposed to, for example, having a url_parse function that does urllib.parse.urlparse then returns our own enhanced ParseResult with extra behavior. But I first want to get to the point that the functions are actually wrappers around urllib.parse.


Fieldset.advancetime through NEMO curvilinear grids

I am trying to run Parcels over NEMO ORCA025 model output - the velocity fields are curvilinear and there are many files for a given year. So, to do this, I am trying to combine the Fieldset.advancetime tutorial with the NEMO curvilinear grids tutorial.
I have defined a loadNEMOfile function which calls the u,v grids and default mesh settings; I wish to loop through a year of 5-day velocity grid files. However, upon attempting fieldset.advancetime, the following error messaged is returned:
RuntimeError: Time of field_new in Field.advancetime() overlaps with times in old Field
Does the mesh_mask.nc4 file need to have updated 'time' variable too? If so, how best to do this?
advancetime_curvilinear.docx

Hi @rm1911, I ran into this issue too, a while ago. Then, I implemented a function along the following lines:
def set_nemo_fieldset(ufiles, vfiles, meshset=None):

    filenames = {'U': ufiles, 'V': vfiles}
    if meshset is None:
        mname = ddir + 'domain/coordinates.nc'
        filenames['mesh_mask'] = mname
        meshnames = {'gU': mname, 'gV': mname, 'gT': mname}
        meshvars = {'gU': 'glamu', 'gV': 'glamv', 'gT': 'glamt'}
        meshdims = {'gU': {'lon': 'glamu', 'lat': 'gphiu'},
                    'gV': {'lon': 'glamv', 'lat': 'gphiv'},
                    'gT': {'lon': 'glamt', 'lat': 'gphit'}}
        meshset = FieldSet.from_netcdf(meshnames, meshvars, meshdims, indices)
        from_nemo = True
    else:
        from_nemo = False

    variables = {'U': 'uo', 'V': 'vo'}
    dimensions = {'U': {'lon': 'nav_lon', 'lat': 'nav_lat', 'depth': 'depthu', 'time': 'time_counter'},
                  'V': {'lon': 'nav_lon', 'lat': 'nav_lat', 'depth': 'depthv', 'time': 'time_counter'}}

    if from_nemo:
        fieldset = FieldSet.from_nemo(filenames, variables, dimensions, indices, allow_time_extrapolation=False)
    else:
        fieldset = FieldSet.from_netcdf(filenames, variables, dimensions, indices, allow_time_extrapolation=False)

    return fieldset, meshset

And then the first time I would call the function with meshset=None and then during the .advancetime() with meshset=meshset. Does that work for you?
Note that we are working on having Parcels do advance_time under the hood, so that users don't need to worry about it anymore (e.g. #216); once that new feature lands, this should all be much easier


Ion-tabs tabs on top on iOS ?

I have an app that contain ion-tabs on top. It works fine on Android but with iOS the tabs are behind of header.
How could I solve this ?
html: http://pastebin.com/y83g97Mp
iOS simulator image: http://i.imgur.com/crrtJuE.png

plz,show more code.
for example, ion-content in html , config in js

@hanung
http://pastebin.com/sRLVpZQ4

maybe.. include 'has-header' class

or look at the spacing that tabs get at the bottom and create a custom CSS class to give you the same spacing at the top.
I had to adjust my css to add more top spacing on android so that my search inputs didn't disappear behind the top tabs.

Hello! Thanks for opening an issue with us! As this seems like more of a support question i will urge that you ask this question on our forum (forum.ionicframework.com). Thanks for using Ionic!


Rebase of all commits.

This branch should have a tidied up history.
If you are happy with it I shall use it to replace main.
Will make a backup of the original main into a new branch beforehand.

#54 is a duplicate. (I renamed the branch 🤦🏼♀)


Add support for FreeVarReference::Error

Description
Next.js needs a way to error when certain globals are used in the edge runtime. For example setImmediate, to cause an error at compile time. This implements support for FreeVarReference::Error which can be used to provide an error message.
Since the internals already track the span the message is applied with the right code location automatically.

Testing Instructions

Current dependencies on/for this PR:

main

PR #6177   👈

This comment was auto-generated by Graphite.


🔧 Repository: maintaining multiple release lines of plugins

Some plugin owners may want to maintain and develop multiple versions of their plugin in parallel.
My initial implementation idea:

For the few cases where this is required, the plugin owner can create a branch named plugin/vN.x where N is the major version line they wish to maintain in parallel.
We have a generic and manually triggerable workflow, which reuses the changesets automation, where we can supply both the branch and workspace to be released.
Only that plugin/workspace gets released from that branch.

short-lived branches when a release is needed

So your suggestion is that we 'd have a branch called workspacename/x.y.z  for each maintenance build?
eg., argocd/1.24.7 to release the 1.24.7 version of the argocd plugin (to support an older Backstage version), while main branch is at version 1.25.1 (aligned to the latest Backstage version)
and if we needed another bugfix we'd have a new argocd/1.24.8 branch... rather than reusing a argocd/1.24 branch for all the updates?

Could you outline some of the needs that lead to this requirement? In the main backstage/backstage repo out only use of multi-track releases has been critical security fixes. Is it the same here and is that the only thing we should solve for? The main requirement for that is to have a publishing set up for a separate branch pattern, and also have strict branch protection rules for that pattern.
We wouldn't want to copy out patch process straight from backstage/backstage though. Without a fixed release cadence you don't end up with the same complexity of needing to leave space for previous patch releases that we have in the main repo. For example, if 1.3.0 of a package goes out in main-line, then 1.3.1 in a patch, we have logic to make sure that the next main-line release skips straight to 1.3.2.

From a real-life simple example we had recently:

our plugin for RBAC support was updated to include changes in Backstage 1.27 (main branch)
then a CVE was discovered which required applying a fix to that plugin and including it in our Backstage 1.26.5-based branch (1.2.2)
however due to the changes in the 1.27 based version not being compatible with 1.26.5, we needed a way to patch the security issue in a version of the plugin that worked with 1.26.5 WHILE still developing new stuff based on 1.27.

The net result was we needed a BS 1.26-compliant RBAC plugin. This was achieved with two branches:
https://github.com/janus-idp/backstage-plugins/blob/1.2.x/plugins/rbac/package.json 1.20.11
https://github.com/janus-idp/backstage-plugins/blob/main/plugins/rbac/package.json 1.28.2
If we could ONLY move forward with a single main branch, this would have been impossible as the 1.21.z and newer versions in main included new features/changes that didn't work with 1.2 (BS 1.26.5).
TL;DR, our maintenance support requires fixing things in older releases as far back as 6mo ago, which can be achieved very simply with the ability to release community plugins from a temporary branch based on an older tag, as @BethGriggs proposes above.

Yep, makes sense and we do need this for critical security fixes 👍
I'd push back on this though:

Other reasons may be tied to the service the plugin provides - a plugin that integrates with a service that has a new major versions with different APIs may prefer to temporarily maintain two release line versions in parallel.

It's likely always best to build support for those multiple versions into the plugin itself instead, that's gonna end up being simpler both for the maintainers and consumers of the plugin. I don't think we want to leave it to the one installing a plugin to have to select which version of the plugin to use, and on the maintainer side I don't think we want to have to manage applying changes multiple times.

Another aspect of this is that it's not always possible to have a plugin support the latest runtime, due to incompatible dependency requirements. We have this problem already brewing with keycloak support as at SOME POINT we'll have a plugin that works with the latest Keycloak (rather than pinned to version 22) but we still have to do 6mo of bug/security maintenance even after we have a newer solution in main.
TL;DR, maintenance is required, and a simple workflow that allows this is necessary.
Would it be possible to grant some users access to manually publish plugins to the @backstage-community scope at npmjs.com? That's protected by 2FA and can be revoked at any time.
You can associate multiple people in a team, then associate a team with a subset of packages, which while it'll involve some adminstration, will provide the granular permission you want at the per-workspace (or per-team) level.
Would that be an acceptable approach to federating the permissions of workspace owners to control their own packages' maintenance lifecycles? If you need more info or screenshots on how this works, LMK and I can add.


Add basic styles for autodoc

It doesn't look super bad right now, but can be improved.

Check how the pydata sphinx theme does their demo docs. They have a section on API reference docs that I can lift probably for development.


Update hadolint and shellcheck

Since the new warning report is in jenkins.sh, widely used in production, I think we need a more detailed review before the correction is merged and delivered to users.  Surrounding the ${JENKINS_WAR} argument in double quotes seems simple and reliable, but I'm not as well versed in safe shell scripting as others are.


Add unique_counts and apply a few fixes to unique_*() functions

Close #291.
This PR:

adds a new API unique_counts as suggested in #291 to return unique values and their corresponding counts
fixes the description of unique APIs:

the description of unique_all() was copied/pasted, which is now properly expanded
the "default integer type" mentions are not accurate if the index/count is too large. Now we allow type promotion as needed.

hmmm why does this PR only have 1 check instead of 3?

@leofang Not sure why it has only one check. 🧐

Not sure why it has only one check. 🧐

My guess is the other two CIs only run for this repo's branches, not for branches from forks. There is a piece of permission bit that needs to be set (at least it's the case for GH actions).

Ah, right. This was probably intentional in order to avoid drive-by PRs consuming resources.

I have reverted all changes on the returned integer type (discussion continued in #319) to make this PR easier to review 🙂

Thanks, @kgryte, good catch!


Ctrl-F7, instead of just f7, to make PerformanceStats show up.

Use Ctrl key as modifier on F7 to toggle Performance Stats visibility.

I added a case to check for Right Control also.


Plaintext http20 via http11 upgrade

Still needs some cleanup and test cases need to be added and updated.

Fantastic @fredthomsen! I'm pretty wiped out this evening so I'll take a look tomorrow and give you some more detailed feedback.

So let's start with the good news: this totally works, at least in the most simple case! I've been quite successful in getting http2bin.org to happily take the plaintext H2 upgrade, which is really awesome.
I'll start providing some code review here, but this is looking really good. @fredthomsen, if you find at any point that you don't think you want to spend the time on test cases, let me know and I'm happy to take over and clean this up and write tests.

Ok, basic code review is done.
This is totally amazing, I'm so excited to add this. I definitely owe you one @fredthomsen! :cake:

Thanks for the feedback.  I'll make these changes today.  One concern I had:
-The first stream id will never be returned for the initial request since we need to parse the response to find out if we were actually upgraded. This means that this behavior/return value differs for the request function for the HTTPConnection proxy object for TLS upgrades vs HTTP upgrades.
I seem to be having some issues with my tox and/or py.test setup as my test execution is hanging.  Once I get the squared up then I will address any test failures and add additional ones as needed.

The first stream id will never be returned for the initial request since we need to parse the response to find out if we were actually upgraded. This means that this behavior/return value differs for the request function for the HTTPConnection proxy object for TLS upgrades vs HTTP upgrades.

Yeah, that's annoying. Right now the API has a limitation there, in that there are no stream IDs returned if you're using HTTP/1.1. For the moment that might be OK.
Longer term, we may be able to extend the HTTP/1.1 API to nominally have stream IDs, but for that to always be stream ID 1, for example. Or possibly None.

Was looking into some of the test case failures and wondering how to handle test_hitting_http2bin_org_http11 in test_release.  This test case depended on non-secure traffic on an HTTP11Connection not getting upgraded.  Should there be a flag or something completely disabling the upgrade mechanism?

The easiest thing to do is to simply change the host we hit. httpbin.org should work fine.

Ok. All the changes discussed above have been made and test cases updated to support this.  Having some issue running the integration tests, as they are just hanging.  Not sure if I have the proper threading support in my environment... Any other test cases you believe are needed for this feature?

Hmm, the tests all blew up. I wonder if that's a timing problem.

Those failures don't appear to be timing related, because they occur on my local machine as well.

Only the integration tests have an issue on my box, the rest are passing.  I'll take a look at the CI logs and try to straighten it out.

Alrighty, I've worked it out. I'll do this merge manually and hopefully that'll fix up the tests.

Merged! :cake: :sparkles: :cake: Thanks so much @fredthomsen! You'll find your name in CONTRIBUTORS.rst: feel free to keep contributing code, we'd love to have it!

Thanks for the help and feedback.  Were all those test case failures resolved with the change made to the SocketLevelTest in server.py?

The test failures were indeed resolved, however we're short some test coverage, as mentioned in #137. If you feel like adding it let me know, otherwise I'll add those tests tomorrow.


Add which(cmd) method to CmdContext.

Example:
path = sh.which("podman") or sh.which("docker")
if path:
  cmd = sh(path, "--version")

Convenience wrapper around shutil.which() that uses the CmdContext's environment, if set.
cmd can be Path, str or bytes.  Returns a Path object or None, if no executable command is found.

A better name is probably find_command.


Closing it


NIOFileSystem uses yet another thread pool instead of NIOThreadPool

This is quite an important issue for adopting NIOFileSystem in real world systems: It needs to use the same thread pool as NIOThreadPool.
Larger scale real-world systems carefully size NIO's thread pool for blocking I/O. They will of course expect to not have another pool spawned by a random module like NIOFileSystem.
The fix should be really straightforward by just removing the custom threads code in NIOFileSystem and using NIOThreadPool instead. That's literally exactly what NIOThreadPool got created for.
Additionally, NIOFileSystem should also accept other NIOThreadPools. But that's less critical for right now.

I was quite surprised to see NIOFileSystem setup its own thread pool as well. Has there been anymore discussion around this as there is no response here.

There's no disagreement on whether this needs fixing, it's just a matter of us scheduling the work.

Fixed by #2692


Fix Rails data migration (and Docker container initialisation)

Currently, attempting to make service-manual-publisher in govuk-docker is broken as the Rails data migration cannot complete. This PR fixes that - see commits for details.
Related Trello: https://trello.com/c/nWRFaLO3/2562-manually-bump-apps-to-rails-61
⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠

I've rebased #952 on top of this but still encounter the same errors — I'm not entirely sure yet whether migrations are being run correctly or if there's some missing step still.

I wonder if this change actually would be better placed in this PR — it's not really part of the 6.1 upgrade but coincidental. Or perhaps a third PR in between these two?


Sigma Value Always Resets to 1 after 'Submit Method'

NOTE: This bug only affects mrsimulator-app when running locally. The current live dev version is not affected by this issue.
Steps to reproduce:

Load any example with experimental data
Go to methods tab
Change sigma to any valid value except 1
Press the Submit Method button

Expected behavior:
Values in method fields remain the same after Submit Method is clicked
Observed behavior:
Other value remain the same, but sigma always resets to 1 regardless of given value
I believe the issue originates in these lines of code:
https://github.com/deepanshs/mrsimulator-app/blob/933f373696222eb9bf71aa1f89403ed8bf1fd5b3/app/assets/javascript/method.js#L106-L119
The application variable is always undefined meaning sigma is always set to 1 before setVaule is called.

The live version IS affected by this issue. When importing a .mrsim file from local machine sigma is always reset to zero.
Online examples (ex. Wollastonite) are not affected.

Issue is resolved in #21


GH-Pages -> Netlify

Move hosting from GH-Pages to Netlify

@chrisheninger, I can walk you through this but since the repo is tied to your account you will need to give Netlify access to the repo so it can rebuild whenever we push to the master branch.

That was easy. 😅


Implementing rand-nth

🔖 Changes

Added rand-nth: it returns a random item from xs.

Tests
(rand-nth @["one" "or" "other"])

It will get one of these: "one", "or", "other"

Hi,
there is a script to build the API documentation: doc/build-api-page.php. Have you used that?

Hi,
there is a script to build the API documentation: doc/build-api-page.php. Have you used that?

No, I did it manually.
Should I run php doc/build-api-page.php and that's it?
Or should I redirect the output of that script to a certain file or somewhere?
Or how should I generate the API documentation? Is that documented somewhere?
About the docu I just found that command that you wrote me + in the README.md at the bottom it says
# Build the documentation
## The documentation is built with Zola.

cd doc
zola serve # build & serve
zola build # build & publish

🤔

No, I did it manually.
Should I run php doc/build-api-page.php and that's it?
Or should I redirect the output of that script to a certain file or somewhere?
Or how should I generate the API documentation? Is that documented somewhere?
About the docu I just found that command that you wrote me + in the README.md at the bottom it says
# Build the documentation
## The documentation is built with Zola.

cd doc
zola serve # build & serve
zola build # build & publish

🤔

It should be php doc/build-api-page.php > doc/content/documentation/api.md

It should be php doc/build-api-page.php > doc/content/documentation/api.md

Ach, way too many changes...
I would keep this PR simple and merge only the new function (removing the last commit). And in another commit directly to master (or PR) update the full docu from API. Fine for you, @jenshaase?

Ach, way too many changes...
I would keep this PR simple and merge only the new function (removing the last commit). And in another commit directly to master (or PR) update the full docu from API. Fine for you, @jenshaase?

Yes that is ok for me. You can commit it directly to master.

Yes that is ok for me. You can commit it directly to master.

It is merged now. Thanks!

It is merged now. Thanks!


ODP Meeting minutes action fails (when unknown attendees are found)

Bug Report
Steps to Reproduce:

Create an ODP Meeting Minutes issue
Any gitHub user that is not filed into FINOS metadata adds a comment (content is not relevant)
Close the issue

Expected Result:

An action is triggered and completes successfully
The indexed label is added to the issue
A comment is posted to the issue, reporting the GitHub username that commented the issue on step nr. 2

Actual Result:

An action is triggered and fails
The indexed label is NOT added to the issue
No comments are posted

Additional Context:
NOTE! This issue is currently affecting all FINOS projects using Meeting minutes; below the list of projects that make use of it; feel free to edit this list to add more.

[x] Cloud Service Certification
[x] Open Developer Platform
[x] FDC3
[x] KDB
[x] Reg Sig
[x] Security Reference Data

Fix
See example on this PR - https://github.com/finos/cloud-service-certification/pull/82/files
The fix consists in replacing
echo "::set-env name=UNKNOWNS_COMMENT::${ISSUE_CONTENT}"

with
echo "${ISSUE_CONTENT}" >> $UNKNOWNS_COMMENT

More info can be found on https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-commands-for-github-actions#setting-an-environment-variable

All done! If any other occurrence is spotted, please reference this issue.


param: changes for making param set/get work with ArduPilot

This pull request contains the minimal necessary changes needed in the MAVSDK to make param set/get work with Ardupilot. Following the discussion from https://github.com/mavlink/MAVSDK/issues/1683, I decided to try the suggestion B from @julianoes

B) Always download all params on startup to then have the type cached when the function is used. This would take longer but make the API easier. What do you think?

I had to, however create a different function to deal with the param set for APM
float MAVLinkParameters::ParamValue::get_4_float_bytes() const
float MAVLinkParameters::ParamValue::get_4_float_bytes_apm() const

As mentioned before, Ardupilot likes to have direct cast to float instead of the re-interpret cast used in MAVSDK for PX4 param set. More details can be found in https://mavlink.io/en/services/parameter.html#ardupilot
Awaiting valued feedback on this.

The CI is not happy, and you should fix the style with something like ./tools/fix_style.sh . :+1: :blush:

@ykhedar I've rebased your PR, fixed style issues, and force pushed it to your branch.
I also added a test to check get_all_params:
cmake --build build/default/ -j6 && build/default/src/integration_tests/integration_tests_runner --gtest_filter="SitlTest.GetAllParams"

(For ArduPilot, don't forget to change add_udp_connection() to add_udp_connection(14550).
The test fails for me for me for ArduPilot,
[05:29:00|Info ] Int params: 0 (param.cpp:149)
[05:29:00|Info ] Float params: 0 (param.cpp:155)
[05:29:00|Info ] Combined params: 0 (param.cpp:161)

and PX4:
[05:30:13|Error] Error: unknown mavlink param type:  (mavlink_parameters.cpp:965)
[05:30:13|Error] Error: unknown mavlink param type:  (mavlink_parameters.cpp:965)
[05:30:14|Info ] Int params: 0 (param.cpp:149)
[05:30:14|Info ] Float params: 0 (param.cpp:155)
[05:30:14|Info ] Combined params: 0 (param.cpp:161)

so something is not quite right yet.
It works for PX4 before that.
One thing that I think of changing is to only get the param that you want to set. That way we don't have to get all params which is not necessarily something that everyone wants to do, always.

FYI @ykhedar I'm currently reworking this.

@ykhedar I've rebased your PR, fixed style issues, and force pushed it to your branch.
I also added a test to check get_all_params:
cmake --build build/default/ -j6 && build/default/src/integration_tests/integration_tests_runner --gtest_filter="SitlTest.GetAllParams"

(For ArduPilot, don't forget to change add_udp_connection() to add_udp_connection(14550).
The test fails for me for me for ArduPilot,
[05:29:00|Info ] Int params: 0 (param.cpp:149)
[05:29:00|Info ] Float params: 0 (param.cpp:155)
[05:29:00|Info ] Combined params: 0 (param.cpp:161)

and PX4:
[05:30:13|Error] Error: unknown mavlink param type:  (mavlink_parameters.cpp:965)
[05:30:13|Error] Error: unknown mavlink param type:  (mavlink_parameters.cpp:965)
[05:30:14|Info ] Int params: 0 (param.cpp:149)
[05:30:14|Info ] Float params: 0 (param.cpp:155)
[05:30:14|Info ] Combined params: 0 (param.cpp:161)

so something is not quite right yet. It works for PX4 before that.
One thing that I think of changing is to only get the param that you want to set. That way we don't have to get all params which is not necessarily something that everyone wants to do, always.

Hi @julianoes Thanks for taking a look at the PR. I am not able to work on it for at least a week more due to the other project so please go ahead and rework if you have the time.
Last time I checked the tests not passing for PX4 set param was most probably because the params were not being cached at the right time. I was looking into it but then dragged into the other project.
I believe caching all params on first connection is not a bad idea. I have seen this behaviour in Mavproxy and really like that, as soon as it is connected to the vehicle it saves all params to a a file. Since MAVSDK is usually connected over a wire to the Autopilot, should not be a huge problem speed or lost packet wise. What do you think?

@julianoes There was a small bug(wrong function name) which was causing issues for CI. I fixed it in my last commit and CI seems to be happy now. Are you still working on something for this pull request or we can rebase and merge it into the main branch?

@ykhedar I'm having a look now, sorry for the delay.

@ykhedar thanks for fixing that, I was wondering what was going on!


UHF-10738 Cookie policy

UHF-10738

What was done

Added JS libraries for the HDS cookie consent and HDBT Cookie banner javascripts and necessary variables to Drupal Settings.
Added default settings for the cookie banner, schema definitions for the configuration variables and new variables for the cookie banner settings form.
Added deprecation comments to EU cookie compliance related code.
Added install hook for the hdbt_cookie_banner to uninstall eu_cookie_compliance module.
Added theme hook and a template for the new cookie policy settings page.
New route and controller for the cookie policy page.

How to install

Make sure your instance is up and running on latest dev branch.

git pull origin dev
make fresh

Update the Helfi Platform config

composer require drupal/helfi_platform_config:dev-UHF-10738 drupal/hdbt:dev-UHF-10738 -W

Run make drush-updb drush-cr
Go to shell and install the hdbt_cookie_banner module

make shell
drush en -y hdbt_cookie_banner

Uninstall the eu_cookie_compliance and helfi_eu_cookie_compliance modules

drush pmu -y eu_cookie_compliance

How to test

[x] Log in to drupal and go to /admin/structure/hdbt-cookie-banner
[x] Select "Use instance specific cookie settings" checkbox.

This will make the Drupal use the instance specific cookie settings and cookie banner javascript

[x] Copy the contents of this file to Site settings textarea: sitesettings.json
[x] Save the changes
[ ] Refresh the page and check that the cookie banner appears

[x] Try to change f.e. the Website name and save the settings, reload the page and check that the cookie banner website name has changed.

How to test the workflow with helfi etusivu

[x] Do the same installation tasks for helfi etusivu

[x] Log in to helfi-etusivu drupal and go to /admin/structure/hdbt-cookie-banner
[x] Select "Use instance specific cookie settings" checkbox.
[ ] Copy the contents of this file to Site settings textarea: sitesettings.json and save the changes

[x] Switch back to the instance you were testing before and head to /admin/structure/hdbt-cookie-banner
[x] Unselect the "Use instance specific cookie settings" checkbox and save the changes
[x] Clear the caches and check that the Cookie banner still works
[ ] Check that code follows our standards

Translations

[x] Translations have been added to .po -files and included in this PR

Other PRs

https://github.com/City-of-Helsinki/drupal-hdbt/pull/1073

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 14.97%. Comparing base (bb50a52) to head (8f5dd4a).
Report is 61 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #821      +/-   ##
============================================
- Coverage     15.29%   14.97%   -0.32%
+ Complexity      259      255       -4
============================================
  Files            31       29       -2
  Lines           981      968      -13
============================================
- Hits            150      145       -5
+ Misses          831      823       -8

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fix Term's "get_type()" implementation

It was not returning the correct type for integers, probably due to a "garbage" arriving because of the wrong type.
This affects the latest v0.30.

Looks like this is not working well on Windows. I'm going to investigate tomorrow.

Hah, even found out who introduced the bug: https://github.com/rusterlium/rustler/pull/212 🕵♂
I can't debug the Windows issue for the next week or so since I won't have a Windows machine available.

I can't debug the Windows issue for the next week or so since I won't have a Windows machine available.

Thanks! I'm trying to setup a Windows VM so I can debug this as well :)

Just to give an update: I've tested and was able to reproduce the build problem on Windows.
Unfortunately I couldn't yet figure out what is going on - it just return "unknown" for any term there :/
I should go back to this next week.

Yeah, I'll be able to look into it this weekend as well. My initial guess would be a mismatched base type for the enum, Windows longs are always 32 bit.

@philss Did you get any further? I couldn't reproduce it so far, but I'll try again tomorrow.

@filmor unfortunately I couldn't :/
I tried to figure out where the int type is wrong, but there is no explicit declaration of it.
For a comparison, I did write a small NIF in C and it works good on Windows. So the problem seems to be on our side.
I will give another try this week as well.

@filmor I tried a bunch of things to fix this problem with the Windows build, but I couldn't find a solution.
I suspect the problem is in the bindings we create in the rustler_sys create for the NIF API.
I also tried to setup rust-bindgen on my windows VM, but without success. The idea was to generate a file that would follow more closely what is expected from the erl_nif.h file.
I think, given that we cannot make it work on Windows easily, we could drop this feature for that OS, documenting this behaviour. WDYT?

Given it never worked, perhaps we should just nuke it altogether. :)

Well, it works fine on Unix and is IMO the preferable approach (single function call vs. potentially ~10). I'll try to get the Windows interface in line (I think this is mostly about distinguishing floats from integers).

It is a single function call but internally it is 10 bitmap comparisons. If you want to know if something is a float or integer, asking specifically for float and integer would be more efficient.
Also note that nor Erlang nor Elixir have a similar function and we have been just fine for decades. Given it is broken in main, odds are that we really don’t need it.
that said, if you can make it work, then that’s great. I am just saying that, if it doesn’t work, it is not the end of the world. :)

@philss @evnu This finally works and passes all tests. It's really not pretty to essentially "copy" this gnarly code for is_float. We could still do as Jose suggests and drop the whole new code path, but since it works fine on non-Windows (which is likely the primary userbase anyhow) and we now have a workaround.
Notes:

I will still have to test this manually on 32bit Windows as that is not part of our CI at all and the is_float codepath is totally different (maybe enif_term_type works there as well?)
There is apparently a bug in OTP24, in that is_fun doesn't work for remote funs (fun module:function/0 or in Elixir &Function.identity/1). I don't intend to debug this further, it works for "function objects".

For what is worth, I don't think we should export a function that does not work on Windows as it may become an additional pitfall for both developers and Windows users. When a package using Rustler misbehaves on Windows, it may lead to both users and authors spent time debugging only to land here.
If you really want to go down that route, can it be an opt-in feature? So it is not available by default, reducing the chance of accidental use. Or, make sure that it is not available on Windows (so it is not even compiled) or that it raises a clear error message?

Which export are you now talking about? enif_term_type is in rustler-sys, which is like all-sys crates "there be dragons". What exactly would you make optional here? My intention is to eventually get rid of the custom is_float again and use enif_term_type everywhere. The way it's now implemented, everything works the same way everywhere (apart from checking remote funs on OTP24, but that is a bug in a version of OTP that we are going to stop supporting in a few months (whem 27 comes out) anyhow.

My comment was to make enif_term_type optional. :) However, I was assuming that it still does not work on Windows (while the C NIF does). Given you said:

The way it's now implemented, everything works the same way everywhere, apart from checking remote funs on OTP24

If it all works on Windows too, then just ignore me. :) But it may be that using enif_get_float and attempting to get a float may be more efficient than the several masks from enif_term_type.

On all non-Windows systems with OTP>=22 we use enif_term_type for the get_type function
On Windows, we use the old way with an additional hacky-copied version of the non-exposed is_float (which I will probably replace with an enif_get_float)
The behavior is now identical, the implementation is not (yet)
The bug with remote funs on OTP24 is preexisting ant not something I intend to follow up on apart from writing it down
I think the get_type will be useful for serializations, if benchmarks show that that's slower than chaining the enif_is_*, I'd consider that a bug in OTP since that is accoding to the docs why enif_term_type was introduced


Format Should Preserve Type Ignore Sub Expression

It seems that the ruff formatter will collapse a multi line expression with a # type: ignore to one line, unlike black.
I would like to keep the existing line split, if possible, since this limits the type ignore to one piece of the statement, instead of all of it. That way, if there is a type error in one of the other parts of the statement they are still caught by the type checker.
This is similar to https://github.com/astral-sh/ruff/issues/7730 but the issue here is not that the line ends up being too long, but that it changes the semantics of the type checker.
Example:
$ ruff format . --diff
--- python/egglog/egraph.py
+++ python/egglog/egraph.py
@@ -536,9 +536,7 @@

         # If this is the class for this method and we have a paramaterized class, recurse
         if (
-            cls_type_and_name
-            and isinstance(tp, _GenericAlias)
-            and tp.__origin__ == cls_type_and_name[0]  # type: ignore
+            cls_type_and_name and isinstance(tp, _GenericAlias) and tp.__origin__ == cls_type_and_name[0]  # type: ignore
         ):
             return TypeRefWithVars(
                 cls_type_and_name[1],

1 file would be reformatted, 25 files left unchanged
$ ruff --version
ruff 0.1.3

Settings:
[tool.ruff]
# Allow lines to be as long as 120.
line-length = 120
ignore = [
    # allow star imports
    "F405",
    "F403",
    # Dont care if cls isnt typed explicitly in classmethod
    "ANN102",
    # Same for self
    "ANN101",
    # Allow single line docstrings on multiple lines
    "D200",
    "D212",
    # Inconsistant formatting
    "D203",
    "COM812",
    "COM819",
    "E501",
    "ISC001",
    "Q001",
    "Q002",
    "Q003",
    "W191",
    "Q000",
    "D206",
    # TODO: Remove the rest of these eventually
    # Allow public methods to not have docstrings
    "D102",
    # Allow longer messages for custom errors
    "TRY003",
    # Allow f-string in exceptions
    "EM102",
]
src = ["python"]
select = ["ALL"]
extend-exclude = ["python/tests"]

I agree this should remain split to narrow the type pragma, I'm surprised by this behavior.

I can take a look at this though @MichaReiser will probably know the immediate answer. My guess is that the comment is attached to the overall binary expression rather than the tp.__origin__ == cls_type_and_name[0] term, so it doesn't cause the expression to expand.

https://play.ruff.rs/b126b941-44e2-44bf-9cca-68370dc14b9c?secondary=Comments

I think you need to increase the line length (e.g., to 120).

I suspect this is actually quite hard to support given that you don’t always want to expand on trailing comments here, and you don’t want to expand even with a type ignore if the line is already collapsed.

My guess is that the comment is attached to the overall binary expression rather than the tp.origin == cls_type_and_name[0] term,

I think that's correct. We could refine how pragma comments get associated in binary expressions but I'm not sure how. I first thought of always assign the comment to the most inner operand but it doesn't necessary yield the desired result, e.g. the above would roughly be formatted as:
if (
    cls_type_and_name
    and isinstance(tp, _GenericAlias)
    and tp.__origin__
    == cls_type_and_name[0]  # type: ignore
):
    pass

We could try to be "clever" and also take the source formatting into consideration, by associating the type ignore comment with the outer most operand that is on the same line as the type ignore
A workaround is to use parentheses to guide the formatter, but I agree that this isn't ideal
if (
    cls_type_and_name
    and isinstance(tp, _GenericAlias)
    and (
        tp.__origin__ == cls_type_and_name[0]  # type: ignore
    )
):
    pass

I feel like the ideal solution needs to somehow take into account which nodes are on the same line as the ignore. If we just assign to the inner-most operand, we'd have the opposite problem -- e.g., given cls_type_and_name and isinstance(tp, _GenericAlias) and tp.__origin__ == cls_type_and_name[0]  # type: ignore, we'd end up breaking that over multiple lines.

Not sure if this is related but I'm having a similar issue inside list comprehension and long lines. Example:
     todo: List[Optional[int]] = list(range(5))

     result = [
-        very_long_name_1234567 + 1 for very_long_name_1234567 in todo  # type: ignore
+        very_long_name_1234567 + 1
+        for very_long_name_1234567 in todo  # type: ignore
     ]

     assert result == [0, 1, 2, 3, 4]

On pip we have a similar issue:
    rmtree_errorhandler(
        mock_func, path, sys.exc_info()  # type: ignore[arg-type]

gets reformatted to
    rmtree_errorhandler(
        mock_func,
        path,
        sys.exc_info()  # type: ignore[arg-type]

This causes mock_func and path to now get type-checked, when previously they would not.
IMO reformatting should never change semantics like this.

Hi @charliermarsh, any plans on this ?
IMO, it would be nice if ruff had the config option to skip formatting strings with #type: ignore

Related black issue: https://github.com/psf/black/issues/997

Hi @MaksimZayats
I'll reply briefly here, but I recommend you open a new discussion if you want to follow up to avoid going off-topic on this issue.
Thanks for the linked issue. The scenario outlined by Guido is something I considered when designing pragma comment support for ruff's formatter. What I understand from the linked issue is, and I agree with, is that it's annoying when the code gets reformatted after I had to add a type: ignore comment. That's why Ruff's formatter doesn't account pragma comments to the line width.
Unfortunately, this doesn't help if you reformat your code with ruff the first time. It can then happen that the type: ignore comment gets moved, e.g. because the formatter now splits a list of arguments onto multiple lines. I agree this isn't ideal because it requires manually moving the pragma comments to the right position. That's why we tried to design the handling in a way that tooling would at least warn you when a comment gets moved to avoid e.g. suppressing type checking for more code without you noticing (which could silence typing errors).
We also considered not to format lines with a type: ignore, but we considered this a bad trade-off because you lose out on the functionality of the formatter.

People use formatters to avoid discussing formatting decisions. Disabling formatting, or reduced formatting resurfaces the very same problem that people try to avoid by using a formatter. This isn't the same as us not caring about pragma comments or not wanting to use any pragma comment specific formatting. It only means that we don't want to use solutions that disable or limit formatting in a significant way.

I hope this is helpful and sets some of our decision-making into context.

Thank you @MichaReiser for the link to your design document regarding comment support! It seems very thorough.
After reading it, there are a few pieces in it that confuse me, since they seem to suggest that this issue wouldn't happen under those design constraints, although I am probably just missing something. It's quite a subtle issue!
When you discuss alternatives you discarded, I read the last sentence (emphasized by me) as suggesting that there is a way to manually move the type comment to preserve the intended semantics, i.e. that only one sub-expression should be ignored by the type checker, not the whole line. Is that how you meant it? If so, is there a way I can format the original example so that ruff will preserve those semantics?

Disable line breaks for type: comments similar to Black [https://github.com/psf/black/pull/1040]. I understand its motivation but believe that limiting formatting for entire lines removes the advantage of using a formatter. Not counting pragma comments towards the line width balances "reducing the frustration when placing pragma comments" with "the benefits of using a formatter" better IMO. I admit that this approach doesn't solve the issue when you format a new project or extend the width of an existing line. But moving the comment manually is a reasonable ask in these situations.

In "Case 1: Suppress single argument/expression" you do give an example of how ruff preserves the scope of a pragma comment. I am realizing that the issue I raised here only occurs when the pragma happens to fall on the last sub-expression that could be reformated into a line. For example, ruff properly preserves the line breaks with this example:
if (
    cls_type_and_name
    and isinstance(tp, _GenericAlias)
    and tp.__origin__ # type: ignore
    == cls_type_and_name[0]
):
    pass

However, if the pragma is on the last line, like in my original example, they are all reformated into one line:
if (
    cls_type_and_name
    and isinstance(tp, _GenericAlias)
    and tp.__origin__
    == cls_type_and_name[0]  # type: ignore
):
    pass

When you discuss alternatives you discarded, I read the last sentence (emphasized by me) as suggesting that there is a way to manually move the type comment to preserve the intended semantics, i.e. that only one sub-expression should be ignored by the type checker, not the whole line.

Yes, that's the intention of the last line.

However, if the pragma is on the last line, like in my original example, they are all reformated into one line:

I assume you're using a line-length of 120 or similar, in which case you get:
if (
    cls_type_and_name and isinstance(tp, _GenericAlias) and tp.__origin__ == cls_type_and_name[0]  # type: ignore
):
    pass

The formatter doesn't allow you to narrow the type: ignore comment because it always collapses the line. The reason it collapse the comment this way is to make the operation reversible if a line expands:
a = (
    cls_type_and_name and isinstance(tp, _GenericAlias) and tp.__origin__ == cls_type_and_naeeeeeeeme[0]  # aaaaaaaaaaaaaa
)

becomes

a = (
    cls_type_and_name
    and isinstance(tp, _GenericAlias)
    and tp.__origin__ == cls_type_and_naeeeeeeeme[0]  # aaaaaaaaaaaaaa
)

and then collapse back to if it is shortened:

a = (
    cls_type_and_name and isinstance(tp, _GenericAlias) and tp.__origin__ == cls_type_and_naeme[0]  # aaaaaaaaaaaaaa
)

I think the solution here is to change the comment association logic in placement.rs for binary like expression to associate any trailing comment with the last comparison (tp.__origin__ == cls_type_and_name[0]) instead of making it a trailing binary expression comment  if the binary expression is formatted across multiple lines. However, it comes with the downside that splitting a binary expression with a trailing comment becomes nonreversible. I'm not sure if this is a good tradeoff.

We're seeing this as well on a long import:
from stripe.request_options import RequestOptions as RequestOptionsStripeRequestOptions  # type: ignore

becomes
from stripe.request_options import (
    RequestOptions as RequestOptionsStripeRequestOptions,
)  # type: ignore

which starts failing in type checking. +1 to the idea that formatting shouldn't cause CI failures.
It works if you keep the #ignore on the middle line, but i'm not sure that you could determine that programatically.


Remove next dependency in favor of skipLibCheck

See https://github.com/chakra-ui/chakra-ui/issues/5082#issuecomment
-979039787.

this potentially can impact our type system accuracy according to the docs:
https://www.typescriptlang.org/tsconfig#skipLibCheck
Perhaps migrating to yarn3 could mitigate it, but I'm not sure which trade-off is more worth it here? (extra dependency vs disabling a check that has a slim chance of biting us someday)

Should we leave a comment in the config file to switch it back to false when we do the yarn 3 upgrade?

bors r+


"message": "  /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stubs/..."
}

  /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stubs/...
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "  /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/bundled/stubs"
}

  /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/bundled/stubs
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "  /home/don/.pyenv/versions/3.9.7/lib/python3.9"
}

  /home/don/.pyenv/versions/3.9.7/lib/python3.9
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "  /home/don/.pyenv/versions/3.9.7/lib/python3.9/lib-dynload"
}

  /home/don/.pyenv/versions/3.9.7/lib/python3.9/lib-dynload
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "  /home/don/.pyenv/versions/3.9.7/lib/python3.9/site-packages"
}

  /home/don/.pyenv/versions/3.9.7/lib/python3.9/site-packages
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 2,
    "message": "Exception received when installing file system watcher: TypeError [ERR_FEATURE_UNAVAILABLE_ON_PLATFORM]: The feature watch recursively is unavailable on the current platform, which is being used to run Node.js"
}

[Warn  - 3:56:56 PM] Exception received when installing file system watcher: TypeError [ERR_FEATURE_UNAVAILABLE_ON_PLATFORM]: The feature watch recursively is unavailable on the current platform, which is being used to run Node.js
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 2,
    "message": "Exception received when installing file system watcher: TypeError [ERR_FEATURE_UNAVAILABLE_ON_PLATFORM]: The feature watch recursively is unavailable on the current platform, which is being used to run Node.js"
}

[Warn  - 3:56:56 PM] Exception received when installing file system watcher: TypeError [ERR_FEATURE_UNAVAILABLE_ON_PLATFORM]: The feature watch recursively is unavailable on the current platform, which is being used to run Node.js
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 2,
    "message": "Exception received when installing file system watcher: TypeError [ERR_FEATURE_UNAVAILABLE_ON_PLATFORM]: The feature watch recursively is unavailable on the current platform, which is being used to run Node.js"
}

[Warn  - 3:56:56 PM] Exception received when installing file system watcher: TypeError [ERR_FEATURE_UNAVAILABLE_ON_PLATFORM]: The feature watch recursively is unavailable on the current platform, which is being used to run Node.js
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 3,
    "message": "Searching for source files"
}

[Info  - 3:56:56 PM] Searching for source files
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 3,
    "message": "Auto-excluding /home/don/samples/pySamples/crap/.venv"
}

[Info  - 3:56:56 PM] Auto-excluding /home/don/samples/pySamples/crap/.venv
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 3,
    "message": "Auto-excluding /home/don/samples/pySamples/crap/.venvClean"
}

[Info  - 3:56:56 PM] Auto-excluding /home/don/samples/pySamples/crap/.venvClean
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 3,
    "message": "Auto-excluding /home/don/samples/pySamples/crap/.venvSklearn"
}

[Info  - 3:56:56 PM] Auto-excluding /home/don/samples/pySamples/crap/.venvSklearn
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 3,
    "message": "Auto-excluding /home/don/samples/pySamples/crap/.venvWidgets"
}

[Info  - 3:56:56 PM] Auto-excluding /home/don/samples/pySamples/crap/.venvWidgets
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 3,
    "message": "Found 4 source files"
}

[Info  - 3:56:56 PM] Found 4 source files
[Trace - 3:56:56 PM] Received notification 'telemetry/event'.
Params: {
    "Properties": {
        "lsVersion": "2021.10.3",
        "openFilesOnly": "true",
        "typeCheckingMode": "off",
        "useLibraryCodeForTypes": "true",
        "autoSearchPaths": "true",
        "autoImportCompletions": "true",
        "indexing": "false",
        "completeFunctionParens": "false",
        "enableExtractCodeAction": "true",
        "hasExtraPaths": "false",
        "hasConfigFile": "false"
    },
    "Measurements": {
        "workspaceCount": 1
    },
    "EventName": "language_server/settings"
}

[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 3,
    "message": "Background analysis(1) root directory: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist"
}

[Info  - 3:56:56 PM] Background analysis(1) root directory: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 3,
    "message": "Background analysis(1) started"
}

[Info  - 3:56:56 PM] Background analysis(1) started
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Background analysis message: setConfigOptions"
}

Background analysis message: setConfigOptions
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Background analysis message: setImportResolver"
}

Background analysis message: setImportResolver
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Background analysis message: ensurePartialStubPackages"
}

Background analysis message: ensurePartialStubPackages
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Background analysis message: setTrackedFiles"
}

Background analysis message: setTrackedFiles
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Background analysis message: markAllFilesDirty"
}

Background analysis message: markAllFilesDirty
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Background analysis message: setFileOpened"
}

Background analysis message: setFileOpened
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Background analysis message: analyze"
}

Background analysis message: analyze
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)] analyzing: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb ..."
}

[BG(1)] analyzing: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb ...
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]   parsing: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb (26ms)"
}

[BG(1)]   parsing: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb (26ms)
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]   parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/builtins.pyi [fs read 4ms] (137ms)"
}

[BG(1)]   parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/builtins.pyi [fs read 4ms] (137ms)
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]   binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/builtins.pyi (44ms)"
}

[BG(1)]   binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/builtins.pyi (44ms)
[Trace - 3:56:56 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]   binding: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb (1ms)"
}

[BG(1)]   binding: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb (1ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]   checking: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb ..."
}

[BG(1)]   checking: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb ...
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/typing.pyi [fs read 2ms] (61ms)"
}

[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/typing.pyi [fs read 2ms] (61ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/typing.pyi (30ms)"
}

[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/typing.pyi (30ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi [fs read 1ms] (17ms)"
}

[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi [fs read 1ms] (17ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi (3ms)"
}

[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi (3ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/typing_extensions.pyi [fs read 1ms] (12ms)"
}

[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/typing_extensions.pyi [fs read 1ms] (12ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/typing_extensions.pyi (2ms)"
}

[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/typing_extensions.pyi (2ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/abc.pyi [fs read 0ms] (3ms)"
}

[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/abc.pyi [fs read 0ms] (3ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/abc.pyi (2ms)"
}

[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/abc.pyi (2ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/os/__init__.pyi [fs read 0ms] (31ms)"
}

[BG(1)]     parsing: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/os/__init__.pyi [fs read 0ms] (31ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/os/__init__.pyi (14ms)"
}

[BG(1)]     binding: /home/don/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2021.10.3/dist/typeshed-fallback/stdlib/os/__init__.pyi (14ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)]   checking: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb (211ms)"
}

[BG(1)]   checking: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb (211ms)
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "[BG(1)] analyzing: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb (421ms)"
}

[BG(1)] analyzing: /home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb (421ms)
[Trace - 3:56:57 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {
    "uri": "vscode-notebook-cell://wsl%2Bubuntu/home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb#ch0000000vscode-remote",
    "version": 1,
    "diagnostics": []
}

[Trace - 3:56:57 PM] Received notification 'telemetry/event'.
Params: {
    "Properties": {
        "lsVersion": "2021.10.3"
    },
    "Measurements": {
        "peakRssMB":<PHONE_NUMBER>,
        "rssMB":<PHONE_NUMBER>,
        "heapTotalMB":<PHONE_NUMBER>,
        "heapUsedMB": 82.57125854492188,
        "externalMB": 28.18996524810791,
        "elapsedMs": 421,
        "numFilesAnalyzed": -1,
        "numFilesInProgram": 22,
        "fatalErrorOccurred": 0,
        "isFirstRun": 1
    },
    "EventName": "language_server/analysis_complete"
}

[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Background analysis message: resumeAnalysis"
}

Background analysis message: resumeAnalysis
[Trace - 3:56:57 PM] Received notification 'telemetry/event'.
Params: {
    "Properties": {
        "lsVersion": "2021.10.3",
        "_resolverId": "1",
        "resolverId": "1"
    },
    "Measurements": {
        "total": 17,
        "stubs": 17,
        "unresolvedTotal": 0,
        "absoluteTotal": 16,
        "absoluteStubs": 16,
        "absoluteUnresolved": 0,
        "absoluteUserUnresolved": 0,
        "thirdPartyImportTotal": 0,
        "thirdPartyImportStubs": 0,
        "localImportTotal": 0,
        "localImportStubs": 0,
        "builtinImportTotal": 16,
        "builtinImportStubs": 16,
        "relativeTotal": 1,
        "relativeStubs": 1,
        "relativeUnresolved": 0
    },
    "EventName": "language_server/import_metrics"
}

[Trace - 3:56:57 PM] Received notification 'telemetry/event'.
Params: {
    "Properties": {
        "lsVersion": "2021.10.3"
    },
    "Measurements": {
        "tokenRangeMs": 0,
        "tokenFullMs": 0,
        "tokenDeltaMs": 0,
        "analysisMs": 425,
        "userIndexMs": 1,
        "totalMs": 447,
        "preSetFileOpenMs": 208,
        "peakRssMB":<PHONE_NUMBER>
    },
    "EventName": "language_server/startup_metrics"
}

[Trace - 3:56:57 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 3:56:57 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Loading ONNX runtime..."
}

Loading ONNX runtime...
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Loaded ONNX runtime. Creating IntelliCode session..."
}

Loaded ONNX runtime. Creating IntelliCode session...
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Created IntelliCode session."
}

Created IntelliCode session.
[Trace - 3:56:57 PM] Received notification 'window/logMessage'.
Params: {
    "type": 4,
    "message": "Initialize deeplearning succeeded"
}

Initialize deeplearning succeeded
[Trace - 3:56:57 PM] Received response 'workspace/executeCommand - (1)' in 1931ms.
No result returned.

[Trace - 3:56:58 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 3:56:59 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 3:57:43 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 3:58:17 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 3:59:20 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 4:00:58 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 4:01:09 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "file:///home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb",
            "type": 2
        }
    ]
}

[Trace - 4:01:11 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 4:01:28 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 4:01:31 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "file:///home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb",
            "type": 2
        }
    ]
}

[Trace - 4:01:34 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "file:///home/don/samples/pySamples/crap/kernel_crash/after_start/one.ipynb",
            "type": 2
        }
    ]
}

[Trace - 4:03:16 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

[Trace - 4:03:35 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "vscode-local:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        },
        {
            "uri": "vscode-userdata:/c%3A/Users/donja/AppData/Roaming/Code%20-%20Insiders/User/globalStorage",
            "type": 2
        }
    ]
}

This is the same as #1973 and #1932.


sass::syntaxerror Undefined mixin 'border-radius'

We upgraded our rails version from 4.2.10 to 5.0.7.We encountered a problem after upgrading the version.When we start our app, we are seeing the following console warning:
Sass::SyntaxError - Undefined mixin 'border-radius'.:
  app/views/welcome/homepage.html.haml:16:in `_app_views_welcome_homepage_html_haml__1663568661347282844_70003372442660'
  app/controllers/welcome_controller.rb:88:in `homepage'

%html{lang: I18n.locale}
  %head
    = stylesheet_link_tag 'bootstrap.min', 'landing-animate', 'publins-homepage-css'
    %link{:href => "https://cdnjs.cloudflare.com/ajax/libs/jqueryui/1.12.1/themes/smoothness/jquery-ui.css"}
    %link{:href => "https://fonts.googleapis.com/css?family=Aldrich", :rel => "stylesheet", :type => "text/css"}/

we got error on stylesheet_link_tag line. we created mixin.scss file in app/assets/stylesheets and imported mixin to bootstrap.min,landing-animate and publins-homepage-css but kept getting same error.
What are your thoughts on this warning?
Thank you very much!!!
System configuration
Rails version:5.0.7
Ruby version: 2.4.0
'bootstrap-sass', '~> 3.4'

o


is windicss dead?

is windicss dead?

People prefer using Tailwind's JIT compiler. Additionally, there are many features missing on Windi compared to the latest version of Tailwind

Since the project UnoCSS is announced at Reimagine Atomic CSS, seems like WindiCSS project support has been dropped.
Maybe you can think about migrating to UnoCSS, it has a preset supports most of class utility that WindiCSS provided.

https://antfu.me/posts/reimagine-atomic-css#what-about-windi-css

https://github.com/windicss/windicss/issues/904


fix: Duplicated toast messages

SUMMARY
This PR fixes a bug where toast messages were duplicated. This happened because the initialization of flash messages (emitted from server-side) was being made both by FlashProvider and during the initialization of SQL Lab state. This PR makes FlashProvider solely responsible for initializing flash messages.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS
1 - Check that messages are not duplicated anymore
2 - Check that messages are displayed normally
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

/testenv up


Provide a way to access Gradle module metadata files from dependency resolution

There is currently a way, through ArtifactResolutionQuery, to get at the POM files for a dependency resolution result.
Gradle should offer a similar access to the Gradle Module Metadata file.
While it might make sense to offer access to metadata through the ResolvableDependencies in the future, this does not mean a more direct / custom access is not needed for specific use cases.

Closing this as the use case can be addressed with component metadata rules:
https://github.com/gradle/gradle/blob/fd9eb88be349f2fb35372c6f4bd2a0bd205be57e/subprojects/dependency-management/src/integTest/groovy/org/gradle/integtests/resolve/rules/VariantFilesMetadataRulesIntegrationTest.groovy#L87-L114
(improved by #11565 in 6.1)


Add Option element constructor

This adds an Option constructor that adheres to the current spec for Option constructors, available through jsdom's window/defaultView.
This has been tested against the specs included in this PR, as well as the real-life use case that led me to raise #1759.
Please let me know if the location of the tests added to the to-upstream directory are organized correctly.

Thank you! This isn't quite correct in a few ways, but instead of back-and-forthing on code review, I'll just merge this and do a follow-up commit correcting the issues :)


Artemis not working correctly at Safari

Describe the bug

The progress of my exercise is not beeing displayed at all in safari, however, it works when opening chrome. Instead it shows a "You have no results yet"

To Reproduce

Go to Safari
Try to display the exercise progress

Expected behavior

It should display the progress as follows:

Screenshots

Console output in safari:

Environment

 - OS: iOS
 - Browser Safari
 - Version Version 13.0.2

Additional context

Output in Web Console

  [REPLACE THIS WITH YOUR INFORMATION]

@lovaiible could you please have a look. Also why there are warnings related to the guided tour?!? I guess you need to check this with a student account.
Thanks!

@floralatz thanks for reporting the problem. We cannot reproduce the problem at the moment. Can you try to reload the page in Safari? What happens if you navigate back to the exercise overview and then again into the exercise details? Which result do you see in the exercise overview?
Thanks for helping to find to the problem!

@krusche navigating back and reloading the page did not solve the problem when it occured, however, since i had the issue i closed safari and reopened a new one and when i got to artemis now it is displayed just fine!

@floralatz thanks for the feedback. Then it was maybe just an issue with the update to the latest release. Good that it works now!


Nation tab - Grid

As a user
I want to see the full list of Nations assigned to my work
so that I can understand the scope of the Work
Acceptance Criteria
Scenario 1:
GIVEN Add Nation is open and all the information is filled in
WHEN I press add button
THEN I see them in a grid with the following information:

nation (search filter)
role (select filter)
relationship holder (search)
PIP (search)
status (select)

THEN above the grid I see

'+ Add Nation' Primary button to the left
Import Nation Button, Download Button, and the Pagination options to the right

Scenario 2:
GIVEN Nation Tab is open and grid is there
WHEN I hover over an avatar near name of the relationship holder
THEN I see information about that person
Scenario 3:
GIVEN Nation Tab is open and grid is there
WHEN I press Import Nation button
THEN I see Import Nation modal
Scenario 4:
GIVEN Nation Tab is open and grid is there
WHEN I press Download Nation button
THEN Nations in the list is exported in .xlx format
Scenario 5:
GIVEN Nation Tab is open and grid is there
WHEN I click on Nation's name
THEN I Nation Modal is open with the following changes to the title

'Nation Name' as a title

Screenshots
Private Zenhub Image
Private Zenhub Image
Private Zenhub Image

@salabh-aot
link to the prototype
https://www.figma.com/file/j5onJ5RZGAxahxhYp68N8m/For-Development?type=design&node-id=3890-84700&mode=design

@salabh-aot
Indigenous Nations in list management should be first nations
Saved notification for the notes all the time for every focus changes
Editing not working
If no nations to import, just disable the button
Import nations button also has to be disabled if there is nothing to import
Show the active ones count in the chip in the tab
Clear Button Style
import nations from the empty tab is  not working

have additional margins for Resources - should get rid of them to mirror the same view as for the Team tab
Private Zenhub Image

Inactive Nations are in the list, so the user can select them without knowing they are inactive. However, when they try to add them, it won't give any message, so it is unclear why this happen.
we should not show inactive nations in the list
Private Zenhub Image

We should make only avatar on hover as having the whole cell on hover prevents to copy information from the card as it immediately jumps to show the next avatar's credentials
[Uploading... Screen Shot 2023-10-13 at 11.43.25 AM.png]

Text on Hover for importing should be 'Import Nations from existing Works'
[Uploading... Screen Shot 2023-10-16 at 10.15.56 AM.png]

when downloading the Nations list from Scenario 4, the file is called Ajax mine evern though that is not the Work I am on.


Some terms are old pcl terms are dangling as CL terms

Old PCL (legacy) still needs cleaning up by removing some old CL terms
@hkir-dev not sure if I just manually delete this or how to handle? Is it ok if I leave this to you?

Fixed in branch issue_222
We are now deleting all non-pcl classes from the old PCL.

Fixed


Fix github issues hyperlink

Originally issue facebook/react-native#19735 and PR facebook/react-native#19738

Sweet, thanks!


What is the "accordion" component that all the examples on material-ui.com use?

On http://www.material-ui.com/#/components/card, there's a component that displays all the source code for each example – It opens when you click the "<>" icon. Is this a component that has not been open sourced yet?

The behavior wasn't abstracted in the v0.x version. It's hard coded in the source. We exposes a Collapse component on the v1-beta branch.


Does Not Work With Visual Studio Code

Downloaded the program and installed it. Works flawlessly everywhere else but simply stops working in visual studio code. Once in visual studio code no sounds are produced. Any one else having the same issue?

Correction: I am working with a terminal emulator (cmder). When start visual studio code from the emulator / terminal by typing "code" Mechvibes doesn't work. However when I start it from the command prompt it works just fine.

try open Mechvibes as Admin, I think it will work as you want

That did the trick. It worked. Able to get the sounds now. Awesome, Thanks so much for your help with this!


The application should notify the user if the PDF download fails

When the application fails to download a file when importing an entry via the JabRef browser extension, then it should notify the user about the failure. The notification should follow the procedure mentioned here.
The notification should not contain logs or any technical related messages, just a simple "heads up" about the failure for the user.

This is implemented as of #7

To clarify, we chose to warn the user when JabRef downloads a PDF file.


Restore registry cache for faster cargo update

This is an attempt to further speed up the CI times.
We now restore a cache from previous runs before running cargo update, which should (in theory) reduce the time to run the command, because the registry is already downloaded.
We'll have to see if this actually makes things faster.

Hmm, I don't think this gives a noticeable improvement.


Merging new slabs in

Changes:

shapeless slabs, which allow for typesafe pipelines.
extraction of said slabs to https://github.com/reactormonk/epic
porting epic to the new slabs

The shapeless slabs are made possible via implicits from shapeless and
scalaz. In case of "implicit missing" make sure scalaz.std.list._
and epic.slab.typeclasses._ are imported.
The slabs use List as the standard collection container instead of
Vector, which creates a few API mismatches between epic and the slabs.
They have been fixed.
To avoid circular dependency, the Spans have been copied over to slabs
as well. The interoptability is defined in
https://github.com/reactormonk/epic/blob/master/src/main/scala/epic/trees/Span.scala#L81-L84
which should be a noop, because both are value classes.
Manual merging required. :-(

You might want until I fix everything at https://github.com/reactormonk/epic-slab/labels/upstream merge
How should I publish epic-slab? I don't have access to org.scalanlp.

@dlwh has some additional data models in mind which aren't publishable atm, so this PR will not be merged.


Add a script to create the core bundle

This script should start from a package.json file with jupyterlab metadata and produce assets.

It should roughly mirror what is in the core_package folder right now

It will be used in dev_mode in the core repo as a script in buildutils, which will be folded in to the static assets for release

This is one entry point that still uses module federation so the constituent modules can be shared with extensions

input is all of the packages (maybe use metapackage)

output is a set of webpack output files in dev_mode, which includes a remote entry point for other extensions to import tokens, etc.

Sharing react, react-dom, lumino, and jupyterlab packages (everything we currently list as a singleton)

Rules for core:

Will include all imported dependencies in package.json as shared
Will include singletons using current logic
Nothing needs to change in dev_mode/package.json generation for now

We do need to change dev_mode/package.json to include all of the core packages, so we get their version info for module federation.

Left to do:

Use modified versions of ensureJupyterLab here to create the package.json from @jupyterlab/metapackage.


[BUG] Disconnect-PnPOnline throws error related to certificates

Reporting an Issue or Missing Feature
Issue
Expected behavior
Disconnect-PnPOnline works without error
Actual behavior
Disconnect-PnPOnline throws an error in PowerShell 7 when connection has been established using a certificate. With PowerShell 5 (5.1.18362.1171) it works without error.
Steps to reproduce behavior

Open PowerShell 7
Create Azure App Registration: Register-PnPAzureADApp -ApplicationName "PnPProv" -Tenant "sometenant.onmicrosoft.com" -DeviceLogin -Out .
Proceed with the registration --> certificate (.cer and .pfx) is placed in the current folder, app registration is created in Azure AD
Connect to SharePoint Online:
$conn = Connect-PnPOnline -ClientId "" -CertificatePath "\pnpprov.pfx" -Url "https://.sharepoint.com/" -Tenant "" -ReturnConnection
Disconnect: Disconnect-PnPOnline -Connection $conn

Running this in PowerShell 7 (using 7.1.2) or in an Azure Function using runtime stack PowerShell Core and Version 7 the following error is thrown:
Disconnect-PnPOnline: Unable to cast object of type 'System.Security.Cryptography.RSACng' to type 'System.Security.Cryptography.RSACryptoServiceProvider'.
The Azure Function outputs some more information including stacktrace:
2021-02-25T16:11:26.475 [Error] ERROR: Unable to cast object of type 'System.Security.Cryptography.RSACng' to type 'System.Security.Cryptography.RSACryptoServiceProvider'.Exception             :Type       : System.InvalidCastExceptionTargetSite :Name          : CleanupCryptoMachineKeyDeclaringType : PnP.PowerShell.Commands.Base.PnPConnectionHelper, PnP.PowerShell, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=nullMemberType    : MethodModule        : PnP.PowerShell.dllStackTrace :at PnP.PowerShell.Commands.Base.PnPConnectionHelper.CleanupCryptoMachineKey(X509Certificate2 certificate) in C:\Users\vanhunen\AppData\Local\Temp\871624b8-a57c-4890-ab73-7fb0ab96fabf\src\Commands\Base\PnPConnectionHelper.cs:line 405at PnP.PowerShell.Commands.Base.DisconnectOnline.ProcessRecord() in C:\Users\vanhunen\AppData\Local\Temp\871624b8-a57c-4890-ab73-7fb0ab96fabf\src\Commands\Base\DisconnectOnline.cs:line 28at System.Management.Automation.Cmdlet.DoProcessRecord()at System.Management.Automation.CommandProcessor.ProcessRecord()Message    : Unable to cast object of type 'System.Security.Cryptography.RSACng' to type 'System.Security.Cryptography.RSACryptoServiceProvider'.Source     : PnP.PowerShellHResult    : -2147467262CategoryInfo          : NotSpecified: (:) [Disconnect-PnPOnline], InvalidCastExceptionFullyQualifiedErrorId : System.InvalidCastException,PnP.PowerShell.Commands.Base.DisconnectOnlineInvocationInfo        :MyCommand        : Disconnect-PnPOnlineScriptLineNumber : 25OffsetInLine     : 1HistoryId        : 1ScriptName       : C:\home\site\wwwroot\InvokePnPSiteTemplate\run.ps1Line             : Disconnect-PnPOnline -Connection $connPositionMessage  : At C:\home\site\wwwroot\InvokePnPSiteTemplate\run.ps1:25 char:1+ Disconnect-PnPOnline -Connection $conn+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~PSScriptRoot     : C:\home\site\wwwroot\InvokePnPSiteTemplatePSCommandPath    : C:\home\site\wwwroot\InvokePnPSiteTemplate\run.ps1InvocationName   : Disconnect-PnPOnlineCommandOrigin    : InternalScriptStackTrace      : at , C:\home\site\wwwroot\InvokePnPSiteTemplate\run.ps1: line 25Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcException : Result: ERROR: Unable to cast object of type 'System.Security.Cryptography.RSACng' to type 'System.Security.Cryptography.RSACryptoServiceProvider'.Exception             :Type       : System.InvalidCastExceptionTargetSite :Name          : CleanupCryptoMachineKeyDeclaringType : PnP.PowerShell.Commands.Base.PnPConnectionHelper, PnP.PowerShell, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=nullMemberType    : MethodModule        : PnP.PowerShell.dllStackTrace :at PnP.PowerShell.Commands.Base.PnPConnectionHelper.CleanupCryptoMachineKey(X509Certificate2 certificate) in C:\Users\vanhunen\AppData\Local\Temp\871624b8-a57c-4890-ab73-7fb0ab96fabf\src\Commands\Base\PnPConnectionHelper.cs:line 405at PnP.PowerShell.Commands.Base.DisconnectOnline.ProcessRecord() in C:\Users\vanhunen\AppData\Local\Temp\871624b8-a57c-4890-ab73-7fb0ab96fabf\src\Commands\Base\DisconnectOnline.cs:line 28at System.Management.Automation.Cmdlet.DoProcessRecord()at System.Management.Automation.CommandProcessor.ProcessRecord()Message    : Unable to cast object of type 'System.Security.Cryptography.RSACng' to type 'System.Security.Cryptography.RSACryptoServiceProvider'.Source     : PnP.PowerShellHResult    : -2147467262CategoryInfo          : NotSpecified: (:) [Disconnect-PnPOnline], InvalidCastExceptionFullyQualifiedErrorId : System.InvalidCastException,PnP.PowerShell.Commands.Base.DisconnectOnlineInvocationInfo        :MyCommand        : Disconnect-PnPOnlineScriptLineNumber : 25OffsetInLine     : 1HistoryId        : 1ScriptName       : C:\home\site\wwwroot\InvokePnPSiteTemplate\run.ps1Line             : Disconnect-PnPOnline -Connection $connPositionMessage  : At C:\home\site\wwwroot\InvokePnPSiteTemplate\run.ps1:25 char:1+ Disconnect-PnPOnline -Connection $conn+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~PSScriptRoot     : C:\home\site\wwwroot\InvokePnPSiteTemplatePSCommandPath    : C:\home\site\wwwroot\InvokePnPSiteTemplate\run.ps1InvocationName   : Disconnect-PnPOnlineCommandOrigin    : InternalScriptStackTrace      : at , C:\home\site\wwwroot\InvokePnPSiteTemplate\run.ps1: line 25Exception: Unable to cast object of type 'System.Security.Cryptography.RSACng' to type 'System.Security.Cryptography.RSACryptoServiceProvider'.Stack:    at PnP.PowerShell.Commands.Base.PnPConnectionHelper.CleanupCryptoMachineKey(X509Certificate2 certificate) in C:\Users\vanhunen\AppData\Local\Temp\871624b8-a57c-4890-ab73-7fb0ab96fabf\src\Commands\Base\PnPConnectionHelper.cs:line 405at PnP.PowerShell.Commands.Base.DisconnectOnline.ProcessRecord() in C:\Users\vanhunen\AppData\Local\Temp\871624b8-a57c-4890-ab73-7fb0ab96fabf\src\Commands\Base\DisconnectOnline.cs:line 28at System.Management.Automation.Cmdlet.DoProcessRecord()at System.Management.Automation.CommandProcessor.ProcessRecord()
What is the version of the Cmdlet module you are running?
PnP.PowerShell 1.3.0
Which operating system/environment are you running PnP PowerShell on?

[ x] Windows
[ ] Linux
[ ] MacOS
[ ] Azure Cloud Shell
[ x] Azure Functions
[ ] Other : please specify

Hi,
We have fixed this in the current nightly builds. It will of course also available in version 1.4 which will most likely to be released next week.
On a side node: it's rarely if at all needed to use Disconnect-PnPOnline. If your script does multiple Connect-PnPOnline calls to different sites, executing a new Connect-PnPOnline will do all the work for you. We're not physically disconnecting, we're just reinitializing internal variables in Disconnect-PnPOnline, but that also happens when you use Connect-PnPOnline.
As an added benefit, if you do -not- disconnect we will not clear the internal token cache and if you connect to the same tenant you will not be prompted again for authentication or in the case of an app-only connection with a certificate we will not have to do the auth handshake if there is a valid token in the cache.
E.g.
# this will call out to the Azure AD to acquire an access token
Connect-PnPOnline -Url 'https://contoso.sharepoint.com/sites/demo1' -ClientId [id] -CertificatePath [path]
Disconnect-PnPOnline # we clear the token cache
 # this will call out again to the Azure AD to acquire an access token
Connect-PnPOnline -Url 'https://contoso.sharepoint.com/sites/demo2' -ClientId [id] -CertificatePath [path]

vs.
# this will call out to the Azure AD to acquire an access token
Connect-PnPOnline -Url 'https://contoso.sharepoint.com/sites/demo1' -ClientId [id] -CertificatePath [path]
# we will recognize you're connecting to the same tenant and if there is an
# access token previously acquired that is still valid, it will be used towards the other site.
Connect-PnPOnline -Url 'https://contoso.sharepoint.com/sites/demo2' -ClientId [id] -CertificatePath [path]

The token cache is in memory and lives during the current PowerShell session. E.g. closing PowerShell will also clear this cache.


Use Compatibools for IgnoreIfSet input.

Right now it is impossible to set this field to true up in Fastly since it is sending up 'true' strings, which fastly will silently translate to '0'. This change fixes that.
Note that if anyone is using this lib is setting this field to true, this change will make that actually happen, which may result in unexpected consequences.

Ping @catsby - this okay?

It is! Thanks @alienth


[For Discussion] Premature removal of encryption keys record prevents a valid 'late filer' scenario.

https://github.com/cds-snc/covid-shield-server/blob/2273ef9e39414c55baefac98b9a3fde401dc582f/pkg/persistence/queries.go#L25
https://github.com/cds-snc/covid-shield-server/blob/9686d9b0b698a41a5ce379b5a6a11ad6cc22ebdd/pkg/config/config.go#L59
Because of the way the 28 day window for submission works, from -14 days from day0_test to +14 days, the period from +14 to +28(ish) should still be valid and allow them to submit keys late, assuming they are within the period of -14 to +14.

Note: We would require the P/T's to submit 'dateOfTest' for this to be valid,

cc: @jeffmaher

cc: @emilykuret For your 👀
Closing as I'm being overly pedantic, and the app won't actually allow this functionality as is. Traceback duration may affect this, but it's still overly pedantic, even for me. :)