fixed integration tests and examples with dsn args

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Other information

Codecov Report
Base: 62.84% // Head: 62.83% // Decreases project coverage by -0.02% :warning:

Coverage data is based on head (c5b4fe6) compared to base (158b2e4).
Patch coverage: 50.00% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #593      +/-   ##
==========================================
- Coverage   62.84%   62.83%   -0.02%
==========================================
  Files         228      228
  Lines       21768    21778      +10
==========================================
+ Hits        13681    13685       +4
- Misses       7391     7401      +10
+ Partials      696      692       -4

Flag
Coverage Δ

1.16.x
62.54% <50.00%> (+0.18%)
:arrow_up:

1.19.x
62.69% <50.00%> (+0.12%)
:arrow_up:

1.20.x
62.54% <50.00%> (-0.14%)
:arrow_down:

insecure
52.86% <50.00%> (-0.07%)
:arrow_down:

integration
53.39% <50.00%> (+0.01%)
:arrow_up:

macOS-latest
44.38% <0.00%> (-0.03%)
:arrow_down:

secure
53.24% <50.00%> (-0.07%)
:arrow_down:

ubuntu-latest
62.80% <50.00%> (-0.04%)
:arrow_down:

unit
44.50% <0.00%> (-0.01%)
:arrow_down:

