Version bump type example

Hi there,
Great package, can you give me an example of how to set the option to change the bump type i.e minor, major ect
Thanks

Look at the tests https://github.com/stevelacy/bump-regex/blob/master/test/index.js#L43

Thanks dude


multiple transform visitors for same nodes

I want to run multiple visitors for the same nodes.
Currently as soon as a transform visitor is found for a node, it runs only that and returns https://github.com/facebook/jstransform/blob/master/src/jstransform.js#L200-L207
It could be made a) so that it returns when the visitor returns false but allow further iteration if the visitor returns true, or b) so that all visitors test first then the valid ones execute or c) execute on test but return afterwards with false if at least one visitor was found (that returned false?).
What do you think?

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.


Revert "accept variable number of key, val in log.WithKeyValue"

Reverts moov-io/base#92
Motivation for this revert is to reduce the chance of passing wrong amount of arguments to the method and getting broken logs. As example,
log.WithKeyValue("one", "1", "two", "2", "three", "3")

Say you miss the "1" in that line and now your indexes are all off. You'd end up with "one=two" "2=three" in logs.
Versus with fixed number of arguments (this PR) you are constrainted by the compiler to not mess it up:
log.WithKeyValue("one", "1").WithKeyValue("two", "2")

Also, if you try to add 3 like this:
log.WithKeyValue("three", )

it would compiler error.
Based on discussion with @InfernoJJ

Codecov Report

Merging #93 into master will decrease coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #93      +/-   ##
==========================================
- Coverage   83.19%   83.13%   -0.06%
==========================================
  Files          19       19
  Lines         601      599       -2
==========================================
- Hits          500      498       -2
  Misses         73       73
  Partials       28       28

Impacted Files
Coverage Δ

log/logger.go
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 340ece6...d41eb7f. Read the comment docs.

cc @InfernoJJ

@InfernoJJ please, approve :) It will take no time for you as I'm just reverting the code.

@vxio we will add:
logger.With(log.Fields{
  "one": "1",
  "two": "2"
})

will it compensate your upset?


[Bug]: Cannot run on case-sensitive OS

What happened?
views/vendor/filament-relation-manager-component/Infolists needs to be renamed views/vendor/filament-relation-manager-component/infolists
How to reproduce the bug
Release to Vapor or any case-sensitive OS
Package Version
1.0.0
PHP Version
8.3.0
Laravel Version
10.48.9
Filament Version
3.2.64
Notes
No response

Fixed in 1.0.1


Non optimal multiple prefix usage

In #11 I did a mistake. Instead of parsing environment variables and then comparing variable names with prefixes I compare each prefix with all os variables every time.
for prefix in prefixes:
    store.update(_preload_existing_vars(prefix))

And it should be as is now. We need to strict to prefix order, not environment variables.
For example
$ export ANOTHER_TT_VALUE=2
$ export SOM_TT_VALUE=1
dump-env -p SOM_TT_ -p ANOTHER_TT_

Would give different results depending os.environ order ordering.


hide/show on tray icon

My Setup

Operating System: Xubuntu 18.04 LTS
App Version: 2.15.0
Installation type: deb 64bit

[x] I have tested with the latest version
[x] I can simulate the issue easily

Description

With the installation of version 2.15.0, the application can no longer be fetched to the foreground with a single click, rather two clicks are necessary, on the icon in the tray and then on "show". Personally, I find this unmanageable; one unnecessary click.
Besides, this is unusual behavior. None of the application in my tray react like this, just a click for foreground or background.
Current Behavior

One click on the tray icon -> then "show" to bring the window to the foreground.
Expected Behavior

Just a single click on the tray icon to bring the window to the foreground or move it to the background.

I'm surprised that the previous versions worked fine on Xubuntu. According to Electron docs:

When app indicator is used on Linux, the click event is ignored.

Which is the standard on Ubuntu 18.04. Is it possible that some GTK component was upgraded too?

@tassoevan I had no problems with all Electron versions since I change to XUbuntu over a year ago.

After a few days it's really a bit annoying when you have to click on the tray icon twice each time you open the client.

I just confirmed that 2.14.7 was triggering the click event. I'm still checking what have changed besides the update from Electron 2 to 4.

Removing libappindicator3-1 restored the old behavior, but it's a critical dependency for Xubuntu...

https://github.com/electron/electron/issues/14941

yes, this is duplicate to #14941. I will close this issue.

yes, this is duplicate to #14941. I will close this issue.

Ah, that is the electron repo, reopend it.

I have the same problem in ubuntu 18.04 with gnome 3.28.2.

Any news? Seems like the behaviour didn't change (or is broken again)?

Client is unusable for me past 2.14.7 because of this. Are there any plans to fix, or should one give up hope?

Please test if the latest release did solve this. If not please reopen the issue or create a new one and tell us. I will be closing this one for now.
Thank you!


Bug: Clear side effects related to DOM event listeners

Create instance methods so they remain unchanged for the removeEventListener call
Add componentWillUnmount with all the removeEventListener calls

Fixes #104

Duplicate of https://github.com/justinmc/react-audio-player/issues/57

I just made these optional so you've got conflicts now.  Would you be able to resolve them?

I just made these optional so you've got conflicts now. Would you be able to resolve them?

Sure! It will be done during today. Thanks for your time!

Done! You can merge now without conflicts ;)

Fixed the types of the arguments of the event listeners by changing e: any to e: Event.

@justinmc Are you having any trouble with this PR? I can adapt it to whatever needs you have.


Update default_data.json

Add me to the list

Thank you for contributing to stackforge/stackalytics!
stackforge/stackalytics uses Gerrit for code review.
Please visit
http://docs.openstack.org/infra/manual/developers.html#development-workflow
and follow the instructions there to upload your change to Gerrit.


How to enable / disable for SDK | Local Development

When I'm running Service Fabric locally, for development, how do I enable/disable this service?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d273a891-b7f9-81db-bfc5-044e6755541f
Version Independent ID: dc9f17bb-64af-d4b5-186f-7647c0a0c511
Content: Azure Service Fabric DNS service
Content Source: articles/service-fabric/service-fabric-dnsservice.md
Service: service-fabric
GitHub Login: @msfussell
Microsoft Alias: msfussell

Looks like this

Yep, gtg, thanks!  Would be nice to have it in the official docs 🤩


Outdenting should keep the same lines selected

Unindenting/outdenting/dedenting a block of code can leave you with a selection without one of the lines that you outdented, so continuing to outdent leaves that line behind.

Also demonstrated in this gif: gutter highlight stays behind
Instead, it should keep part of the selection on that line. In fact, it should select the entire line.
(That would probably be the most sensible solution, rather than, say, keeping a single character selected (which would be weird especially if using spaces) or keeping the leading whitespace selected (which would still have the problem if you dedent all the way))
Did I miss any keywords? unindent unindented dedented dedent indentation

I can confirm on latest master.

This is still a problem 😕


recover from data loss

The main reasons that we want to recover article snapshot data are:

Some snapshots are not parsed yet before the data loss incident.
Some snapshots are parsed before the incident and were saved in parser db, but the parser was older at the time and did not extract some of the metadata.  In particular, there were no site GA tracking id extracted for many producers.

To assess the impact of the data loss, a LossArticle table was created out of the following query:
SELECT article_id, site_id, snapshot_count, (SELECT COUNT(*) FROM ArticleSnapshot WHERE article_id = Article.article_id) AS actual_count FROM Article HAVING snapshot_count > 0 AND actual_count = 0

The results are:

site_id | COUNT(*) |
-- | -- | --
1 | 804
2 | 545
6 | 8274
8 | 10527
13 | 3500
14 | 13632
15 | 3
16 | 878
96 | 270
98 | 2896
99 | 3921
100 | 946
101 | 941
102 | 2188
104 | 847
105 | 1073
106 | 663
107 | 589
108 | 3941
114 | 816
115 | 1491
116 | 921
117 | 2190
118 | 6416
119 | 4718
120 | 14
121 | 189
122 | 10247
123 | 5908
731 | 2
732 | 42307
751 | 11
752 | 634
753 | 1
789 | 538
1668 | 224
1669 | 46
2922 | 1431
4589 | 685

We lost 135227 articles.

Redid the calculation with all snapshot tables we have:
CREATE TABLE Snapshot (article_id INT NOT NULL, snapshot_at INT NOT NULL, PRIMARY KEY (article_id, snapshot_at)) SELECT article_id, snapshot_at FROM ArticleSnapshot;
INSERT Snapshot (article_id, snapshot_at) SELECT article_id, snapshot_at FROM ArticleSnapshot202002;
INSERT Snapshot (article_id, snapshot_at) SELECT article_id, snapshot_at FROM ArticleSnapshot202003;
CREATE TABLE SnapshotLoss (article_id INT PRIMARY KEY, site_id INT NOT NULL, snapshot_count INT NOT NULL, actual_count INT NOT NULL) SELECT article_id, site_id, snapshot_count, (SELECT COUNT(*) FROM Snapshot WHERE article_id = Article.article_id) AS actual_count FROM Article WHERE first_snapshot_at <<PHONE_NUMBER> HAVING snapshot_count > 0 AND actual_count = 0;

It shows there are still 5351 articles discovered before 2020-02-28 09:03:35, the MIN(first_snapshot_at) after the data loss incident, that should have at least one snapshot (snapshot_count > 0) but actually has none (actual_count = 0).  Grouped into sites:

site_id
loss_count

1
2

98
512

99
3328

100
16

107
6

122
642

123
225

751
1

789
538

2922
81

Among which sites 122（壹讀）and 123（每日頭條）are not active at the moment(!?) Other than that, I checked a few of these articles and found that they are indeed 404.  This probably means we have 4484 articles lost for good.

Since all of the above articles has snapshot_count less than 7, the update spider should have checked all of them except for sites 122 and 123.  And since the update spider sets next_snapshot_at to zero when it found an article has 404, the following query shows in our db those articles on which the update spider didn't hit a 404 but somehow couldn't grab a snapshot:
SELECT Article.article_id, Article.site_id, url, next_snapshot_at FROM Article JOIN SnapshotLoss ON Article.article_id = SnapshotLoss.article_id WHERE next_snapshot_at > 0 AND Article.site_id NOT IN (122, 123)

and there are only 16 of them 🎉 :

article_id
site_id
url
next_snapshot_at

1242669
100
https://www.chinatimes.com/realtimenews/20200219003118-260402
1582188254

1244635
100
https://www.chinatimes.com/realtimenews/20200219004733-260402
1582205538

1244638
100
https://www.chinatimes.com/realtimenews/20200219004986-260402
1582205557

1266016
100
https://www.chinatimes.com/realtimenews/20200220004918-260402
1582290022

1282649
100
https://www.chinatimes.com/realtimenews/20200221005318-260407
1582381528

1294493
100
https://www.chinatimes.com/realtimenews/20200222003894-260402
1582464538

1294495
100
https://www.chinatimes.com/realtimenews/20200222003905-260402
1582464549

1299269
100
https://www.chinatimes.com/realtimenews/20200223000869-260410
1582509188

1299273
100
https://www.chinatimes.com/realtimenews/20200223000878-260410
1582509197

1299278
100
https://www.chinatimes.com/realtimenews/20200223000884-260410
1582509207

1299281
100
https://www.chinatimes.com/realtimenews/20200223000809-260410
1582509216

1299283
100
https://www.chinatimes.com/realtimenews/20200223000816-260410
1582509221

1306111
100
https://www.chinatimes.com/realtimenews/20200224003287-260407
1582612175

1311575
100
https://www.chinatimes.com/realtimenews/20200225002516-260402
1582692755

1358109
100
https://www.chinatimes.com/realtimenews/20200227004529-260402
1582926713

1359453
100
https://www.chinatimes.com/realtimenews/20200227004973-260402
1582928905

Looks like they are indeed all 404, it is just that our spider doesn't like the responses from chinatimes.  That means all of the 4484 articles are indeed lost for good, unless we find a way to get them again other than from the sites that published them.

It is still possible to get those articles back from some places like archive.org or google search cache.  For example,

We can get https://www.chinatimes.com/realtimenews/20200227004529-260402 from https://webcache.googleusercontent.com/search?q=cache:bMo4DcU9aRIJ:https://www.chinatimes.com/realtimenews/20200227004529-260402%3Fctrack%3Dpc_main_recmd_p08+&cd=1&hl=fr&ct=clnk&gl=tw&chdtv
There are many archives for PTT like https://www.pttweb.cc/bbs/Gossiping/M.1582847305.A.A5A for https://www.pttweb.cc/bbs/Gossiping/M.1582847305.A.A5A , https://www.pttweb.cc/bbs/HatePolitics/M.1574072804.A.2DE for https://www.ptt.cc/bbs/HatePolitics/M.1574072804.A.2DE.html

For some of the lost articles I could not find a cached version, though.  Also PTTWeb may need a different parser.
I say we conclude the investigation here, compile a brief report of the incident and the affected data, and open new issues separately for recovering lost data for each of Chinatimes, PTT, and other sites in SnapshotLoss, if we want to pursuit the data recovery further, because they all require addition work beyond the capabilities of our current system.

Close the issue here.  Open #105 for PTT data.


Please add a license to the repository

Hi @MattBystrin
Thanks for making your code available. Unfortunately, without a license, I'm unsure if (and under what conditions) I can use it.
Would you mind adding a license to the repository to clarify?
Thanks!

Hi @greschd !
Sure ! Just wait a little bit

Awesome, that was quick! Thanks @MattBystrin!


Api: URL Pattern API implementation

Description

Related issue:  🚧 API: URLPattern #100
Dependencies: urlpattern
This PR uses urlpattern crate (which was created by Deno developers) to implement URLPattern.
The underlying crate, and thus URLPattern as defined here (and also Deno) has difference with the URL Pattern specified: it does not support the ignoreCase option. There is an open PR in urlpattern to support it, but it is already quite old, and not sure if it will be supported.
A single NativeClass is introduced (for URLPattern). For the other components (URLPatternInit, URLPatternInput, URLPatternComponentResult, URLPatternResult) this PR does not introduce native classes, and instead uses needed TryFromJs and IntoJs implementations.
Manual testing

nix develop
cargo run --bin jstz -- repl
>> (function () {
  const pattern = new URLPattern("https://deno.land/foo/:bar");
  console.log(pattern.protocol == "https");
  console.log(pattern.protocol == "https");
  console.log(pattern.hostname == "deno.land");
  console.log(pattern.pathname == "/foo/:bar");
  console.log(pattern.test("https://deno.land/foo/x"));
  console.log(!pattern.test("https://deno.com/foo/x"));
  match = pattern.exec("https://deno.land/foo/x");
  console.log(match);
  console.log(match.pathname.input == "/foo/x");
  // false, but also false in Deno/Chrome
  console.log(match.pathname.groups == { bar: "x" });
})();
[🪵] true
[🪵] true
[🪵] true
[🪵] true
[🪵] true
[🪵] true
[🪵] [object Object]
[🪵] true
[🪵] false
>> (function () {
  const pattern = new URLPattern("/foo/:bar", "https://deno.land");
  console.log(pattern.protocol == "https");
  console.log(pattern.hostname == "deno.land");
  console.log(pattern.pathname == "/foo/:bar");
  console.log(pattern.test("https://deno.land/foo/x"));
  console.log(!pattern.test("https://deno.com/foo/x"));
  const match = pattern.exec("https://deno.land/foo/x");
  console.log(match);
  console.log(match.pathname.input == "/foo/x");
  // false, but also false in Deno/Chrome
  console.log(match.pathname.groups == { bar: "x" });
})();
[🪵] true
[🪵] true
[🪵] true
[🪵] true
[🪵] true
[🪵] [object Object]
[🪵] true
[🪵] false
>> (function () {
  const pattern = new URLPattern({
    pathname: "/foo/:bar",
  });
  console.log(pattern.protocol == "*");
  console.log(pattern.hostname == "*");
  console.log(pattern.pathname == "/foo/:bar");
  console.log(pattern.test("https://deno.land/foo/x"));
  console.log(pattern.test("https://deno.com/foo/x"));
  console.log(!pattern.test("https://deno.com/bar/x"));
  console.log(pattern.test({ pathname: "/foo/x" }));
})();

[🪵] true
[🪵] true
[🪵] true
[🪵] true
[🪵] true
[🪵] true
[🪵] true
>>

Testing

Checklist

[ ] Changes follow the existing code style (use make fmt-check to check)
[ ] Tests for changes have been added
[ ] Internal documentation has been added (if appropriate)
[ ] Testing instructions have been added to PR

LGTM! 🎉
I made a review commit to:

Fix handling of baseURL (incorrect property name in TryFromJs and missing in IntoJS)
Added some TODO comments on handling errors in IntoJs (we should switch to a trait called TryIntoJs soon™)
Minor idiomatic changes to Rust code (namely preferring field access over destructuring)

This PR is ready to be merged, but I'd prefer to hold off on merging it until our testing infrastructure is done.

@erivas-ligo are wpt tests enabled? If not, then this PR will be stuck until so


Block or desc in links

Sometimes it's useful to have a bit of intro text to a set of links made with the element, after the title. Do we want to go down the route of allowing any blocks? That seems crazy. Maybe just allow a single desc as an intro paragraph?

Let's use a single desc for intro block content.

Bumping to Mallard 1.2


Reviewer role / Review reportbacks permission

Create a new role to give to volunteers (or external developers) which grants access to review reportbacks.  Role name for suggestions... reviewer ? volunteer ? moderator ?
Also makes sense to potentially rename / refactor the view any reportback permission as review reportbacks

Change Reviewer admin page access callback/args to check for review any reportback

Change reportback-files/:fid/review access callback/args to check for review any reportback

@mikefantini @barryclark The current Reviewer webform displays a user's email. The Reviewer app specifically does not.
Should this volunteer role be able to access user email? I'm thinking assuming not. Not sure if the Campaigns team ever uses the email address from within the Reviewer form..

yeah @aaronschachter i say no. if we end up seeing a good use case why we would need this we can always add it later, but I'd rather default to not displaying this to volunteer reviewers


Add FlightRadar24 MCP server to list of community servers

Add FlightRadar24 MCP Server
Description
A new Model Context Protocol (MCP) server implementation for real-time flight tracking within Claude Desktop, building on Generative AI technologies to enhance the human-machine interface for transportation sector sensing. By providing real-time access to flight information, this solution aims to improve decision-making and planning in various aspects of transportation, with potential benefits for industry, policy, and research communities. The implementation leverages advanced technologies, including Model Context Protocol, real-time data processing and data fusion, to introduce a new approach to accessing and utilizing flight data. Provided to the community so that it may inform future developments in areas like transportation sector data analytics, sensing technologies, information fusion, and human-machine interface design.
Server Details

Server Type: API Integration
Integration: FlightRadar24 REST API
Capability: Real-time flight data retrieval and processing

Motivation and Context
This MCP server allows Claude to access real-time flight data, enabling users to:

Track specific flights and their status
Get updates on departing/arriving flights at airports
Access emergency flight information
Get real-time ETAs and flight paths

This addition expands Claude's capabilities in aviation-related queries and real-time data processing.
Testing Completed

Tested with Claude Desktop v1.2.0
Verified API responses with sample flight data
Validated error handling for invalid queries
Confirmed real-time data refresh functionality
Tested rate limiting compliance

Breaking Changes

No breaking changes
Additive feature only
Existing MCP configurations remain unchanged

Types of changes

[x] New feature (non-breaking change which adds functionality)
[x] Documentation update

Checklist

[x] I have read the MCP Protocol Documentation
[x] My changes follow MCP security best practices
[x] Server README includes comprehensive setup instructions
[x] Tested with Claude Desktop client
[x] Documentation follows repository style guidelines
[x] Added error handling documentation
[x] Environment variables and configuration options documented

Implementation Notes

Uses secure API key management
Implements rate limiting per FR24 API requirements
Includes error handling for API timeout scenarios
Provides detailed logging for troubleshooting

@jspahrsummers , would you be available to take a look at this PR and provide some feedback? I'd really appreciate your review and insights. Thanks in advance!


[BUG] Some packages no longer install their requirements.

setuptools version
setuptools==68.2.0
Python version
>= 3.8
OS
All OSes
Additional environment information
No response
Description
Packages that change Distribution.install_requires after Distribution._finalize_options is called fail to install requirements.
The Salt codebase has, for a long time, modified Distribution.install_requires in an overridden Distribution.parse_command_line method in it's setup.py.
The changes in #4029 specifically 3c9d6ac96b breaks installing of requirements on most all current and previous Salt releases (see saltstack/salt#64149).
This change will also any other packages that make the assumption install_requires can be modified after the point which _finalize_options get's called in parse_config_files.
Expected behavior
Ideally, preserve previous behavior on order to not break existing package installations.
We, Salt, can fix this issue for future versions but it's a bummer all of our existing versions now fail to install properly.
How to Reproduce
Create a virtual environment. Pip install salt.
Output
This behavior can be observed by pip installing the latest Salt release.
$ pip3 install salt==3006.3
Collecting salt==3006.3
  Using cached salt-3006.3-py3-none-any.whl
Installing collected packages: salt
Successfully installed salt-3006.3

We have similar issue:

setuptools earlier 68.2.0