windows-latest
44.46% <0.00%> (-0.02%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

internal/xsql/conn.go
31.75% <0.00%> (-0.11%)
:arrow_down:

internal/xsql/dsn.go
37.93% <62.50%> (+23.64%)
:arrow_up:

bind/bind.go
0.00% <0.00%> (-100.00%)
:arrow_down:

internal/wait/wait.go
28.57% <0.00%> (-25.00%)
:arrow_down:

sql.go
39.06% <0.00%> (-3.13%)
:arrow_down:

internal/balancer/connections_state.go
97.11% <0.00%> (-2.89%)
:arrow_down:

internal/xerrors/operation.go
69.62% <0.00%> (-2.54%)
:arrow_down:

internal/table/client.go
85.03% <0.00%> (ø)

...al/topic/topicwriterinternal/writer_reconnector.go
80.40% <0.00%> (+0.66%)
:arrow_up:

internal/table/session.go
82.01% <0.00%> (+0.82%)
:arrow_up:

... and 3 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Error: Could not find file "events.js" in getValidSourceFile during getApplicableRefactors

tsserver version: 2.6.1
Hits: 129436
Error: Could not find file: 'c:/.../src/events.js'.
    at getValidSourceFile (tsserver.js:79635:23)
    at Object.getApplicableRefactors (tsserver.js:80231:24)
    at IOSession.Session.getApplicableRefactors (tsserver.js:86474:53)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (tsserver.js:85436:61)
    at tsserver.js:86669:88
    at IOSession.Session.executeWithRequestId (tsserver.js:86660:28)
    at IOSession.Session.executeCommand (tsserver.js:86669:33)
    at IOSession.Session.onMessage (tsserver.js:86689:35)
    at Interface.<anonymous> (tsserver.js:87881:27)
    at emitOne (events.js:96:13)
    at Interface.emit (events.js:191:7)
    at Interface._onLine (readline.js:241:10)
    at Interface._normalWrite (readline.js:384:12)
    at Socket.ondata (readline.js:101:10)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at Pipe.onread (net.js:560:20)

This may be an editor error; note the unusual path c:/.../src/events.js. Note that we call toNormalizedPath in getFileAndProjectWorker. However, I don't expect this would be a bug in normalizePath -- it's not going to synthesize c:\ out of nothing if the input was a relative path. @aozgaa I know you answered already but I forgot, what editor are these from?

VSCode.

@mjbvz Is there anyway vscode might have ended up asking for this path?

@andy-ms Perhaps. Is this only seen for getApplicableRefactors though? Our refactor provider calculates paths the same way as our other providers. Do you have repo steps for this issue?

Unfortunately all we have is telemetry result. But the linked issues #21791 #21795 #21813 happen in different services, not just refactors.

Closing for now.

I'm running into this error pretty consistently when using the Tide Plugin for Emacs.
TypeScript/ Tsserver Version: 3.2.1
Error: Could not find file: '/home/mparsons/Work/develop/admin-frontend/assets/js/src/app/apps/Signage/resources/Schedule/components/form-handler.component.ts'.
at getValidSourceFile (/home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:117219:23)
at Object.getSyntacticDiagnostics (/home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:117412:52)
at /home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:124988:126
at IOSession.Session.getDiagnosticsWorker (/home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:124846:35)
at IOSession.Session.getSyntacticDiagnosticsSync (/home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:124988:29)
at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (/home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:124389:61)
at /home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:125836:88
at IOSession.Session.executeWithRequestId (/home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:125827:28)
at IOSession.Session.executeCommand (/home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:125836:33)
at IOSession.Session.onMessage (/home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:125858:35)
at Interface. (/home/mparsons/Work/develop/admin-frontend/node_modules/typescript/lib/tsserver.js:127118:27)
at emitOne (events.js:116:13)
at Interface.emit (events.js:211:7)
at Interface._onLine (readline.js:280:10)
at Interface._normalWrite (readline.js:422:12)
at Socket.ondata (readline.js:139:10)
at emitOne (events.js:116:13)
at Socket.emit (events.js:211:7)
at addChunk (_stream_readable.js:263:12)
at readableAddChunk (_stream_readable.js:250:11)
at Socket.Readable.push (_stream_readable.js:208:10)
at Pipe.onread (net.js:597:20)
File exists and the path is valid:
$ ls /home/mparsons/Work/develop/admin-frontend/assets/js/src/app/apps/Signage/resources/Schedule/components/form-handler.component.ts
/home/mparsons/Work/develop/admin-frontend/assets/js/src/app/apps/Signage/resources/Schedule/components/form-handler.component.ts

The same here.


Connection Issue

Website is not running even though internet connection is fine.

Does anyone know how to solve this issue?

So this isn't strictly a connection issue, note the bar at the bottom of the screen. There's some error happening which is likely causing the whole connection process to abort.
You can try to hit F12 in your browser and open the "Dev tools", in theory it would look something like this:

I'd need to know what the error(s) are because I can't see those from the server.

I see this when I go to the developer mode:

I noticed the "display: block;" was highlighted when I refresh the page

So that's close to what I need, I need what's in that panel at the bottom, where all the red-text with a pink-background though it's partially cut off. You can also go to the "Console" tab at the top top make that section full-screen.
Odd thing is it does sort of look like it's a connectivity problem based on what I can see... maybe some issue connecting to the SignalR hub even though you can connect to the website itself (the hub is what does the real-time updates to the browser from other users).

Does this work?

Yup, though that's a bit weird since it looks like a DNS lookup failed.
What do you see if you try to go to this URL? Should be a mostly blank page that says connection ID required.
https://hub.xeio.synology.me/Merchant

Actually it tells me that site cannot be reached.

Ok, so something is wrong with your DNS server, I assume you're just using the default that your ISP provides?
It should be finding something like this:
https://dns-lookup.com/hub.xeio.synology.me

Yeah, sometimes it's working but other times it's not.  Here is a screenshot of the developer page when the site is working:

Firefox can’t establish a connection to the server at wss://hub.xeio.synology.me/MerchantHub.

Can you let me know if this is working now? Had to flip to the full chain cert to enable that.

I enabled OCSP again, will be able to give feedback on this as time passes.

I confirm it is working now on firefox.

Sounds good.
Oddly enough can't get SSL stapling to work on the test deployment site which is served from the save nginx instance... but since nobody but me should care about that one I'm just going to close this again, hopefully for good.


Preset conflict with specific rule

Hi,
this game follow a kind of  "work as intended" scenario that prioritize the game preset over the specific sub-rule.
So, for example, if GAME_PRESET is set to "StandardPvE" and then a specific rule is set to the file ServerGameSettings.json (like  "TeleportBoundItems": false) the preset rule prevails over it.
To avoid this it should be possible to not pass  -preset and -difficultyPreset in the entrypoint.sh.
My suggestion, to mantain retrocompatibility,  is to avoid to pass the specific parameters only if GAME_PRESET and/or DIFFICULTY are explicitly set to an empty string.

Yeah I can make that change. Honestly this was just something I threw together quite quick for my own use. Might take me a few days to get to it, but I'll get it done.


step010: adapter NotFound

Hi,
I'm on step010. After build succeeded I ran into this error when running the executable (with my custom logging):
WGPU instance: 0x417ed0
init!
window:0x426060
surface: 0x47c2b0
Requesting adapter...
Could NOT get WebGPU adapter: NotFound
Got adapter: 0
thread '<unnamed>' panicked at 'invalid AdapterId', src/lib.rs:186:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
[1]    28012 IOT instruction (core dumped)  ./build/src/App

Basically the error is Could NOT get WebGPU adapter: NotFound. So it successfully initialized window, found the surface, but somehow an adapter could not be found/initialized?
I'm using wgpu-native, built for Wayland on an Intel graphics laptop. I'm not sure whether it's my code (basically same as yours), or Wayland, or wgpu-native, or the graphics card itself is causing this error. Any help would be greatly appreciated. Thank you!

Okey the problem is that I did not wire Wayland up properly in glfw3webgpu, but there is an easy fix: in glfw3webgpu.c line 47 switch the default WGPU_TARGET to WGPU_TARGET_LINUX_WAYLAND instead if WGPU_TARGET_LINUX_X11.
Sorry I did not spend time looking for a way to automate this because once this is integrated in upstream GLFW I can use GLFW macros (well actually I could use them already, btu hopefully it will soon get merged to I'll do an update of all branches when that happens).

Hey @eliemichel thanks for the quick reply! However I already changed WGPU_TARGET to WGPU_TARGET_LINUX_WAYLAND myself because otherwise it wouldn't compile. cmake build would give me errors. The adapter NotFound error happens after I made the change, during runtime.

Does the adapter initialize well if you don't specify a surface? (adapterOpts.compatibleSurface = nullptr;)

@eliemichel Hey, somehow it works now. Not sure what changed, but it's very likely because I pulled in Vulkan dependencies like I did here.
Surprisingly, when enumerating adapter features, wgpu-native's output is tidier than dawn. Here is the features output I got using wgpu-native:
Adapter features:
 - 1
 - 2
 - 3
 - 4
 - 5
 - 6
 - 7
 - 8
 - 9
 -<PHONE_NUMBER>
 -<PHONE_NUMBER>
 -<PHONE_NUMBER>
 -<PHONE_NUMBER>
 -<PHONE_NUMBER>

and those large numbers at the bottom also differ from the 1002s I got from dawn. Also, there is no warning here, though I got warnings using dawn.

Closing this issue since issue fixed. Thanks!

These large numbers are backend-specific features. They are intentionnally starting at different offsets to avoid conflict, more details here ;)


Chef 15: knife bootstrap without --bootstrap-version option fails

Description
If we run the knife bootstrap without --bootstrap-version option, It looks for the stable/15 version of the chef-client. But we don't have the latest stable version available.
Output:

Omnitruck artifact does not exist for version 15 on platform ubuntu
Either this means:

We do not support ubuntu
We do not have an artifact for 15

Chef Version
Chef Infra Client: 15.0.266
Platform Version
Ubuntu 18.04
Replication Case
knife bootstrap user@ip -P password -N test-node  --sudo
Client Output

Omnitruck artifact does not exist for version 15 on platform ubuntu
Either this means:
We do not support ubuntu
We do not have an artifact for 15

Stacktrace

This is expected.  You can use the deprecated --prerelease flag or specify --channel current to pull in the latest versions of chef.

This is expected.  You can use the deprecated --prerelease flag or specify --channel current to pull in the latest versions of chef.


No notification its running, no results with intentionally misspelled words

There's basically nothing happening. Any help?

Finding that the plugin only works sometimes with no indication that the spell check runs. I also intentionally misspelled words that the plugin misses.

I'm pretty surprised by this. Can you upload your debug logs somewhere I can get to them?
Is this still happening to you?

This was a problem with a little notification that wasn't showing up anymore. Should be fixed as of 1.3.1.

Yep - looks like it’s working now! Thanks for taking care of this.
Rob

On Jun 13, 2019, at 3:53 AM, Sean Rice<EMAIL_ADDRESS>wrote:
This was a problem with a little notification that wasn't showing up anymore. Should be fixed as of 1.3.1.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.


Only first 4 characters are displayed!

When I add more characters (#11), only the first 4 characters on each side are displayed (in any browser)!
When I inspect the page all the HTML elements appear to be there, so maybe this is a CSS issue?
See this branch.

So, um....yeeeeaaaaahhhh.


acorn rm is confusing and doesnt do what i need it to

acorn rm app-foo

deletes the app named app-foo, but leaves the secrets it created behind
so i thought, if i do
acorn rm --all app-foo

or
acorn rm --secrets app-foo

those would delete the app and the created secret.
I guess acorn rm is for deleting different types of resources, so --secret is to delete just a secret and --volume is to just delete a volume.
So, I'm missing a single command that will delete an app and the resources it generates

@ibuildthecloud:

We want to go with what you suggested and then change the flags on rm to support recursive delete so that you can delete the app+volume+secrets if you want. So “acorn rm -rf app” would be recursive force delete. And add a —type flag that defaults to “app,container” so you can add volume,secret,image or “all”.
So we with have the UX you explained and then a cleaned upped rm UX that makes a bit more sense.

Just to add on that. Currently to delete an app, image, volume, ... we need to use the acorn rm command with a flag corresponding to the resource we want to delete (except for app). I thing that could be nice to have the possibility to delete resources directly with acorn image rm , acorn volume rm ,... this approach is already possible with secrets.

tested. looks good. 👍
I opened this as a follow up issue: https://github.com/acorn-io/acorn/issues/899


HumanEval Benchmark

This PR contains:

[x] New features
[ ] Changes to dev-tools e.g. CI config / github tooling
[ ] Docs
[ ] Bug fixes
[ ] Code refactor

What is the current behavior? (You can also link to an open issue here)
The package currently does not support the HumanEval benchmark.
What is the new behavior?
Implementation of the HumanBench benchmark using asynchronous subprocess launches for code-generation validation.
The benchmark can be run using the following command:
inspect eval benchmarks/humaneval/humaneval.py --model openai/gpt-4o --sandbox local

The PR has been validated against the results from gpt-4o and matches full benchmark results.
               | Accuracy | pass@1:mean | pass@1:std | pass@2:mean | pass@2:std | pass@5:mean | pass@5:std |
|--------------|----------|-------------|------------|-------------|------------|-------------|------------|
| simple-evals |    0.916 |       0.916 |      0.243 |       0.938 |      0.225 |       0.951 |      0.243 |
| Inspect      |    0.894 |       0.894 |      0.254 |       0.932 |      0.217 |       0.957 |      0.203 |

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No breaking changes. The PR is a self-contained implementation of the benchmark.

Thank you!!!


Errors after responses update to 0.19.0

Hey,
First off, thanks for the work you input on this very useful project.
I am seeing a new issue when using moto[s3] in my unit tests.  Not sure exactly what is it related to, mayne the usage of get_response_mock() method...or so it seems.
Let me know if you need any further info or tests on my side. Thanks!

Somewhat shorter code to reproduce this:
python3.9.2
boto3==1.21.13
moto==3.0.6
pytest==7.0.1
(and responses==0.19.0)
import boto3
from moto import mock_s3

@mock_s3
def get_fake_bucket_resource():
    return boto3.resource('s3', region_name='us-east-1')

@mock_s3
def test_get_fake_bucket_instance(bucket_name='test-bucket'):
    resource = get_fake_bucket_resource()
    bucket = resource.create_bucket(Bucket=bucket_name)
    res2 = get_fake_bucket_resource()

note that removing @mock_s3 decorator from get_fake_bucket_resource() results in the lack of the above error

Just to add on that, this update is affecting CI tests since the newest version is fetched as dependency unless you explicitly set 'responses' to anything less than 0.19.
So a quick fix for anyone that needs the erratic behavior to solve is adding to your requirements (make sure to get back to this issue and check for a definite fix):
responses==0.18

Thanks for raising this @papierukartka. Will push a fix for this shortly

This should now be fixed as of moto >= 3.0.7.dev2. Please let us know if you're running into any more issues!

This should now be fixed as of moto >= 3.0.7.dev2. Please let us know if you're running into any more issues!

Thanks for this - my team has been dealing with this all day. Is 3.0.7.dev2 out yet? I'm not able to install that version yet.

@jwilmott It is on PyPi! https://pypi.org/project/moto/3.0.7.dev2/

Do you have a schedule for when it might get to a stable release?

@tduque-electric Moto 3.0.7 was released just now: https://pypi.org/project/moto/3.0.7/ :+1:

Thanks to all and sorry for late answer. Updating moto to 3.0.7 solved the issue :)

Facing the same issue as
cls = <class 'jinja2.environment.Template'>, args = ()
def __newobj__(cls, *args):

  return cls.__new__(cls, *args)

E       TypeError: new() missing 1 required positional argument: 'source'
/usr/local/lib/python3.9/copyreg.py:95: TypeError
Updating moto version to 3.0.7 also not worked for me. Can any body suggest ??

Issues still exists with moto 4.0.11


from/into stream

This adds Stream counterparts to FromIterator, IntoIterator and Iterator::collect, allowing to use the same patterns that are common in streams. Thanks!
Tasks

[x]  FromStream
[x] IntoStream
[x] Stream::collect

Screenshot

Okay, so interesting fact here: if we actually want to provide implementations for collect here we'll have to add at least the vec, and probably also the collections submodules to hold the various IntoStream types (e.g. like vec's https://doc.rust-lang.org/std/vec/struct.IntoIter.html).
I won't add it as part of this patch, but it seems like something that we should enumerate if we land this, and probably would make for a good issue to onboard folks with!

Noticed another thing:

futures-rs implements Stream for VecDeque directly: https://docs.rs/futures-preview/0.3.0-alpha.18/futures/stream/trait.Stream.html#foreign-impls
Iterator isn't available on VecDeque, instead IntoIterator is implemented for it: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#implementations

This not only applies to VecDeque, but Vec as well (implements Stream directly). I'm uhhh, feeling like we're going in the right direction here.
Ideally we could also expose stream / stream_mut methods on the collections, but I think that might be more trouble than is worth it.

I've gone ahead and also implemented Stream::collect. Usage example:
use async_std::prelude::*;
use async_std::stream;

let s = stream::repeat(9u8).take(3);
let buf: Vec<u8> = s.collect().await;

assert_eq!(buf, vec![9; 3]);

I couldn't figure out the right trait bounds using static futures, so I just did a box bound on it. It shows up as DynFuture in the doc output. Hope that's okay!

@stjepang could you push your changes from last Tuesday if you have time?

@yoshuawuyts I have pushed the changes into stjepang/async-std (branch into_stream_trait) since I don't have permissions to push into your fork.

I had restore all the Send bounds that were removed in stjepang/async-std because the tests were failing (even if the code did compile). We've been able to keep the Unpin bounds out though. This patch should be all good now. Thanks!

Also note from private chat: we should introduce this feature behind the "unstable" flag.

All feedback implemented; talked about this and we're happy to try this out as "unstable" :tada:
bors r+


How to use the calibration file extracted by ur_calibration

I am using galactic branch.
Is it the right way of using calibration file by specify the arg kinematic_config with ros2 launch ur_bringup ur_control.launch.py ur_type:=ur5e use_fake_hardware:=false launch_rviz:=false initial_joint_controller:=joint_trajectory_controller robot_ip:=<robot_ip> kinematics_config:=${HOME}/my_robot_calibration.yaml

This would be the official way. Or even better, you create your description package and recreate the structure of description package and add parameters for your scenario

Since the issue is pretty old, I will close it.
Also Galactic is EOL, but for Humble and on this issue could be useful for the question.


Add toggle for manage dashboard

Use Case
As a user I want to have only the telegraf agent managed along with auth to pe,
so that I can have pe infra nodes logging to a central influxdb,
and a dashboard that provides a centralised view of all pe servers in a single place.
Currently the module assumes infra agents intending to log to influxdb will host their own dashboard:
https://github.com/puppetlabs/puppet_operational_dashboards/blob/a89c556a6785d20219d85ad029cffc506af1d26c/manifests/init.pp#L126-L132
Describe the Solution You Would Like
add a feature toggle for the dashboards profile somewhere.
Describe Alternatives You've Considered
Managing with a profile wrapper and hiera data:
# dashboard_agent.pp
    if $agent_only {
      include 'puppet_operational_dashboards::telegraf::agent'
    } else {
      include puppet_operational_dashboards
    }

# common.yaml
profile::dashboard::agent_only: true
puppet_operational_dashboards::manage_influxdb: false
puppet_operational_dashboards::manage_telegraf_token: false
puppet_operational_dashboards::profile::dashboards::manage_grafana: false

# roles/dashboard.yaml
profile::dashboard::agent_only: false
puppet_operational_dashboards::manage_influxdb: true
puppet_operational_dashboards::profile::dashboards::manage_grafana: true
puppet_operational_dashboards::manage_telegraf_token: true
puppet_operational_dashboards::telegraf_token: ~
lookup_options:
  puppet_operational_dashboards::telegraf::agent::token:
    convert_to: "Undef"
puppet_operational_dashboards::telegraf::agent::token: ~

Additional Context

hi @zoojar
Is this not infact how it currently works?
As it stands we classify all infrastructure nodes with the class:
puppet_operational_dashboards::enterprise_infrastructure, this does the authorisation and shipping of the data to a singular influxdb data source
and then we select a singular node to be the grafana host which views the common influxdb data source all the infrastructure nodes ship too:
by adding the class:
puppet_operational_dashboards

hi  @MartyEwings  thank you! I re-think this!


交互式日历视图在0.11.1取消了，其实这个功能还挺好的

Is your feature request related to a problem?
交互式日历视图在0.11.1取消了，其实这个功能还挺好的，作为日记使用的时候可以非常方便的看到之前一天的内容。也挺好看的
Describe the solution you'd like
或许可以增加个开关来打开或关闭交互式日历视图，如果不能添加，可以在每日回顾里对有记录的日期进行作色突出显示

Additional context
No response

I also miss this feature.

I also miss that heatmap, it really provided me with a lot of motivation to record memos. I hope there could be a switch that allows us to set whether or not to display the recording heatmap.

I also miss that heatmap, it really provided me with a lot of motivation to record memos. I hope there could be a switch that allows us to set whether or not to display the recording heatmap.

Additionally, I hope there can be a switch to enable or disable the "Ask AI" feature. On one hand, some users (like myself) may not want to use AI assistance in their memos. On the other hand, OpenAI is inaccessible for users in certain regions.


[EN] Feedback for: /web/shows/udacity/?hl=en

Adding https://www.udacity.com/course/building-high-conversion-web-forms--ud890 to the courses page.

@greenido - Did you do this already?

Closing due to age, feel free to re-open if action is required.


Largest cone that can be inscribed within a cube

fix #2424
Largest cone that can be inscribed within a cube

@sairish2001 resolved merge conflicts


Can not update some packages, because this package requires guzzlehttp/guzzle ^6.0 and not ^7.0

Description
Due to some conflics with guzzlehttp/guzzle version I cannot update other packages like google/cloud.
php-http/guzzle6-adapter v2.0.2 requires guzzlehttp/guzzle ^6.0
Possible Solution
Please add guzzlehttp/guzzle ^7.0 to the composer dependencies.

sorry I am stupid ;) there is a php-http/guzzle7-adapter :)