Installation log
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'done'
Requirement already satisfied: networkx<=3.1 in /agent/_work/_tool/Python/3.11.2/x64/lib/python3.11/site-packages (from openvino-dev) (3.1)
Requirement already satisfied: numpy>=1.16.6 in /agent/_work/_tool/Python/3.11.2/x64/lib/python3.11/site-packages (from openvino-dev) (1.23.5)
Collecting opencv-python (from openvino-dev)
  Obtaining dependency information for opencv-python from https://files.pythonhosted.org/packages/f5/d0/2e455d894ec0d6527e662ad55e70c04f421ad83a6fd0a54c3dd73c411282/opencv_python-<IP_ADDRESS>-cp37-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata
  Downloading opencv_python-<IP_ADDRESS>-cp37-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (19 kB)
Requirement already satisfied: openvino-telemetry>=2022.1.0 in /agent/_work/_tool/Python/3.11.2/x64/lib/python3.11/site-packages (from openvino-dev) (2023.1.1)
Requirement already satisfied: pillow>=8.1.2 in /agent/_work/_tool/Python/3.11.2/x64/lib/python3.11/site-packages (from openvino-dev) (10.0.0)
Collecting pyyaml>=5.4.1 (from openvino-dev)
  Obtaining dependency information for pyyaml>=5.4.1 from https://files.pythonhosted.org/packages/7b/5e/efd033ab7199a0b2044dab3b9f7a4f6670e6a52c089de572e928d2873b06/PyYAML-6.0.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata
  Downloading PyYAML-6.0.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.1 kB)
Requirement already satisfied: requests>=2.25.1 in /agent/_work/_tool/Python/3.11.2/x64/lib/python3.11/site-packages (from openvino-dev) (2.31.0)
Collecting texttable>=1.6.3 (from openvino-dev)
  Downloading texttable-1.6.7-py2.py3-none-any.whl (10 kB)
Collecting tqdm>=4.54.1 (from openvino-dev)
  Obtaining dependency information for tqdm>=4.54.1 from https://files.pythonhosted.org/packages/00/e5/f12a80907d0884e6dff9c16d0c0114d81b8cd07dc3ae54c5e962cc83037e/tqdm-4.66.1-py3-none-any.whl.metadata
  Downloading tqdm-4.66.1-py3-none-any.whl.metadata (57 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 57.6/57.6 kB 10.1 MB/s eta 0:00:00
Processing /agent/_work/1/_w/install_pkg/tools/openvino-2023.2.0-12330-cp311-cp311-manylinux_2_31_x86_64.whl (from openvino-dev)
Collecting scipy<1.11,>=1.8 (from openvino-dev)
  Downloading scipy-1.10.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (34.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 34.1/34.1 MB 77.0 MB/s eta 0:00:00
Requirement already satisfied: charset-normalizer<4,>=2 in /agent/_work/_tool/Python/3.11.2/x64/lib/python3.11/site-packages (from requests>=2.25.1->openvino-dev) (3.2.0)
Requirement already satisfied: idna<4,>=2.5 in /agent/_work/_tool/Python/3.11.2/x64/lib/python3.11/site-packages (from requests>=2.25.1->openvino-dev) (3.4)
Requirement already satisfied: urllib3<3,>=1.21.1 in /agent/_work/_tool/Python/3.11.2/x64/lib/python3.11/site-packages (from requests>=2.25.1->openvino-dev) (1.26.16)
Requirement already satisfied: certifi>=2017.4.17 in /agent/_work/_tool/Python/3.11.2/x64/lib/python3.11/site-packages (from requests>=2.25.1->openvino-dev) (2023.7.22)
Downloading PyYAML-6.0.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (757 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 757.7/757.7 kB 94.4 MB/s eta 0:00:00
Downloading tqdm-4.66.1-py3-none-any.whl (78 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 78.3/78.3 kB 38.0 MB/s eta 0:00:00
Downloading opencv_python-<IP_ADDRESS>-cp37-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (61.7 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.7/61.7 MB 52.8 MB/s eta 0:00:00
Building wheels for collected packages: jstyleson
  Building wheel for jstyleson (setup.py): started
  Building wheel for jstyleson (setup.py): finished with status 'done'
  Created wheel for jstyleson: filename=jstyleson-0.0.2-py3-none-any.whl size=2384 sha256=96a786fcd8366c20a88055535b1be1462018b70bd7a0ec90ae3ba2025fc57b4e
  Stored in directory: /home/AzDevOps/.cache/pip/wheels/ad/63/0e/50090147fb424100f7d9078b71c21b9e7468b6f643515a60d6
Successfully built jstyleson
Installing collected packages: texttable, jstyleson, addict, tqdm, scipy, pyyaml, openvino, opencv-python, openvino-dev
  Attempting uninstall: scipy
    Found existing installation: scipy 1.11.2
    Uninstalling scipy-1.11.2:
      Successfully uninstalled scipy-1.11.2
Successfully installed addict-2.4.0 jstyleson-0.0.2 opencv-python-<IP_ADDRESS> openvino-2023.2.0 openvino-dev-2023.2.0 pyyaml-6.0.1 scipy-1.10.1 texttable-1.6.7 tqdm-4.66.1

with setuptools 68.2.0:

Installation log
Processing /agent/_work/1/_w/install_pkg/tools/openvino_dev-2023.2.0-12331-py3-none-any.whl
Installing collected packages: openvino-dev
Successfully installed openvino-dev-2023.2.0

Hi @dwoz, @ilya-lavrenov, could you please try #4043 and see if that prevents your build to break?
You can test that by installing the version of setuptools given in the PR + wheel in a virtual environment and then running python -m build –no-isolation (from that environment, bonus points for testing pip install –no-build-isolation .. For example:
python3.11 -m venv .venv
.venv/bin/python -m pip install -U 'pip>=23.2' 'wheel>=0.41.2' 'build>=1.0.3'
.venv/bin/python -m pip install https://github.com/abravalheri/setuptools/archive/refs/heads/issue-4042.zip
.venv/bin/python -m build –no-isolation .

This change will also affect any other packages that make the assumption install_requires can be modified after the point which _finalize_options get's called in parse_config_files.

This assumption was never safe, even before setuptools<=68.1.0. Maybe the assumption was working for a subset of specific situations and values of install_requires, but not in general.
The reason being that setuptools was already using _finalize_requires to post-process install_requires, extras_require and provides_extra metadata in order to produce valid .egg-info directories  and "ok-ish" PKG-INFO files to be used in the sdists. Note that the files in the .egg-info directory predate wheels and core metadata standardisation, so the file format is different from the ones you find in a .whl file.
If a customisation modifies these attributes after _finalize_requires has been called, the necessary post-processing is not done. Chances are the files in .egg-info and PKG-INFO may deviate from the file format expected by setuptools, being prone to potential parsing errors.
That may or not interfere with to the way pip parses/uses those files too.
I say "may or not", because for the wheel files, bdist_wheel (which is implemented in pypa/wheel, not in pypa/setuptools) regenerates the METADATA file and discards .egg-info/requires.txt. That may "mascarade" eventual problems in PKG-INFO and .egg-info/requires.txt.

.venv/bin/python -m pip install https://github.com/abravalheri/setuptools/archive/refs/heads/issue-4042.zip

Local experiment with this package showed that issue is resolved.
We are using python3 -m pip wheel . in our scripts.
@abravalheri
Could you please mark package on pypi as yanked? In this case it will not be downloaded by users.

Hi @dwoz, @ilya-lavrenov, could you please try #4043 and see if that solves your problem?
You can test that by installing the version of setuptools given in the PR + wheel in a virtual environment and then running python -m build –no-isolation (from that environment, bonus points for testing pip install –-no-build-isolation .). Something like the following (please revise, I wrote from memory):
python3.11 -m venv .venv
.venv/bin/python -m pip install -U 'pip>=23.2' 'wheel>=0.41.2' 'build>=1.0.3'
.venv/bin/python -m pip install https://github.com/abravalheri/setuptools/archive/refs/heads/issue-4042.zip
.venv/bin/python -m build --no-isolation .
.venv/bin/python -m pip install dist/*.whl
.venv/bin/python -m pip install –-no-build-isolation .

This does indeed resolve the issue for Salt. I validated with the following:
testit/bin/pip3 install 'pip>=23.2' 'wheel>=0.41.2' 'build>=1.0.3'
testit/bin/python -m pip install https://github.com/abravalheri/setuptools/archive/refs/heads/issue-4042.zip
./testit/bin/pip install --no-build-isolation --no-cache salt -v

This assumption was never fully safe, even before setuptools<=68.1.0. Maybe the assumption was working for a subset of specific situations and values of install_requires, but not in general.
The reason being that setuptools was already using _finalize_requires to post-process install_requires, extras_require and provides_extra metadata in order to produce .egg-info directories and "ok-ish" PKG-INFO files to be used in the sdists. Note that the files in the .egg-info directory predate wheels and core metadata standardisation, so the file format is different from the ones you find in a .whl file.

This makes perfect sense and is clear based on how _finalize_requires works. We've had plans to fix the way we handle this in salt and hope to address it in the next major release. Having said that, if we can keep older versions working as expected with this proposed fix it will really help.

If a customisation modifies these attributes after _finalize_requires has been called, the necessary post-processing is not done. Chances are the files in .egg-info and PKG-INFO may deviate from the file format expected by setuptools, being prone to potential parsing errors.
That may or not interfere with to the way pip parses/uses those files too. I say "may or not", because for the wheel files, bdist_wheel (which is implemented in pypa/wheel, not in pypa/setuptools) regenerates the METADATA file and discards .egg-info/requires.txt. That may "mascarade" eventual problems in PKG-INFO and .egg-info/requires.txt.

Thanks, this all makes sense as well. For us, I think a better way to handle this would have been to make our modifications in Distribution.__init__ long before _finalize_options is called. However, we're looking at moving away from setup.py completely in favor of pyproject.toml.

Thank you very much for trying out. A new version should be out soon (once the CI finishes running).

Now that the new package is in PyPI, I don't see a strong reason for yanking (also because this was not a generalised bug, just an oversight in the way the customisation was implemented for some specific packages).

@abravalheri Immense thanks for tackling this so quickly~!


add diff of AA and EIP 4337

This pr includes a paragraph on:

AA and Paymaster at aa.md file, and the note lines to connect with differences of Native AA vs EIP 4337

@AlbionaHoti ready when you are ... this probably needs a bit of a copy edit. I can remove the yarn issues too when I do it.


mariadb rework (WIP)

Motivation for this change
We've had quite some split-related problems with the default mysql provider lately; most recently we're unable to update our vulnerable version #17340.
Things done

[x] Tested using sandboxing
(nix.useChroot on NixOS,
or option build-use-chroot in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

TODO:

[ ] check other libmysqlclient users for problems similar to Qt, as headers for it are on a separate prefix now.
[ ] find a less radical solution for (possible) 16.03 vulnerability.

This should've been filed against staging :-/ but I didn't expect this PR to be merged by the green button anyway.

Why is this a mass rebuild?

Well, it rebuilds all Qt, but that's probably not too much actually.

There might be some problems, but I staged it already.

Now it's in master.


[nri-kube-events] bump event forwarder sidecar version

Is this a new chart
no
What this PR does / why we need it:
bumps event forwarder (infra agent) sidecar version
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

Newer version of the bumped sidecar includes curl to facilitate troubleshooting.

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [mychartname])

check that canaries are running with this version since yesterday without issues


Please consider fixing issues detected by repository checker

Notification from ioBroker Check and Service Bot
Dear adapter developer,
I'm the ioBroker Check and Service Bot. I'm an automated tool processing routine tasks for the ioBroker infrastructure. I have recently checked the repository for your adapter haassohn for common errors and appropiate suggestions to keep this adapter up to date.
This check is based the current head revisions (master / main  branch) of the adapter repository
Please see the result of the check below.
ioBroker.haassohn
   -
ERRORS:

[x] :heavy_exclamation_mark: [E026] "{'engines': {'node'>='16'}}" is required at package.json, "{'engines':{'node'>='18'}}" is recommened
[x] :heavy_exclamation_mark: [E033] @iobroker/adapter-core 1.0.3 specified. 3.1.4 is required as minimum, 3.1.6 is recommended. Please update dependencies at package.json
[x] :heavy_exclamation_mark: [E036] @iobroker/testing 2.3.0 specified. 4.1.3 is required as minimum,  4.1.3 is recommended. Please update devDependencies at package.json
[ ] :heavy_exclamation_mark: [E145] No "common.news" found for actual version 1.0.11 in io-package.json
[ ] :heavy_exclamation_mark: [E204] Versions "1.0.10, 1.0.5, 0.2.8, 0.2.7, 0.2.6, 0.2.5, 0.2.4, 0.2.3, 0.2.2" listed at common.news at io-package.json do not exist at NPM. Please remove from news section.
[x] :heavy_exclamation_mark: [E701] No actual year found in LICENSE. Please add "Copyright (c) 2024 Marvin Grieger<EMAIL_ADDRESS>at the start of LICENSE

WARNINGS:

[ ] :eyes: [W105] Missing suggested translation into ru,pt,nl,fr,it,es,pl,uk,zh-cn of "common.titleLang" in io-package.json.
[ ] :eyes: [W109] Missing suggested translation into uk of "common.desc" in io-package.json.
[x] :eyes: [W115] "common.tier" is required in io-package.json. Please check https://github.com/ioBroker/ioBroker.docs/blob/master/docs/en/dev/objectsschema.md#adapter.
[ ] :eyes: [W130] Many "common.news" found in io-package.json. Repositorybuilder will truncate at 7 news. Please remove old news.
[ ] :eyes: [W145] Missing suggested translation into uk of some "common.news" in io-package.json.
[ ] :eyes: [W173] Potential sensitive data "pin" not listed at "protectedNative" in io-package.json
[ ] :eyes: [W174] Potential sensitive data "pin" not listed at "encryptedNative" in io-package.json
[ ] :eyes: [W181] "common.license" in io-package.json is deprecated. Please define object "common.licenseInformation"
[ ] :eyes: [W184] "common.materialize" is deprecated for admin >= 5 at io-package.json. Please use property "adminUI".
[ ] :eyes: [W184] "common.title" is deprecated and replaced by "common.titleLang". Please remove from io-package.json.
[ ] :eyes: [W202] Version of package.json (1.0.11) doesn't match latest version on NPM (1.0.9)
[ ] :eyes: [W853] .npmignore found - consider using package.json object "files" instead.

SUGGESTIONS:

[ ] :pushpin: [S522] Please consider migrating to admin 5 UI (jsonConfig).

Please review issues reported and consider fixing them as soon as appropiate.
Errors reported by repository checker should be fixed as soon as possible. Some of them require a new release to be considered as fixed. Please note that errors reported by checker might be considered as blocking point for future updates at stable repository.
Warnings reported by repository checker should be reviewed. While some warnings can be ignored due to good reasons or a dedicated decision of the developer, most warnings should be fixed as soon as appropiate.
Suggestions reported by repository checker should be reviewed. Suggestions can be ignored due to a decision of the developer but they are reported as a hint to use a configuration which might get required in future or at least is used be most adapters. Suggestions are always optional to follow.
You may start a new check or force the creation of a new issue at any time by adding the following comment to this issue:
@iobroker-bot recheck
@iobroker-bot recreate
Please note that I (and the server at GitHub) have always plenty of work to do. So it may last up to 30 minutes until you see a reaction. I will drop a comment here as soon as I start processing.
Feel free to contact me (@iobroker-bot) if you have any questions or feel that an issue is incorrectly flagged.
And THANKS A LOT for maintaining this adapter from me and all users.
Let's work together for the best user experience.
your
ioBroker Check and Service Bot
@mcm1957 for evidence
Last update at Sat, 07 Sep 2024 13:57:08 GMT

@iobroker-bot recheck

This issue has been updated by ioBroker Check and Service Bot
The following issues are not fixed and have been reopened
[E701] No actual year found in LICENSE. Please add "Copyright (c) 2024 Marvin Grieger<EMAIL_ADDRESS>at the start of LICENSE
RECHECK has been performed as requested.

@ioBroker-Bot recheck

This issue has been updated by ioBroker Check and Service Bot
RECHECK has been performed as requested.
No changes detected.

Issue outdated due to RECREATE request. Follow up issue #64 has been created.
This issue will be closed.
your
ioBroker Check and Service Bot


python27Packages.eventlet: 0.28.1 -> 0.29.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python27Packages.eventlet is: "A concurrent networking library for Python"
meta.homepage for python27Packages.eventlet is: "https://pypi.python.org/pypi/eventlet/"
meta.changelog for python27Packages.eventlet is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 0.29.1 with grep in /nix/store/vsjkwrh2vawamg4lplvnifq7n6vslykf-python2.7-eventlet-0.29.1

directory tree listing: https://gist.github.com/9b0520bcfd1692ae0498aee3afa9046e

du listing: https://gist.github.com/c262c94cd98657e2bae342a39dedc856

Rebuild report (if merged into master) (click to expand)

91 total rebuild path(s)

23 package rebuild(s)

23 x86_64-linux rebuild(s)
23 i686-linux rebuild(s)
22 x86_64-darwin rebuild(s)
23 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
appdaemon
gdbgui
patroni
python27Packages.aioeventlet
python27Packages.cassandra-driver
python27Packages.eventlet
python27Packages.kazoo
python27Packages.zake
python37Packages.cassandra-driver
python37Packages.eventlet
python37Packages.flask-socketio
python37Packages.kazoo
python37Packages.python-engineio
python37Packages.python-socketio
python37Packages.zake
python38Packages.cassandra-driver
python38Packages.eventlet
python38Packages.flask-socketio
python38Packages.kazoo
python38Packages.python-engineio
python38Packages.python-socketio
python38Packages.zake
zk-shell

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/vsjkwrh2vawamg4lplvnifq7n6vslykf-python2.7-eventlet-0.29.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python27Packages.eventlet https://github.com/r-ryantm/nixpkgs/archive/60d2314377eacce31a4b8d9b3e27fb8b4c066376.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/vsjkwrh2vawamg4lplvnifq7n6vslykf-python2.7-eventlet-0.29.1
ls -la /nix/store/vsjkwrh2vawamg4lplvnifq7n6vslykf-python2.7-eventlet-0.29.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

3 packages failed to build:

python27Packages.cassandra-driver
python37Packages.cassandra-driver
python38Packages.cassandra-driver

20 packages built:

appdaemon
gdbgui
patroni
python27Packages.aioeventlet
python27Packages.eventlet
python27Packages.kazoo
python27Packages.zake
python37Packages.eventlet
python37Packages.flask-socketio
python37Packages.kazoo
python37Packages.python-engineio
python37Packages.python-socketio
python37Packages.zake
python38Packages.eventlet
python38Packages.flask-socketio
python38Packages.kazoo
python38Packages.python-engineio
python38Packages.python-socketio
python38Packages.zake
zk-shell

Maintainer pings

python38Packages.cassandra-driver is marked broken on master.

Result of nixpkgs-review pr 105401 1

6 packages marked as broken and skipped:

python27Packages.cassandra-driver
python27Packages.zake
python37Packages.cassandra-driver
python37Packages.zake
python38Packages.cassandra-driver
python38Packages.zake

8 packages failed to build:

appdaemon
gdbgui
python37Packages.flask-socketio
python37Packages.python-engineio
python37Packages.python-socketio
python38Packages.flask-socketio
python38Packages.python-engineio
python38Packages.python-socketio

8 packages built:

python27Packages.aioeventlet
python27Packages.eventlet
python27Packages.kazoo
python37Packages.eventlet
python37Packages.kazoo
python38Packages.eventlet
python38Packages.kazoo
zk-shell

already on staging
[23:08:48] jon@nixos ~/projects/nixpkgs (staging-next)
$ nix eval -f default.nix python3Packages.eventlet.version
"0.29.1"


refactor(validator): pass object for validation into validate

This is mostly meant to serve as a basis for conversation about refactorings for the validator in general pairing with this comment: https://github.com/aurelia/validatejs/issues/33#issuecomment-217710788.
As you can see this begins to decouple the validator from the data it is validating. The refactor is incomplete as the metadata is still stored on the model (further changes down this path would have to be discussed), but I think it begins to exemplify what I was talking about in the comment linked above.
Thoughts?

If we are going to do this we need to move the config off of the object as well.  Then when the object is passed in we get the reporter and the config for that object.

@PWKad agreed, this was more to start showing intent through code to pair with the conversation. A more complete example would look (I think) something more like:
validator = injectedValidator
  .ensure('firstName').length({ minimum: 3 }).required()
  .ensure('lastName').length({ maximum: 5}).presence().required();

...snip...

validator.validate(obj);

I'm not really thinking so much about the implementation right now, just brainstorming what the user facing api might be.

@PWKad Has this issue been addressed in some other design work?

@EisenbergEffect it was part of the plan proposed by @PWKad and @jdanyow, however we seem to be bogged down by discussion over on #33. I'll close this for the time being, as it was only meant to serve as the basis for conversation


Add majonez alias

This is an alias somebody would use after merging a PR on GitHub.
It checks out master, does a pull and deletes the previous branch the user was working on.

I would add kurwa to majonez


401 Client Error: Unauthorized

I'm running into intermittent errors when sending updates to firebase with this library.
For example, if I send a PUT request to this firebase resource: /test/123 with the data payload of {'test': 123} it will randomly fail with a response of 401 Client Error: Unauthorized.
It seems very random. I sent two requests back-to-back and the first one failed while the second succeeded.
This was the first payload:
eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eyJ2IjogMCwgImRlYnVnIjogZmFsc2UsICJhZG1pbiI6IHRydWUsICJpYXQiOiAxNDQ4MDM4Njk5LCAiZCI6IHsiZGVidWciOiBmYWxzZSwgInByb3ZpZGVyIjogInBhc3N3b3JkIiwgImFkbWluIjogdHJ1ZSwgImVtYWlsIjogInRlc3RAdGVzdC5jb20ifX0.07P1p5GhKAxbzXv4UK1ggohsOKKM5heJahRM-R8npBs
This was the second:
eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eyJ2IjogMCwgImRlYnVnIjogZmFsc2UsICJhZG1pbiI6IHRydWUsICJpYXQiOiAxNDQ4MDM4NzAxLCAiZCI6IHsiZGVidWciOiBmYWxzZSwgInByb3ZpZGVyIjogInBhc3N3b3JkIiwgImFkbWluIjogdHJ1ZSwgImVtYWlsIjogInRlc3RAdGVzdC5jb20ifX0.1yJxoP-CLNWjs0305Y4_MUlxGM7GDgt97EGoqtIKJ3k
If you look at these tokens at http://jwt.io/ you'll see the first token had an iat claim of<PHONE_NUMBER> and the next was<PHONE_NUMBER>.
Because this issue seems to be rather random, my suspicion leads me to believe it has to do with the timing and the iat claim, but I may be barking up the wrong tree.
It looks like this library uses different logic than the official python library when creating the iat claim, it appears firebase has since updated their logic. I've updated my local codebase to use their new code, but it didn't help.
Btw it seems others may have experienced this issue:

https://github.com/ozgur/python-firebase/issues/23#issuecomment-63167838
http://stackoverflow.com/questions/32812640/401-unauthorized-with-python-firebase

I've shot off an email to firebase support and they think it could be related to the iat claim as well but at this point I am seeking other opinions. Thanks!

After inspecting the response.text, the message from firebase is:
{
  "error" : "Auth token is expired"
}

Ok, I found that if I explicitly add an exp claim then this issue goes away.
claims['exp'] =  timegm((datetime.datetime.utcnow() + datetime.timedelta(days=7)).utctimetuple())
However, there's no easy way to do this, I had to manually edit the firebase.py file. Is there a better way to add the exp claim?

For anyone who is experiencing this issue, I was able to get it around it by going into the Login & Auth settings and changing the value to 24 hours.
Note: it was already set to 24 hours so I set it to 0 hours then back to 24. That must've triggered something.
In addition, you may also come across this if the forge rules simulator isn't working. I was experiencing an issue when trying to simulate rules, it would quickly run the simulator but then reset the text back to the default 'Enter a path to read and then press...'. It never displayed the actual result.
Looking in the dev console I saw the following log statements:

FIREBASE WARNING: auth() was canceled: Auth token is expired.
FIREBASE WARNING: set at / failed: permission_denied


can i update crud after installation?

Hi!
i have installed crud package but after that i found new fixes , improvement and upgrades in that package
can i just update this package alone?

Hi @c1t1zen ,
Yes you can. You can find the upgrade guides in the documentation: https://laravel-backpack.readme.io/docs/upgrade-guides
Cheers!

Any other minor update can easily be done with composer update.


CCDB 5048: Adding topic2table map config to BQ sink Connector.

Adding topic2table map config to BQ sink Connector.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 6 committers have signed the CLA.:x: gharris1727:x: aakashnshah:x: ypmahajan:x: ManasjyotiSharma:x: sagarrao12:x: ConfluentJenkinsYou have signed the CLA already but the status is still pending? Let us recheck it.


New version: ArtifexSoftware.GhostScript version 10.02.0

Pull request has been created with WinGet Automation :rocket:

Automatic Validation ended with:

Automatic Validation ended with:

Manual Validation ended with:

Is there an installer switch to complete the install automatically?

@stephengillie

Is there an installer switch to complete the install automatically?

No it is not. Since version 10.01.0 they disabled because of security reasons the silent install option (Source: https://artifex.com/news/ghostscript-10.01.0-disabling-silent-install-option).
But it is essential that people wont install version 10.0.0 as main version because < 10.02.0 have massive vulnerability that allows remote code execution. [CVE-2023-43115]


I don't understand the function def noise_images(self, x, t)

Assume that we have img_{0}, img_{1}, ..., img_{T}, which are obtained from adding the noise iteratively. I understand that img{t} is given by the formula "sqrt_alpha_hat * img_{0} + sqrt_one_minus_alpha_hat * Ɛ".
However, I don't understand the function "def noise_images(self, x, t)" in [ddpm.py].
It return Ɛ, where Ɛ = torch.randn_like(x). So, this is just a noise signal draw directly from the normal distribution. I suppose this random noise is not related to the input image? It is becasue randn_like() returns a tensor with the same size as input x that is filled with random numbers from a normal distribution with mean 0 and variance 1
In training, the predicted noise is compared to this Ɛ (line 80 in [ddpm.py]).
Why we are predicting this random noise? Shouldn't we predict the noise added at time t, i.e. "img_{t} - img_{t-1}"?

Hey @colinsctsang, the answer to your question is in the math video "Diffusion Models | Paper Explanation | Math Explained" by the same author.
I'll try to explain but this is not my area of expertise and I will skip many steps. Again watch the math video if you want a comprehensive tutorial on this.
We are interested in the forward process
q(x_t | x_t-1) = Normal(x_t; alpha_t x_t-1, beta I)
We do not have x_t-1 but only x_0 (i.e. the initial image). We can keep expanding the x_t-1 into x_t-2 ... x_0 and we land on the equation,
q(x_t|x_o) = N(x_t;√(alpha_hat_t_), √(1 - alpha_hat_t)I)
Use "Reparameterization Trick" to get the below equation where ε is sampled from a unit normal distribution,
q(x_t|x_0, t) = √(α_bar_t) + √(1 - α_bar_t)ε
This is a sample from the distribution of images after t timesteps of adding noise.
Now we can train a network to learn the function (aka reverse/denoising process) p(x_0 | x_t, t) which predicts the noise in the image at timestep t. It still does so iteratively but the maths allows us to do this in a single step. I think doing everything iteratively should also work but it will be very slow.
The final objective magically mathematically comes out that we can just compute the MSE between this epsilon and the predicted epsilon (that is the model output).

Thank you very much for your answer. I appreciated it!
I am sorry that I am still confused about this:
In the function "def sample", we can see that the variable "t" is looped backward step by step (i.e., T -> T-1 -> ... -> 1). And this "t" is used as an input in the trained U-Net. Hence, the U-Net is used to recover the image iteratively. In other words, U-Net is an approximation for the noise in p(x_{t-1}|x_t, t).
However, according to your explanation in the training stage, the U-Net is trained to approximate the noise in p(x_0 | x_t, t). So, I suppose U-Net can go directly to the initial state (i.e., the final output). Why do we need to do it iteratively in the "def sample" function when we are trying to generate an output?
To conclude, I am trying to understand why we use U-Net to approximate p(x_0 | x_t, t) at the training phase, but it is used as p(x_{t-1} | x_t, t) in the testing phase.
Once again, thank you for answering me!

Thank you very much for your time. I think I understand now.


Add Update option

Cookbook version
6.0.1
Feature request:
Add ability to install latest version of rsyslog or newer.  We are trying to use an external yum repo to get a newer RPM, but the cookbook does not allow us to set it to latest

Updating packages is something we try to keep out of cookbooks. It's a pretty easy thing to add in a wrapper if you want control of how updates occur. In general it makes people pretty nervous in community cookbooks so we avoid it.


increase icon size option?

Can you add an option for different sizes by which the icons are displayed ?

I'd be willing to accept a PR that added an option to enable multiple sizes of icons.


Vulnerability roundup 106: libspf2-1.2.10: 1 advisory [9.8]

search, files

[ ] CVE-2021-20314 CVSSv3=9.8 (nixos-21.05, nixos-unstable)

CVE details
CVE-2021-20314
Stack buffer overflow in libspf2 versions below 1.2.11 when processing certain SPF macros can lead to Denial of service and potentially code execution via malicious crafted SPF explanation messages.

Scanned versions: nixos-21.05: 6120ac5cd20; nixos-unstable: bc9b956714e.
Cc @pacien

There hasn't been a release since the CVE was discovered so we need to add the fixing commit as a patch. We have forked the library to also apply more fixes from other PRs that were unmerged.

In my opinion no substantial objections have been raised on Discourse.

I'm closing this issue because this vulnerability has been patched with commit 46b7a5b and backported on 21.05 in 2fd6748, thanks to @dasJ.
The discussion about whether we want to switch to a fork or not can continue on the dedicated Discourse thread.


Allow the profile editor to edit screen_name?

Now that we've disabled the check for uniqueness on screen names, can we let people check their screen name, since we're no longer worried about collisions?

This will be pushed to production when we deploy all the new features


Run on OpenFaaS Cloud Community Cluster

This should run on the OpenFaaS Cloud Community Cluster.
What do we need to do to enable that?
Are any changes required?

Derek close: implemented today 👍


multiple camera network mode

I am using pyrealsense and pyrealsense-net library and use rs-server to stream data.
I can see the data of the first camera but I can not see the data of other cameras.
There is no option in realsense.viewer too.
Can you please help me?
import pyrealsense2 as rs
import pyrealsense2_net as rsnet

ctx = rs.context()

ip='x.x.x.x'
print ('Connecting to ' + ip)
dev = rsnet.net_device(ip)
print ('Using device 0,', dev.get_info(rs.camera_info.name), ' Serial number: ', dev.get_info(rs.camera_info.serial_number))

# how to get device 1???

Hi @modaresimr  There are known issues with using pyrealsense2-net and rs-server together.  Examples of cases describing the problems are at https://github.com/IntelRealSense/librealsense/issues/9372 and https://github.com/IntelRealSense/librealsense/issues/9946
RealSense users who have tried have typically ended up switching to successfully using re-server with C++ or instead using EtherSense, the dedicated Python ethernet tool for RealSense that was the predecessor of re-server.
https://github.com/IntelRealSense/librealsense/tree/master/wrappers/python/examples/ethernet_client_server
If your preference is to continue attempting to use pyrealsense2-net with rs-server despite the known issues then my first question would be whether you have all of the cameras attached to the same computer / computing device or one camera on each computer.  Usually with multiple camera RealSense ethernet networking, each camera is attached to its own individual computing device such as Raspberry Pi 4 (such as 5 cameras, 5 Pi's).

Thank you for your comment.
I just want to connect multiple cameras to a single device (Pi 4).
I have no problem in build or connecting to a device
The only problem is I want to know if it is possible to connect multiple cameras.
I had an idea that if it is possible to run rs-server with different ports and different devices, is it possible?

If you plan to have multiple cameras active and streaming simultaneously on the same device then a Pi 4 would not be suitable as the processing demands of multiple cameras streaming at the same time would be too great.
For up to 4 active cameras on the same computer, a computer with a processor that is an Intel i7 or greater would be recommended.  For 2 cameras, an Up Squared board should be able to handle the processing demand.
If you have multiple cameras attached to a Pi 4 but can only access one, it is possible that the other cameras are not being detected and enabled because the Pi 4 has insufficient computing or power supply resources to meet the needs of more than one camera at once.
It may be possible to have multiple cameras connected to the same Pi 4 if you only had 1 camera at a time streaming and the other cameras inactive, as the processing demands would be significantly lower.

Hi @modaresimr  Do you require further assistance with this case, please?  Thanks!

Thank you for your complete response
I plan to use more powerful computer 😉

Thanks very much for the update.  If you are satisifed with the outcome of the case, please feel free to close it using the close Issue button under the comment writing box.  Thanks again!

@modaresimr how did you manage to run pyrealsense2_net? Could you share some details like what version of the liberalsense sdk you use and OS?

Hi @mrazadal  the RealSense SDK's network device system was removed in SDK version 2.54.1 in preparation for adding a new networking system in an upcoming SDK release.  So I recommend using SDK 2.51.1 or older if you need networking functionality.
However, if you are using Python then the SDK's alternative EtherSense Python-based networking tool may meet your needs.
https://github.com/IntelRealSense/librealsense/tree/master/wrappers/python/examples/ethernet_client_server
https://dev.intelrealsense.com/docs/depth-camera-over-ethernet-whitepaper

@MartyG-RealSense I had no issue building the library (2.53.1) including pyrealsense2 and pyrealsense2-net but when I try to import pyrealsense2_net I get error an error module not found. I am familiar with ethernet_client_server but I was curious how @modaresimr made the pyrealsense2_net work. If pyrealsense2-net could work, it would be much simpler to use than ethernet_client_server.

pyrealsense2-net has a history of problems that have prevented it from working for some RealSense users, like in the case at https://github.com/IntelRealSense/librealsense/issues/9946
Thanks very much for sharing what worked for you.  In the above discussion, a RealSense user found that replacing import pyrealsense2_net as rsnet with from pyrealsense2 import pyrealsense2_net as rsnet also worked for them.
2.53.1 also contains the pyrealsense2-net support but I suggested 2.54.1 because that would be the best choice if the RealSense ROS wrapper also needed to be used, since there is not a ROS wrapper for 2.53.1.

@mrazadal  I recommend you to see my repository at https://github.com/modaresimr/lissi_realsense/
By the way, using network is not recommended at all since it won't give you quality images with a lot of disconnection


New version: GodotEngine.GodotEngine version 4.2.1

Description

Resolve #130185

Checks

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Hi @Dragon1573

Current manifest version 4.2 has 2 parameters, which is less than this PR's version number 4.2.1's 3 parameters.

Is this intentional?


Jest tests cause require-dir to break in dependencies

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
When a Jest test requires a module in node_modules that uses require-dir with a relative path, the path is resolved relatively to the package that has the executed Jest test instead of the package that uses require-dir (what's supposed to happen). This issue does not occur if exactly the same code is executed directly through Node instead of Jest.
If the current behavior is a bug, please provide the steps to reproduce and either a repl.it demo through https://repl.it/languages/jest or a minimal repository on GitHub that we can yarn install and yarn test.

Clone https://github.com/nickmccurdy/jest-require-dir-bug
npm install-test

~/Repos/jest-require-dir-bug → node index.test.js
~/Repos/jest-require-dir-bug → npm test

> @ test /Users/nick/Repos/ncu-example
> jest

 FAIL  ./index.test.js
  ● Test suite failed to run

    ENOENT: no such file or directory, scandir '/Users/nick/Repos/ncu-example/dir'

      at Object.fs.readdirSync (fs.js:911:18)
      at requireDir (node_modules/require-dir/index.js:25:20)
      at Object.<anonymous> (node_modules/example/index.js:1:112)
      at Object.<anonymous> (index.test.js:1:90)

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total
Time:        0.88s
Ran all test suites.
npm ERR! Test failed.  See above for more details.

This issue can also be observed by requiring code that uses npm-check-updates (which also uses require-dir) via JavaScript in a Jest test.
What is the expected behavior?
Jest's execution environment should allow require-dir to function normally, requiring a relative directory with the requireDir('./example') syntax even in a dependency. Jest should also behave the same as Node itself, or work around this difference in execution environments.
Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.

Empty configuration
index.test.js or __tests__/index.js naming conventions
Jest 15-21.2.1
require-dir 0.3.2
Node 8.6.0
npm 5.4.2
macOS 10.13

Looks like it's a wontfix: https://github.com/facebook/jest/issues/1657
Currently looking into how and the right place to mock the problematic part of my dependency graph.

Thanks for the helpful issue link. I also noticed that when I did use __dirname, I got errors suggesting that Jest was marking the directory as empty (as reported in that issue).
While I personally dislike directory require utilities (in favor of index.js files using static dependencies), it's unfortunate that this causes some third party library (including npm-check-updates to fail in Jest tests when the tested project itself doesn't use them. Is there any way around this besides reimplementing module.parent or patching dependencies to not use module.parent? I was also thinking about a mocking solution, I wonder if we could somehow automatically mock module.parent in a way that could allow this utilities to continue working automatically (or at least with some sort of additional opt in mocking API).

At this point I'm ok if somebody adds support for module.parent, granted the PR includes tests.
We do not support require.cache, so it would only work if you also call jest.resetModules(), which I guess is fine for your use-case, right?

Cool, do you know roughly how involved it would be to add support? Is it a matter of hooking into module loading in the VMs and adding metadata or is it a more invasive refactor?

Shouldn't be too much, check out jest-runtime's main module, which is Jest's require implementation.

@nickmccurdy I've opened a PR for it


[BUG] Review panel broken in several ways

Describe the bug
I installed the extension for the first time. When I tried to use the review pane many things failed:

When I create a note with the tag #review, nothing appears, I have to restart Obsidian in order to see it.
The arrows are too close to the title of the note (unlike screenshots I've seen around the web).
Sometimes an open arrow (pointing downwards) is shown but the section is collapsed.
Sometimes the same section (for some particular day) appears twice, with some notes in one and other notes in the other.
Sometimes some note is not visible but if I collapse a section then the note appears below it.

To reproduce see the screenshots. The expected behavior is obvious.
Screenshots

Versions (please complete the following information):

OS: macOS Sonoma
Obsidian version: 1.5.3
Plugin version: 1.11.1
If on desktop, Installer version: [run this.navigator.appVersion on the developer console, e.g. 5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) obsidian/0.12.3 Chrome/89.0.4389.128 Electron/12.0.6 Safari/537.36"]

'5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) obsidian/1.5.3 Chrome/114.0.5735.289 Electron/25.8.1 Safari/537.36'

Hi @memeplex
Before the bugs are fixed, there is one tip that hopefully will make this less frustrating for you.
Instead of restarting Obsidian, simply click on the flashcard icon.
This has a side effect of regenerating the note review sidebar.

Cheers
Ronny

Hi @karimodm, how are you? Hope all going well.
Given your good work with #424, do you think you would be able to work on this one? Or parts of it?
Cheers
Ronny


Release into master

It looks like I can't review my own pr. 😜

@chetnieter or @cjh1 can you review to merge?

@TristanWright Did this get merged?


Added the todo and todo folder a dynamic todo app with best UI and dyanamic project

See in ss the UI is best and hover also nice and when you are adding the TODO after refreshing it doesn't disappear it remain same particular user sees only there particular todo's

@harshalhonde21 you need to rename your directory from ToDo-harshalhonde to harshalhonde21, rest is fine.

I make the change please review and merge it


WIP: Exception output

Use logger.exception to format current traceback in an error

@rotu Friendly ping.

Oof. Converting to a draft. BTW, do you have a preference between logger.exception(msg) versus logger.error(msg, exc_info=True)?

do you have a preference between logger.exception(msg) versus logger.error(msg, exc_info=True)?

Within an except I would lean toward the former since that is exactly what that method is supposed to be used for.


Link

Have you read the Contributing Guidelines on Pull Requests?
Yes, I have read them.
Description
Just added functionalities of doubly linked list.
Checklist

[X] I've read the contribution guidelines.
[X] I've checked the issue list before deciding what to submit.
[X] I've edited the README.md and link to my code.

Related Issues or Pull Requests
Issue id #508

@siddharth25pandey  ,sir pls help me how could i solve this conflict, I have done the changes as told by you,

And @siddharth25pandey  Pls review it sir ,I have done the changes as told by you.


[DDW-716] Implement static screens for signing dApp interaction transactions

This PR implements static screens for signing dApp interaction transactions.
Todos

[x] dApp transaction request dialog
[x] Transaction confirmation Assets list component
[x] Missing token
[x] Add wallet dropdown option
[x] Togglable content
[x] Copy + translation

Screenshots

Testing Checklist

Slack QA thread
[ ] Test

Review Checklist
Basics

[ ] PR has been assigned and has appropriate labels (feature/bug/chore, release-x.x.x)
[ ] PR is updated to the most recent version of the target branch (and there are no conflicts)
[ ] PR has a good description that summarizes all changes
[ ] PR has default-sized Daedalus window screenshots or animated GIFs of important UI changes:

[ ] In English
[ ] In Japanese

[ ] CHANGELOG entry has been added to the top of the appropriate section (Features, Fixes, Chores) and is linked to the correct PR on GitHub
[ ] Automated tests: All acceptance and unit tests are passing (yarn test)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in development build (yarn dev)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in production build (yarn package / CI builds)
[ ] There are no flow errors or warnings (yarn flow:test)
[ ] There are no lint errors or warnings (yarn lint)
[ ] There are no prettier errors or warnings (yarn prettier:check)
[ ] There are no missing translations (running yarn manage:translations produces no changes)
[ ] Text changes are proofread and approved (Jane Wild / Amy Reeve)
[ ] Japanese text changes are proofread and approved (Junko Oda)
[ ] UI changes look good in all themes (Alexander Rukin)
[ ] Storybook works and no stories are broken (yarn storybook)
[ ] In case of dependency changes yarn.lock file is updated

Code Quality

[ ] Important parts of the code are properly commented and documented
[ ] Code is properly typed with flow
[ ] React components are split-up enough to avoid unnecessary re-renderings
[ ] Any code that only works in main process is neatly separated from components

Testing

[ ] New feature/change is covered by acceptance tests
[ ] New feature/change is manually tested and approved by QA team
[ ] All existing acceptance tests are still up-to-date
[ ] New feature/change is covered by Daedalus Testing scenario
[ ] All existing Daedalus Testing scenarios are still up-to-date

After Review

[ ] Merge the PR
[ ] Delete the source branch
[ ] Move the ticket to done column on the YouTrack board
[ ] Update Slack QA thread by marking it with a green checkmark

@daniloprates A few comments for this dialog:

When the amount of the token is not enough, the red tooltip overlaps the other tooltips for that element. Check this video. Can this be improved? Maybe changing the orientation of the red tooltip?
There are a few translations missing in Japanese. Check screenshots 1, 2 and 3
When there is no enough ADA, there is no indication on the dialog. Shouldn't the dropdown be outlined in red as on this design? Same with the scenario when the token isn't enough.

@gabriela-ponce thanks! I've fixed the items:

When the amount of the token is not enough, the red tooltip overlaps the other tooltips for that element. Check this video. Can this be improved? Maybe changing the orientation of the red tooltip?

Fixed for both cases. Please notice, in case the dialog height is not tall enough, it will open upwards and there's nothing we can do.

There are a few translations missing in Japanese. Check screenshots 1, 2 and 3

All fixed ツ

When there is no enough ADA, there is no indication on the dialog. Shouldn't the dropdown be outlined in red as on this design? Same with the scenario when the token isn't enough.

It's done. I'll reach for proper copy & translation on Monday.

@daniloprates Hey Danilo.
I have a question regarding latest fix for scenario when wallet has not enough ADA. If this happens shouldn't we disable Continue button ? If wallet has not enough ADA then it can't proceed.

@daniloprates Hey Danilo.
I have a question regarding latest fix for scenario when wallet has not enough ADA. If this happens shouldn't we disable Continue button ? If wallet has not enough ADA then it can't proceed.

Nice catch, @dmitrii-gaico. Fixed it.

@daniloprates All the fixes look great, nice job!
Here is a screenshot of some translations in Japanese that are still missing (I know the first one is still pending, mentioning it for tracking purposes).

Hi @daniloprates ,
Tested on 18800.
I am not sure if this is relevant or not but I'm including this for consistency reason. I noticed that the displayed index of the token starts from position "0" screenshot 1, in the webApp when sending multiple tokens, it starts from position "1" screenshot 2.

@gabriela-ponce @miorsufianiohk thanks for the reports. I've added the missing Japanese translation and increased the Token number, so it starts at 1

something wrong with scroll

confused a bit with error message and popup shouldn't be red I suppose

Errors are about almost the same but one has explanations as a separate sentence, other in brackets

looks like this button should be moved to the top (1px)

missing spacing between elements

with 20px (instead of 25px) it looks better

Initially, I planned wallet input should be red in any error case, as it's the source of a problem :D any thoughts?

Not sure if someone already reported a typo so here it is :

Initially, I planned wallet input should be red in any error case, as it's the source of a problem :D any thoughts?

@alexander-rukin It can be confusing because hovering the wallets dropdown won't give you any feedback

Initially, I planned wallet input should be red in any error case, as it's the source of a problem :D any thoughts?

@alexander-rukin It can be confusing because hovering the wallets dropdown won't give you any feedback

it's ok, we highlight error in TX details (we can also consider activating those error dropdown pointing error line while hovering input too)
oh... btw here we should highlight ada row (as this is cause of an issue)

@alexander-rukin @danielmain @dmitrii-gaico thanks for your review and great suggestions. They're done, except the copy changes, which I've asked Nyamh to have a look.

"x" is not centered in the notification

you probably got me wrong, I suggested to make ada row red in TX details, not the dropdown

it also makes other balances red

isn't it possible to have a shift like in designs?

p.s. shouldn't it be "Ada" here and not "ADA"?)

distance looks too big

here design reference

isn't it possible to have a shift like in designs?

p.s. shouldn't it be "Ada" here and not "ADA"?)

@alexander-rukin what do you mean by "shift"? (For amounts we use the ticker, ADA)

isn't it possible to have a shift like in designs?

p.s. shouldn't it be "Ada" here and not "ADA"?)

@alexander-rukin what do you mean by "shift"? (For amounts we use the ticker, ADA)
Yes, for amounts "ADA", but for the line name I guess it should be still "ada" or "Ada" (if at the beginning of sentence)
As for the shift -> look at the vertical line position

isn't it possible to have a shift like in designs?

p.s. shouldn't it be "Ada" here and not "ADA"?)

@alexander-rukin what do you mean by "shift"? (For amounts we use the ticker, ADA)

Yes, for amounts "ADA", but for the line name I guess it should be still "ada" or "Ada" (if at the beginning of sentence)
As for the shift -> look at the vertical line position

@alexander-rukin done!

in the collapsed view it still lacks margin

hover effect here should be same as for the normal icon (increase opacity on hover)

scrollbars still look like this

not sure what caused this, but right end of a content is shifted to the left.  It needs to be Chrome

not sure what caused this, but right end of a content is shifted to the left. Content should end where button ends

Didn't understand.
This is how it looks to me:

Which browser are you using? It needs to be Chrome

I use Chrome Version 92.0.4515.159 (Official Build) (x86_64)

@daniloprates The fixes look good to me, but the issue that @alexander-rukin mentioned about the scroll is still visible (also using Chrome).

The scroll bar is only visible when scrolling with the mouse (can't click on it if you don't scroll first). Also, on hover, it looks bigger. Check this video.

btw I'd expect to see this error message when hovering bottom line in TX (same way as in previous cases)

@daniloprates The fixes look good to me, but the issue that @alexander-rukin mentioned about the scroll is still visible (also using Chrome).

The scroll bar is only visible when scrolling with the mouse (can't click on it if you don't scroll first). Also, on hover, it looks bigger. Check this video.

This is a default behavior for mac. You can change it globally here.
@gabriela-ponce @alexander-rukin I've fixed the different color for the data boxes. They're not as the main dialog. We may need to change the color for all dialog scrollbars, but I prefer to do that in a separated task, testing in the actual app, not only Storybook.

@alexander-rukin added the Ada error here as well 👇

for some reason “computed” line-height here (Ada line)  is 21px -> with 22px it looks better

all line-heights here 21px
I made all of them 22, so line-height = 22px, box-height = 22px
here on a screenshot look at the alignment:
line - 21px
red box - 22px, but shifted to the top
violet box - 21px and aligned with a text
p.s. left violet box just to see that red is bigger

btw receiver line-height seems to be 22, as it’s 44 in total ))

@alexander-rukin added the Ada error here as well 👇

did you push this?

Just noticed that "ADA" suffix has wrong styles - see https://zpl.io/2yDLwD9

I can see that scroll bar is not centered on your screenshot 😓

@daniloprates The fixes look good. Just a little comment about this tooltip. Wouldn't it look better to be displayed over the value (100.00000 in this case)?
I know the current implementation is also how it's done for the tokens, but I think it looks a little odd, as it's not clear what is pointing to.

@daniloprates The fixes look good. Just a little comment about this tooltip. Wouldn't it look better to be displayed over the value (100.00000 in this case)?
I know the current implementation is also how it's done for the tokens, but I think it looks a little odd, as it's not clear what is pointing to.

@gabriela-ponce nice suggestion. The only issue is that, because the Ada Amount element is narrow, it can be opened from the top, as it looks like this. From the left it works fine. @Alexander-rukin what do you think?

@gabriela-ponce nice suggestion. The only issue is that, because the Ada Amount element is narrow, it can be opened from the top, as it looks like this. From the left it works fine. @alexander-rukin what do you think?

I thought we can make the tooltip globally positioned. So it will just go out of bounds for dialog.
As for now, the tooltip points to the whole row which is an error one. If we want to change position and point exact error part, we will need to do this for every case here. Point amount when it's an amount problem. Point token box when "no such token in wallet" error. But still the whole row should be highlighted in red

@gabriela-ponce nice suggestion. The only issue is that, because the Ada Amount element is narrow, it can be opened from the top, as it looks like this. From the left it works fine. @alexander-rukin what do you think?

I thought we can make the tooltip globally positioned. So it will just go out of bounds for dialog.
As for now, the tooltip points to the whole row which is an error one. If we want to change position and point exact error part, we will need to do this for every case here. Point amount when it's an amount problem. Point token box when "no such token in wallet" error. But still the whole row should be highlighted in red

@gabriela-ponce @alexander-rukin reverted the side positioning

I like how you write clean code :) I just added some minor performance Issues when working with functional components. But overall very good!

Thanks, @danielmain. It's done


chore(docs): update path to correct cli project

Woops thanks :)

No problem. Just a side note: the cli generates some crazy artifacts including a strange tests/unit/services/myservice-test.js still so I am probably going to avoid using it for now.

Yes, I don't use it either now, I had to rename .css files to .scss and change the import in the components with a require for css / templates (so that it works with webpack).
I guess it's not ready yet.


Feature Request: UI tweaks in the Notification section of CM Settings

I don't know if other users have stumbled with this issue but since day one I've struggled a bit with looking at the notifications settings and knowing immediately what I'm actually tweaking. I reckon it's because all notifications are displayed in a row without separators making it less readable to the user.
I propose that for each notification there should be a title so that it makes easier to read for the user since it separates into categories.

This would be quite easy to implement, but I am not sure it would actually improve the UI.
It might actually clutter the UI even more.
Right now all toggles and sliders already include the name of the notification. Doesn't that tell you which setting you are tweaking? Or am I missing something?
Also note that the new version will include sliders for the volume settings, which also include a title of the settings that is being changed. As shown in the following screenshot:

This problem happens because the option that grabs my attention is the sound URL. This is due to the fact of being the only one that has always a white text. This is worsen by the fact that not every type of notification has the same number of options (e.g. Golden Cookie (6) options vs Max Magic (4) options) and the position of this option isn't always the last.
I reckon that one problem that might appear with this solution is that it can make the UI more cluttered. However, this could be solved if the sub-section text is smaller than the section text and bigger than the options text.
Also, having a sub-section with a tittle for each notification would shorten several options' descriptions which overall would require less text.  (e.g. "Fortune Cookie Notification").
Finally, by implementing sub-sections, each option would be compartmentalised, which would make the whole section easier to read. Going further with this idea, a hiding feature could be also implemented.

Yeah implementing it while also removing some texts from the labels seems to be the way to go forward.
Making them hide-able should also be an option.
Should not be too difficult to implement this, but I think for now I will not add this to the next version and save it for the one after that.

That's alright! These are just details after all so I think they can wait :D
Once again, thanks for the work you've been doing.

@ScriptForAll do you know how to load the dev-branch? If so, my latest pull request has implemented this.
What do you think of my solution?

Hmm, not really :sweat_smile:
I've tried to load from https://raw.githubusercontent.com/Aktanusa/CookieMonster/dev/CookieMonster.js but it did not work (it deployed a MIME error).
I assume I'm doing something utterly wrong :s
Care to explain how to do so? :D

You have gotten the correct link!
In the future we will provide a way to load it through the Game.LoadMod function. What you can do right now is copy all code that is in that link (ctrl + A should work) and past it into the console of your browser when you are on the Cookie Clicker page. Most browser-consoles upon up by right-clicking the page and clicking "inspect source" or something similar. Make sure CookieMonster is not already running as in that case it won't load the dev-version.

Okay, I didn't try to copy paste it into the console. I was using the Mod Loader so it deployed that error into the console, I guess.
I've tried it out and seems good for me. However, I have some questions:

Why are the "Favicon" and "Timer" options for the Golden Cookie under "Calculation"?
The timer bar options were all put together as one and moved. Personally, I don't have a problem with this but wouldn't some users want to choose which timers they want integrated?

Maybe you could keep the all-in-one Timer Bar option under "Bar/Colours" but having it tweaked under "Notifications" (i.e. being able to choose which timers you want to see).

I moved the FavIcon and Timer settings to Calculation as they didn't fit into Golden Cookie Notifications, but you are right Calculation is also not the right place. I might move them once again to another category, or make a new one for them.
What do you mean with the timer bar options? I guess you are referring to the fact that there is no longer a limit in the number of timers so now every form of buff gets a timer? If that is the case, I agree that this is not the optimal solution. With #388 I intend to rewrite all of the code for the TimerBar and possibly make the different timers configurable. I am not sure about the approach yet as I need to take a better look at the current code and possible new implementations.
For now I was rewriting/annotating most of the graphics code and stumbled upon the TimerBar and thought it would be a quick fix to make it possible for more than 4 timers to appear.

Damn, I got confused, my bad. I thought that GC Timer was a Timer Bar tweak which isn't true.
I was about to change my reply but I now I'm too late :sweat_smile: .
Either way, I do agree that choosing which buffs get to appear on the Timer Bar is the way to go.
With that said, I don't think I have anything else to say regarding this closed issue.
As always, thanks for the work! :+1:

No problem, if you have any suggestions for categories of buffs please add them to the thread of #388.
I do not really play cookie clicker anymore (I just like this project to improve my coding) so I don't know which categories might feel most natural.
I never encounter more than 2 buffs at a time anyway so for me cluttering the TimerBar is not even a real issue, but I have seen pictures of people having 10+ buffs which would certainly break the current code of TimerBar


[5.4] Allow easy overriding of ServiceProvider configuration merging

I put this together after seeing #16991. Requests for recursive merging have come up several times and I thought this could be a good solution to allow for more advanced merging when needed.
If mergeConfig is not overridden in the ServiceProvider it will function exactly as it did before by doing a top-level (non-recursive) merge.
I have had several projects in the past where I needed to merge settings. In most cases a simple array_merge was sufficient, but sometimes I would need to have more control over nested values. Instead of using a catch-all solution that would automatically merge items recursively, I found it much easier to override the rare occurrences and handle them individually.
Example based on #16991:
package/src/ServiceProvider.php
<?php

namespace App;

use Illuminate\Support\ServiceProvider;

class TestServiceProvider extends ServiceProvider
{
    /**
     * @inheritDoc
     */
    protected function mergeConfig($key, array $baseConfig, array $mergeConfig)
    {
        // merge all the values like normal
        $config = parent::mergeConfig($key, $baseConfig, $mergeConfig);

        // merge the individual nested values as needed
        $config['other'] = array_merge($baseConfig['other'], $mergeConfig['other']);

        return $config;
    }
}

config/package.php
<?php

return [
    'example1' => true,
    'other' => [
         'config1' => true,
         'config2' => true,
    ]
];

package/config/main.php
<?php

return [
    'example1' => false,
    'example2' => false,
    'other' => [
         'config1' => false,
         'config2' => false,
         'config3' => false,
    ]
];

test it out
$this->mergeConfigFrom('package/config/main.php', 'package');
dd(config('package'));

result
array:3 [▼
  "example1" => true
  "example2" => false
  "other" => array:3 [▼
    "config1" => true
    "config2" => true
    "config3" => false
  ]
]

👎 from me. Just as easy to just override the whole method tbh.

I thought the same thing too until I took a closer look at the mergeConfigFrom method and saw that the code to load the configurations would need to be duplicated. This way the method that needs to be overridden only handles the merging and not loading anything.

the code to load the configurations would need to be duplicated

Meh, it's only one line.


Unexpected ORM and UI behavior when modifying an Interface and adding a Cable

Environment

Python version: 3.8
Nautobot version: 1.0.2

Use Case
I have a workflow where I need to make several changes to Interface objects and additionally connect two Interface objects via a Cable object. Because creating a Cable object modifies the connected Interface objects, the Interface objects being changed and the UI behavior can have unexpected results if a strict order of operations is not followed. Potential issues are an Interface's Cable and Connection fields/columns are overwritten/hidden. The process below will:

Create a new Cable between two interfaces,
Call validated_save() on one of the interfaces used to establish the connection (without refreshing from the database)
Call validated_save() on the Cable object created

Results will show that the Cable/Connection(Path) data will fluctuate between these three states.
Steps to Reproduce

Get Devices that will have a Cable Connected

user01 = Device.objects.get(name="user01")
user02 = Device.objects.get(name="user02")

Get Interfaces that the connection will be created over

user01_eth1 = user01.interfaces.get(name="Ethernet1/1")
user02_eth1 = user02.interfaces.get(name="Ethernet1/1")

Get status and content-type for creating Cable

ct_dcim_interface = ContentType.objects.get_for_model(Interface)
status_planned = Status.objects.get(slug="planned")

Create the Cable between the two interfaces

cable = Cable(
    termination_a_type=ct_dcim_interface,
    termination_b_type=ct_dcim_interface,
    termination_a_id=user01_eth1.id,
    termination_b_id=user02_eth1.id,
    status=status_planned, type="smf"
)
cable.validated_save()

Call validated_save on user01_eth1 interface object existing before cable was created

user01_eth1.validated_save()

Call validated_save on cable created above

created_cable = Cable.objects.get(id=cable.id)
created_cable.validated_save()

Expected Behavior
I did not anticipate creating a Cable would modify the Interface Objects
I expected the Cable and Connection(Path) to not be affected, or at least be consistent across interactions.

Observed Behavior
The presence of Cable and Connection(Path) data is overwritten depending on what is being saved
I logged the differences of the interface attributes between actions (I just used the Interface objects dict attribute for comparison)
Differences between interface objects before and after creating the cable
* field: cable_id
    pre-cable value: None
    post-cable value: 720e8cc3-0671-4a55-8ad0-9aa97102648c
* field: _cable_peer_type_id
    pre-cable value: None
    post-cable value: 37
* field: _cable_peer_id
    pre-cablevalue: None
    post-cable value: 07f7a05d-d547-4d76-acf7-6e979937814b
* field: _path_id
    pre-cable value: None
    post-cable value: abf0a2aa-a7f1-475f-8aff-eac6de542b55

Summary, creating a cable adds values to the following fields:
  * cable_id
  * _cable_peer_type_id
  * _cable_peer_type_id
  * _path_id

Differences between Interface fetched after creating the Cable and saving the pre-fetch Interface object
used to create the Cable without syncing with database
* field: cable_id
    post-cable value: 720e8cc3-0671-4a55-8ad0-9aa97102648c
    post-interface-save value: None
* field: _cable_peer_type_id
    post-cable value: 37
    post-interface-save value: None
* field: _cable_peer_id
    post-cable value: 07f7a05d-d547-4d76-acf7-6e979937814b
    post-interface-save value: None
* field: _path_id
    post-cable value: abf0a2aa-a7f1-475f-8aff-eac6de542b55
    post-interface-save value: None

Summary, saving the prefetched Interface object without syncing to the database after creating a Cable
reverts the 4 above fields back to their original value (None in this example)

Differences between saving the pre-fetch Interface object used to create the Cable without syncing
with database and saving the Cable object after the Interface save reset the values back to None.
* field: cable_id
    post-interface-save value: None
    post-cable-save value: 720e8cc3-0671-4a55-8ad0-9aa97102648c
* field: _cable_peer_type_id
    post-interface-save value: None
    post-cable-save value: 37
* field: _cable_peer_id
    post-interface-save value: None
    post-cable-save value: 07f7a05d-d547-4d76-acf7-6e979937814b

Summary, saving the cable syncs 3 out of 4 of the above fields, but _path is left as None
(This shows up in the UI, see screenshots):
  * cable_id
  * _cable_peer_type_id
  * _cable_peer_id

I have attached screenshots as well to demonstrate how this behavior shows up in the UI.
image 1: Creating the cable shows up connected in DCIM > Device > Interfaces as expected

image 2: Saving the pre-fetch Interface object removes the Cable and Connection columns from the UI (as above, those fields were set back to None)

image 3: The device that had the Interface that was not saved after creating the Cable still shows as expected in DCIM > Device > Interfaces, since this Interface object did not call a save method, the fields were not set back to None

image 4: The DCIM > Cable view shows the Cable connected to both sides as expected

image 5: Saving the Cable causes the Cable connection to reappear in DCIM > Device > Interfaces, but since _path is not set back, the Connection column is still blank.

My personal opinions/feedback:

It is not obvious that creating a Cable changes Interface attributes (cable_id, _cable_peer_type_id, _cable_peer_type_id, and _path_id).
Current process to configure an Interface via the ORM is not clear nor desirable

create an Interface object for termination_a
create an Interface object for termination_b
create a Cable object for termination_a to termination_b and save it
refresh Interface object from database for termination_a
refresh Interface object from database for termination_b

It seems strange that calling save to an existing Cable Record syncs cable_id, _cable_peer_type_id, and _cable_peer_type_id, but not _path_id.

Thank you for the detailed report and analysis! A few thoughts:

Changing the cable/cable_id on an Interface to None should probably either 1) be disallowed or 2) result in the previously assigned Cable being deleted.
The fact that _path_id isn't restored when saving a Cable feels like a bug to me, even if addressing the previous item makes this moot.

Add some docs to the relevant models (cable, interface) to explain when to use refresh_from_db to prevent your instance being out of sync with the database

If it can be done in under 3 points, also document any other models where a presave/postsave signal could modify the object in memory