can confirm the second. not the first, you noticed yourself how to solve the problem :+1:


Get values of IPFIX IP addresses in human readable format..

Hi there..
I'm trying around with the goflow2, kafka, clickhouse pipeline and I'm searching for a way to make the IP adresses of the inserted IPFIX flows human readable. Maybe it is a question more related to Clickhouse, but I want to try my luck here as well ;)..
As seen in flow.proto protobuf schema the datatypes of the fields with IP adresses are bytes format. But that is not really handy for me to save it in CH database, because I don't know how to read/make use of the byte objects in selects in DB usage. If I use the DB Pipeline tutorial I saw the CH DB column for that is fixed_string(16) but with that I got also byte objects in DB table.
--- snip ----
// Sampler information
bytes SamplerAddress = 11;
// Found inside packet
uint64 TimeFlowStart = 38;
uint64 TimeFlowEnd = 5;
uint64 TimeFlowStartMs = 63;
uint64 TimeFlowEndMs = 64;
// Size of the sampled packet
uint64 Bytes = 9;
uint64 Packets = 10;
// Source/destination addresses
bytes SrcAddr = 6;
bytes DstAddr = 7;
---- snap ---
My tries to change the format in flow.proto  ( SrcAddress, DstAddress, SamplerAdress ) to string ( because I think the docker container compile the Proto format file at startup ? ) ended up with byte objects in the specific columns of the CH DB.
That are the DB schema to read from KAFKA:
CREATE TABLE IF NOT EXISTS sisr_dev.kafka_raw_goflow2_test1_proto_ipfix_consumer ON CLUSTER "dev-ch-cluster" (
Samplingrate UInt64,
SequenceNum UInt32,
SrcAddr String,
DstAddr String,
Bytes UInt64,
Packets UInt64,
SamplerAddress String,
NextHop String,
Proto UInt32,
SrcPort UInt32,
DstPort UInt32,
SrcMac UInt64,
DstMac UInt64,
Etype UInt32,
TimeFlowStart UInt64,
IngressVrfID UInt32,
TimeFlowStartMs UInt64,
TimeFlowEndMs UInt64,
)
ENGINE = Kafka ()
SETTINGS kafka_broker_list =
[kafka_broker]
kafka_topic_list = 'goflow2_test1_raw_ipfix_proto',
kafka_group_name = 'goflow2_raw_ch_kafka', kafka_num_consumers = 8,
kafka_thread_per_consumer = 4,
kafka_format = 'Protobuf',
kafka_schema = 'flow.proto:FlowMessage',
kafka_skip_broken_messages = 1
Data will be written correctly into database.. everything is working like a charm excluding the thing with the byte format ip addresses..
Does anybody can help me ? Or has a example for better understanding and usage of the data ?
best regards and thanks ..
Christian

Hi Christian,
Try using the following to render an IP address stored as bytes into a readable string.
if(EType = 0x800, IPv4NumToString(reinterpretAsUInt32(substring(reverse(SrcAddr), 13,4))), IPv6NumToString(SrcAddr))

Let me know if that works!

Hi, thanks for the fast answer.. :)..
That query seems to work yeah:
SELECT IPv4NumToString(reinterpretAsUInt32(substring(reverse(SrcAddr), 13,4))) as src_ip4, IPv6NumToString(SrcAddr) as src_ip6 FROM sisr_dev.flows_raw_dview;
I changed the if(Etype .. version a little bit, because it only gives me only IPv6.. ( below a snapshot of the output of the select )
--- snip ----
│ <IP_ADDRESS>       │ ::                                      │
│ <IP_ADDRESS>       │ ::                                      │
│ <IP_ADDRESS>       │ ::                                      │
│ <IP_ADDRESS>       │ ::                                      │
│ <IP_ADDRESS>       │ ::                                      │
│ <IP_ADDRESS>       │ ::                                      │
│ <IP_ADDRESS>       │ ::                                      │
│ 42.11.244.xx │ 2a0b:f4c2:xx::xx        │
│ <IP_ADDRESS>       │ ::                                      │
│ <IP_ADDRESS>       │ ::                                      │
│ 32.1.77.xx   │ 2001:4de0:ac10::xx:xx:xx                  │
│ <IP_ADDRESS>       │ ::                                      │
│ <IP_ADDRESS>       │ ::                                      │
│ <IP_ADDRESS>       │ ::                                      │
-------- snap ---
But I'm wondering that so much rows have no IP address.. because I'm testing with a static tcpdump to compare with other tools and with pmacct and json I get for all my IPfix packages an src_ip and dst ip
I didn't tried it with goflow2 and json.. ( I will do ) maybe it is the same in CH destination table.. and it's not a format issue.. but it is a little bit strange. Do you maybe have an idea ?
thanks a lot :)
Best
Christian

Okay I checked if this occurs in json as well and it does..
{"Type":"IPFIX","TimeReceived":1658741332,"SequenceNum":22854725,"SamplingRate":1,"SamplerAddress":"x.x.x.x","TimeFlowStart":1657629118,"TimeFlowEnd":1657629120,"TimeFlowStartMs":1657629118699,"TimeFlowEndMs":1657629120739,"Bytes":2492,"Packets":2,"SrcAddr":"::","DstAddr":"::","Etype":34525,"Proto":17,"SrcPort":443,"DstPort":58829,"InIf":0,"OutIf":0,"SrcMac":"xx:45:xx:69:07:c8","DstMac":"88:xx:09:xx:81:49","SrcVlan":0,"DstVlan":0,"VlanId":0,"IngressVrfID":2,"EgressVrfID":0,"IPTos":0,"ForwardingStatus":0,"IPTTL":0,"TCPFlags":0,"IcmpType":0,"IcmpCode":0,"IPv6FlowLabel":0,"FragmentId":0,"FragmentOffset":0,"BiFlowDirection":0,"SrcAS":0,"DstAS":0,"NextHop":"::","NextHopAS":0,"SrcNet":0,"DstNet":0,"EtypeName":"IPv6","ProtoName":"UDP","IcmpName":""}
I also see that all sampled packages are EtypeName":"IPv6", that is suspicious, because my traffic contains very less IPv6 traffic..
I think there is something strange .. because if I could see an IP address like in my post before I see IPv4 and IPv6 as well which could't be in my opinion.. If I dump the traffic to a textile I can't find that IPs it seems it captures IPv6 only ?
If anybody has an idea what's wrong that would be very helpful.. issue is seen with goflow2 binary and docker container..
best .. and thanks in advance
Christian

I'm assuming this is related to #105.
Let's continue on there.


0.7.3-alpha Breaking Changes

0.7.3-alpha does not work. User creation does not work, encryption doesn't work. Whole app on that version is broken right now. However, 0.7.2-alpha works!

Seems that dart is not reading my environment variables correctly... :hankey: :facepalm:


Unable to add local modifications to firejail profiles without modifying the derivation

Issue description
Cannot modify firejail configurations for, for example, firefox, because .local file includes are pointed to /nix/store.
Steps to reproduce
nix-env -iA nixos.firejail && grep local /nix/store/*-firejail-*/etc/firejail/firefox.profile
Workaround
Replace includes to .local file to /etc/firejail/{name}.local. Could be done with sed maybe?
Technical details
I don't think it's relevant here, but still...

system: "x86_64-linux"
host os: Linux 4.14.35, NixOS, 18.03.132083.06c576b0525 (Impala)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 2.0
channels(root): "nixos-18.03.132083.06c576b0525"
channels(kisik21): ""
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

Is this still the case? Maybe it depends on profile? If I inspect /nix/store/r766faki9abhsgx18ylrmqkh5ljxk512-firejail-0.9.62/etc/firejail/telegram-desktop.profile I see no hard-coded path to /nix/store, just relative paths plus reference to /etc/firejail/telegram.local. The version of firejail on my system (20.03) is 0.9.62.
I am able to declaratively override things by doing something like:
  # Further restrict Telegram in Firejail
  environment.etc."firejail/telegram.local".text = ''
    whitelist ''${HOME}/Downloads
    whitelist ''${HOME}/Desktop
    whitelist ''${HOME}/.TelegramDesktop
    whitelist ''${HOME}/.local/share/TelegramDesktop
  '';

Overriding using /etc seems to be fixed since this commit, however this means the '*.local' profile paths are now hardcoded to /etc, and the ones in ~/.config/firejail/*.local are thus ignored.
This seems to deviate from the behavior described in firejail wiki:

Therefore the easiest way to add one or more commands to a profile, is to create a .local file in ~/.config/firejail/ and write the new commands to it.

By hardcoding to /etc we are thus breaking the upstream behavior.
Maybe the correct thing to do would be to leave the .local includes without a prefix path at all? Just the file name?

Resolved by #83515.

@yurkobb Looks like the patch was merged after 20.03 was branched.


Bug/fieldshandling

Closes #1139. Fixes handling of config's field in ObjectControl.js where before using field would break the widget.
- Summary
    const { field, forID, classNameWrapper, forList } = this.props;
    const { collapsed } = this.state;
    const multiFields = field.get('fields');
    const singleField = field.get('field');

    if (multiFields) {
      return (

          { forList ? null : <TopBar collapsed={collapsed} onCollapseToggle={this.handleCollapseToggle} /> }
          { collapsed ? null : multiFields.map((f, idx) => this.controlFor(f, idx)) }

      );
    } else if (singleField) {
      return this.controlFor(singleField);
    }

    return
No field(s) defined for this widget
;
  }
}

The singleField being passed on to ObjectControl 's controlFor function wasn't able to be properly parsed. Since the handling of fields was working in a pinch for field, which passed its elements to controlFor using multiFields.map, I passed singleField.first() to controlFor and it fixed the issue.
An alternate could be to have singleField and multiFieldshandled the same way in a single if statement:
if (multiFields || singleField) {
     const fieldsForControl = multiFields ? multiFields : singleField
    return (

          { forList ? null : <TopBar collapsed={collapsed} onCollapseToggle={this.handleCollapseToggle} /> }
          { collapsed ? null : fieldsForControl.map((f, idx) => this.controlFor(f, idx)) }

      );

- Test plan
Behold, the working `field' !

- Description for the changelog
Fixes bug in handling of field.
- A picture of a cute animal (not mandatory but encouraged)
Behold, a small wombat!

Deploy preview for netlify-cms-www ready!
Built with commit f77c82c8bb22d330ba4928c29ad3a54c037d975d
https://deploy-preview-1165--netlify-cms-www.netlify.com

Deploy preview for cms-demo ready!
Built with commit f77c82c8bb22d330ba4928c29ad3a54c037d975d
https://deploy-preview-1165--cms-demo.netlify.com

Thanks for this!
Would you mind updating this to use an if statement as you mentioned? That will fix the UI appearance so the field is wrapped in the draggable box.

@brianlmacdonald did you try typing in the field? Getting errors there, the field stops accepting input after one character. Looks like we're not outputting the kind of value expected.

@erquhart I'll check it out and report back soon!

The problem in handleChangeFor(index) was, again, trying to do something different with field vs fields.
There was a check const parsedValue = (this.valueType === valueTypes.SINGLE) ? newObjectValue.first() : newObjectValue; that would hand onchange parsedValue which was a string, instead of an immutable.js Map . Removing this check and handing the onChange the same value that it yields from fields fixes it. Therefore it wasn't necessary to parse a different value from newObjectValue anymore.
While playing around with all the widgets in kitchen sink, all of them work with this change.
handleChangeFor(index) {
    return (fieldName, newValue, newMetadata) => {
      const { value, metadata, onChange, forID } = this.props;
      const newObjectValue = this.getObjectValue(index).set(fieldName, newValue);
      const parsedMetadata = {
        [forID]: Object.assign(metadata ? metadata.toJS() : {}, newMetadata ? newMetadata[forID] : {}),
      };
      onChange(value.set(index, newObjectValue), parsedMetadata);
    };
  }

Thanks for the quick fix Brian!
Starting to notice a few red flags:

Values entered this way aren't showing up in the preview pane
There are other areas of code that treat a single field value differently than "fields", e.g. the handleAdd function
This change is essentially making "field" identical in output to "fields", except that it only accepts a single value and wraps it in a map, versus just accepting a map - I'm concerned we're wiping out functionality without fully understanding why it was included in the first place

One thing that comes to mind is the resulting data structure. I have a feeling that the list widget was using this to produce an array of values, so we should confirm that the data structure is still the same. I'm guessing it isn't.
We should check an old version of the CMS, maybe pre-1.0, and see how this used to behave.

@erquhart Cool! I'll start doing more detective work. While I'm at it, why don't I add some tests for everything ListControl does, so that the next time there's a change like this it'll get snuffed out quickly.

Testing would be awesome! We definitely need to step up our coverage.

@erquhart I checked out each release of Netlify until eventually arriving at PR #175 where the code was introduced, and field still breaks the widget. I emailed Cassio, who authored the code, (he's my former teacher) to make sure that field is being used as intended. I'll let you know when I hear back.

Alright, cool. I won't be shocked if he doesn't remember, it's been a while :)

@erquhart haven't gotten a response yet. I've sent two emails. How would you like me to proceed?

@erquhart I'll jump back on this, this week. Thanks!

Despite my best efforts to rebase, this went chaotically bad. It was late, I had a minor meltdown, and closed this and did a new pr with #1373.


Create better screw fixation holes

A cylinder would grow outwards from the guide surface then, for example, a smaller diameter cylinder would make a hole for the screw head with a difference boolean operation, then a difference boolean operation for the screw shaft with an even smaller diameter cylinder would be made

The cylinders direction should go from the fiducial over the guideBase to the nearest point of the fibulaModel centerline (only valid for fibula surgical guide)


tests, reporter: If the suite fails, execute the reporter

What this PR does / why we need it:
After all tests finished and all teardown fixtures executed, report
the state of the cluster.
This is useful for cases where all tests pass but the suite fails, due
to one of its teardown cleanups (e.g. waiting for all test namespaces to
be deleted).
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note:
NONE

/test pull-kubevirt-e2e-k8s-1.26-sig-storage
/test pull-kubevirt-e2e-k8s-1.27-sig-storage
/test pull-kubevirt-e2e-k8s-1.28-sig-storage

Error occurred and artifacts collected: https://gcsweb.ci.kubevirt.io/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/10692/pull-kubevirt-e2e-k8s-1.28-sig-storage/1721880113642999808/artifacts/k8s-reporter/suite/

/cc @dhiller , @akalenyu

Error occurred and artifacts collected: https://gcsweb.ci.kubevirt.io/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/10692/pull-kubevirt-e2e-k8s-1.28-sig-storage/1721880113642999808/artifacts/k8s-reporter/suite/

Yeah looks like we fail to remove snapshot finalizer
"finalizers": [
                    "snapshot.kubevirt.io/snapshot-source-protection"
                ],

Awesome!  I will try to figure out why that finalizer could be hanging on.
/lgtm
/approve

/cherrypick release-1.1


Styled markers do not appear

According to the mapbox studio tutorial https://www.mapbox.com/help/source-quickstart/.
Styled markers do not appear:

any ideas?
thanks

mh, got it. only works in combination with a style

Ah, wait, not my fault:
after some changes and undo changes the markers disappear again.
Does anyone have any experience with the problem?

@sebastiantiede
Because of marker-comp-op: screen; you have to set your map background to something other than white to see the markers.
The tutorial assumes a background map.


implement zerohub module

zerohub module is a SAL for zerohub endpoints.

[x] Public Endpoints
[x] Restricted Endpoints
[x] Add docs

work is done at development_gridClient in threefold/zerohub/

check docu

move to web3gw code & docu & task

please contact me to review

part of the story for end2end tfhub


Python dumped when using MolFromInchi

I am trying to apply Chem.MolFromInchi func to some InChi text and get "Segmentation fault (core dumped)"
Python 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from rdkit import Chem
>>> inchi = 'InChI=1S/C17H23F3O4/c1-14(2)6-5-11(24-13(22)17(18,19)20)15(3)7-9-8-23-12(21)10(9)16(15,15)4/h9-11H,5-8H2,1-4H3/t9-,10-,11-,14-,16-'
>>> Chem.MolFromInchi(inchi)
Segmentation fault (core dumped)

I know this InChi example is incorrect, but "core dumped" interrupts the python session, and there is no way to catch the error.
Does anyone know what to do with this?

RDKit version: 2021.03.1 (installed as "pip install rdkit-pypi")
OS: Ubuntu 20.04

@skalinin sorry for the slow reply here.
It looks like this seg fault it happening in the inchi code itself, not in the RDKit (this is further reinforced by the fact that if I paste that inchi into marvin sketch it crashes too). Unfortunately there's nothing we can do about it on our side.
Please report the bug to the inchi team.

I got it, thanks for the reply!


the taskbar icon is invisible

it seems as though the icon located within the taskbar is invisible. if i right click i see "homepage desktop" and "quit"

but there is no icon there.

I changed the icon and it should work in a new version 0.1.4


Error in transpiled JavaScript

Describe the bug
I'm having difficulty using this component under Angular 8.  Instead of producing the intended menu, I just get stack trace and the standard menu.  I realized that I might be doing things incorrectly, but I'm not sure how, if this is not a bug, any guidance to solve my issue would be very appreciated.
To Reproduce
Click where you would expect to produce the menu.  Instead of seeing the expected alternative context menu, you will see the standard browser context menu.  If you then look at the console screen you will see this error and stack trace in the console:

GraphComponent.ngfactory.js? [sm]:1 ERROR TypeError: Cannot read property 'disabled' of undefined
at ContextMenuAttachDirective.onContextMenu (ngx-contextmenu.js:1099)
at Object.eval [as handleEvent] (GraphComponent.html:3)
at handleEvent (core.js:43993)
at callWithDebugContext (core.js:45632)
at Object.debugHandleEvent [as handleEvent] (core.js:45247)
at dispatchEvent (core.js:29804)
at core.js:42925
at HTMLLIElement. (platform-browser.js:2668)
at ZoneDelegate.invokeTask (zone-evergreen.js:400)
at Object.onInvokeTask (core.js:39680)

I took a look at ngx-contextmenu.js:1099 and the code that is there appears reasonable, I cannot find it's TypeScript conterpart anywhere.
Expected behavior
I would expect the context menu to show up and the standard menu not to.

Does this solution help you?
https://github.com/isaacplmann/ngx-contextmenu/issues/150

I'm sorry for the slow response.  Yes it does help.  That said, I'm actually looking over the internals of your component now as I am trying to make use of it in conjunction with Plotly JS.  If there is interest and I receive proper permission, I might offer to push my changes upstream.  Once again, thanks for the help.


Fix: Device Viewer CSS Fix

Jira
N/A
Summary
Two small Device Viewer-related CSS fixes I ran into the need for while working on https://github.com/boltdesignsystem/bolt/pull/1579.
Details
Prevents accidentally highlighting the device viewer image (which actually happened to me while zooming in on an image) + fixes the terribly janky transition when the device viewer image is magnified.
How to test
Check out the device viewer section in Pattern Lab and confirm that images can no longer get highlighted (click and drag) + the animation when magnifying an image with your mouse is much smoother.

Thanks @mikemai2awesome!

PR was released with v2.13.0


Old dev-branch

housecleaning

Nice work alloyed im glad to see that you're still working on this project!


Issue1763

Add white space indicators in the editor. #1763

@tonypark0403 a few things: this PR looks like it needs a rebase before it can be merged, but I'm also missing the linkback to the specific issue this addresses (the github issue that your push comment refers to is itself a closed PR, so that doesn't seem quite right). Also, can you update the title so that people looking at the /pulls list can immediately see what it's for?

I changed the branch name to be more clear so please delete this branch.

There's only one person who can delete branches on your repository, and that's you: go to your own repository on github, and then click the "branches" tab. This lets you delete branches from your repository.


installed packages not visible

in file /imports/loader.tsx
<DeepLoaderActive
      key="DEEPCASE_SPACE"
      name="DEEPCASE_SPACE"
      query={spaceQuery}
      onChange={(r) => {
        deep.minilinks?.apply(r, 'space');
      }}

no packet returned to r

https://github.com/deep-foundation/deepcase/issues/63


MINOR: Stateless transformation documentation

Needs to come after https://github.com/apache/kafka/pull/3701
Originally reviewed as part of #3490.

Thanks @dguy

2 unit tests failed: org.apache.kafka.streams.integration.KStreamRepartitionJoinTest.shouldCorrectlyRepartitionOnJoinOperationsWithZeroSizedCache
org.apache.kafka.streams.integration.KStreamRepartitionJoinTest.shouldCorrectlyRepartitionOnJoinOperationsWithNonZeroSizedCache
Not related to PR obviously.

Thanks @enothereska, merged to trunk


Bug:

What happened?

I tried to use an example, but I couldn't import WsResponse
import { OpenIMSDK } from 'open-im-sdk';
const OpenIM = new OpenIMSDK();
import { CbEvents } from 'open-im-sdk';
import type { WsResponse } from 'open-im-sdk';
OpenIM.on(CbEvents.OnConnecting, handleConnecting);
OpenIM.on(CbEvents.OnConnectFailed, handleConnectFailed);
OpenIM.on(CbEvents.OnConnectSuccess, handleConnectSuccess);
OpenIM.login({
userID: 'IM user ID',
token: 'IM user token',
platformID: 5,
wsAddr: 'ws://your-server-ip:10003',
apiAddr: 'http://your-server-ip:10002',
});
function handleConnecting() {
// Connecting...
}
function handleConnectFailed({ errCode, errMsg }: WsResponse) {
// Connection failed ❌
console.log(errCode, errMsg);
}
function handleConnectSuccess() {
// Connection successful ✅
}
What did you expect to happen?
I want to import WsResponse
How can we reproduce it (as minimally and precisely as possible)?
Try importing WsResponse
Anything else we need to know?

version

```console
$ {name} version
# paste output here
```

1
Cloud provider

1
OS version

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

Install tools

open-im-sdk 3.4.0

instead
import type { WsResponse } from "open-im-sdk/lib/types/entity"


Don't abort rollingUpdateStep if a deployment group fails

Just log it instead.

@davidxia

:+1:

Should we log in places like this? https://github.com/spotify/helios/blob/master/helios-services/src/main/java/com/spotify/helios/master/ZooKeeperMasterModel.java#L1664

yeah we should catch and log those exceptions in rollingUpdateStep()
let me add that to the PR

:+1:


Update development-vm directory

The gov.uk virtual machine now lives in the development-vm directory, so change it here so that the database replication works.
Update: tests are failing due to https://github.com/alphagov/stagecraft/issues/467
CC: @leelongmore

👍
Will merging this cause stagecraft in integration to fail because of #467?

It may well trigger an update of requirements which would make it fail, yes. I guess https://github.com/alphagov/stagecraft/issues/467 needs to be fixed first.

@rubenarakelyan I won't merge this then.
@leelongmore Something for the backlog?

I'm going to close this PR for now since it seems like there is no current development on stagecraft.


mat-divider is not shown with align-items: center

Bug, feature request, or proposal:
Bug
What is the expected behavior?
mat-divider should be shown, even with align-items: center
What is the current behavior?
mat-divider is not shown
What are the steps to reproduce?
https://stackblitz.com/edit/angular-material2-issue-enhzcm?file=app/app.component.html
Just remove center from fxLayoutAlign="flex-start center" and it will work.

The divider does work, but you need to define its height yourself. Here's a working fork of your example.


Integration is using deprecated DEVICE_CLASS_* constants

Describe the bug
This custom integration uses deprecated DEVICE_CLASS_* constants in its codebase.
The DEVICE_CLASS_* constants have been deprecated and replaced in Home Assistant Core 2021.12 (over a year ago). I would highly suggest updating/migrating this integration to the new enums.
For example, for the device classes supported by the sensor platform, there is now a SensorDeviceClass enum. So if a sensor previously used the DEVICE_CLASS_ENERGY constant, it should now use SensorDeviceClass.ENERGY. Other platforms (like binary_sensor, and number) provide similar enumerations for their supported device classes.
The migration thus only consists of replacing constants with an enumeration member and is, therefore, very low impact and should be fairly straightforward.
If I can help resolve any questions regarding this change or migration, feel free to ask or respond to this issue. I'm happy to help!
Kindest regards,
../Frenck
Version of the integration
If you are unsure about the version check the github release here.

all

Logs

n/a

Nice! Thanks for fixing! ❤
../Frenck


"Taiwan" should be corrected to “Taiwan, China” or "Taipei, China"

Taiwan not a country, only province of China.
Reference source：https://data.un.org/en/index.html

Thanks, but this data is coming form ICU database, so that's where you should report issues. This just converts it to other formats.

Taiwan is a self-governing democratic country, which has its own government, economy, and borders, and is not a part of the People's Republic of China


15 train baseline model

Description
Contains code for two potential baseline models: one based on label probabilities, and one that just predicts the most common combination of labels each time.
Fixes #15
Instructions for Reviewer
In order to test the code in this PR you need to ...
analysis/baseline_model.py and notebooks/04_train_baseline_model overlap - the former is a script that can easily be called from the command line and that logs the model on weights and biases; the latter is a notebook that includes EDA and compares metrics between the two baseline models, and also between training and validation sets.

Read and run through notebooks/04_train_baseline_model.py
Run baseline_model.py from the command line and check that it runs. There are instructions how to do this at the top of the script.
Run unit tests via pytest discovery_child_development/tests and they should all pass

Please pay special attention to ...

Is discovery_child_development/analysis/ the right place for baseline_model.py or should it go in .../pipeline/?

Checklist:

[x] I have refactored my code out from notebooks/
[x] I have checked the code runs
[x] I have tested the code
[x] I have run pre-commit and addressed any issues not automatically fixed
[x] I have merged any new changes from dev
[x] I have documented the code

[x] Major functions have docstrings
[ ] Appropriate information has been added to READMEs

[x] I have explained this PR above
[x] I have requested a code review

Oh, regarding your last question - I think we can move the baseline model script into pipeline, as it will be part of the model training and checking pipeline. Perhaps we can create a separate subfolder for 'models' ?
The naming of the 'analysis' folder doesn't make that much sense to be fair, if we already have a notebooks folder.


#63 fix neseted routes wrapper component

I know this is old, I gotta think about this a little bit as we move the API forward to converge with React Router.
More context: https://reacttraining.com/blog/reach-react-router-future/
Thanks.

(Oh, and you'll be glad to know our plans for routing focus management, now that we have hooks, doesn't rely on wrapper divs, so those will be going away)

Why wasn't this merged?

It would be super great to get this fixed,
I've setup patch-package to get this already in.
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index 813e894..5cc8bd0 100644
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -222,7 +222,6 @@ var RouterImpl = function (_React$PureComponent) {
     }, []);
     var pathname = location.pathname;

-
     var match = pick(routes, pathname);

     if (match) {
@@ -245,7 +244,7 @@ var RouterImpl = function (_React$PureComponent) {

       var clone = React.cloneElement(element, props, element.props.children ? React.createElement(
         Router,
-        { location: location, primary: primary },
+        { location: location, primary: primary, component },
         element.props.children
       ) : undefined);


Please add this

Hi, first of all: Great docker container. Better than every other i tried.
Could you please add this one? https://github.com/nelu/rutorrent-filemanager
Thank you.
Cheers

Hi @lordvalium,

Could you please add this one? https://github.com/nelu/rutorrent-filemanager

You can already custom plugins within this image. See this section in the README for more info.

Great docker container. Better than every other i tried.

Thanks for your support, glad you like it.


Untracked files shown in Staged TreeView

I am using the Flatpak version 1.2.0
Files in an Untracked directory data are shown in the Staged TreeView. This happens with files where i have no permissions.

@Murmele I'm not sure if the flatpak label fits, I can try to reproduce the error without flatpak tomorrow

@Murmele @exactly-one-kas It is indeed reproducible as non flatpak, just tried it.

I will also have a look into.
In difftreemodel we are using the stageState to determine if staged or not staged. Maybe we can have a look into which value it returns.
Can you try once with the latest release. There we changed the behaviour, but normaly they are shown in the staged and unstaged section and not only in the staged section
      const auto state = node->stageState(index, Node::ParentStageState::Any);

In the current (1.2.0) flatpak release and master it's only shown in the staged view

@0verEngineer can you try again with 1.2.2?
https://github.com/Murmele/Gittyup/pull/368

@Murmele Sorry i completely forgot about this, still happens on 1.3.0


[ldd-img] focus_mode valids

The "valid" list in the img:focus_mode description was not meant to be prescriptive but rather just examples.  I'm personally more comfortable with not having a valid list here but if you want to expand it to include all of these you can.  Let's please go with UPPER_CASE_UNDERSCORE styles for the value here because with the multiple words it would be really difficult to convert them to MixedCase.  So the valid list really is as follows (trying to make the definitions mostly multimission):
(SuperCam)
NO_FOCUS - Doesn't move focus
MANUAL - Positions focus based on other parameters (focus_distance for SuperCam)
BASELINE - Uses SuperCam laser to find optimal focus position
AF_OFFSET - Applies offset from last autofocus solution
(Mastcam-Z and SHERLOC)
AUTOFOCUS - Autofocus mode
EARLY_TERMINATION - Stops the autofocus before the full number of steps has been reached if a peak is detected
THRESHOLD - Causes the focus to not be changed if a test image is within a certain percentage of the last image taken with autofocus (5% for Mastcam-Z and SHERLOC)
EARLY_TERMINATION_AND_THRESHOLD - combination of both
Note that the current keyword also defines Relative and ZStack.  Can we change those to RELATIVE and ZSTACK for consistency?  I don't have definitions.
The other option is just to take off the validation values...?

make focus_mode free text in branch v1800. I left example use case as a comment in the class.


engine: fix merkle audit retries before checkpoint

cc @xgess this was your bug

:cool: thanks :)


Shadow are bugged when sun is in the back of the player

https://youtu.be/rODXspblOoE
Here's the video of the issues, if you look of the left and right bottom corner of the screen you can notice some shadows are not supposed to act like that.
Minecraft version : 1.19.4 (tested in 1.20.1 and the bug is also present)

i think thats working as intended
vanilla doesn't have a shadow map texture or similar
to get "correct" shadows u'd have to voxelize the entire world, and even that's subject to frustum culling
i think the shadows here are done in screen-space, so only objects visible on screen can cast shadows. thats why the shadows on the edges of screen may be inaccurate

See @Godlander's comment. Closed.


ModuleNotFoundError: No module named 'orderedmultidict'

Compiling Surelog 8fb385dd2a644df7f6c8cd578bb7223cc469bf5d
The build failed on my Ubuntu 21.10:
Traceback (most recent call last):
  File "/home/tom/prog/git/Surelog/third_party/UHDM/scripts/generate.py", line 7, in <module>
    import loader
  File "/home/tom/prog/git/Surelog/third_party/UHDM/scripts/loader.py", line 1, in <module>
    import orderedmultidict
ModuleNotFoundError: No module named 'orderedmultidict'
gmake[3]: *** [third_party/UHDM/CMakeFiles/GenerateCode.dir/build.make:403 : third_party/UHDM/generated/src/UHDM.capnp] Erreur 1

Apparently my python3 installation does not have this extra package : orderedmultidict
Couldn't we limit to python package coming from standard installation ?

@hs-apotell please address by documenting.
I had to do the following to be able to do:

make: pip install orderedmultidict
sudo make install: sudo pip install orderedmultidict

Couldn't we limit to python package coming from standard installation ?

Unfortunately, Python doesn't have a data structure required to implement a recurring predictable output. I tried to make the implementation part of the solution itself by adding the file to the repository but that implementation broke with the new python release. Thinking this is going to be a recurring problem, I decided to use a public community maintained solution to the problem.

This has been documented and addressed in CI


#265: Drop extra fields for INIBasedModels

@arthurvd currently there is one test (test_given_structure_text_with_polylinefile_parses_structure``) failing, because the example case contains the following line:
materialtype               = 1             #1 clay 2 sand, used only in algorithm 1
Is this also a research keyword that should be documented and added to our model? Because with the implementation in this PR, it will be dropped.

Hoi @priscavdsluis

@arthurvd currently there is one test (test_given_structure_text_with_polylinefile_parses_structure) failing, because the example case contains the following line: materialtype = 1 #1 clay 2 sand, used only in algorithm 1
Is this also a research keyword that should be documented and added to our model? Because with the implementation in this PR, it will be dropped.

No, it's an unsupported keyword at the moment, so you can remove it from the testcase.


fix(deps): update dependency @openzeppelin/contracts-upgradeable to v5

This PR contains the following updates:

Package
Type
Update
Change

@openzeppelin/contracts-upgradeable (source)
dependencies
major
4.9.3 -> 5.0.2

[!WARNING]
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Release Notes

OpenZeppelin/openzeppelin-contracts-upgradeable (@openzeppelin/contracts-upgradeable)
v5.0.2
Compare Source

Base64: Fix issue where dirty memory located just after the input buffer is affecting the result. (#4926)

v5.0.1
Compare Source

ERC2771Context and Context: Introduce a _contextPrefixLength() getter, used to trim extra information appended to msg.data.
Multicall: Make aware of non-canonical context (i.e. msg.sender is not _msgSender()), allowing compatibility with ERC2771Context.

v5.0.0
Compare Source
Additions Summary
The following contracts and libraries were added:

AccessManager: A consolidated system for managing access control in complex systems.

AccessManaged: A module for connecting a contract to an authority in charge of its access control.
GovernorTimelockAccess: An adapter for time-locking governance proposals using an AccessManager.
AuthorityUtils: A library of utilities for interacting with authority contracts.

GovernorStorage: A Governor module that stores proposal details in storage.
ERC2771Forwarder: An ERC2771 forwarder for meta transactions.
ERC1967Utils: A library with ERC1967 events, errors and getters.
Nonces: An abstraction for managing account nonces.
MessageHashUtils: A library for producing digests for ECDSA operations.
Time: A library with helpers for manipulating time-related objects.

Removals Summary
The following contracts, libraries, and functions were removed:

Address.isContract (because of its ambiguous nature and potential for misuse)
Checkpoints.History
Counters
ERC20Snapshot
ERC20VotesComp
ERC165Storage (in favor of inheritance based approach)
ERC777
ERC1820Implementer
GovernorVotesComp
GovernorProposalThreshold (deprecated since 4.4)
PaymentSplitter
PullPayment
SafeMath
SignedSafeMath
Timers
TokenTimelock (in favor of VestingWallet)
All escrow contracts (Escrow, ConditionalEscrow and RefundEscrow)
All cross-chain contracts, including AccessControlCrossChain and all the vendored bridge interfaces
All presets in favor of OpenZeppelin Contracts Wizard

These removals were implemented in the following PRs: #3637, #3880, #3945, #4258, #4276, #4289
Changes by category
General

Replaced revert strings and require statements with custom errors. (#4261)
Bumped minimum compiler version required to 0.8.20 (#4288, #4489)
Use of abi.encodeCall in place of abi.encodeWithSelector and abi.encodeWithSignature for improved type-checking of parameters (#4293)
Replaced some uses of abi.encodePacked with clearer alternatives (e.g. bytes.concat, string.concat). (#4504) (#4296)
Overrides are now used internally for a number of functions that were previously hardcoded to their default implementation in certain locations: ERC1155Supply.totalSupply, ERC721.ownerOf, ERC721.balanceOf and ERC721.totalSupply in ERC721Enumerable, ERC20.totalSupply in ERC20FlashMint, and ERC1967._getImplementation in ERC1967Proxy. (#4299)
Removed the override specifier from functions that only override a single interface function. (#4315)
Switched to using explicit Solidity import statements. Some previously available symbols may now have to be separately imported. (#4399)
Governor, Initializable, and UUPSUpgradeable: Use internal functions in modifiers to optimize bytecode size. (#4472)
Upgradeable contracts now use namespaced storage (EIP-7201). (#4534)
Upgradeable contracts no longer transpile interfaces and libraries. (#4628)

Access

Ownable: Added an initialOwner parameter to the constructor, making the ownership initialization explicit. (#4267)
Ownable: Prevent using address(0) as the initial owner. (#4531)
AccessControl: Added a boolean return value to the internal _grantRole and _revokeRole functions indicating whether the role was granted or revoked. (#4241)
access: Moved AccessControl extensions to a dedicated directory. (#4359)
AccessManager: Added a new contract for managing access control of complex systems in a consolidated location. (#4121)
AccessManager, AccessManaged, GovernorTimelockAccess: Ensure that calldata shorter than 4 bytes is not padded to 4 bytes. (#4624)
AccessManager: Use named return parameters in functions that return multiple values. (#4624)
AccessManager: Make schedule and execute more conservative when delay is 0. (#4644)

Finance

VestingWallet: Fixed revert during 1 second time window when duration is 0. (#4502)
VestingWallet: Use Ownable instead of an immutable beneficiary. (#4508)

Governance

Governor: Optimized use of storage for proposal data (#4268)
Governor: Added validation in ERC1155 and ERC721 receiver hooks to ensure Governor is the executor. (#4314)
Governor: Refactored internals to implement common queuing logic in the core module of the Governor. Added queue and _queueOperations functions that act at different levels. Modules that implement queuing via timelocks are expected to override _queueOperations to implement the timelock-specific logic. Added _executeOperations as the equivalent for execution. (#4360)
Governor: Added voter and nonce parameters in signed ballots, to avoid forging signatures for random addresses, prevent signature replay, and allow invalidating signatures. Add voter as a new parameter in the castVoteBySig and castVoteWithReasonAndParamsBySig functions. (#4378)
Governor: Added support for casting votes with ERC-1271 signatures by using a bytes memory signature instead of r, s and v arguments in the castVoteBySig and castVoteWithReasonAndParamsBySig functions. (#4418)
Governor: Added a mechanism to restrict the address of the proposer using a suffix in the description.
GovernorStorage: Added a new governor extension that stores the proposal details in storage, with an interface that operates on proposalId, as well as proposal enumerability. This replaces the old GovernorCompatibilityBravo module. (#4360)
GovernorTimelockAccess: Added a module to connect a governor with an instance of AccessManager, allowing the governor to make calls that are delay-restricted by the manager using the normal queue workflow. (#4523)
GovernorTimelockControl: Clean up timelock id on execution for gas refund. (#4118)
GovernorTimelockControl: Added the Governor instance address as part of the TimelockController operation salt to avoid operation id collisions between governors using the same TimelockController. (#4432)
TimelockController: Changed the role architecture to use DEFAULT_ADMIN_ROLE as the admin for all roles, instead of the bespoke TIMELOCK_ADMIN_ROLE that was used previously. This aligns with the general recommendation for AccessControl and makes the addition of new roles easier. Accordingly, the admin parameter and timelock will now be granted DEFAULT_ADMIN_ROLE instead of TIMELOCK_ADMIN_ROLE. (#3799)
TimelockController: Added a state getter that returns an OperationState enum. (#4358)
Votes: Use Trace208 for checkpoints. This enables EIP-6372 clock support for keys but reduces the max supported voting power to uint208. (#4539)

Metatx

ERC2771Forwarder: Added deadline for expiring transactions, batching, and more secure handling of msg.value. (#4346)
ERC2771Context: Return the forwarder address whenever the msg.data of a call originating from a trusted forwarder is not long enough to contain the request signer address (i.e. msg.data.length is less than 20 bytes), as specified by ERC-2771. (#4481)
ERC2771Context: Prevent revert in _msgData() when a call originating from a trusted forwarder is not long enough to contain the request signer address (i.e. msg.data.length is less than 20 bytes). Return the full calldata in that case. (#4484)

Proxy

ProxyAdmin: Removed getProxyAdmin and getProxyImplementation getters. (#3820)
TransparentUpgradeableProxy: Removed admin and implementation getters, which were only callable by the proxy owner and thus not very useful. (#3820)
ERC1967Utils: Refactored the ERC1967Upgrade abstract contract as a library. (#4325)
TransparentUpgradeableProxy: Admin is now stored in an immutable variable (set during construction) to avoid unnecessary storage reads on every proxy call. This removed the ability to ever change the admin. Transfer of the upgrade capability is exclusively handled through the ownership of the ProxyAdmin. (#4354)
Moved the logic to validate ERC-1822 during an upgrade from ERC1967Utils to UUPSUpgradeable. (#4356)
UUPSUpgradeable, TransparentUpgradeableProxy and ProxyAdmin: Removed upgradeTo and upgrade functions, and made upgradeToAndCall and upgradeAndCall ignore the data argument if it is empty. It is no longer possible to invoke the receive function (or send value with empty data) along with an upgrade. (#4382)
BeaconProxy: Reject value in initialization unless a payable function is explicitly invoked. (#4382)
Proxy: Removed redundant receive function. (#4434)
BeaconProxy: Use an immutable variable to store the address of the beacon. It is no longer possible for a BeaconProxy to upgrade by changing to another beacon. (#4435)
Initializable: Use the namespaced storage pattern to avoid putting critical variables in slot 0. Allow reinitializer versions greater than 256. (#4460)
Initializable: Use intermediate variables to improve readability. (#4576)

Token

ERC20, ERC721, ERC1155: Deleted _beforeTokenTransfer and _afterTokenTransfer hooks, added a new internal _update function for customizations, and refactored all extensions using those hooks to use _update instead. (#3838, #3876, #4377)
ERC20: Removed Approval event previously emitted in transferFrom to indicate that part of the allowance was consumed. With this change, allowances are no longer reconstructible from events. See the code for guidelines on how to re-enable this event if needed. (#4370)
ERC20: Removed the non-standard increaseAllowance and decreaseAllowance functions. (#4585)
ERC20Votes: Changed internal vote accounting to reusable Votes module previously used by ERC721Votes. Removed implicit ERC20Permit inheritance. Note that the DOMAIN_SEPARATOR getter was previously guaranteed to be available for ERC20Votes contracts, but is no longer available unless ERC20Permit is explicitly used; ERC-5267 support is included in ERC20Votes with EIP712 and is recommended as an alternative. (#3816)
SafeERC20: Refactored safeDecreaseAllowance and safeIncreaseAllowance to support USDT-like tokens. (#4260)
SafeERC20: Removed safePermit in favor of documentation-only permit recommendations. Based on recommendations from @trust1995 (#4582)
ERC721: _approve no longer allows approving the owner of the tokenId. (#4377) _setApprovalForAll no longer allows setting address(0) as an operator. (#4377)
ERC721: Renamed _requireMinted to _requireOwned and added a return value with the current owner. Implemented ownerOf in terms of _requireOwned. (#4566)
ERC721Consecutive: Added a _firstConsecutiveId internal function that can be overridden to change the id of the first token minted through _mintConsecutive. (#4097)
ERC721URIStorage: Allow setting the token URI prior to minting. (#4559)
ERC721URIStorage, ERC721Royalty: Stop resetting token-specific URI and royalties when burning. (#4561)
ERC1155: Optimized array allocation. (#4196)
ERC1155: Removed check for address zero in balanceOf. (#4263)
ERC1155: Optimized array accesses by skipping bounds checking when unnecessary. (#4300)
ERC1155: Bubble errors triggered in the onERC1155Received and onERC1155BatchReceived hooks. (#4314)
ERC1155Supply: Added a totalSupply() function that returns the total amount of token circulating, this change will restrict the total tokens minted across all ids to 2**256-1 . (#3962)
ERC1155Receiver: Removed in favor of ERC1155Holder. (#4450)

Utils

Address: Removed the ability to customize error messages. A common custom error is always used if the underlying revert reason cannot be bubbled up. (#4502)
Arrays: Added unsafeMemoryAccess helpers to read from a memory array without checking the length. (#4300)
Arrays: Optimized findUpperBound by removing redundant SLOAD. (#4442)
Checkpoints: Library moved from utils to utils/structs (#4275)
DoubleEndedQueue: Refactored internal structure to use uint128 instead of int128. This has no effect on the library interface. (#4150)
ECDSA: Use unchecked arithmetic for the tryRecover function that receives the r and vs short-signature fields separately. (#4301)
EIP712: Added internal getters for the name and version strings (#4303)
Math: Makes ceilDiv to revert on 0 division even if the numerator is 0 (#4348)
Math: Optimized stack operations in mulDiv. (#4494)
Math: Renamed members of Rounding enum, and added a new rounding mode for "away from zero". (#4455)
MerkleProof: Use custom error to report invalid multiproof instead of reverting with overflow panic. (#4564)
MessageHashUtils: Added a new library for creating message digest to be used along with signing or recovery such as ECDSA or ERC-1271. These functions are moved from the ECDSA library. (#4430)
Nonces: Added a new contract to keep track of user nonces. Used for signatures in ERC20Permit, ERC20Votes, and ERC721Votes. (#3816)
ReentrancyGuard, Pausable: Moved to utils directory. (#4551)
Strings: Renamed toString(int256) to toStringSigned(int256). (#4330)
Optimized Strings.equal (#4262)

How to migrate from 4.x
ERC20, ERC721, and ERC1155
These breaking changes will require modifications to ERC20, ERC721, and ERC1155 contracts, since the _afterTokenTransfer and _beforeTokenTransfer functions were removed. Thus, any customization made through those hooks should now be done overriding the new _update function instead.
Minting and burning are implemented by _update and customizations should be done by overriding this function as well. _transfer, _mint and _burn are no longer virtual (meaning they are not overridable) to guard against possible inconsistencies.
For example, a contract using ERC20's _beforeTokenTransfer hook would have to be changed in the following way.
-function _beforeTokenTransfer(
+function _update(
   address from,
   address to,
   uint256 amount
 ) internal virtual override {
-  super._beforeTokenTransfer(from, to, amount);
   require(!condition(), "ERC20: wrong condition");
+  super._update(from, to, amount);
 }

More about ERC721
In the case of ERC721, the _update function does not include a from parameter, as the sender is implicitly the previous owner of the tokenId. The address of this previous owner is returned by the _update function, so it can be used for a posteriori checks. In addition to to and tokenId, a third parameter (auth) is present in this function. This parameter enabled an optional check that the caller/spender is approved to do the transfer. This check cannot be performed after the transfer (because the transfer resets the approval), and doing it before _update would require a duplicate call to _ownerOf.
In this logic of removing hidden SLOADs, the _isApprovedOrOwner function was removed in favor of a new _isAuthorized function. Overrides that used to target the _isApprovedOrOwner should now be performed on the _isAuthorized function. Calls to _isApprovedOrOwner that preceded a call to _transfer, _burn or _approve should be removed in favor of using the auth argument in _update and _approve. This is showcased in ERC721Burnable.burn and in ERC721Wrapper.withdrawTo.
The _exists function was removed. Calls to this function can be replaced by _ownerOf(tokenId) != address(0).
More about ERC1155
Batch transfers will now emit TransferSingle if the batch consists of a single token, while in previous versions the TransferBatch event would be used for all transfers initiated through safeBatchTransferFrom. Both behaviors are compliant with the ERC-1155 specification.
ERC165Storage
Users that were registering EIP-165 interfaces with _registerInterface from ERC165Storage should instead do so so by overriding the supportsInterface function as seen below:
function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {
  return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId);
}

SafeMath
Methods in SafeMath superseded by native overflow checks in Solidity 0.8.0 were removed along with operations providing an interface for revert strings. The remaining methods were moved to utils/Math.sol.
- import "@openzeppelin/contracts/utils/math/SafeMath.sol";
+ import "@openzeppelin/contracts/utils/math/Math.sol";

 function tryOperations(uint256 x, uint256 y) external view {
-  (bool overflowsAdd, uint256 resultAdd) = SafeMath.tryAdd(x, y);
+  (bool overflowsAdd, uint256 resultAdd) = Math.tryAdd(x, y);
-  (bool overflowsSub, uint256 resultSub) = SafeMath.trySub(x, y);
+  (bool overflowsSub, uint256 resultSub) = Math.trySub(x, y);
-  (bool overflowsMul, uint256 resultMul) = SafeMath.tryMul(x, y);
+  (bool overflowsMul, uint256 resultMul) = Math.tryMul(x, y);
-  (bool overflowsDiv, uint256 resultDiv) = SafeMath.tryDiv(x, y);
+  (bool overflowsDiv, uint256 resultDiv) = Math.tryDiv(x, y);
   // ...
 }

Adapting Governor modules
Custom Governor modules that override internal functions may require modifications if migrated to v5. In particular, the new internal functions _queueOperations and _executeOperations may need to be used. If assistance with this migration is needed reach out via the OpenZeppelin Support Forum.
ECDSA and MessageHashUtils
The ECDSA library is now focused on signer recovery. Previously it also included utility methods for producing digests to be used with signing or recovery. These utilities have been moved to the MessageHashUtils library and should be imported if needed:
 import {ECDSA} from "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
+import {MessageHashUtils} from "@openzeppelin/contracts/utils/cryptography/MessageHashUtils.sol";

 contract Verifier {
   using ECDSA for bytes32;
+  using MessageHashUtils for bytes32;

   function _verify(bytes32 data, bytes memory signature, address account) internal pure returns (bool) {
     return data
       .toEthSignedMessageHash()
       .recover(signature) == account;
   }
 }

Interfaces and libraries in upgradeable contracts
The upgradeable version of the contracts library used to include a variant suffixed with Upgradeable for every contract. These variants, which are produced automatically, mainly include changes for dealing with storage that don't apply to libraries and interfaces.
The upgradeable library no longer includes upgradeable variants for libraries and interfaces. Projects migrating to 5.0 should replace their library and interface imports with their corresponding non-upgradeable version:
 // Libraries
-import {AddressUpgradeable} from '@openzeppelin/contracts-upgradeable/utils/AddressUpgradeable.sol';
+import {Address} from '@openzeppelin/contracts/utils/Address.sol';

 // Interfaces
-import {IERC20Upgradeable} from '@openzeppelin/contracts-upgradeable/interfaces/IERC20.sol';
+import {IERC20} from '@openzeppelin/contracts/interfaces/IERC20.sol';

Offchain Considerations
Some changes may affect offchain systems if they rely on assumptions that are changed along with these new breaking changes. These cases are:
Relying on revert strings for processing errors
A concrete example is AccessControl, where it was previously advised to catch revert reasons using the following regex:
/^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/

Instead, contracts now revert with custom errors. Systems that interact with smart contracts outside of the network should consider reliance on revert strings and possibly support the new custom errors.
Relying on storage locations for retrieving data
After 5.0, the storage location of some variables were changed. This is the case for Initializable and all the upgradeable contracts since they now use namespaced storaged locations. Any system relying on storage locations for retrieving data or detecting capabilities should be updated to support these new locations.
v4.9.6
Compare Source

Base64: Fix issue where dirty memory located just after the input buffer is affecting the result. (#4929)

v4.9.5
Compare Source

Multicall: Make aware of non-canonical context (i.e. msg.sender is not _msgSender()), allowing compatibility with ERC2771Context. Patch duplicated Address.functionDelegateCall in v4.9.4 (removed).

v4.9.4
Compare Source

ERC2771Context and Context: Introduce a _contextPrefixLength() getter, used to trim extra information appended to msg.data.
Multicall: Make aware of non-canonical context (i.e. msg.sender is not _msgSender()), allowing compatibility with ERC2771Context.

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

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

This PR has been generated by Renovate Bot.

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

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

The artifact failure details are included below:
File name: packages/contracts-core/yarn.lock
Corepack is about to download https://registry.yarnpkg.com/yarn/-/yarn-1.22.19.tgz.
error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "^12.0.0 || ^14.0.0 || ^16.0.0". Got "20.11.1"
error Found incompatible module.


Quickstart class enhancement

Summary
As of 02/21

~The updates are intended to add optional context to the quickstart class where coreDataSourceIds can be supplied to the data source class. coreDataSourceIds are then submitted to the new instance(s) of Data Source~

~Reason for this, is that we fetch core data source ids from the catalog service using an sync request.~
~Since Data Source extends the Component class, adding an async request in the initialization of the class creates some weirdness.~
The idea behind this is to have a list of core data source IDs defined before initializing the classes (i.e., sending in the IDs from workflows)

So far, this works as intended and was manually checked via PR #1639

TODO:

[x] Add unit test to Quickstart and Data sources classes to verify:

[x] A quickstart that has a CORE data source ID references does not mark either the quickstart or data source as invalid
[x] A stand alone data source that has a CORE data source ID referenced does not get marked as invalid
[x] Fix current tests that may be needing minor updates (this may be avoided if we ensure backwards compatibility)

[x] (verify) If a new COMMUNITY data source is added to the PR, both the quickstart and data source should be valid.

~While running these changes with the changes in #1639, the workflows succeed with core data source IDs. However, it fails on a new local community data source~
Update 02/22
Works as expected with manual test and unit tests for implementation
New iteration
Decided to go with an approach where if a quickstart config has a core data source, we do not create a data source instance that gets generated in this.components
There are unit tests for that

Putting this back into draft to come up with a better solution


feat: support noOverwriteGlobs for templates based on react

Description

add noOverwriteGlobs parameters to methods saveContentToFile and saveRenderedReactContent
pass this.noOverwriteGlobs to saveContentToFile
check the name of file to be written against the noOverwriteGlobs to determine whether it should be actually written to the target directory
add additional comments to relevant codes in the codebase so they are easier for future maintainers and contributors to understand.

Related issue(s)

Fixes #1128

@derberg just update the implementation!

@lmgyuan you'll need to solve conflicts first before you amend your integration tests

Thanks! I will come back and take a closer look at this after my exams and projects are over : )

continued and merged in #1234


Null check does not result in non-optional type in lines in the if-statement

In the code shown below the String? a and String? b are still considered optional after checking their existence in the if-statement. I would assume that the type checker would be able to deal with situations like these, not encouraging me to use a! and b! in this instance.

Dart SDK Version (dart --version)
Based on Flutter 3.7.6
Dart SDK 2.19.3
Whether you are using Windows, MacOSX, or Linux (if applicable)
Reproducible by pasting into online DartPad

I have created a snippet to be pasted into https://dartpad.dev highlighting the issue.
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  MyApp({super.key});

  static const String _title = 'Flutter Code Sample';

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: _title,
      home: MyStatelessWidget(b: 'b'),
    );
  }
}

class MyStatelessWidget extends StatelessWidget {
  String? a;
  String? b;

  MyStatelessWidget({super.key, this.a, this.b});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Potential LSP bug'),
      ),
      body: Center(
        child: Column(
          children: [
            const Text('test'),
            if (a != null && b != null)
              Column(children: [
                Text(a),
                Text(b),
              ]),
          ],
        ),
      ),
    );
  }
}

This is working as intended. Please see https://dart.dev/null-safety/understanding-null-safety#working-with-nullable-fields for more details.

Right, makes sense, thanks!
Sorry for raising this issue.


vocabulary query with category= fails

I have encountered strange behavior where category restriction queries do not work.
My development server built against 23b4176 lists the categories https://scigraph.olympiangods.org/scigraph/vocabulary/categories but when I try to run queries with them I get 404 errors.

200 https://scigraph.olympiangods.org/scigraph/vocabulary/term/brain
404 https://scigraph.olympiangods.org/scigraph/vocabulary/term/brain?category=anatomical entity
404 https://scigraph.olympiangods.org/scigraph/vocabulary/term/brain?category="anatomical entity"
404 https://scigraph.olympiangods.org/scigraph/vocabulary/term/brain?category="anatomical%20entity"

I cannot test against autocomplete or search because I get 500 errors (covered in another issue).
This issue also appears on SciCrunch production built from https://github.com/SciCrunch/SciGraph/tree/upstream.

Category filters work for the monarch instance, maybe it's the double quotes?  https://scigraph-ontology.monarchinitiative.org/scigraph/vocabulary/term/brain?limit=20&searchSynonyms=true&searchAbbreviations=false&searchAcronyms=false&category=anatomical entity

The quotes don't seem to be the issue (though they are an issue as seen by querying the monarch endpoint). https://scigraph.olympiangods.org/scigraph/vocabulary/term/brain?limit=20&searchSynonyms=true&searchAbbreviations=false&searchAcronyms=false&category=anatomical entity shows up in the logs as "GET /scigraph/vocabulary/term/brain?limit=20&searchSynonyms=true&searchAbbreviations=false&searchAcronyms=false&category=anatomical%20entity HTTP/1.1" 404 some something is still wrong.
Comparing https://github.com/monarch-initiative/SciGraph-docker-monarch-data/blob/master/src/main/resources/monarchLoadConfiguration.yaml.tmpl and https://github.com/tgbugs/pyontutils/blob/master/scigraph/graphload.yaml.template doesn't reveal any obvious issues, though I do run that template through python yaml and it comes out with categories at the top, however it is clear that categories are in Neo4j since they can be seen in the results for queries e.g. here https://scigraph.olympiangods.org/scigraph/vocabulary/term/synganglion. I'm going to strip down our services.yaml to see whether it makes a difference.

Stripping down services.yaml doesn't seem to have done anything.
These lines are also present in the build output. So extra confirmation that they are in the graph.
INFO: Tagging 10262 for disease
INFO: Tagging 208 for organism
INFO: Tagging 5123 for subcellular entity
INFO: Tagging 20665 for anatomical entity
INFO: Tagging 12947 for Resource
INFO: Tagging 40955 for biological process
INFO: Tagging 364 for Institution
INFO: Tagging 508 for cell
INFO: Tagging 37902 for molecular entity
INFO: Tagging 2092 for quality

Finally figured out what it was. In graphload.yaml - category must be included in indexedNodeProperties otherwise everything fails. Hopefully this note will help anyone else who might encounter the issue. It might also be worth adding - category by default it any categories are set since the desire to have them indexed is probably the default desire. If someone wants the categories but not the ability to filter on them then that should probably be set manually rather than how it works right now.


Updating resource to work with onesync infinity but to still have backwards compatibility

Updated __resource.lua to fxmanifest.lua.
Added InteractSound_CL:PlayWithinDistanceOS which takes coords sent to it from the server as it's first parameter (needed for it to work with onesync infinity.
Added if statement to InteractSound_SV:PlayWithinDistance which allows for backwards compatibility for servers that are not yet using onesync inifinty.

Thanks @The-Neco. I'll get this merged into master. I really appreciate the PR!


Refactor internal representation of nxdl's to tree structure

The idea is to keep a dict/Template and use the tree as a generic nxdl verification to check against
Here is a testing snippet of the tree generation function:
from pynxtools.dataconverter.helpers import generate_tree_from_nxdl
from pynxtools.dataconverter.convert import get_nxdl_root_and_path

from anytree import RenderTree, Resolver

root, _ = get_nxdl_root_and_path("NXmpes")
tree = generate_tree_from_nxdl(root)
print(RenderTree(tree))

This prints a tree structure of NXmpes to the console:
ROOT[nxmpes] (req)
└── ENTRY[entry] (req)
    ├── definition (req)
    │   └── @version (req)
    ├── title (req)
    ├── start_time (req)
    ├── end_time (rec)
    ├── method (rec)
    ├── COORDINATE_SYSTEM_SET[geometries] (opt)
    ├── USER[user] (rec)
    │   ├── name (req)
    │   └── affiliation (req)
    ├── INSTRUMENT[instrument] (req)
    │   ├── RESOLUTION[energy_resolution] (opt)
    │   │   ├── physical_quantity (req)
    │   │   ├── type (rec)
...

We can also resolve concept paths:
resolver = Resolver("name")
print(resolver.get(tree, "ENTRY/INSTRUMENT/MANIPULATOR/temperature_sensor/name"))

ToDos:

[ ] Add support for dimensions
[ ] Add support for enumerations
[ ] Add dict path traversal and verification function (split, namefit, verify subtree)
[ ] Add required traversal function (aka find if anything is missing in the provided dict)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

30 of 68 (44.12%)  changed or added relevant lines in 2 files are covered.
5 unchanged lines in 3 files lost coverage.
Overall coverage increased (+1.5%) to 80.273%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pynxtools/dataconverter/helpers.py
3
22
13.64%

pynxtools/dataconverter/nexus_tree.py
27
46
58.7%

Files with Coverage Reduction
New Missed Lines
%

pynxtools/definitions/dev_tools/utils/nxdl_utils.py
1
74.23%

tests/dataconverter/test_readers.py
1
91.07%

pynxtools/dataconverter/template.py
3
83.72%

Totals

Change from base Build<PHONE_NUMBER>:
1.5%

Covered Lines:
2592

Relevant Lines:
3229

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

30 of 68 (44.12%)  changed or added relevant lines in 2 files are covered.
5 unchanged lines in 3 files lost coverage.
Overall coverage increased (+1.5%) to 80.273%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pynxtools/dataconverter/helpers.py
3
22
13.64%

pynxtools/dataconverter/nexus_tree.py
27
46
58.7%

Files with Coverage Reduction
New Missed Lines
%

pynxtools/definitions/dev_tools/utils/nxdl_utils.py
1
74.23%

tests/dataconverter/test_readers.py
1
91.07%

pynxtools/dataconverter/template.py
3
83.72%

Totals

Change from base Build<PHONE_NUMBER>:
1.5%

Covered Lines:
2592

Relevant Lines:
3229

💛  - Coveralls

Python 3.8 is failing because typing.Annotated was only added in python 3.9:
https://docs.python.org/3.9/library/typing.html#relevant-peps
It's used in pydantic to check the range of int values. Here I use it to constrain the allowed values of the min/max occurs to $\ge0$. We can either remove the check or support for py3.8

@FAIRmat-NFDI/areab There are still a few things needed but it's already in a reviewable state.
Missing things:

Complete testing (this I would consider necessary for merging)
Currently, it is a separate code from the template verification. This needs to be switched before merging
Support for new features (dimensions, symbols, occurrences, ...) -> Probably best to handle this in a separate PR to progress with a new pynx release